►
From YouTube: Kubernetes SIG API Machinery 20170927
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).
B
A
A
We're
talking
about
where
to
wait.
Where
did
to
Daniel
go
well
we're
talking
here,
you,
okay,
we're
talking
about
where,
to
put
it,
I
think
that
Daniel
and
I
spoke
briefly.
He
doesn't
want
an
API
server
for
the
dependency
reasons.
That
seems
reasonable,
but
case
I,
hope
kubernetes
plugins
would
be
a
reasonable
spot.
To
put
it,
it
would
give
us
practice
with
another
significant
Kamath
provider
and
then
from
there
we
can
see
about
making
an
actual
removable
interface.
B
Yeah
I
mean
so,
can
you
hear
us
now?
I
turned
off
our
video
yeah,
I,
I
sort
of
understand
the
idea
of
getting
two
concrete
things
in
before
before
we
make
something
a
generic
interface
I'm,
not
very
happy
about
taking
another
huge
chunk
of
dependencies
in
the
main
tree.
I
can
sort
of
live
with
it
if
they're
not
dependency
to
the
generic
generic
API,
server,
library
and
and
especially,
if
David,
if
you,
if
you
or
you,
have
someone
who
can
view
it
like
and
that's
that's
good
I
guess
I
can
live
with
it.
Yeah.
A
B
I
I
would
like
some
agreement
that
we're
not
gonna
let
a
third
one
in
and
take
in
another
huge
dependency
tree
like
we
got
it.
People
people
that
want
to
take
on
huge
we've
got
to
get
to
a
state
where
people
who
want
to
add
huge
chunks
of
compile
time
dependencies
need
to
be
able
to
do
it
out
of
tree
well.
D
D
B
A
B
I,
it's
it's
never
fun.
To
tell
somebody.
No
sorry!
We
we
pre-approved
blocking
the
next
person,
so
it
would
be
good
to
have
some
sort
of
design
in
place
before
the
third
person
shows
up
sure,
okay
and
speaking
of
remote
oval
interfaces.
Let's
go
onto
the
extension
API,
the
storage,
the
storage
thing
that
we
were
discussed
last
week,
I
started
putting
together
something
more
concrete
and
it
turns
out
that
a
new
storage
API
would
be
pretty
involved.
B
So
I
came
to
the
conclusion
that
the
most
practical
thing
to
tell
people
right
now
is
either
deploying
a
CD
cluster
deploy
your
own.
It's
a
cluster
or
sweet
talk
to
your
system
administrator
into
letting
you
use
the
main
clusters.
That's
me:
if
I
were
the
system
administrator,
you
wouldn't
be
convincing
me,
but
but
maybe
some
system
administrators
would
allow
that,
but
yeah
and
I've
got
a
nice
little
well
nicest
I've
got
a
diagram
that
shows
like
sort
of
how
you
might
arrange
or
your
extension
and
the
the
third
option.
B
So
the
second
option,
which
I've
put
here
as
not
recommended,
is
implement
it
in
terms
of
CRT
a
integrated
some
comments
from
David
here
as
to
why
that's
not
a
great
idea,
there's
two
basic
reasons.
One
is
that
when
we
do
come
up
with
another
storage
interface,
there's
no
guarantees
that
we're
going
to
have
a
pre-canned
migration
path
for
your
custom,
CRT
implementation.
The
other
reason
is
that
sneer.
These
are
kind
of
their
own
resources,
with
their
own
initializers
and
finalized
errs
and
if
you've
got.
B
B
Basically,
you're
going
to
have
weird
weird
problems:
yeah
yeah,
then
people
could
write
directly
to
the
CRT
and
bypass
any
customer
validation
that
you
did
well
so
so
use
use
the
type
safety
that
you're
supposedly
gained
by
having
an
extension
API,
actually
so
an
option
three
which,
due
to
comments
by
Clayton
I've
emphasized
that
it
is
not
going
to
show
up
anytime
soon,
is
to
just
wait
for
us
to
get
around
to
building
a
storage,
API
and
I've
listed
out
some
requirements
here.
Some
me
some
of
these
are
Brian
and
it.
E
B
F
D
G
B
D
E
Way,
it
would
be
like
I,
believe,
there's
a
number
of
problems
that
need
to
be
solved,
but
there
there's-
or
we
there's
a
bunch
of
problems
that
we
want
to
solve.
We
haven't
yet
determined
whether
it's
worth
it
to
go,
solve
them
all
together,
because
I
I
kind
of
read
this
as
like
I
think.
Yes,
it
would
be
awesome
if
we
had
this
magical
storage
layer,
but
my
like
practical
thing
would
be
I
bet
we'll
spend
the
next
two
years
doing
very
pragmatic
stuff
that
moves
small
things
forward
across
the
platform.
I
I.
B
H
Yeah
and
then
you'll
point
it
out.
The
other
goal
was
to
make
sure
that
other
folks
who
haven't
been
part
of
this
conversation
don't
go
riding
off
over
hilltops,
tilting
at
windmills
without
direction
and
comes
back
with
a
big
PR.
And
then
we
say
oh
wait,
wait
god
I
think
there's
value
in
it
to
show
that
the
future
vision,
even
though
it's
not
there's
no
effort
going
into
it.
It's.
E
Another
question
that
I
had
I
didn't
add
on
the
dock
would
be
like
which
of
these
things
should
be
things
that
we
suggest
people
to
add
to
Etsy
D,
which,
in
a
sense
like,
even
though
we
want
these
things
like.
Do
we
really
care
that
these
are
in
another
storage
system?
That
isn't
something
like
Etsy
D,
so.
B
I
I'm
totally
fine,
with
with
saying,
like
we're,
gonna
put
more
effort
in
that
CD
and
and
I
mean
honestly.
A
bunch
of
these
things
are
actually
possible
in
that
CD
3,
and
we
just
haven't
done
it
because
we're
kind
of
waffling
about
about
whether
we
want
to
preserve
the
possibility
yeah
bending
to
other
storage,
backends
I
I,
want
to
I
want
to
kind
of
close.
That
conversation
just
be
like
we're.
Gonna
stick
with
that.
A
That
the
most
important
sentence
in
this
third
section
is
actually
at
the
very
bottom.
We
are
interested
in
efforts
spent
on
making
the
existing
storage
interface
cross
process
boundaries
as
long
as
there's
a
path
towards
what
we
want
in
the
things
you
listed
above
I.
Think
that's
the
most
important
thing
right,
like
we
aren't
going
to
take
anything
else,
entry
to
target
a
different
vendor.
That's
fine
I
agree
with
that.
That
makes
sense,
but
someone
who
wants
to
come
in
and
spend
the
time
to
try
to
make
the
existing
storage
interface
cross
process
boundaries.
A
B
A
Have
them
properly
set
up
detection
for
feature
flags
and
versioning,
and
all
that
looks
like
is
your
storage
doesn't
support
this
anything
that
they
might
make?
We
would
be
able
to
classify
as
alpha
very
reasonably
for
3/4,
easy
right.
I
mean
like
proving
out
that
it
works
is
valuable.
We
can
be
beta,
tested,
I,
think
from.
E
C
E
Two
reasons
to
do
that:
one:
you
believe
you
actually
have
a
better
data
store
than
Etsy
D
at
a
particular
scale
factor
which,
while
reasonable,
is
not
true
for
the
vast
majority
of
clusters
that
will
ever
exist
and
the
other
one
is
you
and
I
feel
like
this
is
kind
of
a
harsh
statement.
But,
like
you,
you
really
want
your
thing
to
work
with
cube,
but
that
doesn't
make
you
better.
That
makes
your
life
easier
right,
like
cube,
cube,
running
on
top
of
console,
wouldn't
actually
make
console
matter
when
they
caused
the
worse.
E
B
E
And
like
I,
don't
see
anything
in
it
to
be.
We
except
a
few
of
the
details
were
like
yeah
like
yes,
your
cockroach
DB
down
the
road
might
be
able
to
do
it
better
or
spanner
could
do
it
better
dynamo
could
do
it
better
doing
it
better,
isn't
a
good
enough
reason
to
basically
cut
one
of
the
legs
off
of
cig,
a
P
machinery
and
preserving
its
flexibility
to
make
what
we
have
now
worked
much
much
better.
So
can.
H
H
A
Phrased,
I
can
definitely
agree
with
the
phrasing
in
this
doc.
In
that
last
paragraph,
were
we
to
change
it
and
say
we
weren't
interested
in
trying
to
tune
or
tweak
our
storage
interface,
that
that
sounds
a
lot
like
calcification
and
saying
I,
don't
think,
there's
a
better
way.
This
is
good
enough.
It
does
exactly
what
I
don't.
B
A
F
E
B
Of
putting
this
in
a
dock
and
having
a
position
is
so
that
it's
clear
to
people
from
the
get-go
that
if
they
want
to
go
in
this
direction,
they
really
need
to
start
with.
The
proposal
and
they're
gonna
have
to
work
hard
to
to
get
people
on
board,
but
rather
than
assuming
that
it'll
be
easy
and
going
out
and
doing
a
bunch
of
work.
I.
D
Think
I'm
palatable
way
to
phrase.
This
is
to
say
that
we,
for
now
at
least,
we
feel
like
we're.
We
want
to
invest
our
limited
resources
because
I'm
making
the
implementation
we
have
better
rather
than
on
making
it
possible
to
put
other
implementations
in
place
like
really
focused
on
where
is
like
a
different
back
end,
would
just
be
different
storage
problems.
We
have,
we
don't
have
today,
yeah.
C
H
A
That
I
so
know
that
I
would
go.
That
far
is
wholesale
replacement
right.
So
if
Daniel
comes
to
me
and
in
another
another
quarter
or
two
and
says
hey
to
make
blob
storage
I
don't
want
to
have
to
point
it
to
stock
and
say
sorry,
we're
not
doing
that.
I
want
to
be
able
to
say
yeah,
okay.
So
this
is
the
path
forward
to
doing
that.
A
D
Think
the
jig
paying
was
we're
not
interested
in
kubernetes
that
plugs
into
n
different
storage.
Backends,
like
the
plug
ability,
isn't
the
issue.
We
want
there
to
be
a
single
component
that
we
can
put
our
effort
on
and
make
it
reliable.
So
it's
not
so
much
that
blobster,
it's
not
okay,
but
if
we
wish
to
yeah
well,
which
is
the
first
example
of
the
next
one
you
want.
C
D
B
H
There's
a
staffing
issue
to
this
as
well,
so
we
we've
got
a
full-time
engineer
in
about
half
time
of
a
couple
other
engineers
working
on
at
CD,
we're
looking
to
add
to
that
team
and
I
think
this
makes
sense
as
long
as
a
TD
is
the
answer
for
the
foreseeable
future.
If
it's
one
of
many,
then
this
becomes
a
non
scalable
organizational
issue,
yeah
just
points
or
less.
H
More
contributors
to
at
CD
we'd
like
to
invest
in
that.
So
to
me
that
makes
sense
as
long
as
that
CD
is
that
one
storage
solution
for
kubernetes
but
from
my
perspective,
I'd
love
to
see
a
TD
as
part
of
the
kubernetes
project,
and
that
would
make
it
more
clear
from
outside.
I
think
that
its
intention
is
to
be
the
storage
solution
for
kubernetes.
H
A
H
B
E
B
E
Look
I'll
add
some
comments
about
like
the
wording
of
like
the
positional
statement.
If
I
think
we
iterate
it
looks
a
little
bit
more
and
then
say
like
here's
our
position
statement
on
the
back
end
databases
for
all
these
reasons
and
here's
what
we
recommend
for
these
specific
tactical
problems
that
we
know
people
have
right
now
and
if
you
have
new
technical
problems,
bring
them
up
with
a
sig
and
if
you
want
to
go
rewrite
the
backend,
here's
the
kind
of
criteria
and
here's.
E
Why
we
don't
think
that's
gonna
happen,
and
you
know
here's
a
here's,
a
useful
channel
for
you
to
like
I,
don't
want
to
say
no,
you
cannot
propose
something,
but
we
want
to
say
like
before.
You
promote
something
like
understand
these
points
and
then
probably
just
that
you
that's
this
topper
another
doc.
I
think
this
stock
is
a
good
place
to
do
it
so
that
people
don't
take
that
third
bullet
as
yeah
suggesting
okay.
So.
B
B
B
It's
too
bad:
you
have
to
go.
What
are
the
web
hook
and
initializer
requirements
to
get
the
beta
in
1.9?
We
are
super
interested
in
getting
to
beta
in
1.9.
I
would
rather
agree
on
like
concrete,
concrete
requirements.
I
have
I
have
a
list
which,
unfortunately,
I
haven't
put
them
to
a
public
dock.
Yet
I.
B
B
Maybe
maybe
one
thing
that
we
could
do
useful
usefully
here
is
decide
the
criteria
by
which
we'll
decide
what
should
what
what's
required,
the
beta
the
criteria
for
pre,
curious
yeah,
so
so
I
I'm
gonna
maintain
that
for
beta
it
needs
to
solve
so
I'm
gonna
use
case,
and
it
needs
to
not
break
anything
like
it.
Shouldn't
be
stabilized
Buster's,
I,.
A
Think
that
we
also
we're
going
to
need
to
have
a
1/2
forward,
you
should
at
least
be
able
to
see
how
you
get
from
where
you
are
in
beta
to
something
where,
if
we
wanted
to,
we
could
actually
rewrite
our
admission
chain
in
terms
of
the
extension
points
or
attic.
So
I
can
give
a
concrete
example.
Something
like
PSP
is
a
challenge.
Right.
A
B
A
Yeah,
at
least
in
one
of
the
intervening
level,
I
haven't
gone
back
and
checked
exactly
what
we
locked
down
in
terms
of
immutable
fields
and
odds
after
they
got
be
locked,
but
in
concept.
Yes-
and
you
can
envision
writing
other
admission.
Plugins
that
would
face
similar
problems,
say
a
webhook
admission
plugin
that
was
trying
to
validate
a
field
that
got
reset
during
I.
B
A
A
B
I
B
A
So
if
we
can
get
to
a
point
where
we
can
actually
describe
this
is
how
you
would
write
all
of
our
admission
plugins
as
initializers
or
if
we
write
or
weapons,
but
if
we
can't
write
them
in
that
mode,
then
I,
don't
think
that
we
can,
if
we
can't
write
them
in
that
mode,
and
we
can't
describe
how,
in
three
months
you
will
be
able
to
because
we'll
be
able
to
fix
it
in
a
certain
way.
Then
I
don't
think
we
can
call
it
beta.
H
H
G
C
B
B
E
C
I
A
B
A
B
A
The
thing
is
that
we
have
an
own
set
of
here's,
a
bunch
of
useful
things.
This
is
the
chain
that
we
look
like.
This
is
the
chain
that
we
can
build
and
if
we
don't
have
a
way
to
say
this
is
how
you
do
that
externally,
then
it
really
doesn't
feel
like
a
solution.
It
feels
like
a
maybe
someday
it'll,
be
a
solution
and
I
I'm,
not
saying
we
shouldn't
keep
trying
to
understand
I'm,
hard-pressed
to
call
it
they
get
it
where.
D
C
I
think
beta.
We
want
the
design
to
be
fleshed
out
enough
that
we
can
see
the
use
cases
we
care
about
being
satisfied
by
the
design
and,
there's
always
you
know,
v2
v3,
whatever,
like
future
additional
things,
that's
I'm
not
talking
about
boiling
the
ocean
I'm
talking
about
the
use
cases
that
we
have
today
for
admission
should
be
part
of
that
design
like
you,
should
be
able
to
express
it
in
terms
of
this
externalized
admission.
I
think.
B
C
B
B
C
C
D
B
F
Now
yeah
cause
it
if
what
I'm
hearing
and
I
think
actually
we're
pretty
close
to
saying
the
same
thing
is
basically,
some
people
are
saying:
look
I
would
like
to
understand
what
we
can
do
and
if
that
set
of
can
do
ziz
enough,
then
we're
good.
Maybe
what
we
need
to
do
is
just
pull
back
a
bit.
Take
a
quick
look
at
our
existing
set,
see
which
ones
we
think
we
can
not
eat
not
actually
commend
them,
but
just
make
a
convincing
argument
that
this
set
of
admission
plugins.
We
can
express
this
way.
F
C
An
additional
piece
which
is
the
set
that
we
can't
solve.
We
should
understand
why
we
can't
and
and
understand
what
changes
would
be
required
to
get
there
just
so
we
don't
release
a
beta
version.
That
is,
has
fundamental
flaws.
That
would
prevent
us
from
covering
those
that
last
20%
of
use
cases
so.
F
F
A
Don't
have
a
crisp
list
of
precisely
what
is
missing
and
before
we
go
to
beta
I
want
not
just
a
crisp
list.
I
want
to
have
a
fairly
concrete
detail
design
describing
how
we
intend
to
get
there
so
that
we
can
be
sure
that
anything
we
call
beta
doesn't
box
us
out
of
actually
fixing
the
problems
that
we
need
to
address.
So
it's
not
just
identifying
what
gasps
we
have
to
overcome.
It
is
actually
designing
those
pieces.
B
H
So
can
you
guys
hear
me
now,
yes,
I
just
wanted
to
chime
in
with
a
couple
other
thoughts,
there's
a
cost
to
not
bringing
it
to
beta
in
that.
What
is
what
exists
today
is
already
useful
to
other
projects
like
sto
and
Service
Catalog,
which
are
both
open
source
projects.
Trying
to
use
initializers,
which
our
recommended
path
for
doing
this
and
not
bringing
it
to
beta,
is
inspiring
some
creative
workarounds
that
we'll
have
to
deal
with
in
the
future
as
well.
Yeah
don't
get.
H
So
it's
my
bad
I
was
just
expressing
that
there
is
a
real-world
solution
in
what
exists
today
for
some
use
cases
and
second
I
was
gonna,
say
I
think
articulating.
The
goal,
as
we
need
to
imagine
every
use
case
and
have
a
clear,
concrete
design,
is
maybe
too
high
a
goal.
We
should
have
I,
think
a
solid
design
and
then
I
think
the
onus
shifts
in
some
way
to
poke
holes
in
the
design
and
come
up
with
counter
examples
for
which
the
design
does
is
not
sufficient.
Okay,.
C
E
B
A
That
I
think
that
taking
the
time
to
say,
okay,
this
is
what
we
have
today.
We
know
that
these
are
valid
use
cases.
How
would
we
satisfy
them?
Let
me
design
the
pieces
and
see
where
everything
lands
is
just
a
matter
of
due
diligence
before
calling
what
you
have
beta
right,
I'm,
not
saying
that
you
have
to
go,
implement
all
those
pieces,
but
what
I
am
saying
is
that
you
need
to
have
a
concrete
design
for
how
you
would
otherwise
you
can
make
choices
in
an
API
that
are.
D
D
But
let's
be,
let's
be
honest
with
ourselves
and
the
people
we
tell
that
it's
baby
I
totally
get
where
Jake
is
coming
from
and
that
kind
of
like
encouraging
people
to
do
some
workarounds.
That
may
be
unpleasant
if
we
don't
get
to
beta
quickly.
That
said,
let's
be
honest
about
whether
or
not
we
can
call
this
beta.
We
should
not
call
it
beta.
If
we
have
real-world
use
cases
that
you
know,
we
would
say
we're
actually
not
sure.
How
are
you?
That's
not
good.
I
agree.
I.
A
B
Yeah
I,
don't
know
I'm
bias
towards
providing
people,
something
that
that
works
and
solves
a
problem
as
fast
as
possible.
Like
that,
that's
that's
how
we
have
done
things
in
this
project
historically,
at
the
expense
of
incurring
a
lot
more
technical
debt
than
I
would
be
comfortable
with,
but
this
is
an
extension
feature
which
allows
people
to
get
the
technical
debt
into
their
own
repositories
rather
than
entry,
so
I'm
willing
to
incur
additional
technical
day.
C
H
H
A
H
A
A
I
we
can
find
someone.
A
couple
names
come
to
mind.
I'm
gonna
have
to
talk
to
them
before
eyeballin
told
them.
Sir
yeah
we're
planning
on
having
a
team
work
on
this
here
too.
So,
but
I
do
see
that
as
a
blocker
for
beta.
But,
yes,
we
will
find
someone
to
help
and
help
work
through
those
design
challenges,
get
it
to
that
state.
J
Initializer
and
Webfoot
needs
to
go
to
play
the
same
time,
because
I'm
thinking
some
of
the
problems
can
only
be
solved
by
Web
Clips
like
how
can
we
handle
mutation?
Your
way
update,
that's
initializer,
you
know,
stop
that
so
developing
on
david's
argument,
I'm
trying
to
say
some
can
we
can
we
claim
in
its
various
beta
without
such
designing,
how
the
web
works.
You
can't
in
the
face,
because
I
think
there
are
two
distinctive
pieces.
B
C
D
A
A
I'm
being
able
just
saying
in
a
broad
sense,
we
need
to
be
able
to
describe
our
current
admission
chain
in
terms
of
extensible
pieces
of
admission.
Is
it's
actually
fairly
broad
and
gives
you
and
drives
most
of
the
requirements?
I
don't
want
to
have
imaginary
requires
things
like
I
can
imagine
someone
writing
a
different
mission
plugin
that
does
this
and
that's
interest,
but
we
have.
D
So
slightly
reversing
myself
and
they've
been
sitting
here.
I
think
that
we,
both
essential
disagreement,
might
be
about,
is
essentially
with
the
definition
of
product
is
the
first
place.
Is
it
supposed
to
be
able
to
support
the
externalization
of
all
parts
of
admission,
or
is
it
just
supposed
to
be
better
than
today
better
than
yesterday
and.
C
D
C
D
B
B
A
B
B
C
C
I
mean
that
seems
like
a
false,
false
confidence.
If
the
point
is
they
can't
use
alpha,
because
there
are
policies
that
prohibit
enabling,
because
it's
not
stable,
so
let's
declare
it
beta,
so
it
can
be
quote,
unquote
stable,
but
we're
not
really
any
more
confident
that
it's
going
to
be
actually
stable.
That
seems
disingenuous
on.
F
B
Yes,
if
we
were
to
go
to
beta
like
we
have
a
documented
deprecation
policy,
that
means
we'd
have
to
live
with
a
couple
quarters
like,
and
we
would
support
it
for
a
couple
quarters
if
you
do
something
that's
beta
like,
even
if
we
think
that
we're
not
going
to
be
changing
it,
you
use
something.
That's
way
that
you're
taking
to
this,
that
the
deprecation
policy
is
going
to
happen.
One
quarter
sooner
than
it
would
have
gone
to
you
want
I
mean,
but
that's.
B
H
Dead,
just
the
time
checking
a
quick
proposal.
It's
about
five
of
just
to
close
out
on
this
I'd
like
to
propose
that
we
staff
it.
We
come
back
in
two
weeks
and
time
box
it
and
say
this
is
as
far
as
we
got
in
a
document.
How
far
off
is
this
from
the
level
of
design
detail
that
folks
are
comfortable
with
and
it
may
be
super
far
off
and
it
may
be
not
but
I
think
there's
a
lot
of
speculation
going
on
and
I
think
this
is
the
best
next
step
in.
H
I'm
not
saying
that
you
will
agree
that
it
is
a
concrete
design.
What
I'm
saying
is:
let's
staff
it
and
come
up
with
a
document,
and
in
two
weeks
you
can
give
feedback,
whether
you
believe
that
is
a
concrete
design
or
not
sure,
without
that
I'm
speculating
as
to
what
you
mean
by
concrete
design
and
that
there's
no
specificity
around
what
what
that
means.
Okay,.
H
B
Okay,
let's,
let's
let's
break
for
the
day
and
we'll
leave.