►
From YouTube: WG API Expression BI-Weekly Meeting for 20200623
Description
WG API Expression BI-Weekly Meeting for 20200623
A
B
Yeah,
absolutely
so
I
I
I
like
many
of
you
work
on
a
number
of
operator
projects
in
addition
to
the
api
machinery,
and
what
have
you
the
different
projects
we
can
include
cube
builder
as
well
as
operator.
Sdk
have
had
a
number
of
issues
hitting
them
lately
of
those
developers
that
have
upgraded
to
118
as
their
underlying
set
of
libraries.
B
kind
of,
was
ahead
of
any
validation
or
defaults.
If
you
will
in
the
core-
and
so
so,
I
guess
setting
the
stage
make
sure
the
context
is
set
anytime
you're,
creating
a
crd
that
might
use
existing
core
types.
A
validation
failure
will
occur,
saying
that
those
core
types
do
not
have
defaults
and
the
defaults
in
the
core
tend
to
be
comments
and
are
managed
through
code,
and
so
I
thought
I
would
start
a
conversation
here
being
directed
here
in
a
couple
of
places.
B
B
B
I
know
that
there's
other
defaults
that
might
be
determined
by
a
couple
of
properties
and
those
might
be
more
challenging
to
articulate
so
that
I'm
just
opening
up
the
conversation.
I
would
love
to
know
what
to
do.
I'm
more
than
happy
to
invest
time
and
energy
creating
a
cap.
If
that's
where
we
need
to
go
with
it.
C
B
What
happened
is
you
know?
Ideally
the
timing
of
these
things
would
be
coordinated
in
some
way,
and
I
you
know
the
challenges
that
you
run
in
computer
science
in
general.
Are
when
mean
you
know
meaningfully
positive
features,
intersect
intersect
in
some
way,
so
the
things
that
intersected
here
kind
of-
and
I
don't
know-
I
don't
know
enough
information
to
know
if
it
was
intentionally-
I
mean
if
it
was
thought
out
if
it
was
imagined
or
whether.
B
Depends
on
what
you
mean
if,
if
somebody
creates
crds
that
do
not
use
anything
other
than
their
own
defined
types,
then
there's
nothing
really
broken.
Also.
What
we're
also
talking
about,
I
believe,
is
we're
talking
about
something
that
they
might
be
able
to
fix
on
their
own
we're
talking
about
code
generation.
The
problem,
though,
is
that,
with
cube
builder
or
with
operator
sdk,
when
the
generated
crds
are
generated,
form
core
types
and
included
in
the
open
api
schema
for
validation
and
crd.
B
A
B
C
B
C
So
let
me
tell
you
what
we're
doing
that?
Maybe
it's
gonna
help
jenny
is
working
on
making
the
slash,
slash,
plus
default
that
exists
in
keybuilder.
You
know
these
flags
specifically
she's
making
it
so
that
this
this
is
going
to
work
for
core
types,
so
we
are
going
to
have
the
code
types
have
the
slash
default
and
the
static
default
be
specified
directly
there,
and
so
we
are
going
to
have
the
default
for
the
tcp,
for
example,
for
the
protocol,
and
this
will
fix
this.
This
specific
l.
D
C
Yeah
I
mean
the
thing:
is
that
okay,
the
for
the
map
keys?
We
do
believe
that
they
should
be
required.
Technically
I
mean
they
can
have
a
default,
but
I
think
they
should
always
be
required
if
it's
a
key
that
should
be
required.
We
happen
to
have
the
protocol
being
defaulted
and
being
a
key
for
potspec.
I
think
that's
sort
of
unfortunate,
so
we
have
to
say
okay,
it
can
be
either
defaulted
or
required,
but
we
don't
have
a
good
way
to
statically.
D
C
D
D
C
Yeah
yeah,
so
eventually
we
should
have
the
same
test
as
this
in
the
kubernetes
repository,
so
that
when
anybody
writes
a
type
in
go
for
the
code
types,
we
know
if
they're
creating
a
list
map
keys
of
multiple
keys
or
with
a
key
that
is
neither
defaulted
now
required.
We
should
be
able
to
validate
that
within
the
kubernetes
like
four
built-in
types,
but
for
that
we
need
the
support
for
default
and
that's
exactly
what
jenny
is
doing.
C
D
A
D
Yeah
I
mean
my
my
intuition
is
that
most
of
the
time
and
correct
me
if
I'm
wrong
in
my
thinking
here,
is
that
if
you
define
an
object-
and
you
omit
default
fields,
that
it
should
usually
be
valid,
because
that
is
something
you
can
validly
send
to
a
server
and
have
it
default
everything
for
you,
so
that
my
intuition
is
that
usually
should
be
valid,
and
I
can't
really
besides
this.
I
can't
really
think
of
any
cases
where
that
shouldn't
be
true.
B
D
A
D
Yeah,
if
I
understand
right
here,
what
we're
having
we're
expecting
we're
expecting
crd
validation,
which
is
schema
based
validation
to
pass,
which
is
kind
of
like
the
same
thing
you
could
do
on
the
client
right.
You
could
take
the
open
api
spec
and
validate
an
object
against
it
and
what
we're
saying
is:
there's
an
object.
What
we
believe
is
be
valid,
because
one
of
the
map
keys
is
going
to
be
defaulted,
so
that's
typically
valid.
But
if
you
look
at
it
from
an
api
perspective,
it's
no
longer
valid.
D
C
D
C
C
C
Yeah,
it's
interesting
because
when
I,
when
we
thought
about
this,
we
thought
okay
well.
So
if
you
use
servers
at
a
play,
it
means
that
people
are
going
to
have
to
specify
the
protocol,
which
is
annoying
but
not
the
end
of
the
world,
but
yeah
I
mean
it
was
going
to
prevent
people
from
creating
clds.
D
C
B
D
C
D
D
Are
okay
yeah,
so
I
think
I
think
you're
just
the
the
the
hero
most
willing
to
come
up
and
champion.
This
has
been
a
problem
and
there's
a
bunch
of
other
people
that
are
silently
laying
at
their
cube
computers
right
now,
I'm
not
sure
well
how
this
came
to
be,
but
yeah.
It
was
it's
something
that
was
yeah.
I'm
kind
of
worried
about
that.
Okay!
Well,
thank
you
for
bringing
it
to
us.
E
So
I
I
went
and
found
one
and,
let's
see
so
in
you
know,
I
just
took
a
couple
examples
and
just
looked
at
them
and
I
found
cases
where
you
know
again:
there
was
the
dot
empty,
curly
brackets
and
then
everything
below
it
was
also
specified,
and
it
seems
to
me
that's
just
unnecessary
if
you
say
dot
curly.
That
means
everything
below
it.
There's
no
need
to
also
go
ahead
and
say
everything
below
it
list
out
all
the
things
below
it.
E
I
don't
know,
look
what
I'm
saying
is
look
what's
actually
in
the
managed
fields.
I
don't
care
how
it
got
there,
but
we
know
how
it
got
there
right
you
put
stuff
in
there
if
it
was
specified,
so
we're
not
talking
about
defaulted
fields.
Here,
I'm
saying
there
are
examples
where
the
fields
are
all
specified.
C
E
E
C
D
D
He
was
skeptical,
how
much
actual
benefit
you
might
get
from
it.
Not
that
it's
not
right.
It
is
right,
but
the
urgency
and
the
actual
in
practice
benefit.
I
think
he
was
questioning.
I
I'm
not
I'm
not
totally
sure.
I
have
a
good
enough
understanding
of
the
types
to
have
a
say
on
that,
but
I'm
certainly
at
least
something
to
think
about
here
is
like
yeah.
E
E
C
E
E
E
You
know
it
goes
on
and
on
and
on
you
know,
you
guys
seem
to
be
saying
that
if
I
want
the
default
security
account,
I
have
to
actually
write
it
in.
If
I
want
the
default
value
for
host
networking,
I
have
to
actually
write
it
in
and
on
and
on
and
on,
okay
you're,
actually
imposing
a
big
new
burden
on
developers.
I
guess
my
focus
is
on
people
writing
controllers.
You
guys
seem
to
be
thinking
maybe
about
people
using
kube
control,
but
it's
a
burden
on
them
too.
C
C
E
C
E
Sorry
we
could
optimize.
It
say
here
are
the
additional
things
that
I
care
about
that
didn't
bother
to
specify,
so
we
can
infer
the
things
that
are
written
down
that
are
specified.
The
question
is
things
that
are
not
written
down.
We
don't
really
know
whether
you
care
about
or
not,
I
think,
yeah
incorrect
to
infer
that
you
don't
that
the
developer
doesn't
care
about
them.
E
When,
for
example,
well
as
development
happens
in
in
future,
releases
fields
are
added,
typically,
that
have
semantics
that
engage
additional
functionality
and
it's
actually
probably
and
a
little
difficult
to
know.
You
know
whether
developer
for
release
x
wanted
functionality
that
was
introduced
in
release
y
or
not
wanted
the
absence
of
this
functionality
or
didn't
care
about
it.
But
I
would
say
the
most
likely
conclusion
is
that
he
didn't
want
it
because
he
knew
he
wasn't
getting
it.
C
But
I
I'm
still
a
little
bit
focused
on
the
on
the
first
point:
sorry
about
that,
it's
difficult
for
me
to
switch.
I'm
still
thinking
that
if
we
want
people
to
specify
the
part
and
they
do
care
about
the
protocol,
wouldn't
it
be
awkward
for
them
to
specify
somehow
that
they
care
about
the
protocol
without
having
to
actually
type
the
value
for
the
protocol.
E
Yes,
actually
I
agree
this.
This
is
I'm
not
actually
sure
this
is
the
best
suggestion,
I'm
just
saying
I'm
pretty
confident
that
inferring
that
the
developer
or
author,
whatever
it's,
whether
it's
a
person
or
a
controller
inferring,
that
it
doesn't
want
to
own
something
that
wasn't
specified.
I
really
think
that's
incorrect.
E
C
E
E
That's
a
kind
of
an
interesting
question
here
about
this,
so
I
mean
just
thinking
through
examples
right
so,
for
example,
a
person
uses
cube
cuddle
to
submit
a
deployment
object
that
has
a
set
of
containers
and
no
init
containers
and
in
this
cluster
istio
is
deployed
and
istio
adds
an
init
container
right.
Is
that
a
contradiction
or
not
because
the
the
person
who
wrote
the
deployment
said
he
he
didn't,
want
any
knit
containers
but
he's
willing
to
let
the
cluster
add.
E
You
know
whatever
gets
added
for
istio
or
maybe
there's
other
systems
like
it
that
you
know
add
in
in
containers
or
maybe
side
car
containers
that
are
that
are
that
run.
You
know.
I've
seen
other
systems
that
add
side
car
containers
that
they're
not
in
it
containers.
I'm
sorry,
that's
right!
This
is
not
in
it.
It's
a
side
car
right,
so
there
I've
seen
the
various
systems
that
add
sidecar
containers
right
yeah
and
that's
that's
not
a
contradiction,
but
in
some
sense
it's
also.
E
E
E
D
E
C
E
E
F
E
F
C
F
E
F
F
C
F
E
F
F
F
That
that's
what
I
would
expect,
but
unwinding
is
unwinding
the
stack.
I
don't.
I,
I
really
think
a
user
should
own
exactly
the
fields
that
are
present
in
their
manifest
and
know
others
right,
because
because
the
user
is
making
a
declaration
about
those
fields,
they're
not
making
a
declaration
about
any
other
field,
so
I
don't
think
we
should
give
the
user
fields
that
they
don't
explicitly
mention.
E
F
F
E
I
expect
the
defaults
to
semantically
be
stable,
so
I
expect
that
the
things
that
I
let
default
well,
first
off,
you
know
I'm
writing
in
in
a
particular
version
right
when
I
write
a
client
is
it's
declaring
in
a
particular
version,
and
I
expect
if
there
are
any
changes
to
that
version
in
the
future.
I
expect
them
to
be
semantically
continuous,
so
that
my
old
client
continues
to
be
doing
the
right
thing
right.
Otherwise,
we've
broken
backwards
compatibility.
F
Yeah,
so,
okay,
here's
here's!
Here's
an
example
where
this,
where
this
doesn't
work
at
all
the
replicas
field
of
a
deployment
has
a
default
and
the
default
is
one
if
I
submit
a
manifest
without
specifying
that
field,
and
I
own
that
field,
and
I
own
the
fact
that
the
field
has
a
value
of
one.
I
create
a
conflict
with
other
parts
of
the
system.
Right,
that's
that's!
That's
that's
right
like
like,
I
would
have
a
conflict
with
the
hpa.
F
The
next
time
I
went
and
submitted
my
thing:
if
hpa
is
clotter
clobbered
that
that
no
that
number,
I
would
get
a
conflict
and
it
would
be
a
very
mysterious
conflict
because
that
that
field
wouldn't
even
appear
in
my
manifest
so
like.
Why
are
you
giving
me
a
conflict
over
a
field
that
I
haven't
even
mentioned?
F
E
I
agree
that
if
we
simply
give
ownership
to
everything
in
a
struct
that
that's
going
to
stop
hpa
from
working,
on
the
other
hand,
I
I
also
think
that
it
is
so
in
the
example
of
hpa
right.
The
author-
I
would
argue
I
would
argue
that
hpa-
is
incorrect
to
apply
to
a
deployment
where
the
author
is
unwilling
to
have
its
replica
account
changed.
It's
only
correct
to
apply
hpa.
If
the
author
is
willing
to
have
the
replica
account
changed.
E
F
F
E
E
You
know
I
look
at
the
definitions
and
in
cases
you
know,
there's
plenty
of
cases
where
I
look
and
say:
what's
the
default,
what's
this
field
mean
what's
the
default?
Yes,
that's
the
value
I
want.
I
will
leave
it
unspecified
because
I
know
it's
going
to
give
me
what
I
want
and
I
want
what
it's
what
I
want
what
the
default
is.
I
don't
want
somebody
changing
it.
F
A
F
A
A
F
F
You
I
I
think
if
this
is
okay,
so
if
the
system
is
choosing
the
default
and
you're
happy
with
that,
and
you
don't
specify
it
in
your
manifest
what
goes
wrong,
I
don't
think
anything
goes
wrong
right.
You
haven't
mentioned
it,
but
the
system
isn't
going
to
randomly
change
unless
something
else
comes
in
and
changes
it
now,
if
that
something
else
is
a
controller,
it's
going
to
ignore
complex
and
change
it
anyway,
so
you
owning
the
field,
doesn't
help
something
help
me.
F
E
F
We
assume
it's
not
useful
to
give
controllers
a
conflict
error.
It's
not
useful,
because
a
controller
isn't
going
to
do
anything
with
that
message.
Right
like
it,
you
can't
it
a
semantic
message.
The
controller
doesn't
understand
that
so
the
controller,
the
the
policy
is
the
controller,
always
forces
conflicts
and
then
the
next
time
the
user
attempts
to
apply
the
user
gets
an
error
because
the
user
will
understand
the
error
and
know
what
to
do
with
that.
C
A
F
Yes,
antoine,
I
think
that's
not
what
would
happen.
I
think
I
think,
if
we
were
to
to
implement
what
mike
is
suggesting
the
way
it
would
work
is
our
first
step
before
we
go
through
the
apply
logic
is
to
expand
the
user's
manifest
with
all
the
default
fields
that
they
didn't
specify
yeah.
We
would
have
to
do
that
first,
otherwise,
we'll
otherwise
we'll
go
through
the
delete
path,
a
bunch
of
times
when
we.
F
F
F
C
F
F
E
Again,
I
I
spend
most
of
my
time
thinking
about
controllers
and
in
the
controllers,
I've
written
again.
I
you
know
I
cruise
through
the
object
type
definitions,
figure
out
what
the
controller
used
to
specify
and
in
cases
where
the
default
is
what
the
controller
wants.
My
controller
doesn't
specify
it.
F
F
E
Well,
my
controllers
will
typically
not
fit
an
oauth
change,
but
my
point
is
that
the
logic
for
figuring
out
what
should
be?
You
know
the
what
they
should
be.
Writing
you
know.
Typically,
one
object
depends
on
several
objects.
You
know
in
complicated
ways
and
I
I
typically
will
only
go
so
far
as
to
write
down
that
logic
and
not
you
know
optimize.
You
know
special
paths,
for
you
know
precluding
or
shortcutting
or
preventing
anything
else.
I
just
thought
that
project
runs
whenever
anything
relevant
changed.
A
E
Well,
what
it's
describing
is
a
logic
that
says
something
like
you
know.
Whenever
any
relevant
object
changes,
you
know,
put
an
object
reference
in
the
work
queue
and
when
it's
time
to
work
on
object
reference,
you
know,
look
up,
you
know,
read
the
values
of
that
object
and
all
the
related
objects.
You
know
apply
the
logic
that
well
for
each
of
the
in
general.
E
F
I
think
there
might
be
some
confusion
because,
because,
like
I,
I
don't
know
what
your
controller
is.
But
imagine
it's
like
imagine
it's
the
deployment
controller,
okay,
where
it's
writing
replica
sets
and
like
this.
This
controller
is
watching
the
deployment
object
for
changes
that
cause
it
to
need
to
update
the
replica
set.
You
can
imagine
it
might
also
be
watching
the
replica
set
objects
to
see
if
the
user
changes
them
in
a
way
that
would
make
them
stop
matching
the
deployment.
E
Right-
and
I
think
in
this
case
I
can
understand-
you
know
that
that
is
an
optimization
to
say
that
I
know
that
I
am
the
sole
author
of
these
replica
sets
and
no
one
else
is
going
to
be
changing
them,
and
so
I
just
write
them
when
I
need
to
write
them
and-
and
that's
the
end,
and
by
the
way
this
this,
this
cool
new
feature
where
I
can
actually
prevent
others
from
writing
them
yeah.
So.
F
F
E
It
is
in
the
example
you
cited
where
the
deployment
controller
does
not
monitor
the
replica
sets.
You
know
if
the
user
modifies
replica
the
controller's
not
going
to
modify
it.
You
know
in
response
to
that
right,
it'll
only
change
it
at
some
random
time
in
the
future,
when
it
has
some
other
reason
to
change
it.
F
So
part
of
the
part
of
the
part
of
the
value
of
stating
which
field
you
manage
is
is
like
signaling
to
the
rest
of
the
system
about
which
fields
you're
going
to
fight
over,
because
you
can
imagine
like.
I
don't
think
this
would
be
a
good
design,
but
just
imagine
that
somebody
writes
a
resource,
an
automatic
resource
setter
and
that
works
on
the
replica
sets
right
resources
yeah.
This
sets
like
the
request,
limit
or
something
okay.
F
F
F
We
can
imagine
this
is
for
a
defaulted
value
or
something
I.
I
think
it
should
be
the
case
that
the
the
deployment
should
indicate
whether
or
not
it's
going
to
fight
over
that
field
by
whether
or
not
it
manages
it.
It
claims
ownership
of
it
in
the
in
the
in
the
replica
set
managed
fields
right
like
if
a
user
entered
a
specific
spec
I'd
expect
a
specific
cpu
limit.
E
F
E
F
E
Yeah,
I
mean
that's,
that's
just
the
beginning
of
it
right
I
mean
there's.
Also
this.
You
know
stuff
about
pod
security
policies,
and
you
know
that's
gotten
complicated,
more
complicated
from
one
release
to
another
and
you
know
either.
I
would
argue
that
the
developers
you
know
users
as
well
as
controller
writers
right
they
they
want.
F
E
Yeah
and
that's
the
bigger
picture
of
this
for
the
bigger
mission
of
this
group-
so
maybe
we're
at
a
time
now,
but
you
know,
maybe
we
should
just
take
that.
As
you
know,
let's,
let's
again
go
back
to
the
broader
mission
of
this
group
and
think
about
what
the
real
challenge
here
is,
and
you
know
with
the
full
breadth
of
this.
The
mission
here.
F
Yeah
yeah,
I
think
we
probably
can
think
about
defaults.
In
that
light,
I
don't
think
we
can
add
them
to
the
managed
fields
like
this,
but,
like
I
can
imagine
something
else
like
a
a
user
tool
that
expands
your
manifest,
like
you
push
a
button
and
it
fills
in
the
defaults
for
you
or
maybe
maybe,
when
you
run
the
apply
command
it
could
offer
to
do
that,
offer
to
mutate
your
manifest
with
the
defaults.