►
From YouTube: Kubernetes SIG Apps 20170710
Description
Kubernetes 1.7 retro for sig apps and planning for Kubernetes 1.8
A
Hey
everyone
welcome
to
sig
apps
today
is
Rachel
ice-cream
and
we're
going
to
doing
a
nutshell
and
commanding
news
meeting
Jase.
Thank
you
as
always
for
leading
our
live
show
sessions.
If
you
look
in
the
truck
filming
we
retrospective
document,
please
click
on
that
click
on
that
and
start
filling
it
out
if
you're,
not
on
mute
and
if
you're,
not
if
you're,
not
on
using,
not
talking
put
yourself
on
you
the
right
way
to
say
that
put
yourself
on
you
if
you're
not
clicking,
thank
you
and,
with
that
all
hand,
great
thank
you.
B
So
yeah
I
want
to
thank
you
all
for
having
me
here
to
help
facilitate
I
believe
a
really
important
ceremony
in
terms
of
our
commitment
to
continuous
improvement,
which
is
our
look
back
at
the
release
cycle
and
the
things
that
we
felt
good
about
and
the
things
that
maybe
we
wished.
We
could
have
changed
and
we
can
change
moving
forward.
B
So
it
looks
like
hell,
released,
2.30,
2.40,
dough
and
2.5
dotto
lots
of
it
focus
on
accessibility
with
plugin
management,
enabling
chart
developers,
support
for
communities
1.6
and
bug
fixes.
That
is
a
huge,
huge
thing
to
have
such
a
great
release.
Cadence
alongside
the
regular
communities,
release
and
I
believe
that
this
is
going
to
be
something
that's
going
to
say
it's
an
important
example,
as
as
more
and
more
sections
of
the
communities
code
get
broken
out
into
their
own
sections,
so
keep
up
the
great
work
and
being
a
great
role
model
for
other
other
projects.
B
Draft
was
announced,
super
exciting
and
certainly
helping
with
enterprise
adoption,
as
developers
find
a
quick
way
to
deploy
their
applications.
They
may
not
have
necessarily
been
container
ready.
I
moved
monocular
to
github.com,
slash
communities,
I.
Anybody
else
want
to
step
in
and
offer
some
thank-yous
appreciation
or
things
that
they
felt
good
about
this
release
cycle
and
I'm
going
to
meet.
While
you
do
that.
A
You
know:
I
I
definitely
noticed
that
whenever
there
was
an
announcement
about
like
a
flaky
test
or
something
going
on
in
the
indica
Briones
core
world
I
would
just
kind
of
ask
to
see,
like
you
know,
what's
going
on
with
that,
and
someone
always
had
it
under
control
and
was
or
maybe
it
had
already
been
fixed
and
a
lot
of
times.
It
was
Janet.
So
thanks,
Janet
and
and
the
rest
of
the
team.
B
Certainly
I
want
to
thank
the
sig
organizers,
because
this
is
a
really
big
cig
and
a
lot
of
things
happening
here.
I
attend
more
SIG's
and
most
people
and
I
can
tell
you
that
this
is
one
of
the
most
exciting
SIG's
as
far
as
things
that
are
happening,
so
I
think
you
guys
do
a
fantastic
job
with
a
very
difficult
job.
So
that's
my
my
personal
shout
out
to
you
guys.
B
Okay,
well
moving
along
I
think
this
the
retro
is
looking
into
things
that
perhaps
could
have
gone
better.
So
what
I'd
like
to
do
is
right
now
there
are
no
bullet
points
in
there.
I
am
going
to
open
the
floor
and
I
will
try
and
write
the
concerns
down
as
we
go
through
them,
but
feel
free
also
to
add
your
own
in
the
bullet
point.
If
you
have
something
you'd
like
to
just
speak
up
about
so
I.
A
It
did
feel
I
did
feel
a
little
bit
better
than
the
1.6
cycle
a
little
smoother.
It
seems
like
we
had
kind
of
a
grasp
on
who
was
working
on
Wyatt.
From
my
perspective,
there
was
a
lot
more
communication
than
before
and
I
mean
as
far
as
helmand
Roscoe.
We
didn't
have
any
major
issues.
I
just
think
that
we
had
a
lot
of.
We
have
a
lot
of
contributors
and
so
we're
just
definitely
trying
to
keep
on
top
of
pull
requests
and
helping
new
contributors
may
think.
A
There's
some
some
comments
in
the
chat,
not
so
sure,
saying.
I
honestly
cannot
think
of
anything
that
went
wrong
with
1.7.
From
my
perspective,
GPRS
too
Ciardi
migration
was
interesting,
but
that's
when
a
result,
reflection
of
the
release
itself,
I
really
like
to
hear
from
the
Cabrera
team,
Kim,
you're,
muted,
I,
think
you're,
saying
something
I'm,
not
sure
or
Janet.
Do
you
have
anything
to
add
dan
from
your
perspective,
Eric
tune?
You
always
have
a
fun
perspective.
So
if
any
of
y'all
have
anything
to
add
love
to
hear
what
you
have
to
say,.
C
I
guess
what
can
work
some
that
out,
I'll
give
one
quick
comment
which
was
like
I
thought:
the
actual
release
stuff
was
pretty
cool
the
stuff
that
likes
a
full
sets
and
David
says
brought
up.
It
wasn't
as
clear
to
me
what
would
be
ready
until
probably
that
last
like
two
weeks
or
so
so
what
a
bit
better.
C
Maybe
if
we
had
a
little
bit
more
earlier
communication
on
some
of
that
stuff-
and
that's
probably
my
fault
I-
need
to
reach
out
a
little
bit
more
to
try
to
get
more
clarity
on
that,
because
I
think
some
of
the
earlier
meetings
were
getting
some
statuses
but
like
I,
wasn't
exactly
sure
what
what
what
exactly
we're
getting
and
then
on
the
T,
P
or
C
or
D
migration
I.
Think,
like
I
mean
that
was
I
guess
it
was
interesting.
I
think
it
was
mostly
like
we
were
mostly
in
a
supportive
role
on
that
I.
C
Think
a
lot
of
that
work
was
handled
by
the
game
time,
machine
group
or
one
of
the
other
things
I
think,
but
so
I
knew
it
was
there,
but
I
don't
know
how
much
active
work
we
were
doing
there,
but
I
wish
I
wasn't
as
aware
of
like
the
work
beyond
more
some
of
the
support
of
stuff.
We
were
doing
on
that.
B
B
D
Are
we
generally
in
the
future
going
to
plan
to
align
helm,
which
is
a
reasonable
course
of
action?
In
my
opinion,
these
to
align
with
the
previous
release
of
kubernetes,
are
we
going
to
try
to
align
it
to
be
able
to
consume
the
features
that
come
out
with
the
current
like
1.7
and
going
forward
1.8
release.
A
Yes,
so
for
every
kubernetes
release,
usually
the
person
who
goes
in
and
kind
of
tests,
the
new
version
out
with
home
and
adds
support
for
the
new
versions
so
generally
there's
a
Cabrini's
release
and
then,
very
shortly
after
there's
a
home
release
with,
like
you
know,
terrains
1.6
support
or
it's
wearing
2007
support
and
there's
we
want
to
maintain
backwards.
Compatibility
as
well,
so
Adam
generally
works
on
that
and
he
has
a
pull
request
out
for
coverage.
1.7
support
right
now:
okay,.
E
And
to
clarify
that
communities
1.7
support,
that's
just
the
client
library
support.
That's
not
necessarily
the
stuff
like
what
you
were
talking
about,
Ken
about
the
round
tripping
stuff
for
staple
sets
and
I
think
there
was
also
a
couple
of
new
resources
that
were
added
to
kubernetes.
That
helm
does
not
understand
yet
for
its
install
order
and
those
are
also
being
added
by
the
community
as
well.
E
So
that
has
like
the
changes
that
occur
in
a
new
release
having
or
do
not
be
temper
have
not
been
tested
so
much
it's
just
more
like
we
bumped
the
client
version
at
this
point,
I,
don't
know
any
actual
in
terms
of
what
we've
been
doing
currently
for
that
I
know,
we
had
that
problem
in
previous
kubernetes
releases,
where,
like
helm,
will
be
targeting
the
previous
versions.
Releasing
people
like
well,
we
came
out
with
helm
or
mean
kubernetes
one
point
wise
and
helm
the
latest
version
of
helm.
E
F
B
To
look
at
maybe
more
of
the
feature
alignment.
So
if
you
know
the
the
kubernetes
AI
controller
becomes
a
real
thing
in
1.9,
you
know
we
we
make
sure
home
can
can
talk
to
it
or
what?
What
kind
of
alignment
do
we
want
to
do
from
the
feature
world
about
perspectives?
Should
we
focus
on
current
level
features
and
not
worry
about
head
and
just
focus
on
the
client,
or
should
there
be
some
forward-looking
work
in
terms
of
leveraging
new
alpha
and
beta
api's.
B
A
A
G
Sure
I
can
talk
a
little
about
that
I,
think
registry.
What
we
really
need
to
do
is
have
more
Ricci
roadmap
and,
more
just
like
publicly
understandable
room.
We've
done
a
lot
of
stuff
in
stand-up
and
spoken
out
loud
and
kept
these
meetings,
but
they
get
written
down
in
the
gaps,
notes
which
isn't
super
intuitive.
C
G
A
B
B
B
A
Like
there
could
be
more
I
feel
like
stand-ups
are
becoming
more
consistent,
but
there
is
at
least
some
say
gaps,
but
there
are
some
projects
that
kind
of
haven't
shown
up
regularly.
So
I'm
just
kind
of
wondering
you
know:
do
we
need
to
revisit
each
project
and
kind
of
assess
whether
you
know
they
need
to
gap,
support
or
not
anymore,
because
that
list
is
really
long.
So
it's
you
know
there.
There
isn't
any
help.
That's
needed
like,
for
example,
like
open,
compose
and
compose,
are
two
examples,
some
to
call
them
out.
It's
not
a
problem.
A
B
Well
think
about
the
gaps,
just
generally
speaking
as
you
have
all
these,
it's
like
an
umbrella
right.
You
basically
like
a
cig
with
dozens
of
working
groups
underneath
of
it.
That
is
a
model
that's
going
to
become
more
frequent,
especially
when
you
look
at
things
like
Sig
cloud,
with
all
the
working
groups
for
doing
all
the
cloud
providers
under
it.
I
would
love
to
see
this.
This
group
specifically
because
you're
so
far
had
a
curve
on
that
decide.
What
is
what
is
a
good
model
for
a
scrum
of
scrums
or
is
it
you
know?
I
To
just
throw
Anna
thanks,
she's,
probably
not
on
the
call
and
doesn't
hang
out,
see
apps,
but
Don
Chen
had
a
really
tough
job
and
did
a
great
job
and
I
think
one
of
the
reasons
1-7
was
smooth
was
Don
was,
on
top
of
it
had
to
make
some
hard
decisions
about
what
when
could
then
go
and
release
and
fix
a
lot
of
tests.
So
if
you
see
Don
Chan
arounds,
just
thank
her
for
a
good
one.
Seven.
B
Yeah
I,
what's
102
that
she's
really
raised
the
bar
I,
you
know
for
future
the
lease
lease
cool
all
right.
Well,
so,
let's
go
to
the
last
section
of
the
retro,
which
is
what
are
we
concretely
going
to
do
differently
for
1.8
and
beyond,
looks
like
Michelle
you've
got
something
here
will
not
speak
to
that.
Sir.
A
Yeah
I
I
think
what
I've
noticed
is
the
charts
team
continually
having
some
of
the
same
issues
and,
unfortunately,
I.
Don't
think
that
anybody
from
the
church
team
is
here
today
not
just
because
of
vacation
and
other
things
so
something
I've
seen
is
they
have
a
lot
of
coal
requests?
Now
you've
been
adding
new
maintainer
x'
there's.
A
Definitely
some
some
scalability
issues
like
they're
running
into
they
have
all
these
efforts
to
increase
and
make
their
process
more
efficient
people
are
asking
to
be
reviewers.
So
there's
like
an
onboarding
kind
of
transitions.
Authors
are
figuring
out
and
getting
more
comfortable
with
right.
Now,
there's
also
a
lot
of
questions
not
related
to
actual
charts
repo
admin
things,
but
you
know
how
do
you
develop
charts
to
make
that
more
efficient?
How
do
you,
how
do
you
discover,
charts
like
say,
you're
hosting
your
own
sharps
repository?
How
do
you
make
your
charts
more
discoverable?
A
I
A
I
completely
agree,
I
think
we
had
something
in
mind
when
we
started,
but
this
city
is
focused
on
Korea,
the
feedback
loop
between
the
project
developers
and
admins
and
the
actual
users
and
the
end
users,
and
so
I
think
that's
what
we
need
to
focus
on
and
go
back
and
revisit.
Those
questions
that
you
were
saya
mentioned
all
right.
Yeah.
J
And
this
is
Matt
and
it
may
be
worth
even
going
out
and
pulling
the
community
here
too.
I
mean
that's
something
we've
done
in
the
past
is
surveys
because
there
may
be
different
levels.
Some
different
expectation,
we're
not
aware
of
doing
it
here
is
great,
but
this
may
be
a
good
time
to
do
some
form
of
survey.
Yeah.
I
It
has
to
be
good,
if
maybe
someone
could
just
summarize
like
what
the
helm
tool
does
to
like.
Does
it
prefer
a
certain
result
like
how
fluid
is
it
in
terms
of
what
you
pick,
how
many
other
competing
repos
to
charge
like
I?
Don't
know
that
but
like?
Where
are
we
on
the
like
charts
of
the
one
true
place
versus
anyone
can
turn
up
a
repo
and
how
easy
is
it
like
I
think
I
have
ideas
about
that
I,
but
I'd
love
to
hear
from
someone
who's
more
day-to-day
active
on
on
that
question?
A
A
A
D
One
thing
that
is
currently
white
right
now
is
revisiting
how
we
keep
the
charts
repose,
particularly
incubator,
in
github
and
ways
to
go
forward.
So
we
conversion
different
versions
of
charts
to
work
against
different
versions
of
kubernetes
and
make
it
easier
to
deprecate,
charts
that
are
in
flight
I
know
a
nerds
been
working
on
that
and
I
think
Vic's
been
involved
in
that
I've
been
involved
a
little
bit,
I
think
all
the
chart
19
are
aware
of
it,
so
any
may
be
based
on
the
outcome
of
that.
I
I
think
that
relates
to
the
curation
question,
which
is
like
you
can
put
works
with
label
on.
You
know
Kerberos
version
labeled
on
a
bunch
of
charts.
Is
it?
Is
a
label
accurate
or
did
someone's
like
copying
it
for
the
next
version
without
thinking
about
it?
So,
like
there's
a
question
I
shouldn't,
how
should
we
like
to
tell
people
what
works
about
version
but
like
how
accurate
is
that
information
and
like
it's
actually
a
lot
of
work
to
make
sure
everything
works
with
every
version
with
every
possible
set
it
like?
I
H
This
is
Jago
also
from
Google.
One
thing
that
came
up
in
the
community
meeting
was
the
need
to
start
on
release,
notes
earlier
in
the
cycle
and
improve
on
that
process,
so
just
want
to
get
it
on
the
general
roadmap
and
fig
apps
as
well
thinking
through
that.
What
one
of
the
proposals
was
that
every
pull
request
should
have
an
issue
associated
with
it
to
more
easily
auto-generate
the
release,
notes,
but
I
think
there's
also
a
higher
level
sort
of
aggregation
of
the
height
of
the
features.
A
C
Usually
I
think
usually
we
do
and
I
think
what
we
want
to
do.
This
time
is
right.
The
1.8
release,
notes
earlier
and
and
I
think
the
main
point
was
get
that
done
earlier.
So
we
have
a
rough
idea
was
coming
and
we'll
change
it
and
iterate
upon
it
over
over
the
release
time,
but
rather
than
work
on
it
the
last
week
or
the
last
few
days,
we'll
just
do
it
earlier
than
that
and
yeah
I,
usually
supply
line
is
apply.
The
input
for
that
for
sig
apps
I
mean
actually.
C
D
Happened
was
at
the
end
of
1.7.
Basically,
we
had
this
document
of
unorganized
release,
notes
and
a
lot
of
the
PRS
associated
with
them,
weren't,
particularly
clear.
So
a
couple
of
us
had
to
go
through
for
all
the
release,
all
the
features
and
bugs
and
so
forth,
and
see
gaps
prior
to
the
PM's
ironing
in
those
notes
go
through
categorize,
each
one
as
belonging
to
sig
at
signal
support
and
so
on,
and
then
clean
the
release.
D
Note
up,
so
it
actually
be
meaningful
to
a
user
I
think
we
could
probably
start
doing
that
sooner
or
just
making
sure
that
we
people
attach
a
note
like
when
reviewers
like
when
you
look
at
a
PR.
Look
at
the
release
note
and
ask
yourself:
is
this
meaningful
to
a
user?
Was
this
release
Note
written
correctly
to
make
it
easier
for
them?
Then?
The
other
problem
we
ran
into
is.
We
were
doing
all
this
last-minute
primarily
because
people
are
still
trying
to
cherry-pick
features
in
up
until
the
last
minute
right.
D
So
it's
unclear
exactly
what's
going
to
be
in
those
release,
notes
and
I
mean
honestly,
like
I
was
one
of
the
people
who
was
doing
it.
I
know
claim,
was
involved
for
a
couple
of
different
SIG's
Janet
was
involved.
It
was
like
a
lot
to
do
last
minute,
but
it
wasn't
super
overwhelming,
in
my
opinion,
so
for
whatever
it's
worth.
F
Well,
let
me
give
you
a
brief
update
and
what's
worked,
what
we
have
pre-agreed
forget
injuries,
notes
of
director
meeting
and
what
we're
going
to
finally
read
into
next
year,
physically
innocent
generally
in
the
community,
so
we
would
like
to
have
folder
release,
notes,
prepared
and
all
the
features
defi
to
proximately
the
period
well.
Code
phrase
will
happen,
so
we
will
have
future
phrase
at
the
beginning
focus
the
period
of
time
when
all
the
teachers
have
to
be
defined
and
submitted
to
defeat
to
the
future
circle
as
an
insurer
to
the
future
circle.
F
At
the
same
time,
we
would
like
you
as
the
future
illness
to
continue
working
on
these
features
together
with
documentation
in
together
with
release
notes
until
the
beginning
of
September
at
the
actual
core
is
okay,
with
the
real
our
release
date
at
the
end
of
September.
We
were
expecting
to
have
enough
time
to
polish
this
release.
Notes
to
polish
documentation
a
few
weeks
before
that
recruits
I.
Suppose
the
trance
sounds.
D
Well
before
us,
so
that's
that
makes
sense,
but
it
wasn't
I
mean
the
ones
that
were
feature
issues
usually
had
well-defined
issues
that
you
could
read
it
and
make
some
sense
out
of
it.
A
lot
of
the
other
release
notes
were
related
to
break
fix
and
right
sometimes
those
issues.
It
wasn't
clear
what
the
issue
was,
and
it
wasn't
necessarily
clear
what
the
break
fix
did
so
you'd
have
to
go
back
and
look
at
the
PR
and
say:
okay.
Well,
here's
what
this
guy
did.
Here's
what
the
actual
noise
should
be.
F
Right
so
which
one
third
one,
we
have
better
better
situation
with
your
release,
notes
attached
to
the
features
different
with
the
release,
notes
attached
to
but
fix
some
minor
enhancements.
So
we
we
have
to
set
it
like
the
same
barrier
for
all
types
of
release,
valves
and
it
just
like
you
to
have
them
ready
for
Drew.
For
you
until
the
beginning
of
September,.
B
A
B
A
C
Yeah
sure,
so,
if
you
have
the
document
up,
this
is
a
document
for
1.8.
It
looks
like
people
have
been
heading
a
lot
of
their
work
in
here.
So
that's
great.
Essentially
we
are
the
first
part
is
we
have
stateful
set
statements?
That's
deployments
and
replica
sets
those
for
I
mean
the.
The
longer-term
plan
is
to
bring
those
to
hopefully
get
those
for
into
GA
by
the
end
of
the
year,
so
I
think
I,
don't
think
we'll
do
it
in
q3
I
think.
C
Well,
you
do
be
a
step
to
sort
of
get
us
there,
hopefully
in
q4,
and
we
wanted
to
some
from
some
conversations
with
some
of
the
people
in
the
sig.
It
looks
like
I
mean
we
want
to
try
to
do
that.
Keep
these
together
so
that
for
consistency
just
that
they
all
have
the
features
that
we
want
and
then
I
think.
The
next
section
is
really
on
cron
jobs
in
getting
that
to
beta
and
I.
Had
some
conversations
with,
with
with
passage
on
that
I
guess,
we
could
start
with
staple
set
so
yeah.
C
D
So
yeah
for
most
of
the
stuff
er
staple
set
demon
set
and
deployment
we're
trying
to
look
at
what
features,
what
we
need
to
do
to
take
them
TGA
by
the
end
of
the
year
and
try
to
get
as
much
of
the
stability
and
readiness
the
inconsistency
features
in
as
we
can
in
1.8
the
main
thing
for
all
of
them
and
we're
still
open.
Like
really
open
suggestion
about
this
part,
we're
gonna,
we
have
to
move
everything
into
Apps
and
I.
D
Think
the
desire
is
for
every
all
the
core
controllers
to
move
from
apps
to
be
one
as
a
group.
So
we
were
wondering
if
potentially
we
should
move
to
instead
of
just
moving
deployment
or
demon
set
into
V
1
beta
one.
Should
we
move
everything
all
the
core
controllers
into
another
beta
and
then
move
that
as
a
group
into
GA?
All
the
surrounding
work
is
basically
related
to
identified
deficiencies
with
either
API
consistency,
testing
and
impedance.
In
particular,
scheduling
functionality
also
delaying
well
determining
whether
wave
went
demon
set
to
go
through
the
default
scheduler.
C
C
G
One
thing:
April
2012
call
that
in
deployments,
but
I,
don't
know
that
we
should
graduate
any
of
these
to
GA
until
we're
pretty
sure
that
higher-level
orchestrators
can
use
these
effectively.
So
we
think
we
have
most
of
the
solutions
in
place
with
the
partition,
stuff
and
positing,
but
I
do
think
that
it's
important
before
we
go
to
GA,
to
say,
because
one
like
a
controller,
can
someone
like
home
and
care
level
orchestrators
for
things
like
canary?
Can
we
effectively
do
that
in
a
number
of
spots?
I
G
G
Just
not
sure
that
we
can
absolve
ourselves
of
responsibility
for
making
sure
that
complex
upgrades
of
staple
sets
are
even
possible
it.
What
does
it
look
like
when
someone
does
that?
And
we
can
maybe
take
something
like
the
people
using
staple
sets
of
elasticsearch
if
they
pick
something
you
know
full
suit,
more
advanced
stuff.
I
would
like
to
get
a
call
out
for
people
to
to
review,
but
I
don't
know
that
we've
I'm
a
little
worried
because
I
see
people
using
staple
sets.
G
G
I
At
the
same
time,
there's
something
to
be
said
for
the
clarity,
the
messages
say
all
Georgie
a
it
ensures.
We
know
that
we
it's
a
process
that
you
know
can
come
to
conclusion
and
that
we
are
giving
attention
simultaneously
to
the
consistency
across
them,
which
I
think
is
also
has
some
value.
Yes,
absolutely.
G
D
The
only
way
we
can
resolve
this
now
that
we
put
it
out
in
the
wild
is
to
continue
to
get
feedback,
as
people
actually
use
it
and
I
write
that
feedback
as
we
go
forward.
I
think
that's
the
underlying
intention
that
we
have
over
this
next
release
and
over
the
following
release
to
actually
to
make
sure
that
we
incorporate
feedback
from
users
and
for
stateful
set
in
particular,
because
I
think
people
understand
like
I
want
a
global,
sidecar
or
administrated
very
well.
D
People
who
are
deploying
I,
guess
you
call
cloud
native
applications
really
get
the
concept.
I,
think
stateful
applications
and
containers
in
orchestrating
containers
is
relatively
new.
So
maybe
the
onus
might
be
on
us
to
develop
examples
for
the
staple
applications
that
we
think
are
very
prevalent
and
ensure
it
works
well
with
those,
and
also
remember
that
we
can't
hit
all
of
them,
but
we
should
be
able
to
hit
major
categories
of
them
right
or.
G
Even
awed
it
and
summarize
the
state
of
safe,
we'll
set
the
state
of
the
art
in
stateful
set
apps,
and
we
may
not
have
to
write
the
examples.
But
we
should
be
able
to
ayat
review
and
and
yeah
encourage
feedback,
but
also
go
to
solicit
feedback
for
a
few
representative.
Examples
that
we
believe
are
complex
enough.
That
there
may
be
some
doubt
as
to
whether
we've
completely
dissolved
or
whether
we
are
correctly
enabled
on
the
solution
of
level.
G
H
I
want
to
reiterate
something:
Eric
said
about
timeboxing.
It
I
think
there
is
a
clock
to
not
bringing
these
core
controllers
to
GA
in
terms
of
confidence
in
the
system
as
a
whole.
So
I
think
the
consistency
is
critically
important.
I
think
we
shouldn't
expect
that
it
won't
continue
to
evolve
so
I
think
having
some
time
box.
Some
timeline
for
this
process
would
be
important,
also
yeah.
G
D
So
one
other
thing
to
consider:
I
mean
to
movie.
When
we
moved
to
GA,
it
doesn't
mean
we
can't
modify
the
semantics
under
the
hood
small
squeak
size
necessary
right,
but
we
really
asked
have
to
be
sure
that
the
API
that
we've
built
is
stable
enough,
that
it's
not
going
to
be
modified,
as
we
do
point
releases
and
as
we
go
forward.
Yes,.
K
G
D
Now
the
other
thing
particularly
for
deployment
is
I
think
there's
still
some
discussion
that
needs
to
be
had
and
we
need
to
kind
of
start
making
decisions
things
about
things
like
are
we
defaulting,
selectors
and
selector?
Mutability
is
a
big
one
right,
I
think
people
are
starting
to
lean
towards
we're
not
going
to
do
it
I
think
there
may
be
some
use
cases
for
it,
but
I
think
we
kind
of
have
to
make
a
decision
on.
D
I
I
want
to
cause
something
that
Sara
and
ER
have
said
before,
which
is
that
1.8
should
be
focused
on
stabilization.
I,
see
some
things
on
the
lists,
particularly
for
deployment
that,
while
there
have
been
issues
for
a
long
time,
they
are
effectively
going
to
be
new
features,
and
we
should
look
closely
whether
we
want
to
add
new
features,
especially
for
trying
to
drive
to
GA
or
whether
we
should
only
fix
things
that
are
like
bad
defaults
or
inconsistencies
rather
than
new
operational
behaviors.
Any
thoughts
on
that.
G
Yeah
I
mean
that's
kind
of
like
I,
think
that's
almost
the
corollary
corollary
to
what
I
was
asking,
which
is.
Can
we
if
we
go
through
the
list
of
the
remaining
features?
Are
they
things
that
can
be
safely
added
afterwards?
We
have
the
experience,
etc.
I
think
that
ties
into
that
question
that
he
just
asked
for
things
like
automatic
rollback,
with
automatic
rollback
fundamental
deployments,
and
can
we
add
that
gracefully?
We
need
to
know
whether
we
can
add
it:
gracefully,
post,
GA
or
not,
probably
yeah,.
I
Well,
I
mean
at
some
point
you
just
have
to
say
like
if
you
just
keep
adding
something.
I
would
love
for
us
to
go
to
GA.
After
all,
the
things
that
are
in
there
as
much
as
possible
have
had
enough
time
to
get
feedback
on
them.
So
you're
always
adding
a
new
thing,
and
you
always
have
something
that
you
haven't
had
time
to
heat
back
on,
so
might
be
an
opportunity
to
take.
Take
advantage
of
this
1.8
stabilization.
I
G
C
G
G
If
you
want
to
script,
a
stateful
set
update
because
the
core
staple
set
update,
isn't
sufficient
to
update
something,
that's
moderately
complex
or
has
a
number
of
components
or
prereqs
like
draining
traffic
and
does
auto
pausing
have
to
be
part
of
the
fundamental
thing,
because
it
is
likely
to
change
how
we
think
about
the
controller
I
if
we
only
discuss
in
one
eight
or
prototype
to
prove
a
lot
and
we
can
commit
to
it
as
a
feature.
I
think
that's
very
reasonable.
Simply
to
answer
the
question
about
whether
we're
ready
to
lock
it
in
forever.
G
I
Could
do
that
I,
guess
I'm
kind
of
I
feel
like
any
discussion.
That's
not
like
there's
a
lot
of
stuff,
even
if
we
cut
out
the
things
that
are
new
features,
are
still
a
lot
of
work
to
do,
to
bring
it
to
GA
and
I
really
was
hoping.
Maybe
we
would
get
everything
we
know
of
done
in
1/8,
so
then
1/9
all
we
do
is
like
add
a
v1,
apps,
v1
and
add
a
few
lines,
and
we're
done
so
I
feel
like
anything.
G
I
guess
like
and
again
like
I
know,
these
things
are
on
here,
because
people
who
who
I
work
with
have
put
them
on
here
some
of
these
are
what
we
consider
real
blockers
and
production
and
so
I
think
I'm
not
actually
advocating
that
they
are
required.
I'm
merely
I
am
concerned
that
we
declare
something
GA
that
some
people
are
success
with,
but
not
everyone
had
success
with
I
want
to
make
sure
we
at
least
cross
the
eyes
and
teeth
before
we
go
to
GA.
That's
really.
I
G
I
G
Absolutely
I
think
that
that
is
better.
The
clearest
representation
of
what
I
was
trying
to
highlight
is:
can
someone
solve
this
problem
without
us
changing
deployments
again
or
without
changing
stateful
sets
again
I.
Think
it's
a
successful
thing.
We
try
to
do
that
for
every
other
part
of
the
system
can
I,
add
external
store,
can
add
a
new
storage
provider
without
changing
the
API
etc.
So.
I
D
Are
we
agreeing
on
the
idea
that
we're
not
saying
that
for
GA,
we
have
to
implement
any
of
these
things,
but
we
should
give
consideration
to
ensuring
that
the
API
is
capable
of
implementing
these
things
to
ensure
we
all
box
ourselves
in
with
the
design.
It
won't
allow
them
to
be
implemented.
Yes,
because.
G
Once
we
release
the
GA,
like
any
people
so
I'm
most
concerned
about
behavior,
in
that
we
introduced
something,
that's
net
new,
that
other
components
don't
see
in
the
GAAP
I
entered
us
unable
to
deal
with
a
reason
about
like,
even
though
we
say
yes,
we
can
add
new
features
if
they're
opted
in
new
features
that
our
opt-in
can
still
break
external
integrations,
but
don't
realize
that
feature
exists
and
in
the
cubelet
we
have
this
problem
today
we
deal
with
it
by
saying.
Well,
you
know
most
of
the
time
it's
not
a
problem.
G
G
So
the
discussion
is
probably
let's
try
to
do
the
discussion
early
in
1/8
to
close
the
angle
of
discussion
about
whether
we
have
to
add
any
more
features,
starting
with
the
assumption
that
we
aren't
going
to
add
any
more
features
is
a
reasonable
spot.
I
think
we
don't
need
to
add
many
of
these
features.
K
Hi
hi,
everyone
of
a
probable
point
of
view,
I
just
added
the
automatic
roll
back
and
increased
rolling
updates.
So
these
two
features
have
been
added
the
implemented
inside
where
we
and
we
find
it
very
useful.
So
that's
the
reason
we
thought
that
we
will
open
source
it
by
1.8.
We
are
actually
working
on
a
proposal
which
is
getting
the
views
internally
and
it
should
be
able
to
send
out
the
review
for
automatic
roll
back
by
this
week.
K
I
I,
don't
I
think
it'd
be
useful,
I'm,
not
sure
to
me,
like
the
plan,
but
I
think
it'd
be
useful
to
describe
how
that
feature
works
for
you
in
the
context
of
your
larger
CI
CD
pipeline.
So
we
can
understand.
Are
you
saying
like
with
this
feature?
We
just
this
thing
is
so
much
easier
or
do
you
still
have
functionality
in
a
CD
pipeline
and
could
it
have
been
there?
That's
kind
of
the
question
in
my
mind.
K
For
automatic
growth
that
this
is
not
directly
useful
for,
say
a
pipeline,
but
it
is
for
users
who
are
trying
to
deploy
applications
and
then
that
application
phase,
then
it
Arabic
automatically
comes
back
to
the
stated
state
rather
than
getting
hungry
or
you
know
getting
to
a
state
or
bid
lock.
It
automatically
comes
back
to
the
proper
working
state,
but
I
know.
K
The
argument
around
is
that
you
don't
want
to
mess
with
the
app
spec
at
all,
because
the
template
automatically
given
wantonness
with
the
template
I
mean
if
the
user
roster
changes
they're,
all
that
shooting
is
changing
automatically.
Is
we
understand
that?
But
that
is
not
the
really
cemented
internally,
but
so
we're
trying
to
design
this
such
a
way
that
it
doesn't
really
hurt.
So
what
one
of
the
solution?
What
cog
is
mentioned
was
that
we
not.
We
have
failure
strategies
just
like
a
good
stack
disease.
K
I
I
C
I
It
seems
like
it's
kind
of
late
to
add
something
to
one
controller.
We
can't
do
consistency
across
all
of
them
and
it
would
kind
of
defy
the
time
box
I'd
like
to
see
on
GA.
If
we
added
that
now
not
to
say
that
one
after
GA,
we
can't
like
look
at
what
you've
done
and
try
to
add
it
consistently
to
all
of
them,
but
just
rushing
it
into
one
of
them
seems
hasty.
L
Yeah
I
agree
with
that,
and
also
it's
really
been
mentioned
before,
regarding
consistency.
Right
now
have
a
partition
in
future
institutions
which
enables
her
little
Crusaders
to
effectively
manage
the
lifecycle
of
expect
and
do
more
stuff
from
what's
happening
from
the
core
controller
and
auto,
posing
is
essentially
the
same
thing
and
by
enabling
deployments
and
demo
sets
to
be
customizable.
In
that
level,
we
don't
need
stuff
like
automatically
roll
button.
The
main
controllers
could
have
a
higher
the
orchestrator
beside
the
parity
between
this
barreled
bug,
I'm.
I
L
Mean
having
examples
of
how
this
features
work,
because
it's
an
advanced
usage
of
the
controller's
managing
the
whole
life
cycle
and
using
the
partitioning
feature
would
definitely
need
examples
there
and
actually
actually
are
one
other
Vikings
just
going
to
work.
We're
an
example
in
the
1.8
times
right,
yeah.
G
I
was
going
to
say,
like
that
was
a
very
great
thing.
It's
like
either
we
have
said
staples
as
data
sets
and
deployments
are
building
blocks
for
higher
level
distributed
systems
for
them
to
successfully
be
considered
building
blocks
in
the
distributed
system.
They
need
to
be
useable
as
building
blocks,
and
the
the
minimum
bar
for
GA
is
proving
that
they
can
be
used
as
building
blocks,
and
we
can
set
the
goal
as
their
simple
registration
or
complex
orchestration
as
possible,
even
if
we
don't
enable
it
in
GA
as
an
addition.
C
Okay,
I
think
like
we're
in
general
agreement
on
some
of
the
foundational
things
that
we
need
to
build
from.
You
know
for
consistency
as
well
as
for
support
of
some
of
the
higher-level
aspects
in
these
areas.
Let's,
let's
continue
the
discussion.
I
guess
another
time,
because
we're
actually
running
on
the
one
on
time
right
now,
yeah.
Is
there
anything
else
on
1.8
in
the
last
2
minutes
or
any
other
topics
that
I
think
people
want
to
bring
up?
Otherwise
we
can
turn
it
back
to
Michelle
I,
just.
I
Want
to
say,
we
need
to
follow
up
and
don't
think
we
ratified
that
list
of
1.8
proposed
work
is
like
yeah,
we're
doing
it
or
not,
and
we
need
a
follow-up
meeting
to
kind
of
further
narrow
that
down
and
discuss
the
time
box
thing
to
decide.
If
we're
going
to
do
that,
have
a
more
firm
schedule
for
one
a
and
what
could
be
in
it,
I
mean.
C
D
Time
with
interested
subgroups,
okay,
the
interest
is
a
group
of
all
just
a
gaps,
because
it
may
not
be
that
everybody
is
particularly
interested
in.
You
know
exactly
what
features
go
in
1.8
1.9
and
when
GA
happens,
but
there
are
probably
a
lot
of
parties
who
are
very
interested
so
having
something
separate
from
say,
gaps
where
we
just
have
some
blocked
off
time
to
discuss
things
like
this
would
probably
be
good.
So
we
don't.
You
know,
co-op
an
entire
meeting.
A
We
can
also,
if
there's
some
I,
think
there's
some
clarity
that
we
need
around
what
sake.
Architectures
role
is
when
we're
discussing
new
features
to
put
into
someone's
creative
design
proposal
does
that
need
to
go
through
state
architecture
first,
before
we
kind
of
like
approve
it
for
1.8
ad
I,
don't
know
if
anyone
has
the
answers
to
that
question,
they
can
follow
up
offline
since
we're
running
out
of
time.
A
So
that's
one
of
the
questions
I
have
after
this
conversation
and
then
let's
also
follow
up
next
week
on
on
the
conversation
that
happens
separately
on
Cabrini's
1.8,
and
we
can
also
use
next
week's
time
that
we
usually
use
for
stand-ups
for
planning
for
the
Umbrella
projects.
If
that's
good
with
everyone.