►
From YouTube: Kubernetes SIG Architecture 20190207
Description
A
All
right
welcome
everyone.
It
is
Thursday
for
Mary
20,
February,
7th
2019,
and
this
is
the
community's
siga
architecture
meeting
just
to
make
sure
you're
in
the
right
place.
I'm
your
host
I'm,
one
of
the
three
chairs
for
the
project
here
and
I'm,
Jason
senior,
Dumars
and
I
work
at
Google
and
we're
gonna
go
and
get
started.
If
you
want
to
follow
along
with
the
agenda,
it
is
available
at
bit.
A
Dot
ly
/,
cig
architecture
and
before
you
get
into
the
agenda,
I
just
want
to
make
a
quick
reminder
of
our
working
agreements,
which
is
make
feedback
constructive
and
actionable
favor
work
/
discussion
when
possible
and
if
you've
got
a
comment,
try
chat
first
and
if
you're
talking
when
listening,
please
be
mindful
of
others
who
have
not
spoken
so
with
that
we're
gonna
go
ahead
and
get
into
the
agenda
and
I
believe
Erin.
That
is
you
to
start
off
this.
B
C
B
But
my
spot
check
of
all
of
the
caps
is
that
they
are
all
of
wildly
varying
degrees
of
quality
and
specificity
when
it
comes
to
what
I
am
interested
in
from
a
release
team
perspective,
which
is
graduation
criteria
in
the
form
of
a
checklist
and
a
test
plan
that
makes
it
really
easy
for
the
CI
signal
people
to
understand
is
this
feature
actually
passing
its
tests?
Yes
or
no.
So
my
my
hope
here
is
that
we
as
a
community,
can
rally
around
trying
to
get
some
level
of
consistency
here.
B
Some
level
of
making
these
things
actionable
and
trying
to
get
these
things
locked
in
place
prior
to
burn
down
so
burn
down
is
basically
like
a
week
to
week
and
a
half
away
from
code
freeze.
It
is
week
eight
of
the
release
cycle.
The
release
cycle
is
12
weeks,
long
code
freeze,
it
starts
at
week.
Nine.
B
B
But
you
know
it
like
Caleb's,
not
here,
so
you
can't
say
and
I
told
you
so
but
nobody's
surprise
like
this
is
really
difficult
to
keep
track
of,
because
it
basically
involves
humans
staring
at
a
spreadsheet
and
then
trying
to
reconcile
that
against
issues
and
then
trying
to
reconcile
that
against
documents
which
have
multiple
PRS
made
against
multiple
cycles.
So
this
is
as
bumpy
as
I
expected,
but
I
do
think.
B
On
a
positive
note,
the
community
heard
the
rallying
cry
loud
and
clear
that
if
you
don't
have
a
cap,
you
don't
land,
so
everybody
really
did
try
so
like
I'll,
probably
have
a
lot
more
substance
of
feedback
in
terms
of
friction
and
consistency.
For
my
end,
once
I
actually
have
the
time
to
roll
through
all
of
this
I'm,
far
more
interested
in
being
in
hearing
everybody
else's
thoughts
in
perspective.
D
D
All
that
said,
there
is
a
new
kept
template
that
is
up
for
review,
so
everyone
who's
interested
in
having
feedback
on
that
process
like
we'd
like
to
get
it
in
soon,
so
that
it's
a
little
clearer
for
everyone,
but
we
want
to
make
sure
that
it's
done
the
right
way.
So
please
review
the
template
and
if
you
have
suggestions
for
changes,
please
let
me
know
Joe
yeah.
E
I
think
you
know,
there's
dual
purposes
for
keps
and
I.
Think
you
know,
I
don't
want
us
to
like
one
of
those
things
is
to
be
able
to
communicate
plans
and
sort
of
architectural
decisions
and
features
that
people
are
talking
about
so
that
we
can
get
some
review,
get
some
eyes
get
some
process
before
people
write
a
boatload
of
code.
E
That's
a
separate
from
sort
of
the
future,
or
at
least
off
so
I
think
you
know,
as
we
go
through
and
add
more
to
the
template,
as
we
go
through
is
make
this
part
of
the
the
release
process.
I.
Think
that's
important,
but
I
don't
want
us
to
actually
make
it
look
so
overwhelming
that
people
try
to
hide
it
or
don't
share
their
ideas
or
try
to
sneak
stuff
through
so
I
feel
like
there's
a
balance
here
and
maybe
there's
a
way
that
like
like,
we
can
have
like
okay.
E
What
does
a
kemp
need
so
that
I
can
get
implementable
and
then
what
is
a
you
know?
And
then
there's
like
okay?
What
are
the
things
necessary?
You
know
for
for
release
and
I'm,
not
quite
sure
how
to
tease
these
things
apart,
but
I
just
don't
want
this
thing
to
be
like
a
wall
of
like
stuff.
You
have
to
do
you
know
every
time
you
want
to
do
anything
which
I
think
would
you
know
people
then
hide
okay,
Stephen.
D
Hey
so
I
think
it's
well
to
make
it
clear
and
have
it
on
recording
that
the
intent
for
you
know
at
least
one
of
the
intents
for
caps
are
to
merge
early
and
iterate,
often
right
so
making
sure
that,
like
honestly,
when
it
kept
is
in,
is
in
provisional
state
in
a
draft
state.
The
expectation
is
that
we
have
a
summary
and
motivation
and
some
like
goals
right.
So
once
that's
laid
down
I
think
that's
fine
to
merge.
D
The
understanding
should
be
that
moving
into
the
implementable
stage
that
the
the
bar
gets,
the
bar
gets
raised
a
little
bit
right.
So
that's
what
Lang
laying
down
that
checklist
is
for,
and
you
know
what
it's
not
it's,
definitely
not
perfect
yet,
but
I
think
that
at
least
having
it
in
place
will
bring
us
so
place
that
we
can
get
it
a
little
tighter.
Perhaps.
F
A
B
I
think
I'm
in
violent
agreement
like
if
I
had
more
time,
I
would
have
been
vicious
on
that
template.
It
bothers
me
that
there
are
like
over
ten
people
listed
as
reviewers
on
that
and
that
it's
been
hanging
out
for
and
weeks
when
really
what
I
would
have
appreciated
is
if
we
had
gotten
just
the
testing
and
upgrade
downgrade
headings
in
there
and
then
lock
that
in
place,
so
that
the
community
as
a
whole
could
have
just
started
with
that.
It
led
to
mass
confusion,
and
it
concerns
me
that
it
follows
pattern.
B
This
group
sometimes
follows
where
we
try
to
do
the
small
thing
and
then
we
bike
shed
and
it
gets
huge
and
massive,
and
now
we
have
this
big,
overwhelming
wall
of
text
and
I
like
I,
totally
want
the
stupid,
simple
thing
now:
that's
easier
to
automate,
rather
than
the
big
massive
wall
of
text,
so
I'm
really
interested
in
how
we
can
like
okay,
this
one
got
big
and
we're
gonna,
try
and
land
it
somehow.
But
how
can
we
make
sure
that
when
we
move
forward,
we
actually
do
iterate
in
smaller,
discrete
chunks?
B
D
D
So
there
is
a
plan
to
make
sure
that
it's
clear
how
to
move
through
each
of
those
stages
and
that
will
be
included
in
a
follow-up
er.
For
for
that
that
repo,
for
this
template
to
kind
of
lay
the
confusion,
that's
been
happening.
I
would
like
to
maybe
set
a
time
box
on
on
the
comments
and
reviews
so
that
we
can
get
it
merged
in
and
then
we
can
iterate
on
some
of
the
stuff
that
is
is
active.
There.
A
B
Alright
yeah,
so
just
from
a
from
a
vision
perspective
since
I
think
I
got
the
point
across
floor.
You
can't
live
in
at
least
unless
you
have
a
cat.
Like
my
vision,
is
we
swish
all
the
things
into
a
cap?
So
there's
no
design
proposal
anymore,
there's
just
a
cap.
There
is
ideally
not
even
an
enhancement
tracking
issue
anymore.
B
There's
just
a
cap
and
to
Joe's
point
I,
agree:
I,
don't
want
to
have
like
huge
massive
high
friction
process
for
just
doing
things,
so
we
should
make
sure
we
find
a
way
to
communicate
the
appropriate
level
of
fidelity.
But
yes,
one
data
with
many
views
would
be
super
ideal,
I,
just
kind
of
want
to
gradually
smush
everybody
over
to
that
place.
The
feedback
I
need
to
hear
about
this
is
you've
already
switched
everything
over
to
caps,
and
that
has
introduced
some
degree
of
friction.
Is
this
too
much
friction?
Is
there
too
much
noise?
B
Should
we
slow
down
and
work
on
consistency
and
automation,
or
should
we
keep
pushing
right?
I,
don't
know
that
I'm
looking
for
an
answer
now,
although
I
will
definitely
take
feedback,
but
that's
the
general
thing
to
keep
in
mind
because
I'm
right
now,
I'm
trending
towards
just
swish
it
all
into
one
place.
A
D
Sure
so
the
plan
is
to
smush
all
of
the
stuff
and
eventually
like
have
a
different
presentation
mechanism
for
these
like
the
contributor
side.
So
it's
mentioning
on
the
on
the
community
colleges.
Now
what
we
would
like
to
do
as
well
is
if
you're
having
bandwidth,
concerns
around
getting
things
reviewed
or
reviewing
things
yourself.
Please
continue
like
start,
adding
more
reviewers
to
your
sig
specific,
your
specific
subdirectory
in
the
in
the
in
the
caps
folder
great.
A
Thanks
Steven
also
I
want
to
acknowledge
the
work
that
you've
done
here
and
helped
raise
visibility
as
well.
So
again,
thanks
super
appreciated
all
right.
Moving
on
in
the
next
agenda
item
ERD
an
extension
management.
This
is
a
been
a
hot
topic.
I'm
gonna
go
and
hand
the
floor
to
Tim
because
you
are
seem
to
be
the
one
of
the
the
triumvirate
here.
I
don't
see.
F
F
There's
been
a
lot
of
conversations
between
a
group
between
storage
cluster
life
cycle
and
some
API
reviewers
and
I
kind
of
wanted
to
start
framing
the
conversation
first
before
we
start
getting
into
the
logistics
of
what
it
means
to
manage
it
because
I
don't
even
know
the
entire
framing
of
the
debate
right.
So
one
of
the
so,
let's
frame
the
conversation,
what
is
kind
of
happening
is,
we
are
slowly
piecing
apart.
The
API
and
having
CR
d's
were
meant
to
be
an
extension
point
to
the
main
API.
F
But
now,
as
time
has
progressed,
folks
have
seen
it
as
an
option
for
how
to
sort
of
federate
the
actual
core
API
itself
and
one
question:
I
have
and
I
haven't
gotten
a
clean
answer
on
it.
I
think
I'd
like
to
record
it
here
for
posterity,
so
it
helps
to
frame
the
conversation.
Is
that
what
is
the
promise
of
having
core
API
as
C
or
DS?
Or
what
is
what
is
the
end
user
gift?
And
what
are
the
developers
yeah.
A
E
Yeah
I'm
with
the
day
males
have
their
hand
up
there.
I
don't
want
to
you're
at
first
yeah
I.
Think
for
me,
this
is
something
in
a
couple
of
ways.
It
keeps
us
honest
and
it
makes
sure
it's
a
forcing
function
to
make
sure
that
CR
DS
are
first-class
citizens
and
that
we
don't,
you
know,
cheat
for
our
core
api's,
and
so
it
forces
some
of
the
discussions
that
we're
having
now
early
on
with
communities.
E
The
way
that
we
broke
out
the
controller
manager
and
the
scheduler
was
a
forcing
function
to
make
sure
that
we
put
everything
through
our
API
surface
area
and
I
think
that
over
time
that
proved
effective
and
so
I
think
this
is
sort
of
a
in
the
similar
vein
of
keeping
ourselves
honest.
That's
my
take
on
it.
That's.
F
A
developer
centric
view
of
it
right,
so
that's
that's
good.
What
I'm
trying
to
tease
apart
is
who
are
the
personas
and
who
cares
about
this,
because
that
will
affect
the
implementation
details.
So
there's
there's
certain
personas
here,
but
one
thing:
I've,
never
understood
and
in
a
majority
probably
have
comments
here
from
an
end
user
perspective
like
what
is
their
view.
What
do
they
get
out
of
this
Brendan
Byrne,
de-ice
I?
Think.
H
Of
a
couple
of
different
thoughts
here,
I
think
one
thing
to
acknowledge
is
that
for
a
certain
classes,
API
objects.
It
could
very
well
be
that
most
end
users,
don't
get
any
benefit
out
of
this
right.
So
this
is
purely
optimization
for
engineering
and
for
the
way
that
we
develop
things
as
joe
said,
rather
than
an
end
user
benefit.
However,
I
think
that
you
can
look
at
things
like
Darren
Darren's.
What
is
it
case
for
yes
or
whatever,
where
he
went
in
and
in
the
code
stripped
out
a
ton
of
functionality
that
he
didn't
want?
H
You
know,
having
everything
be
linked
in
and
I
think
the
further
you
go
out
into
the
spectrum,
the
more
the
accessibility
becomes
an
end-user
feature
where
I
think
it's
really
good
that
we
could
have
three
different
workflow
implementations
as
committed
as
native
API,
so
I
think
it's
one
of
these
situations,
where
the
benefit
in
the
core
is
for
developers,
kubernetes
and
the
benefits
in
the
periphery
are
for
users
of
humanities
and
and
I.
Don't
know
that
we
have
to
ensure
that
the
balance
is
the
same
in
the
core
as
it
more
appropriate.
So
I'd.
F
Like
to
extrapolate
on
this,
because
I
want
to
really
frame
the
conversation,
what
are
the
core
benefits
to
the
developer
community
liked
it
liked
it?
Let's
be
concrete:
what
are
what
are
the
key
things
that
the
developer
gains
for
making
the
corn
api's?
Not
not
just
the
core
API
stuff,
you
see,
Ernie's
a.
I
Bigger
part:
sorry,
yes,
sir,
as
a
newcomer
to
the
community,
I
can
tell
you
that
the
benefit
for
people
like
me
is
that
made
the
overall
architecture.
Predictable.
I
know
what
I
want
to
find,
because
the
batter
who
bids
and
that's
something
I
appreciate
it's
like
make
because
now
is
huge,
I
mean
so
huge
that
it
every
component
has
a
different
way
to
do
stuff,
and
you
know,
if
you,
you
can
know
easily
move
from
one
area
to
another.
But
now
is
a
reason.
We've
proposed
a
new
API
on
these
ideas.
I
I
have
already
an
idea
how
it
will
more
or
less
work.
So
for
me,
he
saying
be
saving
a
lot
of
time.
Just
understand
the
overall
concept
sometime.
Is
it
hard
to
put
in
the
protector?
This
is
where
I
really
appreciate
about
any
architecture.
Is
that
makes
me
understand
quickly
was
the
way
of
thinking
on
this
is
my
like.
You
know,
overall
theme
or
Mesa
benefit
difference
or
if.
I
I
mean
you:
could
you
can
easily
move
over
one
area
to
another?
Now
they
so
face
was
the
architecture
is
Toby,
and
it's
always
so
fast
that
that
would
basically
is
the
only
way
to
allow
developers
to
move
to
one
Egerton
dollar
is
I,
say
I
know
the
I
was
working
for
for
now,
and
my
focus
now
is
crossing
API,
but
I
also
dress
in
the
part
of
the
volume
management.
If
everything
is
on
the
same
I
can
quickly
move
there.
I
I
know
what
I
want
to
find
everything
will
look
like
familiar
and
mostly,
if
based
on
that,
I
expect
that
some
of
the
implementation
partner
will
repeat
so
I
will
use
my
skills
if
I
implement
a
controller
in
this
area.
I
can
use
the
same
scheme
to
come
in
and
order
put
on
another
area,
because
you
know
I
think
this
is
huge
advantage.
I
mean
really
great.
A
Thanks
for
that
perspective,
Pablo
hand,
the
Florida
Brendan
burns
and
then
over
there
Dems
next,
please
today.
H
After
Tim's
question,
I
think
that
there
are
two
benefits
to
developers,
so
I
won't
be
clear,
like
I.
Don't
think
that
we
should
break
out
existing
core
API
right
if
it's
already
in
there
I,
don't
see
a
lot
of
value
and
breaking
out
all
right.
So
I
don't
know
if
that
was
under
consideration
but,
like
that
doesn't
seem
like
there's
a
ton
of
gain,
but
for
new
API.
Is
that
our
core?
H
J
Dims,
okay,
so
right
now
see
are
these
are
second-class
citizens
right
just
because
the
people
who
are
on
this
call
don't
really
do
er
these
on
a
day
to
day
basis
what
you
are
forcing
other
people
go.
Do
it
now,
once
we
switch
over
and
say
that
any
new
stuff
has
to
be
CR,
DS
and
maybe
we'll
consider
existing
stuff?
J
Also
as
theories,
we
are
forcing
ourselves
to
fix
a
bunch
of
issues
that
other
people
are
seeing
and
we
are
it's
not
anything
else
and
the
first
thing
that
it
does
was
the
CSI
one,
for
example-
and
you
know
what
happened
in
the
previous
meeting
where
he
said:
okay,
fine,
let's
get
some
of
this
yes
CSI
stuff
into
a
domain.
Kk
repository,
that's
what
we
had
enough.
So
that's!
G
Thick
stems
from
Jordan
I
agree
on
benefits
of
fast
prototyping
anytime.
You
have
something
that
the
built-in
components
are
depending
on
I.
Don't
think
you
actually
gain
velocity
improvements
with
CRTs,
because
you
can't
ship
changes
to
the
cubelet
and
how
it
consumes
an
API,
whether
it's
here
at
eBay
store
not
faster
than
the
kubernetes
release.
Cadence.
C
So
I
think
it
really
actually
plays
nicely
into
SIG's
doing
quick
prototyping
to
build
on
what
Brendan
said
a
Sager
more
than
once
a
could
do
something
in
kubernetes,
SIG's
iterate
on
it
prototype
it
work
it
out,
hash
it
out.
Maybe
even
over
some
releases
people
could
start
running
this
in
different
places
in
production
and
then,
when
you
want
to
bring
it
into
core,
the
workflow
works
really
nicely
to
just
bring
it
right
into
core
ship
it
as
default,
and
maybe
even
different
distributions
would
do
that
as
well
right.
C
The
workflow
seems
really
nice
when
you
want
to
create
something
new
and
experiment
with
it,
without
sticking
into
the
corn
having
to
deal
with
release
cycles,
and
things
like
that,
you
can
just
play
with
it
where
it
needs
to
be,
and
people
can
hash
it
out
and
try
it
and
iterate.
That
seems
like
a
nice
flow,
and
then
it
fits
real
nice
in
the
core.
So
I
kind
of
like
this
workflow,
alright.
A
So
I'm
sorry
I'm
doing
a
lousy
job
moderating
here.
There's
a
lot
of
people
competing
for
the
mic,
so
I
Tim's
leading
the
section
he
asked
for
us
to
move
on
in
time
box
soon.
So
let's
try
and
go
through
this
as
best
we
can
Brendan.
Let's
cut
the
comments
after
you,
but
in
the
meantime
we'll
do
Justin
can
Brendan
Saudi
Earth
Justin
can
Brendan
this
Olly
that
make
sense.
I!
Think.
J
H
A
K
I
think
one
of
the
things
that
series
potentially
enable
is
decoupling,
rolling
out
a
new
schema
or
a
new
version
from
rolling
out
the
binary
that
that
writes
it
or
reads
it
and
I
think
that's
one
of
the
things
that
can
enable
smoother
upgrades
and
possibly
even
downgrades
than
we
have
had
to
date.
So
I
think
that
that
is
definitely
a
huge
advantage.
If
we
can
figure
out
that
workflow
yeah
I
think
that.
H
Brendan
I
was
just
in
response
to
what
I
think
Jordan
said
about
the
cubelet,
which
is
I,
don't
actually
know
that's
true.
Now
that
we've
broken
out
CRI
and
CSI
as
separate
things,
you
can
always
land
a
separate
CRI.
That
has
you
know
the
capabilities
you
need
and
passing
through.
The
cubelet
via
annotations
are
like
that.
It's
a
very
narrow
point
and
they're
shut
up
down
because
you've.
G
F
So
if
I
were
to
summarize
I
want
to
keep
moving
here
if
I
were
to
summarize,
the
whole
like
in
summary,
is
consistency
dogfooding,
what
we're
doing,
as
well
as
being
able
to
rapidly
prototype
to
move
things
out
faster
into
the
wild
and
I
have
potentially
different
ways
of
managing
the
API
overtime
or
AP
is
right.
So
that's
that's
good
feedback
I
wanted
to
frame
the
conversation.
Is
that
because
that's
the
first
part
from
me
developer
is
very
developer.
F
Centric,
it's
very
developer
focused,
but
I
also
want
to
put
on
my
consumer
hat,
because,
as
a
cluster
lifecycle,
co-chair
I
get
the
end
user
feedback
of
what
happens
when
developers
move
fast,
but
don't
necessarily
always
put
the
end
users
frame
of
reference
in
mind.
So
as
we
go
through
some
of
these
options
that
people
have
iterate
in
the
document,
I
want
to
make
sure
that
people
are
well
abreast
and
aware
that
consumers
just
want
it
to
work,
and
they
don't
want
to
manage
this
and
putting
any
type
of
management
in
their
court.
F
I
think
would
be
detrimental.
So
the
automation
and
the
lifecycle
and
the
management
of
this
needs
to
be
clean
and
well
thought-out
through
before
we
actually
push
this
on
the
end,
consumer
I
got
to
probably
switch
over
now
to
the
options
that
are
listing.
The
doctor
folks
have
a
link
to
the
doctor.
You.
A
D
So
I
just
a
basic
idea
about
the
the
pounding
and
pounding
away
at
the
caps
again
I.
Don't
think
I,
don't
think
it's
bad
or
wrong
to
lay
this
down
and
I
kept
first,
even
if
they
kept
this
provisional,
like
we
have
additional
statuses
and
we
kept
like
deferred
or
rejected
to
actually
at
least
capture
the
motivation
and
goals
of
the
idea.
And
if
it's
not
a
bit,
it's
not
a
good
idea.
Then
then
fine
toss
it,
but
at
least
we've
captured
that
feedback
and
it
serves
the
community
and
future.
F
F
A
M
F
A
A
K
F
I
think
one
of
the
things
that
we
were
harping
on
as
part
of
the
conversation
was
that
we
should
really
articulate
in
a
cat
form
what
the
promise
and
ideas
B
are
behind
this
migration
of
core
API
CCR
DS,
and
with
that
in
mind,
and
someone
said
Brendan
offered
to
write
up
the
scaredy
philosophy
that
could
be
awesome
or
that
mindless,
we
can
probably
move
to
the
all
options
that
we
kind
of
enumerated
and
again
I
want
to
reiterate
the
end-user
perspective
from
my
and
Justin.
You
were
involved
in
this
too,
along
with
Tim.
G
F
A
F
So
he,
unlike
some
of
the
non
goals
of
above
in
the
goals
and
I,
recommend
reading
that,
but
I
think
the
purpose
of
discussing
it
here
in
this
group
is
to
talk
about
the
logistics
of
the
different
options
that
exist
so
one.
The
first
option
here
is
like
to
add
a
new
coupe
schema
loader
component,
creating
a
binary
as
part
of
the
kubernetes
release
expected
to
run
in
the
control.
Plane,
though,
is
alongside
the
controller
manager
API
server
in
the
cluster.
F
K
F
A
F
They
need
help
to
just
outline
the
four
options
so
sure
this
one
is
to
add
a
schema,
loader
controller
to
the
controller
manager.
This
would
be
entry
I
particularly
kind
of
like
this
one,
because
I
think
the
main
tynin
s--
you
know
I
attained
into
it,
because
the
maintenance
is
then
in
core,
because
I'm
concerned
that
if
you
have
core
P
api's
as
CR
DS
in
a
federated
fashion,
management
of
that
it
consistent
consistent
management,
I
could
couldn't
become
fragmented.
F
The
next
one
is
making
the
API
server
load
a
directory
animal.
This
would
basically
be
the
CRT
definitions.
I
wasn't
I,
wasn't
against
her
for
this
one
I
know
I.
Think
Daniel
actually
had
comments
on
the
last
one.
The
last
one
is
defined
a
bundle
and
make
each
installer
handle
it,
which
is
the
addons
philosophy,
so
it's
basically
building
it
into
the
system
in
some
way,
shape
or
form
having
it
as
a
versioned
component
outside
of
it.
That's
a
managed.
E
Yeah
I
just
want
to
say
that,
like
with
number
three
and
and
I'm
not
sure
how
this
works
with
a
che,
but
it
feels
a
little
bit
analogous
to
static
static.
Pod
manifests
right
where
it's
like
there's
a
directory,
this
stuff
sort
of
gets
integrated,
but
the
source
of
truth
is
no
longer
at
CD.
The
source
of
truth
is
actually
local
I'm,
just
like
I'm
I'm,
not
sure.
If
that's
good
or
bad
I,
just
like
there
seems
to
be
a
parallel
there.
I.
A
Look
at
local,
just
sort
of
punching
machines
and
sticks
it
you
have
to
figure
out
how
to
update
that
state
on
those
machines
and
it's
impossible
to
synchronize
it
across
AJ,
with
all
the
existing
upgrade
tools
that
are
out
there
or
with
any
of
them
rather
I
mean
none
of
them.
Actually
do
that
that
I'm
aware
in
the
way
that
you
want
so.
E
J
A
With
number
two,
the
schema
loader
controller
I,
actually
sort
of
proposed
something
similar
in
the
architectural
roadmap,
doc
in
April,
2017,
and
basically
predicting
that
you
would
have
this
issue
eventually,
even
if
we
wanted
to
do
things
like
extract
the
Cloud
Controller
manager,
we
ran
into
this
issue
when
we
extracted
the
scheduler.
How
do
we
make
are
sexually
visible
changes
to
the
system
to
not
break
every
blog,
post
and
installation
to
everything
the
universe
as
we
built
the
extension
mechanisms
I
think
had
a
lot
more
insight
into
it
now
than
we
did
then.
A
But
it's
clear
that
it's
just
loading
the
schema
is
not
sufficient.
You
also
need
web
hooks
need
something
to
receipt
the
web
hooks.
You
need
a
controller,
you
need
our
back
rules.
The
naming
namespaces
like
the
number
of
different
kinds
of
things
you
need,
starts
to
really
look
like
arbitrary
add-ons,
so
I
think
we
need
to
think
that
context
into
account
with
whichever
option
we
choose
correctly.
G
So
this
is
basically
like
a
glorified
queue,
control
apply
or
if
we
are
wanting
this
thing
to
do
more,
intelligent
things
like
queue,
control,
auth
reconcile
like
additively
ads
in
permissions,
but
it
doesn't
remove
any
permissions
like
some.
You
can
envision
something
similar
for
like
looking
at
a
custom
resource
definition
and
saying
well,
I'm
only
going
to
roll
this
forward.
F
N
I
think
none
of
these
options
are
very
good.
Honestly,
III
I
think
the
fundamental
problem
we
have
is
that
there's
no
trigger
at
the
appropriate
time,
there's
no
trigger
in
the
entire
system
at
the
appropriate
time
to
change
the
the
schema
definition
right.
Api
server
does
not
compute
a
time
when,
like
all
the
API
servers,
have
joined
to
a
new
version
and
it's
appropriate
to
change
the
CR
DS,
the
atom
manager
doesn't
take
a
lock.
The
I
mean
yes,
it
could,
but
it
doesn't
actually
same.
L
N
My
my
point
is
like
the
the
problem.
Everyone
said
the
a
manager
has,
like
all
the
components
had
that
problem.
Yes,
it's
not
it's
not
a
problem
with
the
atom
manager.
It's
a
problem.
We
don't
generate
an
event
anywhere
when,
like
we've
latched
at
a
new
version
right
and
we
have
that
problem,
whether
we
build
it
into
API
server
or
controller
manager
or
a
tower
manager
or
some
hypothetical
schema,
a
loader
slash
web
hook
manager
like
we
still
have
that
problem.
This.
F
N
F
I
don't
know
if
we
can
actually
answer
some
of
the
core
questions.
I
know
that
we
wanted
to
answer
that,
but
this
proposal
together
in
haste
because
it
was
almost
like
we
wanted
to
choose
one
but
I-
felt
super
uncomfortable
along
the
way,
because
I
felt
like
we
were
trying
to
cook
something
with
twice
the
heat
and
half
the
time
that
doesn't
work
so
up.
F
Does
it
sound
reasonable
to
folks
to
have
to
set
up
a
separate
I?
Don't
know
if
it's
gonna
be
working
up
underneath
a
beer
machinery
in
cluster
lifecycle,
Co
minutes
or
something
to
try
and
come
up
with
proposals
for
how
they
want
to
deal
with
this,
so
that
we
can
actually
get
this
attraction
on
this?
That
doesn't
isn't
seem
so
scary.
It
actually
seems
like
it
has
a
life
of
its
own
I.
A
Think
it'd
be
good
to
do
a
kind
of
a
birds
of
a
feather
as
opposed
to
forming
a
working
group,
because
there's
not
really
a
specific
solution.
It's
more
advising
a
cig
architecture
and
other
groups
on
how
to
proceed,
or
at
least
the
pros
and
cons
and
and
I,
don't
think
we
need
the
heavyweight
governance
around
a
working
group
necessarily
I.
A
K
N
M
N
Yeah
yeah
I
mean,
if
you
want
to
be
super
technical
everything
we
do
during
installation
is
optional.
It's
not
a
sin
to
the
operator
to
figure
out
some
replacement
if
they
don't
want
to
run
the
thing
that
we
provide,
but
every
time
I've
wanted
to
add
something
like
say:
the
aggregator
we've
ended
up
finding
that
the
path
of
least
resistance.
This
is
to
build
it
into
something
that
people
are
already
doing,
rather
than
make
people
at
a
step
to
their
process.
K
G
To
I
think
it's
really
good
to
actually
prove
it
out
to
an
actual
deployment
tool,
but
just
recognizing
that
stuff
that's
done
in
QA
DM,
it
doesn't
mean
we
did
in
queue
medium,
and
now
the
world
has
adjusted
it.
That
represents
work
that
has
to
be
done
by
everyone
who
has
written
a
deployment.
So
just
recognizing
that
and
understanding
it
doesn't
stop
with
do
we'd
love
to
get
you
involved
in
cube
ADM.
G
F
F
A
F
N
I
I
think
we
should
probably
loop
in
some
of
the
people
actually
working
on
Ceres
to
like
at
least
make
them
aware
of
it.
So
a
pretty
volunteering
someone
I
probably
have
to
like,
maybe
even
either
ready
or
Stefan
I,
don't
know
if
she's
interested.
That's
part
of
the
reason.
Okay,
if
you
can
loop
in
the
right
people
and
yeah
I
have
too
many
things
going
on
so.
A
Yeah
so
I
would
say,
if
you're,
if
you're
really
truly
looking
to
get
a
community
of
interest
around
this,
as
opposed
to
the
voices
that
are
currently
here
just
and
invite
the
mailing
list
for
the
cigs
that
you
think
are
specifically
interested
and
see
if
people
show
up.
Of
course,
this
is
an
effort
that
favors
work
over
talks,
so
they
mean
we
need
to
have
some
sort
of
document.
At
the
end
of
this,
the
advices,
this
group.
I
The
cat-
oh,
oh,
oh
dad,
did
you
work
in
there
who
was
interested
me
I
would
like
the
rest,
because
in
sousei
we
are
moving
from
considering
a
heavy
users
of
operators,
so
we
need
to
figure
out
how
to
man.
One
of
the
question
we
have
like
you
do
once
we
work
great
to
this
night,
but
you
are
the
boy
like
tenth
of
them
and
then
you
have
to
do
some.
You
know
upgrades
or
whatever,
so
we
are
really
interested
in
understanding.
How
is
the
life
cycle
of
this
stuff
so.
L
A
Well,
we
just
punted
on
the
CSI
here
these
because
we
decided
series
we're
not
ready
so
they're
gonna.
Not
you
see
are
these.
The
next
thing
up
is
runtime
class,
probably
maybe
so
we
need
to
figure
out
whether
they
can
be
ready
in
a
timeline
that
is
satisfactory
for
front-end
class
I.
Think
that's
where
we
need
to
look
at
so
we
don't
end
up
blocking
an
unbounded
number
of
other
efforts
on
the
project
or
pushing
this
problem
on
to.
A
L
And
quick
just
comment:
I
think
we
should
also
come
up
with
what
our
criteria
for
readiness
is.
First,
because
it's
not
clear
to
me
that
anyone's
actually
said
this
is
what
I
think
Sierra
DS
will
be
actually
dumb
enough
to
do
any
of
the
things
we're
talking
about
right
now,
I
think
version
upgrade
is
alpha
right.
So
if
I
install
it
once
there
is
no
non-helpful
way
for
me
to
upgrade
to
a
new
version
opportunity.
L
G
L
N
N
A
G
A
Only
five
minutes
left
so
just
to
reiterate,
the
action
I'm
here
is
to
get
the
birds
of
a
feather
group
together,
come
up
with
some
sort
of
recommendations,
with
the
criteria
mentioned
here
and
hopefully
be
able
to
act
on
it
in
our
last
four
minutes.
Is
there
anything?
Does
anybody
need
to
get
the
last
word
on
anything
who
hasn't
spoken
yet.
G
Okay,
Tim,
you
enough
look.
What
does
this
mean
for
the
things
they're
currently
in
flight
I?
Think
ones
that
don't
depend
on
any
active
components
that
can
be
purely
declarative
and
are
not
required
as
in
if
they're
not
present,
it
doesn't
stop
a
cluster
from
coming
up.
Only
people
who
want
to
want
to
use
those
features
we
need
to
worry
about
getting
these
set
up
in
their
clusters.
I
I
think
the
path
it's
clearer
for
those
just
because
of
their
simplicity
and
the
fact
that
that
are
optional.
G
The
question
about
conversion
is
significant
and
I
would
hesitate
to
gonna
release
a
beta
level
C
or
D
and
say
we
now
support
this
when
we
don't
actually
have
a
clear
picture
about
conversion
and
so,
depending
on
how
complex
the
object
is
and
how
confident
we
are
in
the
current
schema
that
could
influence
whether
we're
willing
to
promote
it.
I
would
say.
A
All
right,
without
any
further
hand,
raises
we're
gonna
go
ahead
and
call
it
thanks
everyone
for
attending
and
definitely
looking
forward
to
seeing
a
week
and
if
anything
comes
up
in
the
meantime,
please
leverage
the
the
mailing
list
for
things.