►
From YouTube: Kubernetes SIG API Machinery 20171025
Description
For more information on this public meeting see this page: https://github.com/kubernetes/community/tree/master/sig-api-machinery
A
A
B
B
B
Okay,
so
the
main
suggestion
is
to
use
slash,
open,
API,
slash,
v2
or
v3,
read
some
HTTP
headers
to
tell
the
server
what
you
want.
You
want
it
in
JSON,
ya,
know
or
or
proto,
and
which
version
you
want
don't
want.
If
you
want
it
to
be
a
state
or
not.
This
is
the
main
suggestion.
The
alternative
suggestion
is
to
have
the
open
API
as
and
a
kubernetes
api
object
store
it
in
actually
actually
store
it.
In
a
CD
and
I
have
I
have
the
design
design
details
there
I
think
some
people
already
commented
there.
B
The
main
benefit
of
the
alternative
design
is
first
of
all
the
amenities
we
get
whatever
we
get
from
the
API.
It's
like
you
know,
different
head.
We
can
set
different
headers
for
that
or
I
think
we
can
watch
so
watch
versioning.
The
standard
access
today
object
to
get
all
of
those
arts
and
everything
so
using
another
endpoint
we'll
need
to
set
the
different
different
type
of
parts.
We
need
to
set
up,
watch
and
everything
else.
So
that's
the
benefit.
B
A
C
So
I
just
I
want
to
ask
like
I.
We
should
be
careful
around
some
of
the
things
right
now
and
then
it's
already
discussing
the
dock.
The
general
idea
here
I'm
watching
something
that's
describing
the
thing
that
you're
watching.
Is
it
because
this
is
a
downstream
metadata
about
something
that
we
have
an
upstream
discovery
for
that?
That
makes
that
okay,
like
we're
saying
well,
you
can
discover
that
open
API
exists
so
that
you
can
then
follow
the
discovery
to
go.
Get
the
open,
API.
A
B
E
A
B
B
C
C
We've
talked
about
things
like
we
want
to
push
validation
the
server
just
because
it's
too
much
work
for
clients
to
go
do
their
own
open,
API
validation
are
we
are
we
a
little
too
focused
on
open
API
as
a
like
I
guess,
I'm
I'm
kind
of
asking
how
important
is
open
API
like
I,
get
the
feeling
that
there's
a
couple
of
use
cases
which
maybe
I
don't
see
why
the
urgency
of
open
API?
Is
this
primal
thing?
That's
fundamentally
the
first-class
kubernetes
concept
that's
exposed
other
than
it
helps
for
automation.
C
A
C
Not
saying
that
this
is
a
google
ism,
that's
leaking
out
into
the
world.
I'm
kind
of
saying
this
is
a
Google
is
like
I'm
a
little
worried.
It's
not
a
Google
ism
I
mean
I.
Gotta,
be
honest
like
there's
a
little
bit
of
this,
which
is
like
open
API
is
great.
It's
not
a
magic
bullet.
I've
been
around
this
block
a
long
time
and
I've
seen
many
of
these
systems
get
really
close
and
then
fail
and
be
good
for
80%
of
the
things,
but
not
a
hundred
percent.
C
Are
we
trying
to
go
for
the
hundred
percent
solution
on
open
API
here
like
like?
If
we're
gonna
make
a
big
investment
in
like
structured
api's
and
all
that
model-driven
api
is
great?
How
much
of
it
do
we
have
to
do
to
deliver
value
for
kubernetes
users
like?
Is
it
80%,
90%
or
a
hundred
percent,
because
I
feel
like
we're
going
for
a
hundred
percent?
But
you.
A
C
G
If
the
main
point
is
client-side
stuff,
then
endpoints
and
schemas
are
what
clients
need
right.
Like
the
validation
we've
said
for
a
long
time,
we
don't
want
that
done.
Client-Side
we
want
that
done,
server-side
and
so,
whether
that's
driven
by
model
stuff
and
open
API
or
some
other
mechanism
from
a
client
perspective.
That's
not
really
crucial.
G
I
see
a
lot
of
things
kind
of
calling
out
open,
API
like
oh,
we
can
put
examples
and,
like
templates,
that
you
could
use
to
create
objects
of
this
kind.
We
can
put
that
in
open
api
objects
and
that
that
seems
like
it's
creeping
past
be
like
we
want
to
be
able
to
generate
a
client
that
knows
what
endpoint
to
talk
to
him.
What
scheme
addition
that
yeah.
A
I
think
one
place
that
open
API
could
fit
in
your
server
stack
is
if,
if
we
want
like
the
aggregator
or
are
ya
say
we
want
the
aggregator
to
validate
like
you
do
entity
check
on
an
incoming
object,
I
mean
C
or
D
is,
is
going
this
way
right,
so
you
you
can
put
an
open,
API,
spec
in
and
C
or
D
checks
it.
This
way.
D
D
A
A
C
Was
not
trying
to
sit
down
just
saying
I
feel
like
this
discussion
is
lacking.
A
scope
for
open
API
and
I
have
seen
a
lot
of
changes
in
the
last
six
months,
where
open
API
is
being
very
aggressively.
Pushed
I
just
want
to
I'm
using
this
as
an
opportunity
to
ask
what
are
we
actually
trying
to
solve,
because
I
can't
evaluate
this
proposal
without
actually
knowing
how
far
we're
trying
to
put
down
the
open
me
up
yeah.
So.
A
A
C
Not
trying
to
be
obstructionist
here,
like
I,
actually
think
even
just
the
base
proposal
of
I'm,
just
saying
like
we
should
have
an
actual
version
to
open,
API
endpoint,
completely
agree
with
I
would
I
would
agree
to
the
minimum
with
no
extra
discussion.
It
is
the
next
step
that
I
am
worried
about
which
is
I.
Have
we've
done
all
we
did
an
abortive
aggregation
attempt
and
API
server.
We
weren't.
Quite
we
were
a
little
concerned
about
that.
C
A
A
E
H
A
H
A
I
So
I
need
an
issue
for
this
last
week
of
the
week
before
anything
mentioned
it
on
slack
or
possibly,
the
meeting,
even
with
feature
freeze
going
on
Friday
I
plan
to
submit
PRS
for
the
future
repo
and
for
the
feature
getting
that
we'll
go
ahead
and
move
Siri
validation
in
beta
I.
Think
there's
only
one
comment
left
on
the
issue
that
I
opened
and
all
of
the
items
mentioned,
and
it
are
things
that
can
be
retrofitted
back
on
even
after
it
moves
to
beta,
but
I
wanted
to
call
it
out
today.
I
D
J
G
B
B
J
B
B
F
In
fact,
in
the
sig
CLI
we
talked
about
the
premise
of
an
SDK
and
what
it
would
take
to
get
there,
and
so
I
was
hoping
to
figure
out
or
start
a
conversation
on.
How
do
we
go
from
where
we
are
to
something
that
is
exceedingly
consumable
for
people
who
want
to
build
tools
on
top
of
kubernetes
and
I'm
happy
to
add
more
context
anywhere,
somebody's
got
questions
on
what
I
mean
yeah.
F
That
external
tool
could
be
coop
control,
it
could
be
helm,
it
could
be
some
fun
new
tools.
Somebody's
writing.
There
are
a
lot
of
tools
that
need
a
library
or
an
SDK
in
order
to
interact
with
kubernetes
api
x',
and
they
need
to
things
like
when
there's
a
version
upgrade
how
the
heck
do
I
deal
with
upgrading
from
one
version
to
the
next.
How
do
I
deal
with
interacting
with
multiple
versions
of
kubernetes?
A
Let
me
let
me
give
the
history
as
I
understand
it,
so
the
API
machinery
were
blocked
and
a
bunch
of
stuff
until
we
could
sort
of
publish
things
differently.
Like
the
you
know,
separate
clients
vendor
that
without
been
during
the
entire,
the
entire
world
need
to
be
API
types
split
out,
so
that
people
could
bender
a
client
and
they
could
vendor
the
types
and
they
could,
you
know,
use
some
other
code
without
having
a
big
diamond
problem.
So
we
sort
of
did
what
we
had
to
to
unblock
ourselves.
A
I
have
a
road
map,
doc
I'm
like
how
sort
of
what
the
next
steps
would
be,
but
it's
there
was
enough
organizational
pushback
on
continuing
to
make
improvements
that
I
sort
of
gave
up
on
it
for
the
moment,
and
it's
not
blocking
anything
in
sig
API
machine
resources
like
just
not
our
top
priority
I
think
there
were
two
parts
of
that
all
right.
Are
there
two
parts
of
this
conversation?
One
is
the
repo
split
and
additional
repo
organization,
and
then
second
to
me,
is
distinct.
A
A
It
probably
is
going
to
like
just
like
our
documentation,
took
like
one
or
two
people
sitting
down
and
making
it
make
sense
like
it's
going
to
take
new
people
locking
themselves
in
a
room
until
we
get
a
coherent
sort
of
SDK
together
and
just
nobody's
done
it,
but
it
says
game
with
the
big
stage.
So
maybe
this
is
kind
of
the
opportunity
for
a
working
group
that
are
you
interested
in
that
kind
of
arrangement.
Hang.
D
D
But
if
you
are
trying
instead
of
working
on
kubernetes
you're
trying
to
develop
something
separate
that
is
attempting
to
vendor
repos
that
do
already
exist
today,
I'm,
not
sure
that
someone
would
perceive
that
much
of
a
difference
right,
you
have
a
client
go
master
is
compatible
with
master.
You
have
particular
branches
named
so
that
they
go
together.
Release
one
eight
release,
one
seven
match
together:
I
can
imagine
having
difficulty
making
ven
during
tools
work,
but
trying
to
run
our
development
process
for
kube
internal
I.
Don't
think
that
Matt
would
see
a
difference.
So
just
Matt.
A
F
A
E
F
Part
of
this
is
the
we'll
get
into
the
upgrade
experience.
That
was
one
of
the
things
we
discussed
in
say:
gaps
is
when
you
went
for
the
version
that
was
designed
for
kubernetes
1:7,
and
now
you
need
the
version
designed
for
kubernetes
1:8,
actually
taking
your
application
and
upgrading
it
to
new
use.
The
new
version
was
really
difficult
and
time-consuming,
and
that's
come
from
a
number
of
different
people
working
on
a
number
of
different
projects.
F
And
experience
then
there's
the
whole
point
in
getting
this
right
so
for
right
now,
if
you
want
to
go,
get
client
go.
How
do
you
go
consume?
It
I
mean
you
can
go
to
the
repo,
but
when
1.8
came
out,
the
version
4
of
1.8
wasn't
there
in
the
repo,
so
people
would
have
to
pull
down
all
of
kubernetes
then
copy
from
the
staging
directory
into
the
right
place
in
the
vendor
directory,
because
we
don't
have
our
stuff
in
sync.
Okay,
so.
D
You
that's
that's
really
helpful
so
for
the
cloning
problem.
I
know
that
Stefan
has
been
working
relentlessly.
Trying
to
get
these
pieces
working.
He
and
chaough
have
been
trying
to
get
a
bot
ready
to
push
I'm,
not
aware
of
where
it's
currently
stuck,
but
that
is
a
problem
that
is
actively
being
worked,
and
it
is
one
that
we
should
be
able
to
solve
right.
It
shouldn't
take
off.
We
get
updates.
You.
A
Have
their
problem,
the
the
unclear
afraid,
experience
is
kind
of
directly
caused
by
our
structure
with
it
being
in
staging,
because
the
the
release
no
generation
and
the
main
kubernetes
repo
is
directed
towards
releases
of
kubernetes
is
not
clear,
which
PRS
effect
the
interfaces
that
client
go
exports.
So
that's
it.
A
Work
on
that
and
we
we
have
some
people
actually
working
on
it,
but
I
don't
know
I
I
think
it's
gonna
be
really
hard
to
get
this
right
until
we
ourselves,
the
kubernetes
engineers
are
battling
this
problem
and
the
only
way
we're
gonna
battle.
This
problem
is:
if
we
switch
our
development
direction,
I.
D
F
D
Instead,
what
if
we
tried
to
actually
use
our
semantic
versions
and
do
something
like
client
go,
would
be
capable
of
generating
code
a
for
version
4.1
that
had
version
one
eight
types.
Would
that
have
worked
better?
Would
you
then
have
chosen
to
upgrade
to
version
4.1
instead
of
trying
to
upgrade
to
version
5?
A
F
A
F
F
E
E
A
G
G
Or
set
up
a
washer
or
whatever
and
the
kubernetes
api
types
are
much
slower,
moving
and
typically
much
more
additive.
Only
that's
not
always
the
case,
but
that
is
almost
always
the
case,
and
so,
if
you
were
using
the
same,
go
api's
to
open,
watches
and
listings
and
create
an
update
things
and
just
the
api
structs
that
got
sent
across
the
wire
to
kubernetes,
where
the
things
getting
changed
or
picking
up
a
new
field
or
adding
a
new
version.
That
would
be
a
much
smaller
change
to
make.
Considering
that
client,
yeah.
F
And
I
think
that
would
be
a
lot
easier,
especially
for
folks
who
have
to
upgrade
because
they
say:
oh
look,
it's
just
you
know
got
the
new
types
that
I
need
to
deal
with.
I'll
upgrade
to
that.
I
can
interact
with
the
new
types
in
the
way
that
I
need
to
that's
a
small
change
for
their
code,
a
small
conceptual
change
for
them.
They
don't
have
to
deal
with.
How
do
I
do
this
thing
differently?
Oh
you
know.
F
Instead
of
importing
API
machinery
I
just
import
API,
you
can
start
looking
at
how
this
works
differently,
and
some
of
this
is
because
of
leaky
abstractions
right,
because
some
of
the
things
you
get
from
client
go
require
you
to
also
import
API
machinery,
and
so,
if
you
could
have
a
nice,
concise
package
that
just
did
the
client
and
then
slowly
as
new
api's
came
out.
Maybe
you
know
6.1
6.2
6.3,
and
there
was
less
churn
on
the
structure
of
the
code
and
just
brought
in
the
new
API
types
and
being
able
to
interact
with
them.
K
D
A
There's
actually
two
problems
didn't
hear
that
that
are
kind
of
directly
opposed
and
one.
On
the
one
hand,
we
the
kubernetes
team,
need
to
add
features
and
make
progress,
and
you
know
make
changes
which
are
hopefully
improvements.
On
the
other
hand,
users
of
client
code
don't
want
to
update
their
code
very
often
and
like
you,
can't
really
have
both
of
those
things.
At
the
same
time,
they
do
want
the
new
feature.
They
do
right.
A
It
seems
like
there's
consensus
and
agreement
that
there
is
pain
to
be
solved.
That
was
not
my
initial
impression,
but
it
seems
like
there
is
clear
understanding
that
oh
yeah,
there
are
improvements
we
made
yeah
I
think
we
made
it
about
a
third
of
the
way
through
your
initial
doc,
which
was
the
worst
of
the
pain
on
the
producer
side,
but
not
much
consideration
on
that
is
merged.
Yeah
err,
I
mean
I,
see
every
time.
Somebody
opens
an
issue
in
client:
go
I,
get
an
email,
so
I'm
very
well
aware
of
yeah.
A
F
Yeah,
that's
the
sync
outfit,
but
that
still
doesn't
solve
the
the
structure
of.
What's
going
on
in
client,
go
I
mean.
Should
this
be
the
case
from
what
I'm
hearing
that
we
move
from
what
client
go
is
now
in
the
way
it
is
to
kind
of
more
the
way
the
other
clients
are
generated
and
maybe
generated
from
the
open,
API
documentation,
plus
some
ultimately.
A
J
A
B
Our
tooling
completely
support
that
the
generators
that
we
have
played
knocking
generated
for
ago
the
thing
is
I.
You
know,
I
think
the
difference
here
is
and
I
don't
see
that
much
problem
of
creating
in
native
clients,
because
we
don't
have
much.
There
are
definitely
less
features
there
and
but
but
not
everybody
wants
all
of
those
client
go
features.
They
may
simply
want
to
call
some
api's
and
they
can
do
it
generated
version.
There
is
no
designed
out
there
and
definitely
they
should
be
if
we
want
to
pursue
that,
we
should
convert
them
to
see.
H
Just
interesting
yeah,
so
Matt
Matt
I,
said:
there's
a
lot
on
Fringe
on
money.
I
try
to
operate
from
one
point:
seven
one:
five
eight
I
want
to
understand
if
it's,
because
we
splitted
the
API
out
in
between
that
where
they
cycle,
because
the
actual
nature
the
API
is
removed
it
from
the
triangle
we
hope
being
as
released,
but
we
will
not
have
this
kind
of
this
problem.
Disruptive
change
in
the
future
I
want
understand
how
much
of
the
problem
is
caused
by
this?
That.
F
Release
is
brought
up,
date
has
brought
disruptive
changes,
and
so
even
one
six
two
one
seven
was
disruptive
and
frustrating
that
was
one
of
the
pieces
of
feedback.
They
came
out
the
retrospective
back
then
as
well,
and
so
it's
not
just
this
one
time
something
happened.
It's
kind
of
an
ongoing
thing.
K
So
I
went
through
and
I
up
created
a
program
yesterday
today
from
4:00
to
5:00,
and
there
were
three
things
that
I
ran
into.
One
was
the
moving
of
the
api's
out
of
Congo
and
indicates
that
Oh
API.
That
was
an
easy
fix.
Another
one
were
some
changes
that
Clayton
did
for
the
speedy,
remote
command
execution,
also
an
easy
fix,
and
then
the
third
one
I
happen
to
be
calling
in
to
I
was
creating
a
dynamic
client
and
expecting
it
to
return
a
pointer
to
a
struct.
And
it's
now
returning
an.
K
Also,
an
easy
fix,
I
think,
there's
probably
two
things
that
would
be
helpful,
one
we
already
talked
about,
which
is
making
it
possible
for
you
just
to
get
the
new
API
types
without
having
to
change
the
major'
version
on
your
client
and
the
second
one
would
be
having
excellent
documentation
around
what
are
the
breaking
changes
between
b4,
b5,
b6
and
so
on.
We.
H
A
I
mean
it
is
the
way
it
is
because
this
is
the
most
direct
route
to
publishing
a
go
client.
This
just
to
publish
the
one
that
we
ourselves
are
using.
Okay,
III
I,
don't
know
what
concrete
action
items
we
can
get
out
of
this,
because
it's
kind
of
a
large
problem.
I
know
if,
if
people
are
interested
in
starting
that
working
group,
that
rock
has
and
has
worked
a
little
bit
on
various
related
things.
If
we're
just
making.
A
J
D
A
D
A
J
A
Okay,
under
a
larger
question,
though,
I
still
feel
like
there
are
API
machinery
interests
or
Sigma
CLI.
Just
there
are
also
chapters
on
Kindred
X
and
the
biggest
problem
in
this
project.
In
my
last
six
months,
observation
is
that
there's
no
real
ownership,
and
so
it
sort
of
is
someone
call
9-1-1
instead
of
hugh,
specifically
call
9-1-1
come
back
here,
and
so
that's
why
I
suggest
the
working
group
path.
Otherwise
it
seems
to
fall
through
the
cracks
Louis
after
release.
I
am
NOT
volunteering
to
lead
that
work.
A
F
C
F
I'm
also
willing
to
take
this
back
to
say,
gaps
because
there
a
number
of
people
over
there
who
are
really
interested
in
this
and
see
what
comes
of
that
I
do
see.
You
know.
Maybe
this
is
people
from
a
few
different
SIG's
have
bested
interests,
working
group.
What
you
know,
whatever
we
do
to
organize
around
it,
I
think
would
be
worthwhile,
and
so
I
can
fire
this
off
to
sig
CLI
again
and
then
take
it
back
to
see
gaps
in
the
next
meeting
on
Monday
and
see
if
there's
any
interest
there
too,.
B
A
D
E
E
C
D
Because
I
noticed
there
have
been
some
significant
changes
to
the
dock.
Further
on
there
were
some
questions,
I
think
they
have
been
answered,
but
yeah.
You
know
I
think
we
agreed
to
a
snapshot
in
time
and
then,
if
anyone
were
going
to
change
it
from
that
snapshot
in
time
I,
don't
you
see
those
change
bars,
yeah.