►
From YouTube: Kubernetes SIG API Machinery 20191106
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
So
this
issue
came
up
when
we
were
trying
to
figure
out
what
to
do
for
the
scale
sub
resource
for
apply
like
how
are
we
supposed
to
go
through
and
assign
owners,
and
we
realized
that
actually,
the
web
hook
chain
kind
of
has
the
same
problem
and
it's
basically
unsolved
and
may
be
unthought
through.
Although
I
I
know
that
some
great
thinking
has
happened
in
this
issue,
or
at
least
I
saw
a
bunch
of
comments
which
I
haven't
read.
B
So
the
basic
idea
of
the
problem
is
when
a
request
comes
into
a
web
hook
or
when
a
request
comes
into
API
server.
You
can
register
web
hooks
for
either
the
parent
resource
or
a
sub
resource,
and
the
promise
that
we
thought
we
offered
to
rub
web
hooks
was
that,
like
every
change
to
the
resource
would
go
through
your
Web
book,
but
that's
not
actually.
What
happens?
What
happens
is
if
a
change
goes
to
like
the
scale
sub
resource.
B
One
pokes
that
register
for
the
scale
sub
resource
get
the
sale
scale
object
to
see
the
change
but
right
what
the
web
hooks
who
have
registered
for
the
parent
resource
do
not
see
the
change.
So,
for
example,
if
you
wrote
a
web
book
for
that
hook,
deployments
and
you
expect
to
take
action
whenever
the
the
spec
that
replicas
field
changes-
and
somebody
goes
in.
Somebody
like
the
horizontal
autoscaler,
goes
in
and
makes
a
call
to
the
scale
sub
resource.
B
C
B
Yes,
it
is,
it
is
true
of
all
resources,
but
scale
scale
status
is
a
little
bit
unique
because
we
enforce
an
API
server
that
if
you
call
the
status,
you
cannot
change
spec
and
likewise,
if
you
call
the
spec,
you
can
actually
your
status.
You
can
change
metadata
in
both
places.
So
if
your
welcome
to
expected
that
then
yes,
it.
D
B
C
D
I
think
that's
a
restatement
of
the
problem
yeah.
Well,
you
really
need
to
be
able
to
separate
those
two
things
out
right
like
if
you
look
at
the
way
we
validate
spec
and
status
for
resources
we
create.
We
are
very
careful
to
separate
out.
Are
you
updating,
spec
or
are
you
updating
status
so
that
a
change
to
status
with
a
spec
that
is
already
invalid
can
still
be
accepted?
And
we
do
that
so
that
if
something
goes
wrong,
controllers
are
still
able
to
report
the
state
of
the
world.
E
B
B
B
Yeah,
if
you
keep
scrolling
down
here,
who
is
this
you
fede
yeah,
you
keep
scrolling
down
a
little
bit.
Jordan
yeah
Jordan
asks
some
really
hard
questions
there.
What
user
like
we
now?
We
have
a
big
problem
because
we're
not
directly
echoing
the
requests
like,
for
example,
if
I'm
authorized
to
send
changes
to
the
status
or
sorry
this,
the
the
scale
sub
resource
that
does
not
at
all
imply
that
I
am
authorized
to
make
other
changes
to
the
parent
resource
so
and
we
tell
webhooks
the
user
that
is
making
the
change.
F
B
G
B
B
C
B
I
think
for
series:
you
can
already
map
that
you
can
enable
the
sub
resource
in
math
that
field
to
any
sincerity
which
is
fine
and
not
problematic.
The
problematic
part
comes
in
when
the
mutating
web
book
echoes
that
somewhere
else
in
the
object,
and
now
it's
changing
a
field
that
we
don't
necessarily
expect
the
scale
sub
resource
to
change.
But
maybe
it's
okay
and
that's
that's
sort
of
the
questions
like
is
it
actually?
Okay,
I.
D
G
A
E
B
G
B
It's
echoing
it
somewhere,
that
is
maybe
okay,
like
I,
can
sort
of
yeah
like
like
setting
memory
requirements
based
on
number
of
replicas.
Maybe
I
can
see
that,
like
you,
probably
quadratically
scale
and
shouldn't
do
that,
but
but
I
can
understand
somebody
actually
doing
it
the
place.
The
part
where
it
becomes
kind
of
impossible
is,
if
you
want
to
go
both
directions
like
if
a
client
sets
replicas.
Do
this
other
thing?
B
E
E
B
I
think
there's
definitely
some
value.
You
know,
since,
if
it's
less
objectionable
to
call
the
validating
web
book,
it
does
seem
like
there's
some
value
in
like
at
least
letting
people
enforce
their
system
and
variants.
Even
if
that
means
that
all
calls
to
the
scales
of
resource
will
fail,
that
does
seem
somewhat
valuable.
D
G
Bad
also,
how
well
is
this
going
to
get
I
mean
if
I
break
autoscaler
by
putting
in
a
ballad
dating?
Is
that
just
going
to
be
a
hidden
error,
because
the
only
thing
that
ever
saw
the
error
message
of
why
the
the
submarines
orce
request
failed?
Is
some
system
resource
that
young
people
are
needing
this
okay,
there.
G
E
B
So
the
other
so
assuming
we
can
figure
out,
it
seems
like
if
we
want
to
call
mutating
web
books,
we
either
have
to
agree
that
it
is
okay
for
the
mutating
weapon
to
change
a
field
other
than
the
field
included
in
the
sub
resource,
or
we
have
to
filter
the
output
of
the
web
book
and
prevent
it
from
doing
so.
In
which
case,
why
would
we
bother
running
the
field
or
the
web
book
at
all
yeah?
E
E
G
E
B
H
B
D
B
I
J
D
So
it's
weird
enough
that
I
would
consider
trying
to
make
the
call
me
for
some
resources,
something
optional,
that
you
can
decide.
You
know
what
I
really
want
to
be
called
any
time.
The
spec
of
this
respect
or
meditative
subject,
changes
and
I
will
manage
my
expectations
based
on
sub
resource,
because
I
just
looked
and
that
get
past
it.
B
B
E
E
E
B
Okay,
so
we
could.
The
problem
with
that
is
that
people
who
have
marked
that
they
want
equivalent
resources
may
not
expect
a
scale
to
be
an
equivalent
resource
yeah.
Arguably
they
should,
but
they
may
not.
B
D
H
C
D
For
example,
we
had
an
open
system
resource
overrides
and
a
couple.
Others
we've
eliminated
a
few
of
them,
but
it
checked
the
user
to
decide
whether
you
add
permissions
to
you
to
formally
do
something
or
unilaterally
do
something
regardless
about
the
policy
and
if
you
did
it,
let
it
through,
and
if
you
didn't
it
would
run
a
secondary
check,
make
sure
that
your
user,
having
granted
the
permission
to
take
the
action
and
it
was
applied
to
things
like
deployments,
stateful
sets
and
replica
sets
yes.
This
definitely
would
have
broken
that
even.
D
D
H
B
Think
that's
basically
what
Joe
just
proposed
yeah
and
so
there's
I.
Don't
call
it
literally
that
but
yeah
include
versus
or
alternatives
representing
something
like
that.
So
it
sounds
like
we've
kind
of
converged
on
and
I
found,
Joe's
point
convincing.
It
sounds
like
we
kind
of
converged
on
add
a
field
to
the
API.
If
the
field
is
is
set,
then
we
need
to
call
the
the
parent
sub
resource
or
the
the
that
web
book,
even
if
the
scale,
even
if
it's
a
resource,
yeah
yeah.
E
F
E
B
B
B
H
D
E
B
G
B
B
Eye
I
think
if
you're
gonna
opt
in
I,
don't
think
you
should
be
able
to
I
agree
with
you,
yeah,
okay
and
so
finally,
the
ordering
I
think.
The
only
thing
that
is
clear
to
me
about
the
ordering
is
that
all
the
mutating
ones
have
to
be
called
before
all
of
the
validating
ones.
Yeah
right
like
it,
wouldn't
make
sense
to
let
us
to
like
mutating
validating
mutating
validating,
because
then
someone
variants
might
be
skipped.
C
D
B
The
as
if
the
core
resource
mutating
web
hook
changes
this
this
Specter
replicas
value
in
a
way
that
the
scale
sub
resource
web
book
doesn't
like
then
you've
skipped
that
you've
made
that
now.
Of
course,
it
shouldn't
do
that,
because
that
is
changing
the
users
intent,
but
it
could.
We
don't
prevent
it
I'm
trying
to.
E
E
So,
basically,
you
have
things
that
want
to
mutate
or
validate
the
sub
resource,
what
to
mutate
or
validate
the
parent
resource,
and
so
in
the
simplest
case,
a
mutating
one
on
the
sub
resource
would
like
set
the
scale
to
two
and
a
validator
would
make
sure
that
scale
was
two
and
if
you
run
both
of
those
and
they
both
pass.
And
then
you
start
calling
mutaters
and
validators
on
the
parent
one
I
mutator
there
could
say:
oh
no
replication
should
definitely
be
three
an
ability-
or
there
would
say
sure
three
looks
good
to
me.
B
E
It
lets
you
change
a
feel
that
can
also
be
change
via
the
main
resource.
If
we're
wanting
to
make
this
generic
and
say
you
can
register
a
web
hook
for
the
top-level
resource
and
say
also
send
me
things
for
sub
resources,
when
they
mess
with
my
fields,
then
you
could
register
one
for
the
top-level
object
and
say
also
send
me
status
things.
E
And
so
that's
a
more
compelling
example
where
the
thing
that
registers
specifically
for
status,
monkey
with
status
and
it's
mutating
hook
and
then
a
sort
of
an
invariant
and
it's
validating
hook,
and
that
actually
today
is
protecting,
like
you
can't
change
stuff
under
status,
except
by
going
to
that
endpoint
and
so
they're.
The
order
where
you
call
the
one
registered
specifically
for
the
sub
resource
and
once
registered
specifically
for
the
parent
resource.
H
E
B
Yeah,
so
how
would
the
opt-in
work
if
I
registered
for
the
scale
sub
resource
or
for
the
sub
resource,
rather
than
the
resource
if
I
opted
in?
Does
that
mean
I'm
I
should
view
changes
to
the
root
resource,
or
should
we
make
it
a
one-way
like
we
can
solve
this
concern
by
API
I
would
make
the
API
be
like
also
sub
resources,
foo
bar
Baz,
like
okay,
so
that
makes
it
clear
that
if
you
register
for
a
sub
resource,
you
don't
get
the
root
resources
change.
B
J
D
B
H
B
G
B
G
E
F
B
E
E
E
E
B
E
If
you
have
to
round-trip
the
changes
through
the
object
that
is
submitted
to
the
sub
resource
because
remember,
we
have
to
be
able
to
call
mutating
sub
resource
admission,
plugins,
then
parent
admission,
plugins,
then
sub
resource,
then
parent.
If
you
have
to
round-trip
guys
yell
object,
you
can
only
do
that
with
the
replicas
field.
B
J
B
So
summary
is
the
reason
to
call
the
mutating
weapons
is
that
some
sub
resources
have
overlapping
fields
right?
It's
not
super
useful
for
scaled,
because
there's
only
that
one
field-
and
you
wouldn't
be
able
to
use
this-
to
use
the
specter
replicas
field
to
update
your
environment.
Variable
we're
basically
saying
you
can't
do
that.
B
B
C
B
Get
the
poor
actually
does
do
become.
Can
you
change
metadata
on
the
deployment
by
calling
those
scales
of
resource
I
can't
recall,
I,
don't
think
so.
I
hope
Tom
I,
don't
think
so
either
I
think
yes,
I,
think
I
looked
at
the
code
and
is
literally
just
copying
them
or
anything
it
just
copies.
The
replica
yeah.
K
I
K
I
B
I
B
B
This
is
kind
of
why
I
thought
we'd
all
agreed
that,
yes,
it
was
okay,
but
I.
Guess
everybody
broke
up
at
that
instant
and
we're
not
yeah.
It
doesn't
seem
super
useful
to
call
a
mutating
weapon
if
it
basically
can
only
change
exactly
the
thing
that
the
user
can
change.
Do
we
have
any
other
compelling
examples.
Besides
the
scale
sub
resource
the
binding
one
for
pod,
also
only
a
single
field.
K
B
H
B
So
for
some
of
our
resources,
it
is
expressible,
like
you
can
attempt
this
the
corresponding
thing
today,
like
for
status,
you
can
try
to
set
spec
and
when
he
calls
the
main
one,
you
can
try
to
side
the
status
field,
and
today
we
transparently
just
drop
it.
If
you
do
this
during
the
annoyance
of
most
of
our
users,
you
know
do
not
expect
that
I
have
a
question
about
them.
When
once
I
come
in
I
mean
let
me
enumerate
the
other
case,
which
is
the
rest
of
our
relevant
sub
resources.
B
You
cannot
even
express
this
right,
like
you
can't
when
you
send
a
scale
sub
resource.
You
can't
also
include,
like
a
environment,
variable
change,
so
you
can't
actually
express
it.
So
if
we
squint,
maybe
we
can
say
that
that
behavior
is
actually
just
undefined
rather
than
like
explicitly
disallowed,
and
we
can
define
a
different
behavior
for
the
for
the
webhooks
involved.
I
find.
E
B
Defined
to
me,
let
me
let
me
try
one
other
thing,
which
is
by
our
conversion:
world
every
field
needs
to
be
round-trip
achill
so
that
it
can
survive
arbitrary,
arbitrary
convergence.
The
sub
resources
currently
do
not
abide
by
this
rule
right
like
deployment
to
scale.
The
deployment
is
a
super
lossy
transformation
which
is
not
actually
how
our
conversions
are
supposed
to
work.
If
our
conversions
worked
correctly
and
it
called
them
correctly,
then
we
would
get
this
behavior
by
default
like
a
mutating.
D
C
D
E
B
K
Chick
with
those
hooks
get
the
sub
resource
get
only
the
supreme
source
and
the
parent,
the
parent
is
make
a
whole
object
or
how
does
it
work?
Sorry,
I
didn't
hear
the
first
part
of
the
question.
Other
sub
resources
work,
the
mutating
web
probes
first
up
resource,
it
only
gets
the
sub
resource
and
the
parent
one
gets
the
full
object.
Yeah.
B
A
Years
super
quick,
so
next
meeting
is
going
to
be
canceled
because
there
is
coupon
North
America
and
many
of
this
group
are
going
to
be
there
very
still.
We
shall
see
a
payment
a
brand.
It
talks
that
I
am
aware,
but
maybe
there
is
no
I
will
be
doing
introduction
to
cata
machinery
on
Wednesday
and
I'm
one
you're
going
to
be
doing
there
deep
dive
right,
Chris,
Jeff,
Anya
yeah
with
so
come
by.
If
you're
there
hope
to
see
many
of
you
there
in
person
say
hi
and
hopefully
those
presentations
are
also
going
to
be.