►
From YouTube: A Vision For API Machinery: Coming to Terms with the Platform We Built - Daniel Smith, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A Vision For API Machinery: Coming to Terms with the Platform We Built - Daniel Smith, Google
Kubernetes is what it is in large part due to the API Machinery it is constructed from and co-evolved with. At this point in the project’s life, we have a much richer understanding of the users API Machinery serves--and their needs. And so we propose a path forward, describing how API Machinery can better serve these and future users, and how the Kubernetes runtime, libraries, tools, and repositories can be refactored in service of this goal. API Machinery is a force multiplier for Kubernetes, but often disguised as a tax; it’s time to rectify this together.
To learn more: https://sched.co/GrTu
A
My
talk
is
a
vision
for
API
machinery
and
it's
my
vision
and
Who
am
I
since
I've
been
here
a
long
time,
but
there's
many
people
at
this
conference-
and
maybe
you
don't
know
me,
I'm
I'm
daniel
Smith
I've
been
working
on
kubernetes
since
before
was
open-source
I
work
for
Google
there's
some
contact
information.
So,
although
the
the
some
of
the
details
in
this
talk
might
just
be
my
vision
in
particular
I
think
the
broad
strokes
are
shared
by
a
lot
of
people
and
so
I
hope.
You'll
agree
with
me.
A
A
A
The
amount
of
uptake
has
just
been
phenomenal:
there's
something
like
8,000
people
here
at
this
conference,
which
is
like
10x
growth
for
every
year
of
the
project,
or
something
ridiculous
is
really
crazy,
so
and
and
the
reason
I
tell
I
say
that
is
just
to
sort
of
set
the
set
the
stage
for
everything
that
I'm
going
to
say
next
and
the
next
thing
I
want
to
talk
about
is
our
is
our
code,
so
I
want
to
give
you
just
a
very,
very
brief
tour
of.
Where
did
our
code
for
API
machinery?
How
did
it
evolve?
A
A
So
here's
the
here's,
the
endpoints
object.
You
can
see.
There's
no
header,
there's
a
very
brief
comment:
there,
there's
no
real
structure
and
below
it.
I
have
the
function
that
parses
it
you
don't
have
to
understand
this.
The
point
is,
is
very
simple:
there's
not
much
here,
there's
no
machinery
really.
A
We
had
to
write
a
parse
X
for
every
X
in
the
system,
not
very
user-friendly,
not
very
repeatable
easy
to
make
mistakes
shortly
after
that
I
think
it
was
probably
me:
we've
got
a
JSON
base
here,
which
is
embedded
into
every
type,
so
we
have
some
consistent
things
here.
We
have
a
sort
of
a
type
and
an
ID
and
a
timestamp.
A
We've
got
JSON
and
the
ML
tags
now
and
and
we're
starting
to
get
to
the
point
where
we
could
probably
have
some
generic
Marshall
and
Marshall
functions.
Not
long
after
that
we
have
we've
changed
the
name
to
type
meta.
It's
grown
more
things
got
some
comments,
not
long
after
that
you
can
see,
it
gets
longer
and
longer
it
goes
off.
The
screen.
I
didn't
even
pull
up
a
recent
one,
because
all
that
happens
is
it
just
gets
longer
and
longer
and
add
some
prototypes,
and
you
can
see
now:
we've
got
detailed
documentation
on
every
field.
A
The
machinery
like
puts
that
out
into
the
discovery
documents.
So
the
point
of
this
is
to
is
to
show
you
that
the
trajectory
is
getting
more
complicated,
more
sophisticated,
more
features,
more
places
for
you
to
document
your
intent
and
the
machinery
does
more
things
for
you
like
I'm,
not
showing
you
the
the
code
for
serializing
and
deserializing,
because
we
could
spend
the
whole
talk
on
that,
and
that's
not
what
you
came
here
for
the
final
story.
A
A
On
kubernetes
first
came
out:
we
had
pods
replica
sets
and
and
deployments
as
management
technologies,
although
replica
sets
had
a
different
name
at
the
time.
I
won't
go
into
that
as
kubernetes
grew
up.
We
grew
more
management
systems
for
four
pods
and
and
and
I
think
you
all
probably
know
like
pods
or
collections
of
containers.
Replicas
sets
are
striping
pods
across
machines
deployments.
A
A
One
way
is
Q
control
apply.
Maybe
you
have
a
CI
CD
system.
Cute
control
apply
works
particularly
well.
If
there's
not
much
in
the
way
of
parameterization,
you
have
to
pass
to
these
things.
Maybe
if
you're
a
little
bit
more
complicated,
you
have
a
CI
CD
system,
but
if
your
workload
is
even
more
complicated-
and
you
know
something
specific
about
it,
you
can
do
better.
You
can
write
a
custom.
A
And
so
then
the
obvious
question
is:
how
do
you
manage
your
custom
operator
and,
as
you
walk
the
the
abstraction
ladder
here,
your
stuff
is
getting
more
and
more
abstract,
but
that
means
the
interface
is
getting
simpler
and
simpler
unless
you're
doing
wrong,
but
the
interface
should
be
getting
simpler
and
simpler,
and
this
means
eventually
you're
going
to
get
to
something
that
you
can
manage
with
very
few
templatized
variable.
So
you
can,
you
can
basically
manage
it
with
the
deployment
use,
queue,
control,
apply
and-
and
you
know
worst
case-
you
can
layer
it
again.
A
So
you
end
up
with
an
operator
operator
and
I
want
I
want
to
say
that
that
that's
that's
where
I
stop.
So
you
know
you
don't
need
to
get
more
complicated
than
that.
You
don't
need
to
get
more
abstract
than
that
right,
an
operator
operators
just
another
operator,
so
we
can
manage
an
arbitrary
amount
of
technical
infrastructure
with
the
concepts
that
we've
developed.
We
don't
need
to
develop
more
concepts.
A
Sometimes
people
think
of
individual
API
calls
like
a
put
or
a
get
or,
if
you're
doing
something
more
custom
with
G
RPC
like
you
can
just
have
arbitrary
words.
So
I'm
not
talking
about
that
I'm
talking
about
the
the
resource
model
right,
like
all
of
the
resources,
the
kubernetes
exposes,
have
the
same
verbs,
the
same
words
and
by
the
way
when
I
say
resource
I
mean
that
the
type
I
like
to
call
individual
items
objects
just
in
case,
that's
not
clear.
So
the
kubernetes
has
a
consistent
resource
model.
A
It
is
compartmental
and
reusable,
and-
and
this
means
like
the
the
things
that
we
make-
API
objects
for
the
things
that
we
make
resources
for.
Are
you
there?
There
are
little
pieces
of
functionality
that
you
can
mix
up
and
combine
with
with
operators
and
controllers
and
higher
level
abstractions.
So
API
machinery,
in
contrast,
supports
an
extensible
API
and
we
have
two
primary
modes
of
extensions.
I'm
going
to
argue
one
is
types
or
you
can.
You
can
add
more
resources
to
the
system.
The
other
one
is
policy
you
can.
A
You
can
have
like
admission
web
hooks
or
authorization
Web
books,
so
there's
like
two
two
primary
dimensions
of
extensible
plugin
hooks
and
API
machinery.
So
what's
the
difference
between
API
machinery
and
kubernetes,
I'm
gonna
do
go
through
some
compare
and
contrast,
slides,
real,
quick,
so
kubernetes
and
API
machinery
both
have
api's
kubernetes
api
czar.
You
know,
and
these
are
not
complete
lists.
These
are
just
to
give
you
the
idea.
A
So
the
the
real
list
for
kubernetes
api
is
is
quite
long
but
deployment
pod,
endpoints
node,
like
services,
those
are
those
are
kubernetes
specific
api's
api
machinery.
Api's
are
much
more
general
like
custom
resource
definition.
That's
CRTs
is
how
you
the
primary
way
of
adding
types
of
the
system
API
service.
The
way
of
adding
aggregated
api
is
ordered
addition.
Another
way
of
adding
types
to
the
system,
namespace
a
container
for
other
types,
other
objects,
webhook
configuration
object.
These
are
api
machinery
api's.
A
All
of
these
things
are
served
out
of
the
binary
cube
api
server
so
operationally.
If
you've
ever
tried
to
run
kubernetes
api
server
is
one
of
the
binaries
you
run
and
it
runs
a
collection
of
code.
Some
of
it
is
kubernetes
specific
and
some
of
it
I'll
argue
is
api
machinery
specific.
The
kubernetes
code
is
like
the
all
the
handlers
for
the
built-in
resources,
the
the
validation
code
right.
A
So
so,
like
node
pod,
you
know
the
the
validation
code
there's
some
especially
interesting
custom,
sub,
sub
resource
handlers
like
the
the
logs
employing
or
the
proxy
or
the
port
forward,
like
those
those
like
break
glass
ways
of
getting
out
of
the
kubernetes
api
model
api.
Sir
api
machinery.
On
the
other
hand,
we
own
the
aggregator,
which
is
like
the
front
door
of
api
server,
the
the
thing
that
serves
the
c
or
DS.
The
policy
hook
calls
the
the
entire
framework
around
which
you
insert
your
resource
handlers
into.
A
So
we
own
large
parts
of
it
and
and
it's
kind
of
like
mixed
together,
everybody
publishes
their
api.
Api
machinery
unfortunately
publishes
in
the
same
places
kubernetes,
but
we
also
have
some
some
meta
stuff
in
another
place
controllers.
The
other
aspect,
like
all
the
business
logic
of
kubernetes,
goes
into
controllers.
So
so
kubernetes
has
the
controllers
that
enact
your
will
for
the
deployments
replica
sets
in
points
nodes.
You
know
all
ticket
stuff
in.
A
Also,
it
has
some
controllers
because
we
we
own
some
facets
of
the
system,
so
the
two
main
ones
are
the
the
namespace
lifecycle
like
delete
a
namespace.
It
goes
and
cleans
up
all
the
objects
that
are
sitting
in
that
namespace.
We
also
in
the
garbage
collector,
so
you
delete
the
root
of
a
tree
of
objects
and
it
walks
them
and
deletes
them
for
you,
so
that
that's
API
machinery
owned
and
all
of
this
stuff
is
in
controller
manager.
A
A
So
so,
like
the
the
object
meta,
the
the
data
that
we
put
at
the
top
of
every
object
to
help
you
introspect
the
system-
that's
that's
the
format
of
that
is
owned
by
API
machinery,
the
concept
of
optimistic
concurrency
that
you
can
write
and
read
objects
in
a
safe
way,
even
in
the
face
of
many
other
readers
and
writers.
That's
that's
API
machinery
concept,
owner
references
which
power
the
garbage
collector,
the
various
wire
formats
for
both
for
watch
and
for
proto
the
status,
their
return
format.
This
is
all
stuff
that
API
machinery
owns.
A
On
the
other
hand,
concrete
stuff
like
like
specifically
applied
stuff,
is
mostly
kubernetes
specific,
so
liveness
readiness
checks
like
that
is
not
an
API
Machinery
concept.
That's
a
very
specific
contract
between
cubelet
and
the
pods
that
is
running
the
containers
that
is
running
service,
selectors
yeah,
there's
a
listener:
I'm,
not
gonna.
Read
it
to
you.
Api
machinery
I
tried
to
think
of
like
what
are
concrete
decisions
that
API
machinery
has
made.
One
that
came
to
mind
is
the
flat
namespace
hierarchy.
The
fact
that
you
don't
have
namespaces
nested,
that's
an
example.
A
A
Okay,
so
did
you
have
a
good
experience
every
time?
Yeah,
it's
tricky
right.
Api
machinery
also
has
some
some
issues:
there's
no
coordination
between
replicas
of
API
server,
for
example,
I'm
sure,
especially
as
people
add
more
series
to
the
system,
we're
gonna,
get
requests
to
scale,
to
support
larger
numbers
of
objects
and
we've
already
gotten
with
these
requests.
A
That's
something
that
I
haven't
seen
discussed
too
much.
If
at
all
is
that
these
operational
issues
kind
of
have
a
cross
product.
All
right
so
there's
there's
like
there's
concerns
that
are
basically
completely
kubernetes
like
I
want
to
add
a
field
to
my
view
on
resource
there's
concerns
that
are
almost
entirely
api
machinery.
I
want
to
add
a
new
proto
format
and
these
things
like
since
we
roll
out
right
now,
changes
in
both
at
the
same
time
and
lockstep.
It's
it's
a
it's
hard
to
be
sure
that
you've
tested
the
the
whole
cross-product
right
yeah.
A
So,
in
spite
of
that,
kubernetes
clearly
has
lots
of
uptake
as
I
mentioned
at
the
beginning.
Okay,
so
forward-looking
this.
This
section
I've
also
got
three
three
parts.
What
are
our
goals
is
first,
so
I
think
our
goal
is
a
product
as
a
project.
We've
got
two
groups
of
people
that
we
want
to
support
the
kubernetes
ecosystem
and
the
kubernetes
project,
and
then
I
really
want
to
argue
that
these
are
the
this
is
actually
the
same
group
of
people
or
or
that
at
least
that
we
can.
A
Really
have
an
ecosystem.
You
have
a
bunch
of
islands
for
interoperability
like
there's,
there's
client-side
interoperability
like
Cube
control,
I,
I,
think
I
think
cube.
Control
is.
If
we
do
things
right,
you
should
only
need
to
keep
control
as
a
command-line,
client
and
and
I'm.
This
also
applies
to
libraries
for
languages
right
now.
There's
a
bunch
of
functionality
and
queue
control
that
you
basically
have
to
rewrite.
A
We
still
need
some
client-side
constructs
like
the
controller.
The
framework
II
bits
we've
written
for
controllers,
but
basically
like
if
stuff
doesn't
work
for
C
or
DS
stuff
in
Q
control,
it
doesn't
work
for
C
or
DS,
move
something
to
the
feature
just
to
the
server
and
just
keep
going
until
everything
works
seamlessly
for
CR,
DS
and
I.
Think
phil
has
already
started.
Fill-In
team
are
already
working
on
that,
so
I'm
not
gonna,
focus
on
it
too
much.
The
next
part,
which
I'll
spend
a
little
bit
more
time
on,
is
server
side
up
interoperability.
A
How
many
of
you
have
seen
one
of
these
before
I'm
sure?
None
of
you
have
a
legacy
system
that
you
need
to
man,
but
maybe
you
know
somebody
who
does
so
there's,
there's
sort
of
two
ways
that
you
can
hook
up
a
legacy
system
with
kubernetes
like
like
a
control,
plane,
type
legacy
system
like
maybe
it's
your
your
network
switches
or
who
knows
what
it
is
so
this
first
one
is
really
the
recommended
way
of
doing
this.
A
It
is,
it
is
really
the
Gibbs
appliance,
the
the
the
primitives
they
expect
and
it
lets
you
cleanly
command
your
legacy
system.
The
way
it
expects-
and
this
is
this
is
like
clients
are
here-
they
read
and
write
to
as
you've
made
a
C
or
D,
then
you've
also
written
a
controller
which
reads
from
the
CR
D.
A
It
sends
imperative
commands
over
to
your
legacy
system
and
its
got
like
a
pull
loop
or
maybe
if
your
legacy
system
supports
a
pub/sub,
it
can
watch
it
or
something
like
that
and
it
pulls
data
from
your
legacy
system
and
writes
the
status
back
to
this
year.
D,
and
this
this.
If
this
looks
familiar,
it's
basically
exactly
the
operator
pattern
just
applied
to
a
legacy
system.
A
So
this
is.
This
is
really
the
way
I
recommend
you
hook
up
a
legacy
system
to
the
urban
at
ease,
control,
plane,
I,
I.
Think
it's
it's!
It's
actually
one
of
the
better
stories
for
this,
because
you
can
just
write
your
control
plant,
your
controller
separate
you
don't
have
to
recompile
anything
about
API
server,
so
I
recommend
this.
However,
I've
had
multiple
people
requests
to
bring
their
own
API
server
and
I.
You
know:
I
can't
recommend
this,
but
people
want
to
do
it.
A
So
what
is
it?
What
does
it
take
to
to
to
hook
up
your
API
server
as
a
source
of
truth?
Basically,
the
the
design
looks
like
this.
So
you've
got
the
aggregator
you
make
any
API
service
and
and
you've
got
some
sort
of
shim
or
something
between
your
legacy
system
and
the
aggregator.
So
if
we
zoom
in
there,
it's
pretty
easy
to
imagine
how
you
can
write
a
write,
a
shim
to
take
like
a
post
command
and
turn
it
into
a
create
on
your
legacy
system
right
and
put
get
lists.
These
are
pretty
easy.
A
It's
less
easy
to
imagine
how
you
really
implement
watch
with
the
with
the
semantics
and-
and
so
my
my
point
of
putting
this
up
here-
isn't
that
I
think
this
is
a
great
thing
or
that
we
should
spend
a
lot
of
time
supporting
it.
My
point
is
that
it's
not
clear
to
people
how
they
would
even
do
this
right.
We
haven't
written
down
what
exactly
it
means
to
be
interoperable
from
a
server
perspective.
A
Is
it
required
for
people
to
implement
watch
I
would
like
to
say
it
is
I
think
that
that
is
a
really
important
part
of
the
kubernetes
api
experience,
but
it's
hard
and
we
haven't.
We
haven't
written
down
the
compatibility
guidelines
so
that
that's
really
my
point
in
bringing
this
up
is
it's
hard
to
be
interoperable
and
clear
guidelines
or
the
difference
between
your
legacy
systems.
Looking
like
this
or
like
this,
so
how
can
we
support
the
kubernetes
project?
At
the
same
time?
A
I
actually
think,
as
there's
a
there's,
a
drive
to
like
do
more
and
more
API
societies,
I
think
we
can
really
support
both
the
kubernetes
project
specifically
and
the
ecosystem
at
large,
with
many
of
the
same
actions
so
so
clarifying
our
boundaries,
conformance
testing,
I
think
these
are.
These
are
great
uses
of
our
time,
even
if
we
weren't
considering
the
ecosystem
at
large
and
just
the
the
kubernetes
project
itself.
A
Okay,
so
this
is
the
fun
part.
Is
now
I'm
going
to
give
you
a
series
of
ideas
and
increasingly
harebrained,
perhaps
but
I
really
think
that
many
of
these
are
composable
like
we
can
pick
and
choose
which
ones
we
do
and
I
think
all
of
them
drive
at
a
better
way
of
operating
in
general,
so
and
and
I
might
get
a
little
technical
here
and
talk
a
little
bit
about
the
the
internals.
But
this
is
gonna
be
far
from
a
complete
proposal.
A
So,
like
I
mentioned
before
today,
we
run
the
API
server
and
it's
got
a
lot
of
stuff
built
into
it.
So
client
talks
to
the
aggregator
which
might
forward
to
the
built-in
kubernetes
kubernetes
resource
handlers,
and
if
it's
not
there
am
I
forward
to
the
sierra
tea
api
server,
but
there's
also
the
aggregator
might
send
you
off
to
the
metrics
api
server
or
some
other
API
servers
and
that's
through
like
network
connections.
A
What,
if
we
split
this
apart,
so
we
actually
had
a
process
that
was
owned
by
a
guy
machinery
and
separate
processes
that
were
owned
by
the
kubernetes
project
at
large,
I
I'm
thinking,
in
particular,
of
the
the
CBE
we
had
the
other
day,
it'd
be
great
to
be
great.
To
have
been
able
to
upgrade
this
aggregator
front
door
without
touching
the
rest
of
the
system.
I
have
another
slide
about
that
in
a
second.
A
This
is
just
a
sketch
of
a
design.
It
does
increase
the
operational
complexity
a
little
bit.
I
personally
think
it's
worth
it.
You
can
come
to
the
API
machinery,
sig
List
and
argue
with
me,
if
you
don't,
but
the
the
basic
idea
is
like:
let's,
let's
move
the
the
kubernetes
built-ins,
let's
move
them
out
to
a
separate
API
server
like
maybe
for
performance.
We
need
to
use
a
UNIX
domain
socket
or
something
like
that
to
communicate
with
it
and
co-locate
it
with
the
front
door
here.
A
But
the
basic
idea
is
to
clarify
who
is
responsible
for
what
component
right
like
I'd,
like
a
binary
that
API
machinery
owns
and
a
binary
that
the
the
kubernetes
project
owns
right,
maybe
maybe
even
most
like
like
at
that
point.
It's
no
longer
like
my
personal
problem,
but
I
think
it
would
be
nifty
if
that
kubernetes
owned
process.
A
Maybe
they
can
individual
owners
of
api's
and
there
could
either
switch
their
thing
to
a
C
or
D,
or
maybe
they
could
operate
a
API
server
binary
that
serves
just
that
API
so
that
so
there's
complete
ownership
of
the
component
right.
This,
of
course,
is
just
as
just
a
sketch.
It's
I've
got
my
little
construction
worker
in
the
corner
there
to
tell
you
it's
not
a
detailed
design.
It's
definitely
not
implemented.
A
A
Don't
know
interesting
idea,
hopefully,
so
the
other
main
binary
in
our
system
is
a
controller
manager,
and
today
we
have
all
the
controllers
in
one
place
and
like
there's
some
that
are
logically
API
machinery,
as
I
mentioned,
there's
some
that
are
logically
kubernetes.
There's
many
that
are
logically
belonged
at
the
cloud
provider
and
there's
already
a
work-in-progress
to
split
that
out.
So
we're
soon
going
to
have
a
controller
manager
and
a
cloud
controller
manager.
But
maybe
we
should
think
about
having
three.
A
So
why
not
go
even
further
and
just
run
every
controller
in
its
own
binary
and
I've
heard
two
reasons.
The
the
one
that
I
buy
is
on
this
slide
like
it's
expensive,
every
controller,
basically
caches
every
object
in
the
system,
so
it's
very
expensive
to
split
them
out
into
into
many
separate
binaries,
expensive
at
runtime
in
terms
of
RAM
and
CPU.
The
other
argument
I've
heard,
is
that
it
is
more
much
more
operationally
complex
to
do
this.
I,
don't
actually
personally
buy
that
one
I
think
like
we're
software
engineers.
This
is
what
we
do.
A
A
So
what
if
we
refactored
our
process,
I'm
I'm,
actually
personally
frustrated
with
the
cadence
of
releases
of
the
the
kubernetes
project
at
large,
both
in
terms
of
like
how
long
it
takes
to
fix
something
in
terms
of
people
rush
to
get
in
at
the
last
minute,
because
these
releases
happen
like
every
three
months
or
something
so
there's
really
not
that
many
trains
leaving
the
station.
It's
very
important
to
get
your
feature
on
one
eye:
I
would
really
love
and-
and
so
those
are,
those
are
like
constraints
faced
by
the
kubernetes
system.
A
Right,
like
not,
everybody
wants
to
update
their
their
their
cluster
all
the
time.
So
it's
hard,
but
we
API
machinery
don't
necessarily
need
to
face
those
constraints.
So
if
we
have
binary
level
components
that
we
own,
why
not
release
them
more
frequently
like
every
two
weeks
like
right
and
and
the
when
the
kubernetes
project
finishes
their
release
cycle
and
they
were
ready
to
ship.
They
pick
the
API
machinery
loop,
release,
that's
green
and
has
the
features
they
want
right.
So
I
I
think
that
that
idea
is
really
appealing
to
me.
A
I
know
I
am
motivated
personally
when
I
can
put
a
change
in
and,
and
it
goes
through
the
pipeline
and
it's
live
and
I
don't
have
to
worry
about
it
right.
The
the
broader
kubernetes
release
cycle
makes
that
really
hard
like
for
some
changes,
especially
API
changes.
You
have
to
it's
not
a
very
complicated
change.
It's
just
got
to
be
split
among
so
many
releases
like
you
might
be
spending
a
year
on
on
on
some
field,
deprecation
removal,
we've
been
so
really.
A
What
I'm
saying
here
is
the
kubernetes
version
is
sort
of
one
dimension
of
your
cluster
and
the
API
machinery
version
is
sort
of
a
different
dimension
and
I
think
it's
totally
legitimate
that
you
may
want
to
change
your
schemas,
but
not
your
mechanism.
That
is
like
get
the
new.
The
new
version
of
your
kubernetes
objects.
I
think
it's
also
legitimate
that
you
might
want
to
change
mechanisms,
but
not
your
schemas,
like
I,
want
to
get
a
security
fix,
but
I
don't
want
to
change
my
pod
semantics
right,
especially
the
recent
CV.
A
A
What
if
we
did
a
little
social
structure,
refactoring
I
can
actually
imagine
a
github
org
for
API
machinery.
Maybe
we
need
to
come
up
with
a
better
name,
but
I
can
I
can
actually
man
imagine
making
larger
changes
to
the
kubernetes
project
that
enable
us
to
move
faster
and
encourage
us
to
encourage
us
to
build
the
right
things.
A
There's
there's
a
sort
of
joke
law
out
there
that
you
end
up
shipping
your
org.
So
if
we
want
to
ship
things
in
a
certain
way,
maybe
we
need
to
refactor
our
organization
organization
to
to
facilitate
that
all
right.
So
is
there
any
actual
practical
way
to
make
these
changes,
or
is
this
a
vision
that
cannot
be
realized
and
I
think
there's
sort
of
two
approaches
we
could
take
to
to
make
progress
towards
some
of
these
goals?
The
first
one
and
I'm
sorry
but
I'm
mentioning
some
technical
details
about
the
kubernetes
project.
A
We
have
this
staging
directory.
The
first
one
is:
we
could
focus
on
the
staging
directory.
This
is,
this
has
been
our
way
classically
of
carving
out
pieces
of
the
kubernetes
project
that
we
want
to
expose
externally,
like
the
the
client
library
or
API
machinery
or
whatever.
So
we
could,
we
could
embrace
that
and
add
even
more
things
to
it
and
I
know.
A
Staging
is
everybody's
favorite
directory,
but
I
think
there
is
maybe
a
better
way,
which
is
basically
make
a
new
repository
set
up
the
process
that
we
want
to
have
in
that
repository,
and
that
includes
like
healthy
development,
test
release
practices
so
basically
get
our
release
story
in
order
and
then
move
a
small
piece
of
functionality
over
consume
that
in
the
main
repository
and
just
keep
repeating
that
process.
I
think
this
is
has
a
better
chance
of
eventually
arriving
at
the
release.
Semantics
that
I
would
really
like
to
see
and
repeat
until
everybody's
happy.
A
So
it
sounds
like
a
lot
of
work.
Is
it
worth
it
and
I
have
these?
Are
the
factors
that
I
that
I
think
are
relevant?
This
is
really
a
growth
rate
multiplier
on
the
ecosystem.
One
could
argue
that
the
ecosystem
has
been
having
no
problem
with
growing,
but
I
think
it
could
be
growing
even
faster
and
healthier.
A
This
gives
architectural
clarity
for
new
entrants
to
the
system.
Right,
like
you
come
into
kubernetes,
you
read
our
Docs.
It's
not
clear,
like
if
you're
reading
a
general
principle,
a
general
fact
about
all
the
resources
or
a
specific
thing
about
a
specific
resource.
If
you
dig
into
the
code,
it's
not
clear
if
you're
writing
some
some
code,
that
or
if
you're
modifying
some
code
that
needs
to
go
to
an
individual
API
author
or
to
the
API
machinery
sig,
often
in
our
triage
meeting.
We're
like
this
is
not
a
ciggy
I'm
machinery.
A
This
is
like
SEC
architecture.
This
is
no
because
you're
you're
changing
there's
no
thing,
or
this
is
the
storage,
because
you're
adding
this
storied
API,
so
I
think
that
that's
actually
worth
quite
a
lot,
and
this
is
sort
of
tautologically
true.
But
if
we
do
this,
we
end
up
with
improved
testing
and
confidence,
because
usually
it's
impossible
to
do
this
without
really
good
tests
that
represent
what
kubernetes
does
with
the
API
machinery
outputs.
A
So
and
my
personal
opinion
I
think
our
velocity
in
terms
of
features
would
be
slower
at
first,
perhaps,
but
eventually
get
faster
and
it's
it's
definitely
like
it's
not
an
it's,
not
a
law.
It's
not
an
important
part
of
velocity,
but
in
terms
of
number
commits
lines
of
code
changes.
I
think
that's
just
definitely
going
to
be
faster.
This
way
I
mean
it's
good
in
terms
of
morale
to
be
able
to
like
make
progress,
but
I
think
the
important
things
are
the
other
ones
on
this
slide.
A
So
this
brings
me
to
the
end
of
my
talk.
If
you
like
these
ideas-
or
you
want
to
try
and
talk
me
out
of
it,
you
can
join
the
API
machinery.
Mailing
list
come
to
our
meeting.
I
think
we'll
probably
have
to
talk
about
some
of
this
and
the
sega
architecture
mailing
list
in
a
meeting.
So
I
would
love
to
hear
your
feedback.
I
think
it'd
be
great
to
I've
heard
from
a
lot
of
people
today
or
at
this
conference
that
they,
like
this
general,
these
general
ideas,
so
I
hope
that
you'll
join
me.
A
A
A
This
pretty
much
reduce
the
API
surface
to
API
server
with
the
Sierra
T
implementation
and
just
controllers
and
I
think
the
answer
is
mostly
there's
a
couple
exceptions
which
are
some
of
the
built-in
resources.
Do
a
few
extra
things
that
you
can't
do
with
a
CRT
and
I'm,
not
sure
it'd
be
a
good
idea
to
do
with
the
Sierra
T.
For
example,
the
service
optic
will
allocate
an
IP
address
for
you.
A
That
is
not
a
thing
that
we
would
support
about.
Maybe
you
could
implement
it
with
a
web
hook,
but
I,
don't
I,
don't
know
and
I
don't
think
you
would
want
to
yeah
David
is
shaking
his
head
yeah,
so
I
think
yes
and
I
think
the
kubernetes
api
objects
API
resources
that
that
don't
support
this
yet
should
be
changed
like
maybe
those
were
like
specifically
the
surface
with
the
IP
allocation.
I
think
that
was
a
poor
architectural
decision
at
the
beginning,
it
should
have
been
handled
asynchronously
by
a
controller.
A
D
Because
I
think
it's
a
great
idea
to
move
machinery-
and
you
guys
refer
to
parts
of
always
setting
like
machinery
can
be
its
own
project
or
but
the
thing
that
scared
me
be
glossed
over
it.
When
you
made
that
split,
you
started
redirecting
clients
too
directly
to
nodes
to
do
things
like
proxy
and
exact.
A
Obviously,
I
don't
have
a
detailed
design
proposal,
but
the
basic
sketch
here
the
idea
is
the
aggregators
extended,
so
that
we
can
register
sub
resources
and
redirect
those
to
to
external
services,
and
it
wouldn't
have
to
be
directing
people
directly
to
nodes
like
III,
see
like
a
like
a
parallel
service
like
it
like
a
like
a
control,
plane,
type
service
that
handles
stage
requests
and
then
like
basically
take
the
code.
That's
currently
today,
an
API
server
move
it
to
a
separate
service,
redirect
clients
to
that
service.
A
C
A
A
Yeah,
so
so
so
the
question
is
right:
like
we
leave
services
to
connect
to
their
pods
with
label
selectors,
could
we
do
that
in
some
more
general
way,
I
think
actually,
we've
discussed
adding
garbage
collector,
like
a
new
concept
for
the
garbage
collector,
which
lets
you
denote
in
your
in
your
open,
API
discovery
that
this
particular
set
of
field
is
a
reference
to
some
other
object,
so
that
would
actually
be
really
powerful.
Is
like
it'd
be
useful,
not
just
for
the
garbage
collector,
but
you
could
follow.
You
could
like
navigate
the
directory
tree
generically.
A
Yeah
I
think
the
question
is
like:
why
is
it
so
hard
to
get
a
delete,
protection
and
I?
Think
that's
actually
that's
actually
a
good
question
and
I
think
there's,
maybe
some
simple
things
we
could
do
to
add
one.
The
final
lasers
are
not
ideal
because
once
you
once
you've
entered
the
delete
pipeline,
there's
no
return
so
I
think
there's
actually
change
a
relatively
simple
general
change
that
we
can
make
to
solve
that
problem.
Please
pipe
up
on
the
API
machinery
mailing
list
yeah,
especially
if
you
have
time
to
help
us.
Okay.
Thank
you.
Everybody.