►
From YouTube: Kubernetes SIG API Machinery 20190130
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
Well,
everyone
welcome
to
the
January
30
edition
of
the
API
Machinery
meeting.
It's
a
pretty
short
looking
schedule
today.
So
we'll
just
get
started
Jordan,
it
looks
like
you
have
the
two
main
items.
B
B
So,
for
the
the
first
one
we
are
looking
to
make
progress
with
the
admission
webhook
feature:
it's
been
in
beta
for
a
few
releases.
We've
gotten
some
good
feedback
about
various
people's
experiences
trying
to
use
it
friction
points
things
that
they
ran
into,
and
so,
if
you
want
to
take
a
look
at
the
proposal
for
1:14
work,
it
is
basically
a
rundown
addressing
many
of
the
issues
people
have
encountered.
D
B
Is
distinct
from
the
version
of
the
envelope
objects
that
you
get
yeah?
That
is
a
good
open
question
that
is
not
in
this
list
and
should
be
so
we
will.
We
will
add
that
to
the
set
of
open
questions,
I,
don't
think
it
I,
don't
think
it
impacts
any
of
these
items,
but
it
is
a
good,
a
good
question.
It's.
C
B
B
And
then
the
last
oh,
we're
not
even
close
to
the
end.
If
we're
grouping
these
logically,
the
next
two
would
probably
be
what
information
gets
sent
to
admission
Web
books.
So
there
have
been
requests
to
see,
option
information
along
with
requests.
So
as
we
start
to
have
more
robust
interactions
like
preconditions
on
delete
or
dry
run
for
the.
B
B
So
when
you
delete
an
object,
letting
the
admission
web
book
see
the
object
that
is
going
to
be
deleted,
that
that's
actually
been
a
long-standing
request.
Even
for
entry
admission
plugins,
some
of
the
entry
ones
do
kind
of
wacky
things
to
work
around,
not
having
that
information
available,
and
we
did
something
similar
for
update
the
way
the
update
admission
hook
is
run.
It
has
access
to
the
existing
object,
and
so
this
would
be
getting
parody
for
delete
and
then
the
last
it's
not
less
than
a
list.
B
Modify
or
default
fields
inside
containers
to
do
things
like
enforce
running
as
specific
UIDs
or
using
specific
image
pool
policies.
But
those
are
just
sort
of
particular
examples
of
a
general
class
of
admission
plugin.
That
applies
to
faulting
and
then
requires
compliance
with
specific
values
that
interacted
poorly
with
a
later
plug-in
that
tried
to
add
a
new
container,
for
example.
B
B
First
of
all,
it's
not
even
possible
always
to
order
plug-ins.
Sometimes
one
plug-in
will
make
two
different
changes,
and
one
of
those
changes
needs
to
run
before
something,
and
one
of
those
changes
needs
to
run
after
something,
and
so
you
kind
of
run
into
this
granularity
problem
where
you
start
having
to
break
down
every
plug-in
into
one
individual
change
and
then
try
to
order
them
totally
across
the
total
order.
B
So
even
just
getting
to
the
spot
where
they
could
be
ordered
is
is
not
easy
and
then
once
you're
there,
assuming
that
the
cost
administrator
is
the
one
you
know
responsible
for
sorting
out
this
mishmash
of
plugins
knows
enough
about
all
the
interactions
between
them.
To
pick
an
order
that
will
work
in
our
experience
has
not
proven
true,
even
with
the
entry
plugins
that
didn't
have
that
many
strange
interactions,
there
were
a
couple
even
with
just
that
set
of
entry
plugins
when
the
order
was
specified
by
the
closure
administrator.
B
They
often
got
it
wrong,
which
is
why
we
moved
to
this
recommended
order
for
entry,
plugins
administrator,
just
as
I
want
these
on
or
off,
and
we
put
them
in
the
right
order
for
them,
reintroducing
that
ordering
problem
or
putting
that
back
in
the
cluster
administrator's
plate
for
admission
webhook
did
not
seem
so
workable.
One.
E
Thing,
that's
not
on
this
list
and
is
relevant
to
that,
and
if
you
just
refresh
the
page,
I
just
added
a
few
comments,
one
thing
is
he's:
a
web
book
allowed
to
mutate.
I
feel
that
a
user
specifically
set
to
a
given
value
and
the
follow-up
question
is:
if
web
book
a
changes,
the
field
and
then
what
would
be
wants
to
change
the
same
field
is.
Do
we
specifically
support
that.
C
E
E
B
No,
so
the
the
problem
we
ran
into
was
actually
things
that
were
changing
different
fields,
but
at
different
structural
levels,
so
I
think
it
was
misty.
Oh
was
injecting
a
container
I,
see
and
some
other
plug-in
was
defaulting
a
field
and
requiring
fields
on
a
particular
container
to
be
set
to
a
particular
value,
and
so
it
wasn't
actually
two
plugins
that
had
different
opinions
about
the
same
field.
If
you
have
two
two
plugins
that
have
different
opinions
about
the
same
field,
yeah
you're,
not
gonna,
have
a
good
time.
D
Maybe
well
run
I
mean
I
get
the
case
you're
thinking
of,
but
even
something
like
the
image
policy
and
Estia
right.
If
you
wanted
to
say,
look
I
want
to
make
sure
that
I
pull
STM
from
my
repository,
not
where
the
default
is,
do
plug-in
that
signs
it
when
it
sets
up
a
container
I
think
is
actually
a
pretty
valid
use
case
and
involves
two
plugins
modifying
what
amounts
to
the
same
field:
yeah
I'm,
the.
B
E
We
probably
shouldn't
design
this
here,
but
one
thing
that
occurs
to
me
is:
we
can
actually
look
at
what
plugins
do
like
what
field?
What
fields
do
they
actually
change
after
the
fact,
because
we
have
the
thing
that
we
sent
to
them
and
we
have
the
thing
that
they
sent
back.
We
could
we
could
potentially
forms
in
sort
of
a
graph
of
what
changes,
what
and
run
them
in
the
correct
order
automatically.
A
B
Was
the
last
one
in
the
list,
so
that
is
the
set
of
feedback
from
users
that
seemed
tractable
to
work
on
addressing
in
the
1:14
timeframe.
There
were
a
couple
requests
that
we
discussed
and
either
didn't
think
should
be
done
or
we're
going
to
defer
decisions
on.
So
that
was
splitting
out
references
from
the
trust
bundle
in
the
web.config
to
a
separate
object,
making
making
it
no
longer
be
a
self-contained
configuration
but
sort
of
spreading
it
across
multiple
objects.
B
B
A
Great
okay,
should
we
move
on.
It
looks
like
the
next
one
is
CID
pruning,
defaulting
yeah.
B
This
I
didn't
really
plan
to
discuss
this
a
lot.
This
was
more.
This
God
opened
moves
to
the
cut
format.
I
I
would
like
to
see
this
discussion
start
back
up
and
try
to
get
resolved
in
the
1:14
time
frame
so
that
whatever
implementation
is
going
to
come
out
of.
That
is
ready
to
go
the
beginning
of
1:15
just
so,
we
can
make
progress
on
getting
custom
resources.
B
A
C
F
C
C
B
B
A
B
What,
while
we
have,
if
there's
nothing
else,
sorry
I
will
wait
until
there's
something
else.
I
think
you're
welcome
to
it.
Ok!
Well,
we
have
people
here.
I
would
love
to
kind
of
talk
through
some
of
the
questions
from
that
first
item,
like
I,
said
we're
trying
to
sketch
out
the
1:14
stuff
and
there's
a
desire
to
have
work
scoped
by
the
end
of
this
week,
not
necessarily
everything
every
design
point
nailed
down,
but
at
least
understanding
what
we're
going
to
do
so.