►
From YouTube: Kubernetes SIG Architecture Office Hours 10 19 2017
Description
B
A
C
B
B
So
the
the
two
minute
summary
is:
we
started
out
the
quarter,
thinking
we
were
going
to
work
really
hard
and
get
initializers
to
beta
and
while
I
was
out
the
people
working
on
this
examined
it
and
decided
that
actually
the
needs
would
be
better
served
if
we
switched
and
added
mutation
to
webhooks
and
got
mutating
weapons
to
beta.
So
that's
that's
now
the
plan
its
record,
so
this
would
be
instead
of
initializers.
B
C
So,
what's
our
guidance
to
users
in
terms
of
the
difference
between
these
things
and
when
they
want
to
use
one
versus
the
other
and
what
works
in
what
situations?
Because
they're
both
ways
for
sort
of
things
from
the
outside
to
the
to
you
know,
play
a
part
of
these
sort
of
flow
of
api
objects.
Right.
My.
A
Understanding,
since
I
was
around
when
Daniel
was
out,
is
that
there
are
a
few
things
that
happened.
One
was
that
people
working
on
initializers
and
examining
that
and
trying
to
figure
out
how
to
actually
use
it.
We're
working
together
a
nun
serviced,
a
lot
of
corner
cases
that
they
wasn't
entirely
clear
how
to
resolve,
or
they
thought
you
know
they
would
take
a
long
time
to
resolve
and
at
the
same
time
there
is
an
AA,
an
analysis
done
of
all
the
existing
admission,
control
controllers
and
kubernetes
and
in
openshift
and
said
well.
A
If
we
were
going
to
move
these
to
an
extension
mechanism
which
one
would
work
best
and
in
addition
to
the
customers
of
the
extension
which
of
which
there
are
several
waiting
in
the
wings
for
this
mechanism-
and
it
was
the
conclusion
was
that
mutating
webhooks
would
be
simpler
and
serve
more
use.
Cases
such
as
they
can
there's
a
story
for
update
like
we
don't
have
a
story
for
initializers
on
update
yeah
yeah,
that's
one
of
the
big
ones.
We
needs
provisional
state
mechanism
or
something
like
that,
and
I
have
ideas
about
how
to
do
that.
A
Kubernetes
developers
already
know
how
to
write
controllers
initializers
will
be
easier
to
write
and
I
think
the
conclusion
is:
that's
not
a
that.
People
think
that
controllers
are
not
easy
to
write,
because
the
Informer's
and
everything
are
actually
very
tricky.
So
people
are
people
are
working
on
ways
to
make
them
easier
to
write
like
meta
controller.
Basically,
ways
to
convert
watch
into
reliable
hooks
is
what
it
comes
down
to.
So
if
this
story
is
people
that
people
actually
need
hooks,
then-
and
we're
gonna
have
hooks
anyway,
and
it
serves
more
use
cases
an
is
simpler.
A
B
A
There's
also
all
the
use
cases
that
we
initially
wanted
to
serve
with
initializers,
but
we
may
want
to
change
the
semantics.
So,
in
the
past,
we've
had
this
concept
of
inert
where
we
wanted
to
be
able
to
create
a
resource
and
then
fill
in
details
before
it
really
became
active
and
that
has
kind
of
morphed
into
initializers.
A
D
D
So
the
the
synchronous
is
simpler
for
right
now
and,
as
they
said,
is
like
similar
Delta
I
think
we
were
always
going
to
need
an
issue.
Mutate,
initializer,
webhook,
mutating
webhooks,
I.
Think
initializers
might
be
the
thing
that
most
people,
if
we
could
figure
out
a
way
to
present
them,
would
want
to
wrap
their
heads
around
getting
started
and
would
probably
work
more
in
a
familiar
way.
But
as
we
said
like
we're
still
early
in
those
days,
yeah.
A
D
A
For
maybe
potential
interest
or
background,
we
use
something
like
initializers
in
borg,
but
in
a
more
ad
hoc
way,
and
we
have
several
parts
of
Borg
jobs
that
get
can
get
filled
in
asynchronously
after
the
job
object.
Its
gets
created
it's
not
as
general
of
a
mechanism
as
initializers
like
these
are
very
specific
things
that
were
added
to
for
jobs
and
only
got
object.
You.
C
C
B
A
B
D
First
on
my
list,
initialize
there's
definitely
have
an
advantage
there,
because
you're
gonna
do
a
certain
amount
of
writes
yeah,
admittedly,
like
the
other
problem
with
initializers,
they
do
amplify
the
number
of
writes
in
the
system.
So
every
update
might
require
you
to
write
the
partial
state
and
get
like
five
initializers.
They
might
make
five
updates
in
a
row
so
you're
already
gonna
have
some
level
of
you're
gonna
start
going
for
throughput
rather
than
latency,
but
it's
a
mechanism
that
we
already
have
in
our
controllers,
where
we
are
fairly
throughput
oriented,
okay,.
C
C
If
one
goes
to
beta
first
people
are
gonna,
be
like
oh
well,
like
you
know,
everybody
made
a
lot
of
noise
about
initializers
and,
like
Kelsey,
was
doing
demos
of
this
stuff,
and
that
was
the
new
hotness,
and
now
it
turns
out
that
those
things
are
actually
being
you
know
held
back.
While
we
do
this
other
thing
and
so
like
I
know,
that's
not
the
story,
but
I.
A
Alpha
right,
so
we
experienced
this
with
the
whole
pet
set
thing
as
well.
Like
people
were
very
excited
about
the
about
the
functionality
right,
so
they
made
a
lot
of
noise
about
it
and
then
who
is
Elvis?
Oh,
it
changed,
surprise,
surprise,
yeah
yeah,
and
we
need
to
do
a
better
job
of
putting
caveats
like
we
know
that
this
personality
is
needed.
We
don't
give
it
a
try
it
out.
It's
an
it's
an
experiment,
we'll
change
it.
If
it
needs
to
be
changed
and
improved
yeah.
C
Think
the
other
two
issues
and
I
don't
know:
I
haven't
read
the
doc,
but
but
maybe
cleaner
or
Daniel
you
know
is
I
saw
some
reference
to
dynamic
registration
of
these
things.
Can
you
register
these
things
that
run
yes,
yeah,
there's
a
there's,
a
there's,
a
config
mechanism.
Okay!
Is
that
getting
rationalize
with
with
the
the
component
config
stuff?
Or
is
this
just
a
another
different
config
thing?
That's.
B
D
A
C
A
B
B
Yeah,
that's
the
other
big
one
is
no
gets
order.
Lists
I
do
agree
that
we
should
rationalize
the
configuration
approach,
because
the
authorization
webhook
is
currently
configured
statically
at
startup
and
it's
configured
with
a
very
strange
is,
like
somebody
repurposed,
a
cube
config
file
to
do
the
config,
which
is
which
is
really
confusing
to
me
and.
E
C
Except
Julia,
Evans
I
know
well
she
wrote
this
huge
thing,
but
it
took
really
probably
a
week
to
actually
figure
that
stuff
out
and
I
look
at
it
and
I'm
like
yeah.
I
know
why
we're
doing
all
that,
but
it's
just
because
we
don't
have
this
bedrock
identity
system
to
actually
fall
back
on,
and
so
this
isn't
exactly
the
the
container
working
group
gonna
be
working
group,
but
it
definitely
because
these
things
don't
have
to
be
running
on
cluster
right.
You
can
have
a
web
hook
to
something
that's
running
off
clusters,
so
it
can't.
B
We
discovered
yesterday
that
it's
actually
worse
because
we
want
the
dynamic
omission
stack
to
run
from
extension,
API
servers,
as
well
as
the
the
main
API
server,
which
means
that
in
and
probably
saying
the
system
administrators
don't
want
the
same
cert
from
like
those
as
much
as
the
other
ones.
Right
so.
C
B
C
B
C
I'm
not
gonna
bring
I'm,
not
gonna,
I'm,
not
gonna,
say
the
word
that
you
know
I'm
gonna
say
but
like
I,
think
that
is
something
that
the
more
and
more
web
hooks
we
had.
That's
one
of
the
things
that
is
nice
about
initializers
is
that
you
don't
have
to
deal
like.
We
already
have
an
identity
system
for
things,
calling
in
there's
a
guy
server.
C
B
A
D
Of
the
container
identity
discussion
we
briefly
touched
on
what
CA
is
the
cluster
trusts
or
what
CAS
are
available
in
the
cluster,
and
so
there
was
some
overlap
there,
because
we
have
this
general
problem
of
when
you
give
a
node
a
service
account.
You
are
also
giving
it
the
CA
that
it's
going
to
use
to
talk
back
to
the
API
server.
We
have
a
couple
of
cases
in
bootstrapping
that
deal
with
CAS
and
there's
their
overlapping
problems,
they're,
not
necessarily
all
solved,
but
I
think
they
both
might
be
a
good
place
to
discuss
it.
C
B
Gonna
be
wired
with
others,
gonna
be
wired
into
the
cube
API
server.
Our
current
decision
is
that
we're
not
going
to
make
we're
gonna.
Allow
extension
API
servers
to
depend
on
DNS
and
routing
within
the
cluster,
but
we
don't
believe
that
the
cube
the
main
API
server
should
depend
on
those.
It's
a
layering
problem.
C
B
B
C
B
C
B
Yeah,
that
should
be
fine
too,
but
at
that
can,
in
that
case
you're
not
depending
on
the
DNS
or
routing
you
guess.
Oh
yeah
yeah,
it's
not
you,
don't
have
a
bootstrapping
sort
of
that.
Yes,
you
just
issue
they're
going
on
okay,
yeah
yeah
the
issue
with
the
main
API
servers
that
you
got
to
be
able
to
start
it
before.
You
start
the
controllers
that
manage
the
routing
in
the
DNS.
D
Yeah
and
web
hooks
web
hooks
fail
closed
today,
so
there's
a
discussion
that
needs
to
happen
on
some
of
the
details
of
that.
That
is
gonna
update
both
of
the
proposals,
because
it
is
one
of
the
things
that
we
said
was
a
prereq
for
beta
does
not
I,
don't
know.
If
we
you
got,
you
guys
saw
it
in
there,
but
it
is
something
that
has
to
get.
D
B
A
A
C
Yeah,
all
right
so
I'm
gonna
be
some
cold
water.
Here
this
looks
like
some
significant
changes
from
the
stuff.
That's
in
beta,
it
seems
like
there's
a
little
bit
of
like
hey.
We
did
something
completely
different,
but
we're
rewriting
it
all
for
beta
right.
It
feels
like
this
should.
Maybe
all
these
changes
should
be
alpha
for
a
cycle
before
they
move
to
beta
right,
like
there's
a
lot
of
changes
in
this
dock
from
so.
D
One
thought
that
I
might
have
Joe
is
like
it's
the
mechanism
for
actually
doing
the
check
and
the
checks
themselves
in
a
beta
you're.
Still,
it's
still
an
opt-in
system,
which
is,
if
you
use
a
beta
admission,
controller
and
beta
X
emission
control
mechanism.
The
changes
are
probably
on
the
config
side,
like
the
mechanism
is
unlikely
to
change
for
the
the
actual
webhook
call
out
like
if
you
said
like
today.
D
If
someone
wrote
code
patched
it
into
kubernetes
and
added
a
mission
chunk,
it's
not
really
like
it's
that
code,
that's
the
beta
quality,
and
that
was
one
of
the
thoughts
behind
like
we're
not
actually
changing
the
mechanism
other
than
completing
the
mutating.
There
are
definitely
edge
cases,
but
none
of
those
necessarily
change
the
mechanism.
They
change.
The
registration
and
the
handling
well,.
C
I
mean
there's
stuff
like
the
the
mutation
stuff
like
I'm.
Looking
at
this
like,
oh,
are
we
gonna
do
patch?
Are
we
gonna
do
a
put
you
know?
Are
we
gonna
support
all
the
different
types
of
patch?
Like
you
know,
those
things
are
gonna,
be
you
know
like
I,
look
at
strategic
merger
patch
I'm,
not
a
fan,
I
think
it's
overly
complicated,
I
think
the
things
should
be
versioned
because,
like
I
can
changes,
we
should
have
merged
strategic
merged
past
one
two,
three
four
right.
C
You
know
it's
like
I
mean
like
these
are
all
sort
of
things
that
that
are
gonna,
be
you
know
that
they're
gonna
have
to
be
shaken
out
now.
I
understand
that
the
the
rush
to
beta
means
that
you
get
access
to
these
things
on
things
like
GK,
think
I
mean
I
mean.
Is
that
one
of
the
things
that's
actually
pushing
this
forward
practically.
C
B
So,
actually,
that's
that's
not
completely
true,
because
the
web
hooks
do
exist
right
now.
They
are
in
alpha
I.
The
beginning
of
the
cycle.
I
tried
hard
to
find
somebody
who
had
used
them
and
I.
Finally,
today
just
got
some
feedback
from
from
Kelsey,
but
he
hadn't
he
hadn't
even
tried
them.
When
I,
when
I
went
out,
asking
and
I
was
able
unable
to
find
someone
who
had
so
so
we
didn't
actually
get
much
feedback
on
the
on
the
on
those
web
books.
I
guess.
C
What
I'm
trying
to
say
is
that
is
that
there's
there's
conditions
that
lead
to
a
lot
of
engagement
and
feedback
and
those
conditions
that
lead
for
lead
to
people
kind
of
ignoring
these
things.
I'm,
not
sure
that
you
know
I'm,
not
sure
that
that
the
alpha-beta
thing
is
the
thing
that's
actually
leaning
for
feedback
are
not
feedback.
A
C
B
C
Yeah
I
mean
I'll.
Give
you
an
example.
Is
that,
like
you
know,
we've
been
taking
our
time
say
taking
the
bootstrap
tokens
in
queue
medium
to
GA,
right
and,
and
we
kept
them
in
alpha
for
a
long
time
and
as
we
transition
to
beta
there's
essentially
been
very
little
changes
through
the
beta
through
the
beta
process.
Yeah.
B
D
Well
it
to
be
fair,
I
think
I,
agree,
Jo
and
like
there's,
some
there's
some
level
here
of
the
mechanism
for
mutating
is
almost
certainly
going
to
look
something
like
this
I
think
that
you're
you're
absolutely
correct
that
there
is
a
we're
almost
through
the
1-9
cycle
and
we're
talking
about.
Well,
we
might
do
this
particular
patch
mechanism.
Some
of
these
have
been
like
things
have
been
discussed
for
a
long
time.
D
So
it's
not
like
that
surprising
to
some
of
the
folks
involved
in
the
initializers,
but
I
would
or
webhooks
I
would
agree
that,
with
pet
set
as
an
example,
we
were
fairly
confident
that
what
we
had
was
ready
to
be
tried
and
used
by
users.
We
knew
there
were
some
gaps,
updating,
etc.
The
choice
to
go
to
beta
was
specifically
to
get
a
wider
range
of
people
with
a
certain
promise
that
we
were
gonna
provide.
D
We
did
change
staple
sets
in
beta
several
times
and
what
we
avoid.
It
was
an
API
incompatibility,
because
we
thought
about
those
issues.
Do
you
feel?
Are
you
more
concerned
about
the
the
mechanism
being
API
compatible
or
ignored
is
concerned
about
the
the
some
of
the
vagueness
in
the
design
at
this
point
in
the
1:9
I?
Think.
C
C
B
C
We
need
to
get
clear
here
because,
like
a
couple
of
weeks
ago,
it
was
the
discussion
there
was.
Was
there
may
be
API
changes,
but
we're
gonna
think
really
hard
about
it,
because
we
know
that
people
are
using
it
and
we're
not
gonna.
Do
it
unless
we
absolutely
well
there
I
I'm,
just
I
I
feel
like
this
feels
a
little
rushed
to
me.
That's
all
so.
A
D
A
D
A
little
bit
easier
there
because
we
are
sending
an
API,
and
so
we
this
is
not
a
persisted
API,
so
we
have
a
little
bit
more
flexibility
in
terms
of
we
could
the
implementation
is
we
send
an
API
and
if
you
don't
recognize
it
or
don't
respond
to
it,
you
should
be
erroring
anyway.
We
don't
actually
persist
that
and
have
to
do
round
tripping
in
the
same
way
like
the
Delta.
There
is
going
to
be
fairly
its
semantics.
There's.
B
Not
a
wire
format
in
stakes
in
place,
so
yeah,
it's
not
like
yeah.
That
makes
it
a
little
easier,
but
I
still
think
we
need
a
good
plan
for
updating
both
the
web
hooks
themselves
and
also
the
control
plane
like
whichever
order
you
either
need
to
define
the
order
or
we
need
to
make
sure
upgrading
in
either
order
works
is.
D
There
a
way
for
us
to
to
do
this
in
a
way
that
we're
really
clear
that
we,
because,
like
we,
have
changed
some
of
the
web
hook
in
beta
before
and
those
were
kind
of
stepping-stone
sorts
of
things
like
webhooks
definitely
are
a
call
out
mechanism,
which
is
a
little
bit
more
isolated.
Is
there
some
way
that
we
can
ensure
that
this
is
not
backing
us
into
a
corner?
D
From
the
perspective
of
you
know,
future
change,
because
I
mean
I
would
agree
with
you
I
think,
like
you
know,
we
want
this
because
extension
is
one
of
the
fundamental
pillars
of
what
we're
trying
to
do.
I,
don't
wanna
slow
things
down,
but
you
can't
expect
you
can't
extend
cube
today.
How
do
we
balance
those.
B
C
Actually
argue
with
that
Daniel
I
think
four
core
set
of
people
around
the
API
machinery
that
has
been
the
bias
for
stuff.
That's
further
out
that
a
lot
of
the
advice
has
been
slow
down.
Take
your
time
right,
I
think
we
I
think
end
of
line
that
that
sort
of
the
alpha-beta
GA
things
like
if
you
look
for
people
looking
for
future
exceptions
late
in
the
cycle,
you'll
find
that
that
the
API
machinery
stuff
is
given
a
hell
of
a
lot
more
leeway
than
other
parts
of
the
project.
B
I,
don't
know
that
I
agree
with
that
I
also
I
also
think
I
I
think
API
machinery
extension
stuff
is
really
high
leverage
and
we're
locking
a
lot
of
people
right
now.
So
I
think
this
is
the
remaining
area
of
the
project
where
that
logic
applies
like
at
the
beginning
of
the
project
that
logic
applied
to
everything,
because
everything
was
like
zero
come
on.
We
have
a
now.
B
Need
to
slow
down
and
more
carefully
way
where
we
add
technical
debt
and
I've
been
telling
API
machinery
sig.
That
I'm
only
willing
to
add
technical
debt
for
features
that
are
per
extensibility
features,
basically
like,
because
that
enables
people
to
get
the
technical
debt
out
of
our
code
and
into
their
own
code.
Essentially.
D
Yeah
I
would
say
like
right
now
like
when
you
think
about
projects
like
sto
projects
like
OPA,
open
policy,
guys
I'm,
just
oh
Allah,
there's
like
the
thing
that
does
gate
is
a
way
to
start
iterating
I
mean
so
hypothetically,
let's
say
from
the
perspectives
of
getting
feedback,
and
you
know
having
a
comfort
level.
What
is
the
minimum
that
we
could
do
for
B
1
beta
1,
with
the
expectation
that
we
will
iterate
and
change
it,
and
that
I
mean
like
because
we
did
this
for
stateful
sites.
D
C
It's
just:
how
do
we
position
this?
How
do
we
talk
about
it?
I
think
a
lot
of
stuff
coming
out
of
API
machinery.
There's
a
lot
of
good
hard
work
going
on
there,
I,
don't
think
it's
necessarily
communicated
super
well
right.
I
think
the
change
is
around
moving
API
objects
between
different
API
groups
is
is
one
of
those
things
where
I
see
it.
You
know
confuse
users
again
and
again.
We
haven't.
D
C
Around
this
stuff
right,
it's
and
again
it's
like
if
something's
in
beta
and
it's
like
hey
this-
will
change
right.
That
is.
That
is
something
that
that
you
know
we
really
got
to
get
across
to
folks
that
hey
look,
this
is
beta.
We
really
mean
it
right,
I,
just
don't
think.
We've
necessarily
been
been
great
in
that
communication,
both
in
terms
of
letting
people
know
about
it
and
in
terms
of
making
clear
sort
of
what
the
roadmap,
what
the
plans
are,
how
this
stuff
works.
Yeah.
A
We
would
like
there
not
to
have
to
be
more
Forks
of
that
kind,
but
what
we
see
is
you
know
if
we
don't
address
this
particular
admission,
our
extension
point
soon,
weird
Forks
are
going
to
proliferate,
both
due
to
enterprise
users
needing
to
enforce
policies
like
using
opa
or
something
like
that,
but
also
all
these
services
coming
online,
whether
it's
GAE
or
amazon
or
whoever
is
building
a
community
service.
They
all
need
some
mechanism
like
this,
so
yeah
all.
C
C
B
Was
the
stock
was
written
to
this?
Is
this
is
not
a
complete
design
doc
if
you
go
through
it,
you'll
notice
that
there's
links
to
other
design
Doc's
where
people
are
ironing
out
more
concrete
details.
This
was
this
talk
was
written
to
make
sure
everybody
is,
on
the
page
same
page
and
they're
agreeing
to
the
same
direction
and
then
we're
going
to
try
and
parallel
eyes
the
the
fiddly
details.
C
Its
landing
her
dude
to
be
honest,
I
read
its
I
mean
this
is
this
is
really
really
ambitious
to
get
this
stuff
done
for
the
1:9
cycle
and
then
be
able
to
communicate
it
and
test
it.
It
feels
to
me,
like
you
know,
their
skin
is
gonna,
come
down
to
the
wire
and
there's
going
to
be
exceptions
and
there's
gonna
be
patches
a
as
point
releases
all
because
we
want
to
get
this
stuff
to
beta
quicker
I.
B
B
D
D
To
be
fair,
Jo
I
have
all
the
same
concerns
and
I
think
like
I'm,
a
little
bit
more
biased
towards
getting
the
extensibility
in,
even
though
we
so
OpenShift
probably
isn't
gonna
be
able
to
use
this
right
away.
One
of
the
things
like
I'd
rather
have
us
do
is
spend
a
bunch
of
time
observing
how
everyone
else
is
using
it
and
then
come
back
and
say
we're
gonna
go
try
to
put
like
something
super
high-performance
through
this,
and
so
like
I
expect
this
to
be
a
fairly
long
beta
process,
no
matter
what
okay.
A
Yeah-
and
we
also
need
to
sort
out
how
this
place
with
other
extension
mechanisms
like
API,
aggregation
and
CR
DS
and
things
all
right.
You
know
there
is
going
to
be
a
long
beta
period.
I
would
like
it
to
get
to
GA
before
the
end
of
next
year,
so
you
know
having
it
be
in
a
state
where
it's
broadly
usable,
together
with
these
other
mechanisms
and
users
for
a
few
releases
next
year,
I
think
is
pretty
important.
So
I.
C
C
Oh,
it
took
me
half
an
hour
to
figure
out
the
flags
for
enabling
a
new
API
group,
because
there's
this
mini
language
and
the
flags
for
doing
this
stuff,
like
our
documentation
around
our
GA
features,
is
awful
right,
like
like
I.
Think
as
we
look
at
like
I'm
a
channel
caleb
a
little
bit
here.
Right
like
we
want
Docs
like
this
to
actually
be
part
of
our
release,
notes
and
actually
be
something
that
users
can
look
at
and
understand:
hey!
Here's!
What's
going
on
here
where
things
are
going,
these
are
notes
for
insiders.
C
These
are
not
actually
proposals
that
people
outside
of
the
outside
of
the
the
sort
of
core
set
of
people
can
actually
consume,
and
so,
even
if
we
get
the
code
in
for
beta
hitting
sort
of
the,
if
you
really
want
to
see
usability,
if
you
really
want
to
see
people
sort
of
outside
of
that
core
group
of
insiders
use
this
stuff,
there's
a
whole
other
set
of
things
that
have
to
happen
as
part
of
this
and
I.
Just
don't
feel
like
anybody's,
really
thinking
about
our
planning
for
that.
So.
C
B
C
A
C
A
Raised
documentation
is
one
thing
that
we
have
been
you
know.
Google
has
been
adding
staff
to,
and
we've
been
filtering
the
burden
of
that,
and
we
did
get
other
companies
to
agree
to
help
out
in
that
area
if
they
actually
delivered
that
will
almost
smell
people.
We
have
helping
with
documentation
so.
C
Two
things
there
so
number
one
is:
is
this
type
of
documentation
you
can't
pawn
off
on
somebody
else?
This
stuff
has
to
be
driven
by
the
folks
who
understand
this
thing
at
a
sort
of
root
level,
or
they
have
to
present
stuff.
That's
consumable
by
the
folks
who
are
actually
gonna
clean
it
up
right.
If
we
had
our
cut
processing
in
place-
and
this
went
through
the
kept
process,
we
would
have,
it
would
take
longer
right
because
we
wouldn't
be
having
like
it
would
take
longer.
C
Let's
just
be
clear
there,
but
the
end
result
would
be
something
that
would
actually
be
consumable
by
a
wider
audience.
I
think
even
bringing
this
document
to
this
group,
because
I'm
not
going
to
all
the
API
machineries,
will
lead
to
new
folks,
actually
thinking
about
how
do
I
actually
sort
of
create
these
proposals
in
a
more
consumable
way.
So.
A
C
Not
create
that
that
that
that
information
architecture
is
totally
important,
but
that's
not
going
to
solve
the
problem
of
like
how
do
we
actually
get
this
stuff
consumable
by
folks
and
saying
that
we're
gonna
have
doc
writers
do
it
is
not
going
to
get
us
over
the
hump
there
and
I.
Don't
know
that
we
can
point
any
of
those
doc
writers
at
this
proposal
and
have
them
actually
extract
anything
useful.
So
so
how
about?
How
about
this
I
I
will.
B
C
Right
as
we
think
about
how
do
we
want
to
deal
with
proposals
in
general
if
we
had
had
that
process
from
the
get-go
I
think
what
we
would
have
looked
for
is
to
actually
end
up
with
a
proposal
that
actually
hits
a
whole
bunch
of
audiences
and
is
also
something
that
doc
writers
could
actually
take
and
sort
of
like
mutate
into
into
into
into
you
box
right,
so
I
I
think
I'm.
Some
of
it
is
like
yes,
this
thing
needs
to
get
done
in
like
if
you're
gonna
come
poor
engineers
do
it.
Let's
do
it.
C
That's
fine!
You
don't
have
to
put
me
in
the
loop,
but
I
think
some
of
it
is
that,
like
how
do
we
get
processes
in
where
that
is
not
an
afterthought
of
like
oh
I'm,
gonna
assign
somebody
to
do
that,
but
it's
something
that
actually
happens
as
part
of
the
planning
process
sort
of
naturally,
and
so
there's
a
little
bit
of
meta
thing
going
on
in
my
head,
I.
C
B
G
This
job,
all
right,
I'm
done
I'm
done
I-
want
to
jump
in
this.
My
friend
I
just
offer
one
thing
up
here.
So
one
of
the
problems
we
have
is
our
Doc's
are
not
good
right.
I
mean
this
has
come
up
all
over
the
place
that
our
Doc's
are
in
bad
shape.
In
fact,
more
than
once,
I've
talked
to
somebody
building
against
kubernetes.
G
You
said:
I
gave
up
on
the
docs
and
I'm
trying
to
figure
it
out
by
going
and
reading
all
the
source,
because
I
can't
understand
the
docs
and
so
really
having
a
healthy
conversation
about
how
do
we
have
better
Doc's,
whether
it's
doc,
writers
or
core
developers,
or
how
we
all
get
together
on
it?
I
think
it's
incredibly
useful,
because
right
now,
we're
not
in
good
shape.
F
I
weigh
in
on
that,
because
I
lived,
I
breathed,
all
the
docs
things
happen
and
when
a
release
and
the
tech
writers
are
doing
an
incredibly
hard
job
with
limited
resources
to
do
that
stuff,
and
this
needs
to
not
be
decorators.
This
needs
to
be
check
writers
polishing
what
SIG's
right,
so
you
need
to
own
their
their
stuff
and
they
need
to
pull
in
people
who
are
actually
using
this
and
do
test,
use
cases
and
say:
hey
Justin,
garrison.
You
know,
let's
try
this
at
Disney
tell
us
how
it
works,
give
us
feedback.
F
You
know
we
need
to
have
that
kind
of
feedback
loop
with
our
with
our
user
base
and
we
don't
have
it,
and
so
we
need
to.
We
need
to
get
much
better,
not
only
documentation,
but
documenting
things
are
actually
meaningful,
and
so
things
are
the
only
ones
who
are
going
to
be
able
to
have
that
back-and-forth
dialogue
with
the
people
using
their
features
that
are
gonna
going
to
be
able
to
produce
that.
So
we,
this
is
where
it's
a
great
place.
C
Okay,
it's
metaphor:
sega
architecture.
I
don't
think
it's
necessarily
immediate
relevant
for
it
for
the
the
topic
that
we're
discussing
here,
which
is
daniel's
things
so
I'm,
not
gonna,
I'm,
not
gonna,
say
this
is
out
of
scope
for
sega
architecture,
but
I
think
it's
definitely
a
little
bit
of
a
sidetrack
for
the
stuff
that
we're
talking
about
ya.
B
A
Yeah,
it
is
a
month
before
the
feature
complete
deadline
in
the
entire
history.
The
project
I,
don't
can't
remember
a
single
time
where
Docs
were
done
so
early
and
I'm,
not
saying
that
we
shouldn't
try
to
do
that,
but
there
are
a
lot
of
forces
in
play
that
caused
that
to
happen
and
I,
don't
think
it's
gonna
change
without
other
significant
changes.
The
way
we
do
do
development
so.
C
B
B
A
B
A
One
thing
that
isn't
go
pursue
architecture
is
that
we
need
to
move
to
branches.
We
have
to
get
the
development
of
kubernetes
kubernetes
master
so
that
we
can
keep
the
master
in
a
healthy
state
and
make
a
decision
a
go/no-go
decision
based
on
when
a
feature
is
ready,
including
docks
and
whatever
else
tests
code
quality,
because
the
current
state
is
code
gets
crammed
into
master
people
rush
to
get
stuff
in
before
the
feature
complete
deadline.
And
then
they
ask
for
exceptions
to
actually
finish
all
the
work
you.
A
C
Here's
I
mean
so
I'm
looking
through
the
Python
peps,
and
those
things
are
clear
enough
that
they
could
be
end-user
documentation
right.
We
need
to
get
to
the
point
where,
when
we
actually
propose
changes,
they're
actually
something
that
general
users
of
kubernetes
can
actually
read
and
understand,
and
then
that
actually
turns
itself
into
Docs,
and
so
when
you
say
we
need
it,
we
need
to
change
the
process.
C
What
I'm
saying
is
that
if
we
get
more
formal
about
proposals
and
reviewing
those
proposals
with
an
eye
towards
actually
viewing
them
from
the
point
of
view
of
the
general
user
base,
we're
gonna
end
up
with
something
that
actually
leads
to
better
Docs
out
the
of
the
gate.
That's
not
that's!
You
know
the
that
ship
has
sailed
for
for
this
particular
thing,
but
that's
the
meta
point
that
I'm
trying
to
make
here
all
right
cause.
Well,
yeah,
I,
I,
don't
I.
C
So
here's
the
thing
we're
accomplishing
things,
but
nobody
understands
what
the
hell
we're
accomplishing
or
how
to
use
it
right.
It's
like
if
a
tree
falls
in
a
forest
right.
If
code
gets
written
and
people
don't
know
how
to
use
it,
does
it
matter
and
it
actually
ends
up
in
my
mind,
it
ends
up
being
a
threat
to
the
project
when
we
actually
have
these
features
landing,
and
you
have
to
read
the
code
to
be
able
to
use
them.
It's
it's
I
think.
B
C
I
think
you
know
it's
gonna,
take
just
as
long
to
get
features
to
GA
right,
I.
Think
it's
just
a
matter
of
like
do.
We
actually
do
more
planning
up
front
versus
versus
spray,
some
code
and
hope
for
the
best
right
and
and
when
I
look
at
like
this
proposal,
there's
so
many
gaps
or
there's
so
many
questions.
There's
so
many
like
we'll
write
the
code
and
then
we'll
figure
it
out
afterwards.
I
think
we
have
to
start
changing
the
mode
we.
B
A
And
other
items
that
were
not
on
the
agenda,
but
there
was
email.
There
was
a
question
from
scheduling
about
how
to
represent
things
in
status.
That's
kind
of
in
the
same
vein
as
some
of
the
previous
discussions
we
had
about
conditions
so
if
you're
interested
in
that
follow
up
on
the
email,
but
it
looks
like
clean
and
I
both
gave
responses
that
were
consistent.
A
F
One
regular
meeting
I
have
one
quick
thing,
which
is
a
follow-up
to
last
meetings.
Discussion
on
the
bill,
you
delivery
and
tying
the
cap
process
to
him
to
an
implementation.
I
went
through
this
and
removed
a
lot
of
trigger
e
language
and
took
some
suggestions
from
Joe,
and
hopefully
this
document
is
getting
closer
to
being
able
to
submit
as
an
actual
proposal.
So
it's
again
it's
a
little
bit
sidelong
to
architecture,
but
this
is
a
this
is
a
group
that
is
a
stakeholder
in
this
process.
D
Was
one
item
that
came
out
of
sig
and
sequester
lifecycle,
which
was
a
discussion
about
Damon,
said
it's
going
to
be
one
and
the
concern
that
Damon
sets
right
now
aren't
guaranteed
at
most
one
their
best
effort
at
most
one
and
whether
we
think
that's
important
enough
to
delay
defer
warn
with
a
V
one
release.
We
could
talk
about
it
next
time
on
the
next
agenda.
A
D
A
D
But
we're
telling
users
yep
we've
protected
you
and
we're
not
telling
them
hey.
You
should
go
protect
yourself
and
that's
the
worst
combination,
which
is
we
should
either
protect
you
or
you
should
protect
yourself,
but
not
either
or
I'm.
Just
I'm
concerned
about
we've
taken
a
very
strong
stance
on
staple
sets
and
a
very
weak
stance
on
replica
sets
and
there's
we're
a
little
vague
on
Damen
sets,
especially
if
you
know
it
like
we're.
Telling
people
hey
run.
D
Gluster
servers
in
a
payment
set
I
need
to
know
whether
to
tell
the
Gluster
team
that
they
better
be
darn
sure
that
they
have
all
the
locks
necessary
even
on
their
initial
config,
to
make
sure
that,
in
a
controller
restart
scenario,
they
don't
go
and
eat
the
data.
That's
serving
the
entire
cluster.
Those
sorts
of
things
and
I
think
that
it's
gonna
come
up
for
self
hosting
because
self
hosting
you
know
we
should
be
telling
people
you
need
to
use
strongly
consistent
locks
on
the
system
and
here's
how
you
should
go.
A
D
Sure,
but
the
people
who
were
burned
by
this
we're
not
doing
this
like
every
failure,
so
far
has
been
someone
using
daemon
sets
like
is
creating
pods.
Multiple
positive
is
causing
problems
for
me,
which
is
the
users
speak
for
I,
have
no
idea
what
you're
doing
and
I
just
trusted.
You
and
I
think
that's
I
I
see
a
lot
of
that
and
so
I
next
time
we
can
talk
a
little
bit
more
about
it
or
maybe
have
a
discussion
on
the
email
thread.
D
G
Have
one
very
fast
question
because
those
happen
here:
there's
the
cluster
add-ons
inside
of
kubernetes
that
now
have
listed
as
legacy
or
deprecated
the
add-on
manager
in
there
I'm
guessing
is
also
legacy
and
deprecated.
Is
there
any
follow-up
to
that
or
who
owns
that
or
do
add-ons
come
in
not
through
a
general
managers
or
so
so
that's
something
that
we
we've.
C
Been
looking
at
that
cookie
has
been
forced
by
some
degree
by
for
cluster
lifecycle,
but
there
hasn't
been
a
lot
of
action
on
that.
Justin
sb
has
a
proposal
out
there,
but
it
hasn't
really.
It's
been
a
fellow
for
a
while.
So
this
is
honestly
something
that's
kind
of
kind
of
getting
dropped
right
now
that
that
shouldn't
be
so
that
is.
A
The
short
answer
is,
there
is
no
official
there's,
no
officially
he's
no
such
things
add-ons.
It's
part
of
the
individual
cluster
lifecycle
mechanisms
like
Cuba,
which
is
deprecated,
you're
right
and
cops,
has
an
add-on
mechanism,
and
many
heute
has
an
add-on
mechanism
but
they're
all
different
mechanisms.
So.
G
A
And
so
yeah,
and
that
is
something
I
would
like
to
fix.
Justin's
proposal
is
not
adequate.
There
are
a
bunch
of
issues,
I
catalogued
them
in
the
issue
about
this.
It's
gonna
require
significant
effort.
You
address,
we
don't
have.
We
don't
have
enough
people
too
many
things
are
going
on.
Someone
wants
to
address
that.
You
can
take
a
look
at
the
issue
and
we
can
handcraft
a
proposal
that
will
work
and
be
happy
to
have.
Someone
worked
on
that.
Okay,.