►
From YouTube: WG API Expression Bi-Weekly Meeting for 20210316
Description
WG API Expression Bi-Weekly Meeting for 20210316
A
B
A
B
B
B
A
B
C
B
A
B
A
B
It
doesn't
know
what
to
look
for,
and
so
it
should
explicitly.
There
should
be
an
extract.
We
could
use
a
parameter
for
it,
but
we
could
have
a
function
extract
for
the
main
resource
and
an
extract
status
for
the
status,
and
it
would
know
which
manager
to
look
for,
and
so
it
would
use
the
proper
manage
fields.
A
A
B
A
A
A
A
A
C
B
Yes,
correct
andrea,
I
initially
did
it
for
deployment,
but
we
actually
want
to
do
it
for
stateful
self
replicas
and
all
and
for
crd
is
due-
and
I
think
I
think
most
of
the
code
is
ready
and
working
and
we're
writing
the
test.
I
I
was
doing
that
quickly
during
the
exception
process,
but
since
we
didn't
actually
make
it
andrea
is
going
to
finish
that.
B
B
B
A
A
B
B
B
A
B
C
C
B
D
D
What
do
people
think
about
the
idea
that
we
make
sense
immediately
check
very
strictly
basically
means
that
if
you
don't
specify
a
field,
is
you
then
you
are
and
and
it
will
get
a
default
value
most
in
most
of
the
cases
I
checked
the
core
types.
That's
that's
basically
what
happened?
If
you
don't
specify
fields
and
if
the?
D
If
the,
if
the
api
server
or
the
controller
really
cares
by
an
initial
field,
then
there
will
be
a
default
field
or
there
will
be
some
fields
generated
on
the
admission
time,
and
that
means
you,
even
users,
don't
specify
here.
There
will
always
always
be
a
meter
field
provide
somewhere
and
then
the
immutability
check
will
compare
with
that
initial
field
with
the
updated
field,
updated
value.
So,
given
this
observation,
so
I
think
we
can
go
go
with
with
the
you
know,
straightforward
approach.
D
B
D
Was
it
defaulted
yeah
I
so
by
default
I
mean
that
I
I'm
reading
the
like
the
code
for
the
existing
core
types
of
kubernetes
core
types.
Usually,
if
the
they
have
some,
you
know
cosmological
to
determine
to
validate
the
immutability
of
fields
right
and
most
those
fields
are
either
required.
So
that
means
you
have
to
specify
a
value
in
the
first
place
or
the
value
is
defaulted
on
admission
process,
but
is
it
defaulted
in
the
admission.
D
Yeah
or
or
there
would
be
some-
you
know,
customer
logic,
then
to
be
or
generate
a
id
or
generate
a
value
for
it
like
what
I
told
you
about
the
label
selector
some,
I
think,
for
the
party
who
don't
specify
the
label
selector
on
the
on
creation
on
creation
or
mission
time.
I
think
the
current
logic
is
set
is
the
yin
validation,
but
there
to
do
things,
move
this
logic
to
defaulting
but
anyway.
B
D
Yeah,
that's
basically
the
the
approach
I
want
to
go
with.
Unfortunately,
it
wouldn't
just
certify
kcc's
use
case,
because
we
do
allow
users
to
you
know
unspecify
some
fields
we
don't
care
about,
and
the
value
will
be
determined
by
the
controller
by
calling
the
underlying
api.
Basically,
the
value
is
determined
by
the
gcp
services
and
the
controller
it
just
populates
the
value
back.
I
see
what
you're
saying
it's
like
this
identifier
is
generated.
B
D
B
A
B
A
A
D
B
Looks
at
the
old
object
and
I'm
just
curious
after
the
mutation
on
the
creation.
Do
we
actually
com
look
at
what
the
mutating
is.
The
validation
correct
after
the
mutation
as
in
the
old
object
is
what
we
would
have
created
and
the
new
object
is
what
the
mutation
change:
how
do
we
just
do
a
nail
to
entirely
new
object?
That's
what
I
don't
know
and
would
like
to
understand.
D
B
A
Okay,
I
mean
this
only
would
solve
the
problem
if
a
admission
webhook
would
be
used,
and
I
I
I
think
there
could
be
cases
where
a
control
where
you
want
to
have
a
controller
that
sets
the
field
at
some
point
and
not
block
the
admission
chain
on
it.
So
I
still
could
see
the
case
where
we
want
to
be
able
to
specify
a
field
for
the
first
time
later,
on.
A
A
D
A
A
C
B
B
A
B
A
D
B
A
B
D
Addition
and
and
the
deletion
for
immutable
fields,
because
that
will
give
you
a
backdoor
to
bypass
the
validation
right.
If
you
allow
remove
a
field,
your
user
can
do
that
first
and
then
reset
it
with
a
different
value.
Then
the
validation
webhook,
so
the
immutability
validation
logic
would
not
prevent
it.
B
Yeah-
I
don't
disagree
with
that,
but
I
don't
know
if
that's
what
about-
and
I
was
thinking
specifically
about
list
items
like.
Maybe
we
can't
you
can't
change
the
container,
but
you
can
rename
it
remove
one
and
add
another
one
which
is
literally
renaming
the
I
can
add
later
and
I
can
remove
later-
would
allow
you
to
do
that.
You
would
be
able
to
remove
and
recreate
on
your
container.
D
B
D
B
A
B
B
B
A
D
Yeah,
okay,
I
will
go
with
that
direction,
a
little
bit
further
saying
that
we
allow
delete.
Basically,
we
treat
delete
and
then
we
added
another
change
yeah,
let's
see
how
it
works
yeah.
If
we
can
accept
that
philosophy,
then
maybe
things
can
go
smoother
and
it
will
apply
to
maps
and
containers
at
least
maybe
but
yeah.
I
will
think
of
more
of
that,
but
yeah
thanks
for
the
suggestion.
A
I
remember
one
question:
I
don't
know
if
I
asked
it
last
time
for
the
recursive
immutability
is
like
that
would
be
hard
to
specify,
but
do
we
need
some
mechanic
to
say
the
recursiveness
stops
here
like
don't
make
this
immutable
or
would
like?
I
think
we
kind
of
mentioned
it
with
specifying
a
non-immutable
field
set
or
something,
but.
D
D
A
D
Yes,
I
I
think
so
you
basically
you
needed
to
introduce
more
extensions
to
to
define
this
fingering
behavior
saying:
okay,
even
though
the
parents
said
it's
immutable,
but
for
the
children
this
is
exception,
something
like
that,
but
I'm
trying
to
like
work
from
the
use
cases.
I
I
couldn't
find
any
good
use
case
to
mapping
to
that
approach.
But
if
you
know
yeah,
let
me
know
I
will
take
it
in.
B
You
might
want
to
actually
do
it
directly
recursive,
but
with
the
ability
to
override
the
semantics
in
the
in
the
middle,
for
example,
because
the
list
so
let's
say
you,
have
a
list
of
containers
and
so
the
containers
you
shouldn't
be
able
to
change.
But
the
least
you
are
able
to
add
and
delete
today,
you're
going
to
say:
okay,
the
list
is
add
and
delete
and
because
it's
going
to
be
fully
recursive,
it
means
necessarily
the
containers
have
to
be
identity
too.
A
B
A
A
B
D
B
So
when
you
write
the
types
that
go
you're
going
to
have
this
slash,
slash,
press
immutability
and
we're
going
to
include
that
in
the
open
api.
So
as
we
traverse
the
open
api,
we're
going
to
see
the
mutability
of
each
field,
and
so
as
we
do
the
integration
to
see
if
the
the
immutability
constraints
are
expected,
we
are
going
to
work
the
schema
at
the
same
time
and
see
what
has
changed
and
what
hasn't.
D
A
A
B
A
B
D
B
Generally,
because
we
had
multiple
types
of
lists,
so
the
atomic
list
is
probably
considered
as
a
consider
the
atomic
list,
as
if
it
was
a
string.
So
if
it
changes
it's
a
change
the
set,
I
would
say
if
it's
tricked,
then
you
can
change
the
set.
If
it's
add
only,
then
you
can
add
items
to
the
set.
If
it's
delete,
if
it
allows
deletion,
then
you
can
delete
stuff
from
the
list
and
what
is
the
other
case,
an
associative
list?
B
B
D
B
D
Okay,
yeah
mine
makes
sense.
Okay,
I
follow
up
with
you
offline
about
this
one.
I
just
wonder.
I
think
there
might
be
a
very
used
consent.
Some
users
just
want
to
mark
a
list,
that's
immutable
and
don't
allow
change
anything,
don't
allow
adding
stuff,
don't
allow
the
linking
stuff
and
don't
allow
changing
existing
values.
B
B
D
B
B
B
A
A
B
Yeah-
let's,
let's
finish
it
for
good
yeah
and
before
we
before
we're
done
with
that.
So
before
april
15th,
I
have
to
write
a
document,
because
I
have
a
million
changes
that
I
want
to
make
to
the
open
api,
and
so
I'm
going
to
try
and
work
on
describing
these
changes
sounds
interesting,
yeah
and
I'll
talk
in
two
weeks
about
these.
If
you
want.
C
A
B
B
A
A
B
I
would
want
someone
to
propose
and
work
on
splitting
the
open
api
background
version,
or
maybe
just
group,
so
that
when
you
do
slash
open
api,
slash
v2
on
the
api
server,
you
actually
get.
You
can
do
slash
open
api,
slash,
v2,
slash,
call
I'll,
slash,
open
api,
slash,
v2,
slash
apps,
and
you
just
get
the
open
api
for
this
specific
group,
and
that
would
probably
helps
alleviate
some
of
these
problems.