►
From YouTube: WG API Expression Bi-Weekly Meeting for 20200818
Description
WG API Expression Bi-Weekly Meeting for 20200818
A
A
All
right,
I
added
this
after
daniel
mentioned
it
or
mentioned
us
on
github,
there
was
a
question
for
how
people
could
validate
api
types
that
are
are
being
used
from
a
gold
types
like
if
you
use
the
pot
spec
in
your
crd,
how
you
could
validate
that-
and
it
was
discussed
a
bit
in
here
and
then
somewhere
here,
okay,
I
said
we
should
look
at
it
or
we
could
look
at
it
and
I
just
added
it.
A
B
I
I
I
would
at
very
least
like
to
note
that,
like
the
suggested
solution
of
like
just
call
dry
run,
isn't
particularly
user
friendly,
like
there's
a
relatively
high
activation
energy
for
setting
up
a
validating
web
hook
like
even
even
with
tooling,
to
help
you
like
there's
a
lot
of
extra
things
to
coordinate
there
so
like,
while
that
is
like
technically
viable,
it's
not
the
best.
A
A
C
I
I
did,
I
started
to
try
and
audit
the
validation
across
a
bunch
of
built-in
types
understand
like
my
goal
was
just
to
understand
what
kind
of
validation
we're
actually
doing
in
the
in
the
functions
that
are
handwritten
in
the
kubernetes
code.
To
see
what
patterns
are,
what
could
potentially
be
like
transferred
from
being
handwritten
functions
to
being
declarative
comment?
You
know
declarative
information
on
schemas
that
could
be
then
leveraged
by
anything
that
consumes
open
api.
C
There
is
a
lot
of
stuff
that
could
go
through
like
everything
I
looked
at.
There
was
a
fairly
substantial
percentage
of
the
validation
rules
were
really
bucketed
down
into
really
simple
things
that
you
could
easily
express
with
open
api
right.
Like
I
exp,
a
lot
of
them
are
actually
these
kind
of
format
rules.
I
expect
this
string
to
adhere
to
this
formatting
rule
like
some
dns
name,
rule
or
some
kind
of
quantity
or
time
or
something
like
that.
That
was
really
common.
C
C
A
Yeah
I
it's
it
would
be
like
I
I
I
had
a
comparable
situation
with
with
the
status
wiping
stuff
it
would
be
pretty
cool
to
have.
I
guess
that's
quite
work
to
compile
to
have
a
a
a
list
of
thing
or
general
overview.
What
we
already
could
do
like
if
it's,
if
it's
worth
the
trouble,
if
it's
the
majority
of
fields
and
then
mostly
fields
that
are
commonly
used
or
types
because
then
we
could
show
that
we
could
implement
that.
C
C
I
think
we
could
get
a
ton
of
mileage
about
putting
stuff
in
open
api
based
on
what
I've
seen,
but
maybe
maybe
in
a
future
meeting.
I
could
try
and
go
over
my
findings
so
far
in
more
detail.
I
could
try
and
organize
it.
C
Adding
stuff
there
I
mean,
there's,
there's
a
symmetry
to
like
a
lot
of
fields
have
defaults
and
a
lot
of
fields
have
validating
rules.
I
feel
like
there's
like
this
kind
of
like
they're
they're,
both
these
things
that
you
might
want
to
annotate
about
a
field
I
feel
like
the
validating
ones.
Many
of
them
are
actually
even
more
basic
because,
like
a
lot
of
them
are
just
very
simple,
like
this
string
is
not
just
a
string,
it's
a
string
that
may
only
contain
an
x
ever,
and
so
it's
very
straightforward.
C
C
There
are
there's,
there's
multiple
classes
of
them
right,
like
not
all
validating
rules
are
simple,
but
there
are
a
bunch
that
really
are.
In
fact,
really.
You
could
argue
from
a
type
perspective
that
some
of
them,
the
type's,
not
even
really
a
string.
The
type
is
something
else,
and
it
just
happens
to
be
represented
as
historic.
We
don't
currently
think
of
it.
That
way,
but.
B
A
B
B
Actually,
I
should
I
should
clarify
it's
impossible
to
properly
dot.
Quantity
itself
is
actually
impossible
to
properly
decoratively
specify
because
it's
actually,
according
to
the
api
server
the
way
the
api
server
is
supposed
to
accept
it.
It's
into
or
string
or
float
yeah
and
the
float
gets
converted
back
into
a
string
which
is
not
something
that
can
be
represented
in
crd,
structural
schemas.
C
C
B
Yeah
I
mean
we
can
like
you:
could
we
could
probably
put
annotations
about
validation
on
the
type
itself.
Similarly,
to
the
way
controller
controller,
gen
and
controller
tools
expects
it.
B
I
think
the
hard
thing
here
is,
I
would
be
surprised
if
we
don't
discover
a
few
more
cases
like
like
resource
dot
quantity,
where
it's
like
just
we've
constructed
rules
for
our
crds.
B
That
mean
we
literally
can't
express
built-in
built-in
types
in
crd
open
api
which,
like
I,
I'm
wary
of
solutions
that
that
that
just
involve
what
we
do
today
with
more
with
more
open
api.
Like
that's
a
good
starting
point,
but
I
I
have
a
suspicion
that
we're
going
to
need
to
tackle
something
more
complicated,
eventually.
C
Yeah,
I'm
worried
about
that
too.
It
feels
like
open
api
was
selected
as
a
thing.
It
would
work
without
any
like
really
rigor
to
determine
whether
or
not
it
is
there.
There's
like
a
fundamental
impedance
mismatch
there,
and
I
don't
know
I
feel
like
there's
a
abstract
notion
of
the
schema,
that's
kind
of
hidden
behind
everything
that
would
make
sense
that
we're
just
trying
to
like
materialize
out
into
this
more
constrained
format.
A
B
Client,
client-side
validation
is
pulled
from
the
open
api
spec
published
by
the
api
server.
But
it's
you
know
it's
not
all
of
the
validation
right.
Okay,
it's
it's!
It's
not.
In
fact
it's
not
there's
not
at
nearly
as
much
of
it
as
as
what
we
do.
Server
side.
A
All
right,
so
it's
it's
already.
We
provide
something,
that's
already
incomplete
and
we
we
will
also
improve
on
that
when
we,
if
we
fixed
it.
A
Okay,
does
anybody
have
something
to
add
or
if
we
couldn't
update.
C
I
would
definitely
think
I
definitely
feel
like
that's
an
area
where
there's
some
help
wanted,
so
we
might
want
to
make
a
note
of
that
explicitly.
Yes
right
now,
I
think
we've
got
like
a
yeah.
I
think
we
all
can
agree
that
there's
a
lot
to
be
done
there
yeah,
nobody
actually
actually
really
dedicating
time
yet
as
far
somewhere.
C
No,
it's
really
not,
and
but
there
are,
there
are
different
sizes
of
useful
tasks
that
could
potentially
be
done.
There
yeah,
you
could
kind
of
bite
off
as
much
as
you
can
chew,
and
have
plenty
to
do.
A
C
I
know
there
was
a
early
version
of
a
cat
being
worked
on,
so
there's
been
quite
a
bit
of
progress
on
this.
A
A
I
still
have
a
problem
with
crds
and
crs
that
don't
behave
as
I
expected
them
to
behave
for
non-clear
reasons
so
far.
I'm
I
have
to
look
into
it
again,
but,
aside
from
that,
it
looks
almost
good.
I
still
have
some
stuff
to
do
like
adding
the
the
code
that
decides
which
for
fields
to
do
disabled
for
parts
based
on
features.
That's
a
lot
of
features
parts
can
this
can
can
respect
when
wiping
fields?
It's
it's
a
bit
messy
yeah
there's
there
was
some
progress.
C
Oh
great
here
is
there
anything
that
you're
blocked
on
review
for.
A
The
crd
is
working
and
well
there's
the
so.
There
is
still
some
open
stuff
and
I
I
wrote
in
a
comment
in
the
pr
somewhere.
It's
highly
recommended
to
commit
by
commit
because
every
commit
contains
one
resource
is
being
changed.
Otherwise,
you'll
have
to
read
through
a
lot
of
files.
That's
not
really
enjoyable,
but
if
you
want
to
look
at
it,
I
wouldn't
mind
more
pairs,
advice.
C
Api
clients,
so
we
took
this
to
api
machinery
and
I
think
we
got
some
good
feedback
there.
I'll
just
give
a
30
second
summary,
which
was.
C
We
would
like
to
see
a
prototype
using
the
builders,
we're
not
exactly
sure
what
the
the
formulation
that
would
be,
but
like
basically,
somehow
use
the
builder
pattern.
Don't
do
it
in
case
kate's,
yet
as
like
an
official
thing
but
build
a
prototype
somewhere.
Get
identify.
Community
members
and
remember
silly
had
mentioned
last
time
that
some
of
the
controller
runtime
group
might
be
willing
to
try
things
out.
So
I
think
the
goal
is
to
find
find
people
that
are
willing
to
try.
C
It
get
them
to
actually
try
it
get
meaningful
feedback
and
then
then
iterate
from
there.
A
D
A
C
Tools-
I
haven't
any
opinion
about
that
yet,
but
if
you
have
an
opinion
talk
to
jenny,
we'll
kind
of
identify,
I
don't
think
we're
gonna
build
a
new
repo.
At
this
point,
I
think
we
might
just
try
and
like
open
a
pr
that
we
don't
merge
into
another
repo
for
now
and
get
started
that
way.
A
C
Yeah
also
took
it
to
apm
machinery
and
the
feedback
was.
We
would
like
to
see
a
couple
alternative
designs
and
how
they
work
out.
So
I'm
going
to
try
and
sketch
those
up
this
week.
One
would
be
to
put
the
tombstone
information
into
the
into
the
unmanaged
fields
of
data
directly
so
that
you
don't
modify
the
main
object,
but
you
just
extend
what
the
manage
field
state
has.
C
The
other
one
was
to
have
some
kind
of
like
negative
object,
representation
that
represents
everything
you
believe
should
be
excluded
from
the
object
as
like
a
separate
yaml.
So
like
dash
dash
dash
more
yammel
or
something
in
the
request.
I
don't
know
it's
just
a
brainstorming
idea.
I'm
gonna
look
at
both
of
those
ideas
and
update
the
doc,
and
then
I
will
circle
back
with
everyone.
A
C
But,
okay,
I
think
maybe
both
were
on
the
table.
I
think
there
was
even
a
third
one
that
anthony
was
thinking
where
you
even
had
a
different,
a
different
like
object
that
you
modified.
That
was
the
negative,
so
I
think
there's
multiple
different
ways
to
express
that
the
negative
object.
Maybe
I
will
list
out
the
alternatives
and
see
which
one
maybe
works
out.
That's
the
most
pleasing
of
those
three
and
then
we
should
have
three
major
designs
to
consider.
C
All
which
are
probably
gonna
have
downsides,
but
at
least
we'll
have
alternatives.
A
C
A
All
right,
I
saw
some
more
comments
on
the
creative
plan
for
executive
fields.
I
hate
talks
there
are
going
on
if
somebody's
here
wants
to
discuss
with
more
now's
the
time.
C
My
only
thought-
and
I
think
this
is
already
expressed
a
little
bit-
was
that
there
seems
to
be
two
problems
being
solved.
One
is
just
that:
how
do
you,
how
do
you
deal
with
the
basic
like
optimistic,
concurrency,
problem
of
of
conflicts
and
then
the
other
one
is
kind
of
this
bigger
like?
How
do
you
support
some
kind
of
plan
feature?
C
I
don't
have
this.
I
don't
know
nearly
as
much
about
the
idea
of
a
plan
feature,
but
the
I
think
antoine
has
proposed,
I
think,
a
fairly
simple
kind
of
optimistic
and
currency
control
mechanism,
which
is
basically
very
similar
to
how
we'd
already
do
it
in
an
update,
except
for
that.
Our
our
token
is
not
the
resource
version.
It's
some
other
token.
C
A
A
Yeah
yeah.
No,
no.
I
write
the
situation
kind
of
sound
a
bit
like
yeah,
like
you're,
like
you're,
sending
a
a
like
cash
in
using
the
hash
you
you
saw
before
and
if
it
doesn't
fit,
something
else
happens.
C
A
Yeah
I
like
that
one
all
right,
then:
let's
keep
that
discussion
open
and,
let's
see,
is
two
more
mike
here.
No,
so
I
think
we
have
no
update
on
the
documentation.
A
A
Okay,
no
no
you're!
I
I
saw
your
prs
okay,
yeah
close
there
to
go.
D
I
think
it's
pretty
much
done.
I
think
daniel
reviewed
it
yesterday
and
I
don't
know
a
new
comment
and
that
should
be
it.
Let's
see
if
it's
gonna
be
merged
as
soon
as
the
last
review
is
made.
A
A
You
were
asking
about
shop,
research,
stuff,
I
don't
know
I
sent
one
here.
No,
no!
So
I
remember
some
stuff.
Some
parts
about
the
scales
of
research.
D
Yeah
I've
just
I've
just
picked
that
at
random.
Basically
because
it
reminds
me
a
little
bit
of
my
work
in
that,
but.
A
I
I
came
across
it
to
do
the
code
while
adding
the
status
up
resource
stuff
to
crds,
and
I
I
really
don't
remember
what
it
was.
I
guess
antoine
might
remember
it.
I
don't
know
if
we
have
any
other
stuff
explicitly
market
help
needed
so
higher.
Maybe.
A
A
I'm
lost
here
yeah.
This
one
is
an
expert
health
needed.
We
don't
have
anything
new
on
it.
I
think
what
is
that.
A
C
Oh
yeah,
so
I've
actually
been
working
directly
on
this
sorry,
I
was
looking
at
something
yeah,
so
I
have
a.
I
have
a
pr
that
fixes
this
and
we
were
about
to
roll
it
out
into
kubernetes
when
we
made
the
observation
that
existing
data,
so
if
you've
already
done
an
apply,
and
then
I
change
this
annotation
on
the
type
that
you
end
up
in
a
bit
of
a
weird
state.
So
I'm
following
up
with
that,
but
basically,
what's
going
to
happen,
is
you're
going
to
be
able
to
annotate
directly
on
any
struct.
C
That
is
an
atomic
you
can't
annotate
on
the
references
or
the
the
usages
of
it.
That's
true
today,
so
we're
just
adding
the
ability
to
directly
like
say
a
label.
Selector
is
a
struct
is
an
atomic
struct.
What
that
means
is
when
you
modify
a
label
selector,
you
modify
the
whole
label
selector.
C
It
turns
out
that
they
don't
merge
very
well
they're
fairly.
Atomic
is
a
unit
like
we
don't
expect
collaboration
on
them,
so
I
think
it
all
makes
sense,
but
there
I'm
prototyping,
to
see
if
I
can
fix
the
problem
where,
if
somebody
had
had
applied
a
label
selector
before
we
make
this
change,
and
then
we
make
this
change
that
we
don't
end
up
like
orphaning,
a
bunch
of
field
data
forever,
and
we
don't
end
up
like
missing
conflicts
that
we
should
have
gotten.
C
C
We
don't
really
deal
with
the
fact
that
you
can
make
unchanged
you
can
make
conversion
changes
to
schemas
like
you
can
have
v1
of
the
schema
and
go
in
and
change
certain
things
about
it,
and
some
of
those
are
actually
pretty
valid.
Changes
are
really
going
to
happen,
especially
in
series,
and
when
that
does
happen,
the
managed
fields
become
out
of
sync.
C
So
this
is
a
manifestation
of
that
problem,
a
very
specific
one,
and
so
I'm
going
to
do
a
prototype
I'll
come
back
and
let
people
know
that.
But
I
think
this
is
fixable.
It's
just
a
question
we
can
do
it.
A
He
said,
would
that
mean
we
should
we
would
help
to
have
like
a
our
own
version
or
hash
of
the
currently
used
schema
in
the
managed
fields.
C
Yeah,
that's
one
of
my
proposals
is
that
we
somehow
like
basically
in
the
managed
fields
that,
in
addition
to
saying
which
version
you're
at
like
v1,
we
also
have
a
hash
of
the
exact
state
of
the
schema.
Because
then
you
could
check
to
see
if
anything
about
the
schema
has
changed,
and
only
then
you
could
like
apply
certain
like
amount
of
fix
up.
C
A
C
In
scd
completely
invalid,
but
at
least
for
a
subset
of
changes
which
are
legal
and
are
pretty
sane
like.
Oh,
I
forgot
to
make
this
thing
atomic.
Let's
just
fix
it.
Those
kinds
of
changes
like
some
of
them
are
possible
to
fix
up
and
for
those
I'd
like
to
see
if
we
can
actually
do
something
reasonable,
because
the
the
problem
we're
having
in
kubernetes
with
labels.
So
after
kind
of
highlights
that,
like
we,
don't
always
get
this
right
and
when
we
do
have
it
wrong,
we
probably
need
the
way
to
fix
it.
A
C
C
You
can
only
mark
it
on
the
usage,
which
makes
sense
because,
like
that's
kind
of
how
it
works,
but
if
it's
direct
right
now
you
can't
do
anything,
and
so
what
I'm
doing
is
planning
to
initially
just
add
support
for
adding
the
annotation
on
the
struct
itself,
because
I
think
that's
usually
what
you
want,
like
you
define
the
structure,
define
the
formal
time,
but
you
should.
You
should
be
able
to
say
how
that
type
works
in
the
future.
C
If
we
ever
needed
to
stay
at
the
at
the
usage,
if
the
rules
should
be
different,
we
could
add
support
for
that
later
and
then
we'd
have
to
figure
out
what
the
rules
are
for,
if
there's
a
annotation
on
both
usage
and
the
struct
itself,
if
there's
a
priority
rule
or
if
that's
a
conflict
or
what
happens,
but
now
I
don't.
I
don't
really
need
to
deal
with
that.
So
I
was
going
to
do
the
basic
thing
of
just
add:
support
on
the
strike
itself.
A
C
Yeah
yeah-
and
this
is
what
I'm
actively
working
on
so
yeah.