►
From YouTube: Kubernetes SIG Architecture meeting 10 26 2017
Description
A
A
All
right,
so
everybody
welcome
to
the
architecture
special
interest
group
for
communities.
It
is
Thursday
October,
26,
2017
I,
am
your
host
Jay
singer
Dumars
I
work
for
Microsoft.
They
paid
my
paycheck
but
honestly
I
work
for
communities
as
we
all
do
so
we're
gonna
run
through
the
backlog
and
some
of
the
things
in
the
agenda.
The
agenda
is
available
via
a
short
URL
at
bit.
A
A
Can
you
see
that
okay,
good
all
right
so
I,
don't
want
to
actually
go
through
this
line
by
line
more
I
just
want
to
make
everybody
aware
that
we
have
this
backlog
and
that
these
are
things
that
we
need
to
do?
I
would
say,
hopefully,
soon
later
41.9
there's
some
things
that
we
should
look
at
a
synchronously
I
know
that
we're
all
pretty
busy
with
reviews
and
whatnot
of
other
things,
but
specifically
this
architecture
diagram
and
the
cleanup
the
proposals
directory
is
really
critical
work.
A
The
reason
why
partially
is
at
least
for
the
design
proposals
we
want
to
get
everything
ready
to
move
to
the
kept
process,
the
Carini's
enhancement
process
proposal
process,
so
that
we
can
start
reformulating
the
way
we
manage
features
quote-unquote
and
all
that
good
stuff.
So
there's
a
lot
of
predicates
here
to
the
work
that
we
want
to
do
in
other
parts
of
the
the
project
that
we
need
to
finish
so
offer
to
sense
their
real
quick.
Please.
C
Damn
we
I
started:
I
wrote
a
cap
proposal,
okay,
say
cluster
lifecycle,
mm-hmm,
the
the
the
format
for
the
fields
is
a
little
bit
prescriptive
and
in
fact
the
nomenclature
is
a
little
bit
different.
Then
I
think
what
you
might
expect
when
you're
designing
it.
So
we
might
want
to
do
a
pilot
type
of
rollout
where
we
refine
the
fields
that
we
want
to
do,
because
in
that
way
we
get
quick
churn
and
we
don't.
We
don't
force
everybody
into
a
process
before
we've
actually
vetted
it
ourselves.
Yes,.
B
I
would
view
the
kept
process,
as
it
is,
is
kind
of
at
alpha
stage.
To
be
honest,
I
think
you
know
it's
still
marked
as
trapped
there,
so
yeah
I
think
I.
Would
love
I'm
happy
to
get
together
with
you
Tim
and
take
some
notes
and
do
sometime
in
the
next
week?
Do
a
do
a
turn
on
that
that
that
other
folks
can
look
at
because
then
I
might
look
to
actually
do
another
edit
of
that
process
and.
A
We
had
talked
about
a
sort
of
retrofitting
an
existing.
You
know
something
that
is
like
daemon
sets
or
something
that's
like
super
solid
and
has
gone
through
the
various
stages
through
the
kept
process.
Just
as
a
mental
exercise,
I
would
love
to
still
do
that.
White
boarding
exercise
to
see
if,
if
that
meets
all
the
requirements,
because
that
that
that
would
be
a
great
way
to
see
if
this
matches
and
I
and
I
definitely
want
to
know
Tim
like
what.
A
C
B
C
B
Think
I
do
think
this
is
a
critical
sort
of
like
you
know.
This
is
gonna,
be
sort
of
the
way
that
we
do
business
in
this
group
moving
forward.
Most
probably
is
that,
like
I
think
we
want
to
get
to
the
point
where
it's
like
every
meeting.
We
have
like
two
caps
on
the
agenda
that
we're
gonna
actually
go
ahead
and
review
and
discuss,
and
so
I
think
getting
to
the
point
where
that's
useful
for
everybody.
Both
the
producers
and
the
consumers
of
the
capsule
I
think
it's
critical,
so
yeah.
D
I
was
gonna,
suggest
that
that
we'd
be
very
careful
about
piloting
it
with
anything
other
than
a
very
willing
cig
and
a
very
willing
enhancement
proposer,
because
otherwise
we
risk
yeah
kind
of
irritating
people
with
a
very
alpha
process,
which
is
gonna,
require
quite
a
bit
of
massaging
I.
Think
to
make
it
useful.
So
so
Tim's
proposal
seems
like
a
great
one.
If
he's
is
the
said,
willing,
proposer
and
willing
thing.
A
Awesome
yeah,
that's
great
I
would
yeah
I
don't
want
to
I,
don't
want
to
pour
salt
on
people's
wounds
that
too
soon
so
great
and
I
actually
I.
Think
that's
that's
something
we
should
absolutely
do
is
have
you
know
a
lot
of
six
have
like
a
ten
minute
demo
slot?
Maybe
we
have
a
10
or
15
minute,
kept
slot
I
just
as
a
running
thing,
so
so
there's
a
lot
of
other
things
in
this
backlog.
Honestly,
it's
starting
to
feel
a
little
bit
like
we're.
A
Never
ever
gonna
reach
them
these
things,
because
everything
we
do
take
so
long
to
discuss
so
we
do
need
to.
We
do
need
to
figure
out
a
way
to
time
box
discussions
and
come
up
with
some
sort
of
way
of
agreeing
or
disagreeing
on
things.
I
mean
we
have
the
lazy
consensus
model
and
whatnot,
but
I,
don't
feel
necessarily
that
that's
a
great
mechanism
for
in
sort
of
in-flight
discussion.
A
So
maybe
we,
if
anybody's
feeling
excited
about
proposing
that
I,
would
nominate
Caleb
because
he's
got
a
really
deep
understanding
of
different
consensus
models
or
anybody
else
who
has
a
maybe
talk
about
how
we
do
that
the
that
is
a
direct
relevance
on
the
second
balloon
bullet
point
in
the
agenda
and
actually
a
third
as
well.
So
somebody
put
this
in
here:
I'm,
not
sure
who
did,
but
if
that
person
is
present,
could
you
bring
this
up
and
we
can
talk
about
it?
Well,.
E
E
D
Yeah
I
wanted
to
just
bring
up
something
that
came
up
in
yesterday's
steering
committee
stuff
as
well,
which
is
I,
mean
I.
Think
it's
a
good
idea
to
have
these
architectural
diagrams,
but
I
I
think
it's
also
useful
to
step
back
and
try
and
clearly
enunciate
what
exactly
we
the
problems
we
are
trying
to
solve
by
coming
up
with
whatever
lairs
architectures
definitions
we
do,
because
otherwise,
it
becomes
very
difficult
to
you
know:
judge
judge
better
alternatives
from
worse
alternatives.
D
E
I'll
tell
you
the
problem
that
I'm
trying
to
solve
most
folks,
especially
those
outside
of
say
this
meeting
and
some
of
the
cigs,
don't
understand,
kubernetes
architecture
or
layout
or
how
things
come
together
or
where
the
ecosystem
fits.
They
they
don't
have
a
clear
picture
and
so
I
mean
the
reason
that
I
took
on
taking
Brian's
stuff
and
trying
to
iterate
on
it
was
to
try
to
help
mere
mortals
understand
what
the
heck
is
going
on
and
where
the
different
parts
are.
I
I.
B
B
D
I
was
gonna,
say
that
and
that's
sort
of
get
connect
to
you
know
if
we
don't
have
a
clear
statement
of
what
we're
trying
to
achieve
with
the
diagram,
then
we
run
into
the
problem
of
you
know
not
soulful
thing
specifically.
So
for
the
specific
problem
we're
trying
to
solve
is
a
conceptual
overview
of
communities.
Then
that
requires
one
thing:
if
it
is
understanding
how
all
the
code
fits
together,
that's
a
different
problem
with
a
different
solution,
so.
C
I
wanted
to
interject
here
because
Joe's
comment
echos
previous
lives
of
mine,
where
I
had
to
do
what
were
multiple
views
or
slices
of
the
architecture
and
we
kind
of
channeled
Carnegie
Mel
software
software
architecture,
document
structure,
where
you
you
have.
The
different
conceptual
view
is
based
upon.
Who
is
the
actor
involved?
And
if
you
have
a
user
story
for
that
actor.
That
makes
a
lot
of
sense
how
you
slice
the
view.
C
F
F
So
there
are
a
bunch
of
things
that
we're
going
to
be
doing
like
breaking
out
API
machinery
to
make
a
generally
reusable
machinery.
We
need
to
inform
what
plug
in
points
we
need
for
out
of
tree
and
out
of
process
plugins.
So
that
was
the
main
initial
goal
of
doing
that.
It
does
have
some
other
potential
purposes
or
could
inform
other
types
of
diagrams
for
sure
one
kind
of
diagram
will
everybody.
You
know
some
people
need
more
detail.
Some
people
need
less
detail.
F
F
E
Which
was
actually
the
topic
that
I
had
here
to
continue
on
in
the
second
discussion
topic
bullet
point
was
how
do
we?
How
do
we
get
there
right?
So
we
talked
a
little
bit
about
API
machinery
and
client
go
and
in
some
of
this
in
sig
CLI,
sig,
apps
and
sig
API
machinery
in
the
last
couple
of
weeks
it
keeps
coming
up
and-
and
it
becomes,
how
do
we
actually
get
from
where
we're
at
to
where
we're
going
to
go.
It
seems
like
in
each
of
these
sakes
it's
yeah.
F
I
think
I
think
you
just
hit
the
nail
on
the
head
there,
which
is.
It
is
a
kind
of
social
engineering
and
prioritization
problem
right
now,
much
more
than
a
technical
one,
I
mean
for
sure
there
are
technical
ones,
but
they
are
normal
kinds
of
things
that
engineers
know
how
to
deal
with
and
refactoring
and
such
so.
F
You
know
I
think
we
need
to
get
some
agreement
and
draw
some
lines
in
the
sand.
This
is
after
X
release.
No
more
things
of
this
kind
can
be
added
the
name
depository
or
this
thing
needs
to
move
out
by
such
as
mr.
gate.
We
need
to
actually
set
some
project
wide
goals
and
policies
around
that
and
whitelist
or
grandfather
specific
activities,
instead
of
the
other
way
around
saying
that
you
know
this
thing
cannot
happen,
but
by
default
everything
else
else
goes
in.
F
We
have
been
pushing
on
queue,
control,
you're,
hampered
by
just
the
growth
of
the
project,
is
so
rapid
and
so
large
it's
hard
we're
spread
super,
but
we
are
trying
to
chip
away
at
the
cute
control
dependencies.
One
thing
that
we're
doing
to
try
to
facilitate
making
progress.
There
is
by
using
blades
or
a
basal
sorry.
So
at
the
same
time
we
have
the
basal
team
trying
to
remove
the
obstacles
from
the
dust
from
more
completely
adopting
possible
for
the
project
like
multi
architectural
support,
and
things
like
that.
F
So
we
are
getting
support
from
other
parts
of
Google
since
I.
Think
kubernetes
is
one
of
the
largest
NGO
projects
exist.
These
other
teams
have
some
interest
in
letting
us
flounder
with
the
tools
yeah.
So
so
we
are
making
progress,
but
it's
a
it's
a
big
problem,
so
that
would
be
one
thing
like:
if
you
have
any
influence
over
engineers
times
in
your
organization,
ask
them
to
spend
some
amount
of
time
working
to
just
you
know,
chop
wood
and
carry
water
just
chip
away
at
like
you.
G
F
Is
the
most
obvious
example
of
something
we
could
be
able
to
move
out
right
like
this
has
been
called
out
in
many
places
and
just
in
terms
of
other
parts
of
projects
they
will
say:
well,
we
don't
want
to
move
out
because
then
we'll
be
perceived
as
not
being
part
of
the
main
whatever,
and
so
we
want
some
other
thing.
That's
obviously
critical
to
move
out
before
we
move
out
right,
whether
it's
qadian
or
Federation
or
whatever
it
is
I
mean
Federation's
actually
move
moving.
But
you
know
we
need
something
to
move.
F
First,
that
people
can
see.
Ok,
yeah.
This
is
the
direction
we're
really
going
to
go.
So
we've
chosen
in
control
I
think
there
are
a
bunch
of
other
benefits
to
moving
cute
control
as
well
like
we
need
to
make
right
now
we
don't
even
reliably
make
one
release
of
versions
to
work
the
queue
control.
You
really
need
to
actually
run
the
same
release
of
keep
control
as
the
cluster,
which
is
not
a
good
situation
to
be
in.
F
It
should
work
as
long
as
the
api's
work,
according
to
our
API
deprecation
policy
right,
unless
you
need
a
new
feature,
it
should
just
work
in
for
the
ape
all
the
API
resources.
It
should
just
pass
through
all
the
field,
so
we
need
to
not
round-trip
all
the
objects,
so
right,
I
would
say
like
we
need
to
get
client
go
out
of
cube
control
completely
and.
E
That's
actually
what
I
was
gonna
to
say,
because
when
I
brought
it
up
an
API
machinery
that
didn't
appear
to
be
one
of
their
priorities,
in
fact,
one
of
the
things
because
of
doing
some
of
this
with
clients-
and
that
was
you
know-
it
mean
if
it's
not
one
of
their
priorities
and
they're,
not
putting
folks
on
it,
then
that
now
hampers
something
else.
And
so
how
do
we
say.
F
E
If
some-
and
if
somebody
we're
gonna,
come
in
to
try
to
help
this
this
situation
along,
then
how
would
they
even
know
what
to
do?
Because
that's
one
of
the
things
we
have
for
new
folks
to
come
in
like
this
isn't
an
easy
problem,
and
so
even
somebody
who
knows
kubernetes
says
now
I'm
gonna,
step
in
and
start
trying
to
solve
this
space,
because
you
break
something
out
now
that
repo
needs
to
have
people
sign
up
to
be
owners.
E
You've
got
to
deal
with
dependency
management
and
I
moose,
there's
a
whole
bunch
of
these
other
things
that
you're
gonna
have
to
do
each
time,
and
in
that
first
time
it
needs
to
be
solved
and
now
where's
kind
of
that
list.
Okay,
we're
gonna,
go
move
client,
go
out
really
you
gotta
move,
client,
go
and
API
machinery
and.
F
E
F
Know
the
list
until
they
do
it,
like
people,
need
to
jump
in,
spend
not
spend
a
lot
of
time
on
it.
Ask
questions
on
slack
and
and
figure
it
out
like
the
work.
Jeff
has
done
to
fine
all
the
cute
control
dependencies.
I
mean
it's
a
matter
of
putting
in
a
lot
of
dough,
build
visibility,
rules,
iterating
moving
things
around
refactoring;
okay,
it's
not
a
rocket
science.
It's
iterative
work
and
until
someone
doesn't
once
we're
not
going
to
have
an
example
that
other
people
can
follow,
yeah.
D
I
think
there's
another
problem:
Brian,
which
is
and
I
agree
with
you
that
there's
no
substitute
for
actually
doing
the
stuff,
but
the
other
problem
people
run
into
is
that
there
isn't
actually
like
a
full
mandate
for
some
of
the
stuff.
So
you
try
and
do
this
and
you
have
to
end
up
getting
you
know:
half
a
dozen
cigs
to
approve
your
PR,
because
you
know
that's
where
the
code
is,
and
some
of
them
say
well,.
F
B
B
And
I
think
I
think
it's
gonna
be
so
much
harder
to
get
folks
to
get
involved.
When
the
communication
for
what's
going
on
here
is
very
much
one-to-one,
or
at
least
it
feels
one-to-one.
Now
there
may
be
documents
out
there.
These
things
don't
get
shared
widely
outside
of
API
machinery
and
and
they
definitely
don't
get
reviewed
by
it
by
the
people
that
they
impact
big
time
and
so
I
I.
You
know
I
think
there's
a
certain
amount
of
like
hey.
F
F
Needs
to
be
like
a
small
single-digit
number
of
people
pounding
on
it.
It
can't
be
a
hundred
people,
that's
just
a
total
waste
of
time.
We
spend
more
time
like
explaining
to
people
what
to
do
than
actually
doing
the
work.
I
I'm
not
signing
up
with,
like
we
have
no
hard
data,
which
shows
that
this
is
true,
so
I
I'm,
I'm.
C
F
We
needed
to
have
API
machinery
available
outside
the
kubernetes
repository.
That
is
the
reason,
so
the
API
machinery,
team
and
Daniel
in
particular
did
uncho
and
some
others
did
work
to
make
those
things
available
without
having
to
vendor
all
of
kubernetes
kubernetes
and
that
took
a
while.
It
took
like
multiple
quarters.
F
We
have
that
now
we
are
still
not
where
we
want
to
be,
because
the
development
still
is
in
kubernetes
kubernetes
and
it
gets
mirrored
out,
but
a
bunch
of
these
things,
but
we
right
now
don't
have
bandwidth
to
continue
pushing
that
forward
like
unless
it
looks
more
people
get
involved.
Instead,
we
are
working
on
unblocking
other
moving
out
other
things.
E
B
F
B
B
Like
so,
let's
start
with
cube
control
right,
here's.
The
thing
is
that
if
we
take
the
stuff
that
it's
very
difficult
to
start
with
stuff
on
the
periphery
like
that,
because
then
it
means
that
well,
there's
there's,
there's
not
a
motivation
to
actually
complete
the
work
right
and
that's
the
thing
that
worries
me
is
that
we'll
do
the
easy
stuff
and
we
won't
actually
end
up
doing
deliver
so.
F
I
suggest
we
work
we
pound
on
cue
control
because
we,
the
jeff,
is
on
that.
We
need
to
do
that
in
order
to
build
xq
control
extensions.
So
that
is
why
we
are
currently
focused
on
that.
Much
like
api
machinery
work.
We
did
enough
work
that
we
could
unblock
work
on
building
aggregating,
API
servers
and
see
ids,
and
things
like
that.
Out
of
the
core
repo.
B
I
know
and
I've
been
trying
to
be
fair
about
this
stuff.
Just
because
we
are,
you
know
as
a
company
we're
pretty
constrained
and
so
I
don't
have
the
capacity
to
so.
You
know,
I
can
get
you
up
to
a
certain
level,
but
like
my
capacity
to
put
engineers
I'm
trying
to
be
reasonable
about
this,
I
just
I
think
it's
a
matter
of.
Can
we
set
the
conditions
so
that,
like
we
can
have
more
people
getting
involved
and
endeth
and
and
I
gotta
be.
F
Us
more
of
the
right
kind
of
people
like
more
full-time
people,
I
don't
want
a
hundred
one
percent
time,
people
that
just
totally
waste
our
time
and
consumes
a
huge
amount
of
our
bandwidth.
If
you
actually
look
at
the
data,
ninety
or
ninety-five
percent
of
our
contributors
are
only
like
could
contribute
a
few
Ciel's
huge
amount
of
time
to
spend
time,
mentoring,
people
and
then
have
them
flake
out
and
not
on
things
for
more
than
a
month.
So.
D
A
B
Able
to
tell
SIG's
what
to
do
and
like
move
code
around
that's
gonna,
go
a
lot
easier
if
there's
more
documentation
of
what
this
roadmap
looks
like
right,
I
think
a
big
part
of
this
is
like
communicating
what
the
plan
is
and
what
the
impact
is,
because
it
does
have
impact
across
the
entire
project.
So
that's
something
that
I
think
we
need
to
and
and
and
I
mean
just
to
back
up,
like
I
think
when
you
step
back
and
look
at
this.
B
What
we
have
here
is
a
this
refactoring
project
for
API
machinery
has
been
going
on
for
how
long
now,
nine
months,
a
year
with
a
very
small
set
of
people-
and
it's
been
excruciating
ly
painful
over
a
long
amount
of
time.
Right
now,
I'm
not
gonna,
say
that
there's
not
another
way
to
do
that.
But
for
me,
that
sort
of,
like
lights
up
some
warning
bells
that
like
look,
we
need
to
find
a
better
way
to
actually
start
cracking.
That's
not
open
and
I.
B
F
F
The
political
stuff
I
can
deal
with
the
challenges
in
order
to
ramp
people
up
and
learn
the
code
base
and
figure
out
how
to
move
things
around
a
big
part
of
the
and
it's
a
lot
of
grungy
work
like
trying
to
move
stuff
and
figuring
out
where
in
humans
are
in
the
best
way
to
break
those
entanglements
I
think
that
is
gonna
require
interaction
potentially
in
real
time
to
make
progress.
I
don't
know
how
to
avoid
that
for
new
people
who
are
not
that
familiar
with
the
code
base,
I
mean.
D
Just
to
be
clear,
I
mean
we
have
lots
of
people
who
are
not
new
and
I
are
familiar
with
the
code
base,
but
they're
busy
on
other
things.
So
these
new
people
would
certainly
have
mentors
close
by
who
are
familiar
with
the
code
base.
I
just
don't
want
them
to
be
forced
to
engage
with
a
cig
on
a
regular
basis
to
get
a
PR,
approved
or
reviewed
or
not
kicked
out,
because
that
just
you
know,
makes
an
already
difficult
task
even
more
difficult.
So.
B
Okay,
so
my
understand
is
that,
with
with
cube
control,
the
biggest
issue
is,
is
the
reliance
on
internal
types,
and
that
is
not
because
one
of
the
issues
well
and
the
biggest
problem
there
is
that,
like
moving
towards
moving
towards
explicit
types,
means
that
there
ends
up
being
a
lot
of
duplicated
code,
a
lot
of
like
because
you
can't
use
the
the
conversion
stuff
built
in
and
then
work
on.
The
sort
of
you
know
keep.
F
What
you
have
been
moving
towards
is
so
for
the
most
part,
it
should
interoperate
with
the
api's
generically
and
talk
to
whatever
version
the
user
specifies
for
this
specific
cases
like
say,
cute
control
run
where
it's
generating
a
deployment
or
a
job,
or
something
like
that.
Yes,
it
should
use
a
specific
version.
My
position
there,
as
those
features
should
be
relatively
few
and
relatively
stable.
They
should
target
stable
versions
and
api's.
So
even
as
we
introduced
new
API
versions
like
when
we
introduced
apps
v1
of
deployment,
it
should
not
immediately
move
to
that.
F
We
have
to
do
where
when
we
introduced
a
new
API
version,
we
can't
actually
make
it
the
default
storage
version
in
NCD,
because
if
you
roll
back
your
cluster
you'll
be
hosed,
because
the
API
server
won't
be
able
to
decode
the
resource
and
we
can't
make
it
the
D
furred
version
and
the
API,
because
versions,
queued
versions
of
cute
controller
won't
be
able
to
understand
it
either.
So,
there's
this
dance,
we
need
to
do
when
we
roll
out
these
new
API
versions
of
actually
migrating
clients
to
them.
F
B
F
B
F
F
But
there's
a
list
of
known
issues,
just
for
example,
the
Clayton
has
been
pounding
on
server
side
getting
described
right,
so
getting
all
that
print
logic
out
of
queue
control
is
we
need
to
just
ujin.
We
just
need
to
do
generic
rendering
in
queue
control
and
have
all
the
business
logic
of
computing.
The
data
that
needs
to
be
presented
in
the
server
that's
needed
for
multiple
reasons.
Anyway,
like
everything
everything
anything
that
wants
to
present
the
pod
status.
The
way
keep
control
does
basically
ask
to
copy
paste
the
cute
control
code.
That
does
that.
F
So
you
eyes
do
that
other
clients
do
it.
We
need
to
get
that
code
actually
in
the
API
server
and
just
put
it
in
a
field
in
the
pods
status,
so
they're
a
bunch
of
known
issues
like
that
or
adding
information
to
the
open,
API
spec,
so
that
we
don't
have
to
look
at
the
tags
on
the
fields
and
the
types
from
types
that
go
stuff
like
that,
so
it's
heart
gonna
be
hard
to
do
from
scratch.
F
E
F
E
B
B
F
C
I
have
a
logistical
question
that
I
want
to
ask
who
this
really
needs,
like
a
working
group
and
a
working
group
lead
to
make
the
execution
of
this
even
possible
because
otherwise
you're
asking
for
people
to
come
into
something
and
they
have
to
cherry-pick
across
SIG's.
The
only
structure
that
we
have
for
this
is
a
working
group.
Do
we
have
a
working
group
who's
solely
dedicated
to
this
purpose?
We.
F
F
F
But
yeah,
but
but
yes,
I
mean
in
terms
of
direction.
As
we
talked
about
a
little
bit
earlier,
I
would
like
to
start
drawing
some
lines
in
the
sand.
I
haven't
had
time
to
catch
up
on
the
cloud
provider
thread,
but
that's
definitely
something
I'm
gonna
push
on
see.
If
we
can
visually
back
out
some
of
the
chaos
changes.
F
It's
a
super
critical
feature,
but
I
don't
want
it
to
work
and
kind
of
the
opposite
direction
of
where
we
need
to
go
for
project
health,
so
I'm
gonna,
see
if
I
can
do
something
about
that.
But
I
would
like
to
take
a
position
that
we
don't
put
any
new
cloud
provider
code
into
kubernetes
kubernetes
and
in
general
I'm.
Looking
for
in
110
or
111
to
draw
a
line
and
say
only
whitelisted
changes
can
go
into
kubernetes
grenades,
master.
Everything
else
has
to
be
in
another
repo
or
a
filter
branch.
So.
B
B
F
G
B
F
G
B
F
F
G
B
F
This
is
where
I
want
to
want
to
make
it
simple
and
just
say:
look
you
have
to
get
all
the
cloud
provider
specific
stuff
out
of
the
tree,
including
kms
and
cleaning
volumes
like
in
the
v2
version
of
the
API
I.
Don't
want
cloud
provider
specific
volumes
yeah,
so
that's
the
biggest
thing
I
regret
in
the
kubernetes
api
I
would
have
to
say
so.
A
I
I
hunted
percent
agree,
but
there's
also,
we
can't
hamstring
the
cloud
providers
that
are
in
there
by
making
them
adhere
to
a
standard
that
isn't
even
baked
yet
the
the
external
cloud
provider
stuff
is
stalled
and
it
isn't
it
isn't
ready
for
primetime
and
if
we,
if
we
stop
all
all
entry
development
for
cloud
providers
and
basically
what
that.
That's
that's,
not
an
acceptable
answer
either.
We
need
to.
A
F
A
A
H
F
What
it's
drawn
one
way
week
ago,
which
I'm
not
a
huge
fan
of
but
I
in
one
possibility,
is
we
could
say
you
know
if
people
need
to
work
around
some
of
these
things
in
the
short
term.
Well,
first
of
all,
I
think
putting
putting
a
strawman
schedule
would
help
provide
clarity
to
people,
and
we
could
say
well.
This
is
that
the
timeline
will
accept
changes
up
to
this
release.
F
After
this
release,
only
grandfather
ones
can
still
make
changes,
and
after
this
release,
everybody
has
to
be
out
I
think
that
would
help
a
lot
Daniel
getting
that
a
thumbs
up.
So
we
should.
We
should
definitely
try
to
do
that
if
we
can
get
some
I
agree,
Joe
that
it's
definitely
not
clear.
This
stuff
isn't
shared
widely
enough.
Maybe
one
thing
we
can
do
in
Sagarika.
F
But
you
know
in
other
areas,
for
example,
I'm
trying
to
get
the
test
infrastructure
where
it
needs
to
be
so
that
we
can
do
branches.
The
one
big
chain
enabler
for
that
that
happened
recently
is
now
knew
all
this
stuff
can
run
in
one
GCD
project,
so
people
don't
need
to
create
new
projects
run
tests
on
start
tests
on
you
branches.
They
just
need
to
submit
a
PR,
and
anybody
can
do
that.
B
I
think
one
of
the
one
of
the
things
that
this
group
could
do,
and
this
and
again
I
haven't
reviewed,
Jace's
doc,
because
I
think
it
may
mix
in
some
of
this,
but
but
I
really
write
I
propose
this
model
of
boundaries,
attractors
and
communication
right,
like
the
the
layer
cake
diagram.
If
it's
aspirational
ends
up
being
talking
about
boundaries,
we
will
not
do
this.
We
will
not
allow
this.
This
is
what's
in.
What's
not
in
this
is
a
layer
violation,
that's
a
useful
guidance
in
terms
of
how
people
build
stuff.
B
The
attractors
are
like
here's.
The
things
that
are
the
priorities
are
gonna
get
priority
in
terms
of
review
time.
I'm.
Sorry,
your
features
going
to
get
backed
up
behind
this
right
and
I.
Think
and
then
communication
helps
people
to
understand
what
the
priorities
are,
what
those
attractors
are
and
it
presents
it
prevents
a
certain
amount
of
resentment
of
like
I.
B
F
Reason
why
I
pushed
to
get
the
dev
stats
dashboard
in
place
and
worked
with
them
to
get
some
initial
set
of
dashboards
I
highly
well.
I
will
request
that
everybody
look
at
those
dashboards
and
think
about
what
decisions
we
want
to
make
or
what
lights
we
want
to
shine
and
regularly
and
make
sure
we
have
actionable
data
in
the
dashboard
that
can
show
that
right,
like
I've.
Had
people
even
arguing
til
today
about
you
know,
are
we
really
doing
multiple
repos
or
whatever?
F
B
F
B
C
B
Yeah
and
so
I
think,
and
even
if,
like
it's
you
know,
a
lot
of
those
have
joined
the
project
since
we
had
the
leadership
summit,
so
I
think
we
need
to
keep
pounding
in
that.
This
is
the
priorities.
This
is
the
thing
that
we're
focusing
on,
and
this
is
the
stuff
that's
actually
going
in
above
and
beyond
features
now
I
mean
one
of
the
things
that
you
know
as
a
company
that
we've
done
with
hefty
o
is
that
we've
tried
to
do
things
from
the
outside.
B
We've
tried
not
to
increase
the
burden
in
terms
of
actually
trying
to
get
stuff
into
kubernetes,
kubernetes
and
and
in
where
we
do
we're
trying
to
do
things
that
are
all
able.
You
know
more
people
to
do
more
things
in
more
places,
so
we've
been
trying
to
live
that
little
bit,
we
haven't
had
as
much
bandwidth
I
think
to
to
contribute,
as
as
I'd
like
to
the
course
dose
but
yeah
so
I'm,
okay
with
if
we
say
you
know
core
features,
slowdown
because
that's
how
we've
been
building
assuming
so.
E
B
F
We
can
also
say
we
did
this
at
the
leadership
summit.
We
had
a
session
on
this
very
topic
and
it
was
pretty
hard
to
make
much
progress
because
most
people
had
not
read
the
relevant
code
right
like
it's
hard
to
have
a
discussion
on
a
whiteboard
when
people
haven't
done
their
homework
in
advance
and
and
it's
much
harder
to
explain
the
problems
pretty
concretely
in
a
way
that
you
can
make
forward
progress.
But
you
can
motivate
people
and
draw
some
high-level
pictures.
F
B
I'm
with
you
I
think,
I
think
a
hackathon
there
is
is
definitely
interesting,
so
I
mean
one
of
the
things
that
I
think
would
be
useful
and
and
I
think
we
just
need
to
keep
some
of
this
stuff
top
of
mind.
If
this
really
is
our
top
priority
and
I
think
this
plus
extensibility
points
me
meet
the
bar
there
well
you're
doing
things
and
I
know
it's
a
little
bit
painful,
but
like
a
check-in,
a
sort
of
what's
happening
with
the
refactor
this
week
every
other
week
or
something
like
that
at
the
community
meeting.
B
F
A
F
I'm
gonna
dig
into
the
kms
one
specifically
and
Luco
you
about
that,
because
I
think
that's
an
area
where
we
just
need
an
answer.
Are
we
gonna
allow
cloud
providers
in
for
some
amount
of
time?
Are
we
going
to
back
out
what
we
did?
Yeah
I
think
those
are
really
the
only
two
rational
options.
Daniel
made
the
point
that
the
benefits
one
benefit
of
putting
stuff
in
trees.
It
allows
us
to
get
a
few
examples
before
we
generalize
the
extension
API
yeah
I.
Maybe.
G
F
F
F
F
If
a
question
comes
up
that
we
think
is
going
to
be
applicable
in
the
future
to
other
situations
that
are
similar,
we
should
try
to
write
down
the
answer
and
not
just
say
the
answer
right
so
I
want
the
API
conventions,
for
example,
to
expand
pretty
dramatically.
We
talked
about
well
well,
watch
doesn't
document
it
in
whatever.
Well,
let's
start
go
documenting
this
stuff
on
so
I'm
gonna
try
to
take
a
pretty
hard
line.
There.
F
I'll
get
asked
things
like
all
day
long
every
day,
I'm
gonna
stop
answering
people
and
start
spending
time
writing
stuff
down,
because
usually
what
I
do
is
I
say:
okay,
now
you
write
down
what
I
said
to
see
if
you
understand
and
then
that
never
happens
so
I'm
gonna
stop
doing
that
and
I'm
gonna
try
to
write
down
answers
instead.
Now.
F
F
Naturally,
discover
it
excellent
question,
so
I've
had
some
thoughts
about
that,
so
the
API
conventions
in
particular,
I,
can
announce
when
there
are
updates.
I
can
also
presented
every
I,
don't
know
six
months
or
something
and
evolve
it.
That
way,
like
I
recently
did
an
internal
presentation
about,
could
win
any
API
conventions
for
folks,
and
it
was
had
some
Google
specific
orientation
because
in
within
Google,
people
build
their
API
as
a
certain
different
way.
So
it
was
more
to
teach
them
how
to
bend
their
thinking
to
it.
D
Was
just
gonna
say
brand,
the
the
biggest
the
biggest
thing
is
actually
just
to
write
it
down
and
get
it
in
the
documentation
for
kubernetes,
because
there's
a
thing
called
a
search
engine
that
people
can
find
it
with
and
at
the
very
least
you
know
when
somebody
says
Brian.
What's
the
answer
to
this,
you
can
say:
go
and
look
in
the
documentation.
So,
even
if
you
don't
do
a
single
presentation
or
communicate
any
of
this
stuff
other
than
commit
to
PR
I,
think
that's
like
an
enormous
step
forward.
Yes,.