►
From YouTube: Kubernetes SIG API Machinery 20180829
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
Hello
and
welcome
to
the
sig
API
machinery
by
weekly
meeting
for
Wednesday
August
29.
We
do
not
have
much
of
an
agenda
yet
this
week,
unless
some
items
have
been
out,
it
looks
like
a
couple:
have
that's
good?
We
will
jump
straight
into
those.
Some
of
the
Googlers
aren't
here
today.
So
I
am
filling
in.
B
This
dynamic
got
it
ap
I'm
for
a
while
we've
number
of
times,
I
think
we've
gotten
that
place
stability
I'm
just
saying.
If
we
can,
you
know
essentially
I,
shall
these
remaining
issues
before
yet.
Freeze
here,
I
didn't
know.
If
anyone
comments
on
us
or
if
there's
any
advice,
we
could
this
still
get
this
hearing
before
freezes
seems
to
kind
of
have
a
in
a
block
here.
Somehow
so
just
trying
to
discuss
I
guess,
freeze.
B
B
So
we
changed
API
a
couple
times
we
originally
put
in
the
API
server,
then,
because
of
issues
of
legacy
scheme,
I
would
change
about
a
couple
things.
The
most
recent
was
we
had
to
copy
out
the
policy
objects
that
was
refund
API
server.
We
had
to
put
it
into
I.
Basically
a
case
I
heard
up.
You
know
slash
API
I.
B
In
doing
so,
there
was
maybe
some
changes
wanted.
I
know
lava
lamp
was
wanting
some
changes
there
that
is
tracking
with
the
internal
API,
so
there
was
just
I
guess
a
disagreement
on
whether
we're
making
changes
with
this
type
going
in
we're
we're
just
trying
to
expose
it
a
trusts.
That's
already
existing
implementation
or
I.
B
C
C
The
only
exception
I
know
of
would
be
the
custom
resource
versioning
web
book,
but
that's
been
that's
been
under
review
for
some
time
and
the
design
started
and
was
more
or
less
agreed
to
you
know
back
before
we
started.
I
can
see
comments
in
the
link
pull
here
that
are
actually
even
questioning
whether
this
should
be
a
custom
resource
or
not.
B
B
D
A
weigh
in
on
a
couple
things
there
did
I'm
process
taking
months
and
months
is
not
unusual,
and
when
this
originally
started
it
was
kind
of
proposed
to
be
phased
in
as
a
let's
register,
webhooks
alone,
but
not
policy
and
then
kind
of
towards
the
end
of
feature.
Freeze,
adding
expanding
it
to
policy
was
tried
to
be
added
in,
and
the
feedback
at
that
point
was
that
this
is
pretty
aggressive
for
112
to
try
to
bite
off.
D
D
Agreement
to
work
towards
being
able
to
register
webhooks
with
dynamic
policy
for
dynamic
audit
doesn't
preclude
an
initial
stage
of
that
development
happening
out
of
tree,
so
I
think
Tim's
kind
of
clarification
comment
was
not
probably
accurate
like
this.
This
is
still
a
direction
that
we
want
to
see,
but
that
doesn't
mean
we
can't
make
the
first
phase
of
it
be
done
using
auditory
methods.
B
D
Also,
like
Tim
said
he,
some
of
this
is,
has
been
evolving
this.
This
release
right,
like
we're
kind
of
reaching
a
point
where
bandwidth
wise,
trying
not
to
block
people
trying
to
allow
experimentation
without
destabilizing
or
bloating.
The
core
repose
is
pushing
more
and
more
things
to
be
built.
That
way,
even
things
that
this
release
were
being
proposed
as
kind
of
injury
resources,
so
it
I
apologize
for
the
the
extent
to
which
you've
been
kind
of
on
the
receiving
end
of
some
of
the
turn
around
how
we're
hoping
these
things
can
be
built.
D
B
I
mean
is
still
a
lot
of
time.
I've
spent
a
good
I,
don't
know
a
month
and
a
half
like
just
straight
or
beyond
this
feature,
and
you
know
it's
tested,
it's
working
I
ever
run
in
a
cluster
everything's
good
I
sitting.
Now
you
know
last
minute
kind
of
pulled
back
on
something.
That's
working
its
feature,
get
it's
an
alpha
feature.
We've
followed
all
the
steps
to
get
it
up.
It
just
seems
like
it.
B
You
know
feels
like
I'm
getting
kicked
in
the
teeth
a
little
bit,
so
it
just
feel
like
there's
something
wrong,
then
with
the
process
of
the
captain
there,
because
it's
certainly
a
lot
of
time.
But
you
know
FDA's
invested
into
this
feature
that
we're
now
gonna
lose
I.
Guess
maybe
not
leaves
entirely.
But
it's
you
know
it's
just
I
guess
is
just
frustrating.
You
know.
D
Yeah,
like
I,
said
I'm,
definitely
sympathetic
to
that
I
think
some
of
those
kind
of
timeframes
for
or
expectations
around
how
long
it
takes
to
get
something
like
this
in
your
you're
in
good
company,
which
isn't
comforting
when
you're
in
that
position.
But
it's
not
it's
not
uncommon
for
things
that
especially
go
into
like
the
API
server
level,
not
even
the
cube
API
server,
but
things
that
are.
D
B
See
the
CVI
objects,
I
think
that
makes
sense,
but
as
far
as
the
entry
work
around
the
implement,
it
seems
like
that'd,
be
pretty
hard
to
get.
You
know
valuable
feedback
having
that
somehow
out
of
tree
outside
the
API
server
not
worked
into
the
pipeline
there.
So
I
guess
I,
don't
know
how
that
leaves
us
well.
D
D
Web
hook
right
and
if,
if
you're
at
an
implementation
of
that
web
hook,
that
would
pay
attention
to
these
dynamic
distribution
objects
and
like
the
implementation
you
already
have,
is
basically
what
are
similar
to
what
would
be
needed
to.
You
know:
send
events
of
different
levels
to
different
web
hooks
way.
D
One
of
the
things
we've
been
talking
about
recently
and
slick
architecture
is
how
do
we
get
feedback
on
alpha
features?
And
today,
if
you
turn
on
alpha
features
in
your
API
server
or
any
of
your
components,
unsupported
upgrading
those
we
don't.
If
you
report
bugs
like
we
want
to
know
the
bugs,
but
we're
not
going
to
back
port
them
to
old
versions.
Things
like
that
so
figuring
out
how
we
actually
gain
experience
with
alpha
features.
If
you.
D
Of
tree
education,
deploying
it
on
a
cluster,
consists
of
like
set
up
the
C
or
D
and
start
your
API
server,
pointing
at
a
web
book
audit
sync
and
sending
all
events
to
it
and
that
that's
a
pretty
I
guess
relatively
lightweight
way
to
start
trying
out
a
feature
like
this.
Just
for
my
consumer
perspective,
they
don't
have
to
put
on
to
wait
for
Q,
Bernays,
112
or
even
111
right,
like
any
of
the
versions
that
can
send
audit
events
to
a
web
book
could
try
out
this
feature.
B
Basically,
today,
for
a
little
while
I
I
guess,
the
point
was
to
try
and
actually
get
the
code.
You
know
the
at
least
implementation
piece
into
the
API
server
or
we
could.
You
know,
begin
testing
on
that
around
I
mean
it
is
totally
feature
given
I
guess,
June's
point
here.
Talking
with
him
earlier
is
that
you
know
it's:
we've
got
a
completely
featured
yet
it's
the
point
is
to
get
it
in
the
customers
hands.
We
began
iterating
on
that
piece
and
actually
getting
feedback.
B
B
D
E
Yeah,
so
if
we
had
this
to
do
over
again
like
we
had
the
cap
and
it
had
proposed
API
and
some
proposed
changes
to
the
API
server
implementation,
it
sounds
like
the
do-over
would
have
been
okay.
Maybe
we
do
a
cap,
okay,
but
we
prove
it
out
with
CR
DS,
with
no
modifications
to
core
get
various
SIG's
input
and
buy-in
and
feedback,
and
then
get
some
sort
of
little
thing
to
go.
E
E
D
E
D
E
E
E
D
D
Visibility
is
what
we're
doing
and
then
also
balancing
out
reviews
so
that,
like
one
person,
isn't
blocking
eight
things
and
other
people
only
have
one
thing
on
their
plate.
So
the
thing
is
that
involve
API
changes
are
getting
scheduled
and
then
assigned,
and
people
can
see
like
where,
where
am
I
in
this
process,
what
can
I
expect
as
far
as
like
a
time
frame
for
feedback
and
Andy
to
your
point?
There
are
two
kind
of
types
of
reviews.
We're
looking
to
do.
One
is
things.
D
A
city
highball
okay,
so
if
someone's
doing
something
out
of
tree,
but
it's
you
know
sponsored
by
sick
or
something
they're
gonna,
do
it
as
a
C
or
D,
but
they
want
kind
of
eyes
on
the
API.
To
say
like
is
this
obviously
problematic
advisory
reviews,
our
category
of
thing
that
we're
wanting
to
be
able
to
be
involved
in
as
well
and
so
part
of
that
effort
is
to
get
visibility
on
the
pipeline.
D
D
People
who
want
to
get
involved
can
jump
in
and
take
passes
over
it
and
make
suggestions,
make
observations
and
the
the
API
approver
pool
can
kind
of
give
final
sign-off,
but
then
also
help
mentor
the
people
who
are
jumping
and
doing
kind
of
provisional
reviews
and
say:
oh
well.
This
person
has
given
feedback
on
these
ten
different
API
is
they
did
a
really
good
job,
they're
spotting
things
and
like
catching
things,
and
and
so
this
is
our
effort
to
help
grow.
B
B
You
know
I
mean
just
filtering.
Events
was
like
one
little
piece
of
code
in
this
whole,
you
know
big
PR
and
to
do
that,
as
you
know,
it's
really
just
one
test
to
know
that
you're
doing
that
properly,
you
know
I
just
don't
know
how
much
light
could
really
be
gained
in
this
scenario,
from
from
doing
it
with
a
seer,
C
or
D.
B
D
You
know
so
for
the
for
the
specific
feedback
the
Daniel
had
on
the
API
I
actually
saw
his
comments
come
in,
but
I
hadn't
had
time
to
go.
Look
at
them.
I
know
he
was
kind
of
asking
questions
about
things
that
are
currently
the
beyond
the
file
based
config
and
Tim
was
answering
some
of
those,
but
neither
of
them
are
on
the
call
actually
I
yeah,
so
I
think
Daniel
was
looking
for
more
consistency
with
some
other
like
a
web
hook
related
thing
or
the
admission
web
hook
config.
D
But
if
the
audit
use
cases
are
working
and
makes
sense,
then
I
think
that
would
probably
be
okay
to
leave
as
it
is
yeah
like
I
said
for
112,
the
I
think
it
was
aggressive
to
get
all
of
it
in
and
I.
Don't
know
that
and
this
weekend's
a
holiday
weekend
like
it's,
the
the
rahnaways
super
short
and
I,
think
it's
probably
unlikely
for
112.
D
If
we
want
to
solicit
feedback
about
whether
this
would
be
asked
to
be
done
out
of
tree,
even
in
a
later
release,
we
could
find
that
out.
Like
Tim
said,
I
think
there
are
some
big
voices
and
cigars
that
are
asking
basically
everything
to
be
done.
That
way,
if
at
all
possible,
and
so
I,
don't
know
if
that
is
the
guidance.
If
you
would
want
to
go
ahead
and
start
looking
at
that
or
if
you'd
want
to
wait
and
try
to
get
something
in
the
present
form
in
in
113.
B
D
Big
API
surface
things
coming
in
entry
raise
eyebrows,
and
the
question
is
always:
can
we
do
this
without
bringing
it
entry
just
because
big
API
services
are
take
a
lot
to
support
and
and
sometimes
the
answer
is
no
and
that's
okay
but
I-
think
it's
a
reasonable
thing
to
investigate
and
ask
first
instead
of
just
assuming
yeah.
Well,
entry
is
easy
because
then
I
don't
have
to
think
about
like
how
people
set
this
up.
Well,.
B
D
Is
this
a
use
case
that
people
care
about,
and
so
like
you
don't
want
a
hand,
wave
completely
hand,
wave
or
implementation
details,
but
the
the
agreement
about
this
is
a
valuable
thing
for
those
things
to
pursue
was
I,
think
more
about
the
capability
and
the
feature
set
and,
to
some
extent
even
the
API
is
you
know.
Discussion
of
API
is
is
fine,
whether
they're
native
or
CRD,
to
a
client.
They
should
not
care.
D
B
D
I
think
I
think
this
is
a
good
example
of
an
API
or
feature
that,
on
the
one
hand,
you
could
do
the
Aesir
at
ease.
Like
it's
slow-moving.
You
know
it's
not
a
high
traffic
API,
so
I,
basically
a
config
API,
that's
yeah,
pretty
slow-moving,
but
on
the
other
hand
you
have
the
API
server
itself
using
it
depending
on
it
and
like
how,
if
you
wanted
to
build
the
sending
piece
in
tree
and
have
it
and
implement
the
API
is
a
CRD
like
that.
D
B
D
E
D
B
D
Think
some
some
of
it
is
some
of
it
is
bandwidth
just
because
someone
saw
part
of
it
doesn't
mean
that
everyone
sat
down
and
kind
of
thought
all
the
way
through
it.
Some
of
it
is
yeah
kind
of
settling
on
this
new
proposed
way
of
working
and
reasoning
through
the
implications
on
all
the
things
that
are
in
progress,
and
some
of
it
is
kind
of
individuals.
D
Some
individuals
are
hitting
that
direction
stronger
than
others
and
quickening
on
who
is
looking
at
it
you,
you
will
get
that
feedback
more
strongly,
and
so
again
these
are
things
that
need
to
be
figured
out
and
made
consistent
and
made
clear
and
and
I've
applied,
consistently
to
caps
and
polls
and
and
so
feedback
from
you
to
sig
arch
about
this
experience
and
kind
of
request
for
specific
guidance
would
would
be
a
good
next
step.
I
recommend
that
go.