►
From YouTube: WG API Expression Bi-Weekly Meeting for 20201124
Description
WG API Expression Bi-Weekly Meeting for 20201124
A
All
right
welcome
to
the
working
group,
api
expression,
it's
the
24th
of
november
2020..
I
added
two
topics.
Oh,
we
have
three
topics
on
the
gender.
Now
I'm.
A
Great
number
one
we
got
on
a
buck
report
last
week.
I
think
about
a
problem
where
the
managed
fields
got
corrupted
and
when
looking
into
it,
we
found
that
it
is
possible
for
a
mutating
admission
webhook
to
be
outdated
or
maliciously
update
the
managed
fields
to
make
them
unusable
and
that's
kind
of
a
problem
and
anton
put
the
problem
into
two
categories
like
we
should
think
about.
C
D
Yeah
one
thing
we
didn't
mention
is:
how
are
we
going
to
be
able
to
change
that
behavior
in
the
future
like?
Is
there
any
specific
path
that
allows
us
to
change
our
mind
later?
D
The
question
is:
if
oh,
is
that,
whatever
we
do,
are
we
going
to
have
to
stick
with
it
forever
because
it'd
be
nice?
If
we
have
the,
I
I
like
when
I
can
change
my
mind.
A
Yeah,
I
don't
know
why
I
think
like
if
we,
the
the
biggest
problem
about
changing
your
mind,
would
be
the
failing
requests,
part
or
failing
the
admission
chain
part,
because
if
we
do
not,
if
you
decide
we
we
let
changes
like
we
don't
give
an
error
to
the
user
now
and
we
go
to
ga
and
we
at
some
point
give
an
error
to
the
user.
It
would
technically
not
be
backwards
compatible.
I
think
so.
That
would
kind
of
that
could
be
a
problem
we
would
have
to.
A
I
think
we
had
a
few
discussions
about
that
before,
like
the
validation
rating
registering
and
stuff
like
that,
aside
from
that,
whatever
we
do,
it
would
only
become
it
could
only
become
better
like
if
we
just
skip
changes.
The
admission
chain
does
that
are
not
correct.
D
If
we
so
you're,
focusing
on
the
on
the
point
two,
what
about
the
point
one?
Can
we
decide
we're
not
tracking
right
now
and
later
we
decide,
we
track
the
fields
for
admission
chain.
E
D
D
D
What
is
the
less
surprising
to
people?
That's
probably
one
dimension.
We
could
look
at
the
other.
One
would
be
what's
the
most
likely
to
break.
D
A
D
They're
not
strictly
orthogonal
yeah,
I
kind
of
agree
if,
if
we
fix,
if
we
start
tracking
the
chances
about
the
admission
chain,
I
don't
know
if
it
makes
as
much
sense
to
allow
admission
sharing
to
change
it.
I
don't
even,
is
there
a
good
use
case
for
the
admission
chain
to
change
the
managed
fields?
I
I.
A
D
I
mean
so
the
mutating
web
hooks
are
are
meant
to
be
synchronous,
which
is
different
from
controllers,
which
are
asynchronous,
so
I
mean
whatever
we
say
here.
The
question
is:
does
it
have
to
happen
synchronously,
or
can
it
happen
asynchronously
so
see?
For
example,
if
you
want
to
clean
up
the
thing
you
could
have
a
controller
that
looks
at
the
at
the
manage
fields
and
cleans
up
whenever
needed.
D
It
doesn't
have
to
be
done
at
the
request
time.
Specifically,
if
you
wanted
to
have
maybe
a
mutating
web
hook.
That
says
this
field
should
never
be
owned
by
anyone.
So
I'm
always
going
to
clear
that
up.
D
D
D
A
What
what
about
we
definitely
don't
want
them
to
change
on
apply,
so
it
would
only
be
for
updates
that
we
should
allow
the
mutating
webhook
to
change
them
right.
I
don't
know
why.
A
G
G
E
I
kind
of
I
kind
of
see
a
admission
web
hook
as
an
allowance
of
whether
something
is
allowed
or
not.
In
other
words,
does
it
have?
Can
it
be
admitted,
I
don't
see
them
as
ownership
right
like
I
see
that
it
is
providing
admission
for
the
thing
that
owns
the
changes,
so
I'm
not
quite
understanding
when
an
admission.
F
F
A
Maybe
maybe
about
like:
do
we
agree
that
if
we
decide
we
track
changes
from
the
admission
chain
that
we
shouldn't
be,
they
shouldn't
be
allowed
to
change
them,
because
I
would
yeah,
but
probably.
A
D
A
Say
we
don't
allow
it
what
you
just
had
the
synchronous
asynchronous
part?
If
we
say
we
don't
allow
it
do
we
take
away
an
option
to
change
many
fields
and
that's
not
true,
because
you
can
still
send
an
update
and
fix
them
if
you
want
to
so
it
really
has
to
be
something
that
has
to
be
done
synchronously
rather
than
that.
A
D
A
Request
we
we
had
a,
we
had
a
camp
about
it
and
I
think
I
I
I
want
to
revise
something
we
had
there
in
that
camp.
We
wanted,
we
were
assigned,
we
would
have
been
assigning
manager
name
for
the
web
hook.
A
Thinking
about
it
now,
I
think
I
would
rather
give
the
changes.
The
admission
chain
does
to
the
same
manager
as
the
request.
So
if,
if
you
send
a
request
and
you
change
and
you
change
something
and
then
the
admission
hook
changes
something
else
you
should
I
I
think
I
would
like
to
own
both
because
I
my
request
calls
them,
but
they
are
not
specifically
my
intent.
So
even.
B
D
F
D
D
Would
it
would,
but
if
we
want
to
make
it
a
conscious
decision,
I
think
it's
the
it's
the
best
time
to
do
so.
Yeah.
A
D
So
if
we
wanted
to
keep
the
same
behavior
as
today,
which
is
one
option,
the
the
answer
to
these
questions
would
be,
we
do
not
track
the
changes
made
by
the
admission
chain.
A
Because
we
just
track
changes
made
to
yeah
the
request
to
the
object
after
by
the
admission
chain
and
add
them
to
the
managed
fields
that
it
might
even
be
possible
to
add
them
to
the
managed
fields.
The
admission
chain
might
have
changed
before.
D
Yeah,
okay,
I
think
my
suggestion
is
gonna,
be
let's
just
do
these,
what
the
thing
that
is
the
most
consistent,
and
so
I
think
it
allows
for
people
to
come
up.
I
I
enjoy
the
idea
of
people
being
able
to
come
up
with
solutions
to
their
problems,
and
so,
if
they
want
to
change
the
mutating,
what
the
the
managed
fields
I
I
don't
see
a
good
reason
to
prevent
them
from
doing
that.
Obviously
they
shouldn't
be
able
to
break
it.
D
A
A
D
Oh,
no,
what's
the
jenny,
do
you
remember?
What's
the
ignore
field
in
the
admission
chain
like
we
have
a
way
literally
to
say
if
this
doesn't
work.
F
D
A
D
Thing
that
I
find
surprising
is
how
aren't
we
supposed
to
just
reset
the
manage
fields
when
we
can't
decode
them?
Why
do
we
actually
fade
the
request
after
the
mutating
web
pockets
work
on
the
managerials
max,
but
yeah
the
yeah?
This
bug
right?
Aren't
we
supposed
to
do
something
when
there's
a
failure.
A
D
Yeah
yeah
yeah,
that's
something
we
need
to
look
for,
and
I
would
say
I
would
say
if
a
mutating
webhook
today
can
break
an
object
by
sending
an
embedded
manage.
D
D
No,
I
mean
we
would
reset
it
anyway.
I'm
very
yeah,
I'm
very
curious
about
I'm
curious
about
this
one
specifically
because
I
thought
we
would
actually
reset
the
managed
fields
on
ours,
and
so,
if
we
actually
do,
then
we
don't
have
to
change
anything.
If
the
mutating
web
hook
breaks
the
manage
fields,
it's
going
to
get
reset
the
next
time.
We
do
something
with
the
object
here,
specifically,
that
seems
odd,
but
what
do
they
get
reset.
A
D
D
A
D
C
A
Pr,
okay,
yeah,
but
a
first
plan
of
action
would
be
to
make
sure
we
reset
when
the
mutation
sets
it
into
invalid
and
then.
D
Who's
insulted
the
item
about
operator
and.
A
That
was
me
as
well.
I
just
wanted
to
to
yeah
talk
about
it.
If
we
have
a
way
to
make
sure
people
know
when
what
if
they
can
use
it
and
how
an
operator
would
decide
to
use
it.
A
A
D
D
That
thing
I
mean
literally
in
coop
cuddle,
we
verify
whether
the
feature
is
available
or
not.
How
do
we
do
that?
So
in
the
opener
api
we
do
publish
the
path
you
know.
So
what
are
the
endpoint
available?
And
so,
if
you
look
at
the
batch
endpoint
you're
going
to
see
the
type
of
the
content
types
available.
D
Yeah,
that's
a
good
point
in
general,
I
so
what
I
understood
from
this
was:
are
there
specific
use
cases
that
are
good
for
controllers
to
use
ssa
and
other
specific
use
cases
where
I
would
suggest
not
using
ssa
yeah,
and
I
think.
D
We
could
do
a
much
better
job
of
describing
how
to
even
use
ssa
in
controller,
because
I
don't
think
it's
super
clear
to
everyone
that
if
you
want
to
use
that
in
the
controllers,
you
have
to
specify
all
the
things
you
care
about
in
the
object
before
you
send
it
and
how?
Because
it's
it's
kind
of
a
different
paradigm
for
people
writing
controllers
and
we're
not
describing
this.
But
I'm
probably
today.
A
A
D
F
D
I
mean
yeah,
we
should
open
a
bug
in
controller
runtime
fallout,
maybe.
F
D
B
B
Yeah,
so
I
did
some
brief
polishing
of
this
document,
mainly
just
copied
some
stuff
over
from
the
other
document
and
look
into
the
kept
design
of
what
actually
needs
what
the
stuff
we
actually
need
for
ga
just
a
brief
overview.
So
the
timeline
for
121
looks
to
be
probably
the
code
freezes
around
early
to
mid
march,
depending
on.
If
the
release
team
decides
on
a
12
or
15
week,
release
cycle-
and
let's
see
so-
I
was
looking
at
the
original
cap
that
we
had
for
reply.
B
D
Someone
that
knows
about
this
in
the
release
team,
probably
whether
we
need
to
whether
we
need
to
update
or
do
we
need
to
create
a
specific
cap
for
going
to
ga.
I
would
talk
to
someone
in
the
release
gym
for
that:
okay,
yeah.
B
I
can
follow
up
for
that,
so
I
was
also
looking
at
the
features
that
we
had.
It
looks
like
the
main
thing
that
we
had
was
the
api
client
for
servers.
I
apply
with
the
rest
of
this
looks
like
most
of
the
rest
of
the
tasks
are
bug
fixes
yeah.
Is
that
correct.
D
Yes,
yes,
I
would
say
there
is
yes,
it's
mostly
publishing
at
this
point.
Assuming
that
I
mean
we
don't
do
the
status
wiping
and
the
tracking
is
is
good,
which
I
think
it
is
yeah.
So
yes,
it's
mostly
the
client
and
some
publishing.
B
Yeah,
okay,
okay,
so
there's
a
link
below,
for
it
says
right
beside
working
group,
api
expressions,
tag
issues:
it
looks
like
there's
quite
a
couple
of
issues,
I'm
sure
that
we
probably
went
through
most
of
them
but
like
maybe
not
in
this
meeting,
but
sometimes
we'll
probably
need
to
just
go
back
and
see
like
if
everything's
tracked,
yeah.
That's
a
very
good
thing.
Yeah
from
the
issues
to
our
document.
D
B
Yeah
for
our
current
track
issues,
can
we
just
quickly
go
over
them
and
just
like
look
like
double
check
with
the
status
of
every
single
one
of
them
is
for
the
box
or
yeah.
A
A
Just
a
couple
yeah,
I'm
not
sure
if
you
want
to
talk
about
this
or
just
we
had
a
weird
talk
yesterday
that
was
already
conclusive
and
we're.
A
D
A
A
C
Yeah
antoine
reviewed,
my
pr,
so
I
have
a
few
tasks
to
check,
but
yeah
it's
there.
It
seems
that
it's
making
progress
so.
D
Yeah
thanks
andrea,
I
think
it
looks
good.
Does
the
this
one
thing
with
the
test?
D
We
might
want
to
improve
the
test
framework
for
the
integration
test,
because
it's
it's
not
easy
to
write
one,
but
it's
not
maybe
after
ga.
C
D
Track
this
by
the
way,
let
me
add
one
more
comment
yields
yeah.
We
need
to
also
maybe.
D
Both
ga
it
does
and
these
documents,
so
I
I'm
assuming
that
all
of
the
things
in
these
documents
are
meant
for
ga.
We
need
to
have
a
specific
section
about
the
things
that
we
plan
on
doing
after
ga.
A
D
Oh
okay,
sorry,
I
gotta
get
confused.
No,
that's
fine
yeah!
So
because,
in
the
document
it
looks
good
if
we
show
that
we
know
what
the
step
forwards
are
and
that
we
say
okay,
this
is
not
done.
We
agree,
it's
not
done.
We
are
planning
on
doing
it,
but
not
for
gi,
and
this
is
the
testing
framework-
would
be
a
good
post.
Ga
task,
I
think,
got
it:
okay,
okay,.
A
I
just
added
that
anton.
Do
you
remember
what
the
status
part
here
was
about?
I
just
looked
through
the
issue
and
it
is
closed
by
a
pr
of
years.
D
D
A
With
because
I
think
it's
confusing.
B
For
dangling
feels
it
looks
like
it's
a
is
it
something
we
have
a
fix
for,
or
is
this
something
that
we
just
need
a
back
port?
No,
we
don't
have
the
fix
yet.
B
G
D
D
Yeah
I
was
considering
working
on
that.
If
no
one
else
has
time
to
do
it,
and
I
believe
everyone
is
super
busy.
B
A
D
D
Maybe
julian.
I
think
julian
would
be
a
good
candidate,
should
go
to
ucla
and
talk
about
this.
C
D
D
I'll
put
your
name
jeff
on
the
dangling
field.
Let's.
D
F
The
api
clients
on
this
one
has
a
a
prototype,
but
it's
not
finished
like.
I
have
to
do
some
work
to
convert
it
so
that
people
can
use
it
but
yeah.
It's
still.
Work
in
progress
was.
F
Yeah,
I
think
that
joe
met
with
somebody
about
it
and
or
some
maybe
the
controller
tools
group,
and
then
they
had
some
ideas
about
things
to
add
like
to
exposed
an
extra
way
to
interact
with
it
and
see
if
people
prefer
one
or
the
other.
So
I'm.
C
D
A
B
Yeah
and
the
graduation
criteria,
I
saw
those
no
for
that.
A
D
I
I'll
talk
to
you
I'll
talk
to
stefan,
and
maybe
we
can
hack
something
for
this.
Specifically,
I'm
not
excited
about
this,
but
we
can
look
at
it.
I'll
look.
A
D
A
A
D
G
F
A
D
Yeah
I
mean
so.
The
expert
could
be
jenny.
D
Who
knows
how
to
set
up
the
south
side
of
life
for
the
address.
Obviously
I
mean
you
usually
do
these
things
very
quickly.
F
D
B
I
guess
yeah,
so
the
rest
of
the
this
document
is
mainly
just
bullet
plate
copy
and
paste
from
the
cap
structure.
Just
a
couple
of
things
I
had
some
questions
about
number
one
is
so
we
need
conformance
tests
on
all
our
added
endpoints
for
server
side
apply.
I'm
not
exactly
sure
where
to
find
that.
Do
you
have
any.
D
Pointers,
so
I
would
expect
a
lot
of
the
conformance
test
and
julian
can
tell
you
more
about
conformance
tests.
You
know
a
lot
of
con
about
conformance
tests.
Also,
as
far
as
I
know,
we
have
integration
tests
and
I
would
expect
them
to
be
quite
similar.
D
Okay,
we
also
sort
of
need
to
test
that
update
work
because
we're
modifying
all
the
endpoints
anyway,
all
the
modifying
endpoints,
but
I
I
would
what
we
can
do
for
the
conformance
test,
would
probably
be
to
select
specific
integration
test
and
make
turn
them
into
conformance
tests.
Do
you
know
julian?
Is
that
receivable?
I
don't
know
if
they're
running
a
different
setup
for
conformance.
F
Only
only
end-to-end
test
can
become
a
conformance
test
right.
D
F
A
Yeah,
I
I
can't
immediately
think
of
any
of
our
integration
tests
that
would
not
be
required
if
somebody
wants
to
support
apply
like
our
integration
tests
are
make.
We
make
sure
that
apply
works
as
it's
supposed
and
if
you
don't
yeah,
we
should
probably
translate
almost
all
our
integration
tests
into
that.
B
Also,
another
question
I
had
was
around
scalability,
so
I
remember,
I
think,
antoine
you
mentioned
you
did
some
scalability
tests
when
going
to
beta?
Is
that
something
we
can?
Is
that
something
we
need
to
do
again,
or
is
that
something
that
we
have
like
data
points
for.
D
So
yeah,
I
think
we've
done
most
of
the
work
here
and
I
can
talk
to
joe
because
he
definitely
had
some
numbers
back
then
it's
my
perspective
is
that
we
need
to
maybe
mention
the
increase
in
size
of
objects.
D
D
D
Oh
sorry,
go
ahead.
No!
I
I,
I
think
in
terms
of
requirement,
it
doesn't
change
the
requirements
for
kubernetes
that
the
resource,
the
the
request,
need
to
reply
in
like
30
seconds.
So
I
can't
remember
what
the
exact
number
is.
I
don't
think
that
changes
any
of
that
and
I
think
that's
pretty
much
what
they
said
for
crds.
D
They
said
yeah
the
crds
have
the
same
requirements
as
the
other
resources.
We
can
show
with
numbers
that
we're
not
affecting
that
so
bad
and
I
think
that'd
be
good.
B
Oh
yeah,
yes,
definitely
that'd
be
good
to
have
do.
We
currently
have
any
metrics
for
monitoring
service
reply.
D
F
We
have
some
metrics
that
yeah
there's
a
metric
already
that
tracks
the
request
time
and
we
added
something
to
that.
That
would
separate
apply
requests,
so
we
could
see
we
could
compare
them
with
non-apply
requests.
I
think
that's
probably
what
we
need
right.
A
F
B
Okay,
okay,
cool
yeah-
I
can
double
check
them
too
and
like
just
draw
the
data
into
this
document
manage
field
size
would
be
very
interesting.
G
B
Okay,
got
it
got
it
all
right.
Okay,
that's
all
I
have
for
this
document.
I
have
a
bunch
of
action
items
for
myself
to
add
some
more
stuff.
D
That's
great,
I'm
can
I
can
I
go
over
my
agenda
items
item
so
yeah
open
the
link.
D
So
much
here
mentioned
that
there
is
no
manage
fields.
I
don't
know
if
you
know,
but
there
is
frustration
about
the
internet
or
these
manage
fields,
because
it's
too
big
and
people
keep
complaining
on
twitter
and
and
so
manchester,
thanks
to
him
he's
suggesting
that
we
actually
build
a
cool
feature
kind
of
a
good
blame
using
these
fields
to
show
why
it's
useful,
because
some
people
don't
realize
why
the
fields
are
useful
in
the
first
place
so
like.
D
Why
is
my
object,
so
big
with
managed
fields,
that's
of
no
purpose
so
now
matcha
is
showing
an
example
of
what
we
can
do
and
if
you
scroll
down
somebody
has
implemented
it
recently.
D
Oh
nice
yeah,
that's
cool
and
you
can
yeah
look
at
the
video,
maybe
the
link
here.
D
So
you
can.
You
can
blame
pretty
much.
So
that's
not
that's
nothing
new,
but
it's
kind
of
cool
to
be
able
to
see
who
wants
what.
D
D
Do
you
do
you
don't
know
about
these
during
two
verbals.
A
D
There's
a
long
thread
somewhere.
I
can
thank
you.
I
can
punch
to
you
it's.
Maybe
we
probably
need
to
include
that
in
the
in
the
ga
document,
because
having
people.
G
D
So
people
one
suggestion,
might
be
wow
there's
a
lot
of
likes
on
this
issue.
One
solution
might
be
to
have
a
different
format
and.
D
Another
format-
maybe
a
short
yaml,
so
that
you
can
see
the
thing
without
the
managed
fields.
There's
also
made
the
possibility
of
encoding
the
managed
fields
in
json
in
one
nano
there's
also
complaints
about
the
network.
D
It's
impacting
the
network
because
it's
adding
much
more
data,
and
we've
mentioned
that
in
the
past.
That
controllers
are
caching
this
data
now
for
no
reason,
so
I
suspect,
maybe
we
could
add
a
flag
on
the
on
the
server
to
say
I
don't
care
about
these
fields,
don't
send
them
to
me
which
controller
could
use
if
they
don't
care
about
these,
and
we
could
have
coupe
code
use
it
when
you
use
the
specific
shots
option.
A
Yeah,
we
were
talking
about
this,
I
don't
know
a
year
ago
and
I
I
still
think
it
wouldn't
be
bad
to
be
able
to
tell
that
you
don't
want
them,
because
you
rarely
need
them.
D
G
A
D
Yeah,
I
think
it's
yeah
adidas
a
feature,
maybe.
A
A
Okay,
yeah
at
all
anything
else,.
A
Then
we're
done
here
thanks
for
coming
and
a
nice
afternoon
morning
evening,
everybody.