►
From YouTube: Kubernetes SIG Cluster Lifecycle 20181120
Description
Meeting Notes: https://docs.google.com/document/d/1deJYPIF4LmhGjDVaqrswErIrV7mtwJgovtLnPCDxP7U/edit#heading=h.517coa2gca4m
Highlights:
- 1.13 release notes and blog post
- Version skew and upgrade order documentation
- LTS working group
- Sending out surveys
A
A
The
first
one
is
about
the
release,
notes
and
making
sure
that
our
sig
is
covered
sufficiently
in
the
release,
notes.
I
know
this
is
something
that
Tim
and
the
folks
that
worked
on
cue.
Badminton
have
been
definitely
keeping
up
on
both
both
this
one
and
the
next
one,
but
I
did
further
release.
Notes
want
to
ask
right
now
the
sickle
cell
lifecycle,
release
notes
are
entirely
about
key
badminton
GA
and
if
there
were
folks
on
the
call
that
thought
we
should
be
covering
any
of
the
other
sub
projects.
A
But
Tim
and
I
were
chatting
and
they're
really
some
stock
and
he
said
that
it
might
make
sense
to
drop
some
bread
comes
to
the
other
tools,
release
pages
and
and
mention
that
they
have
sort
of
separate
release
cycles
so
on
to
see
what
people
thought
about
that.
Maybe
just
and
I
saw
you
online.
You
can
chime
in
since
you've
done
this
in
the
past
for
crops
I.
B
Read
like
the
idea
of
just
dropping
a
bread
crumb
I
feel
like
that.
That
and
saying
that,
like
there
were,
any
cycles
are
separate.
I
think
that,
like
is
a
sort
of
proportionate
response
that
sort
of
sidesteps
the
issue,
but
still
like
it's
like
a
cluster
API
right.
We
want
to
like
mention
all
the
works.
Gonna
go
straight
guy,
but
it's
not
like.
There
is
a
milestone
that
we
have
hit
on
coordination
with
this
particular
kubernetes
milestone.
C
A
I'm,
just
looking
over,
like
the
sub-project
listed
on
our
cig
page,
we've
got
beaut
cube
cluster
API
cops,
Q
beta
s,
cube,
deploy,
cube
up,
Thank
You
Batman,
which
are
both
part
of
the
main
release,
cube
admin,
the
IND
cluster
communities
anywhere
cube
spray
and
mini
cube
right.
So
there's
many
different
sub
projects
and
right
now
we're
covering
one
of
those
there's,
probably
not
a
lot
to
say
in
the
release,
notes
about
cube
up,
even
though
it
is
bundled
in
the
same
release.
A
Q
raised
anywhere
it's
sort
of
on
the
deprecation
trail,
but
I
think
for
things
like
maybe
reaching
out
to
the
mini
cube
owners.
The
cube
spray
owners-
you
know
Justin
and
I-
can
can
help
out
with
with
cops
and
cluster
API,
and
then
maybe,
if
there's
anything
from
the
DI
UV
cluster
folks
or
cube
a
DA
of
us
that
we
want
to
put
any
breadcrumbs
and
also
and
also
boot,
cubes
I
checked
recently,
and
they
still
have
activity
going
on
there.
A
B
Yeah
and
by
way
back
I'm,
like
four
cups,
I
think
the
goal
is
the
feedback
we've
got
in
cups.
Is
that
people
like
the
fact
that
cups
races
don't
come
out
at
the
same
time,
because
it
means
that
when
cops
does
land,
we
try
to
be
a
working
thing
that
you
would
feel
comfortable
installing
and
the
same
it
like
GTA
doesn't
release
like
on
the
same
day
that
koruna
days,
1.13
ZUP
zero
is
released
right.
B
The
likely
future
update
will
be
bit
like
we
want
to
get
to
the
point
where
we
have
an
alpha
or
a
beta
release
available
at
release.
So
hopefully
we
can
link
to
that
in
future.
I.
Imagine
my
understanding
is
cube.
Atm
at
some
stage
wants
to
move
out
of
tree,
and
so,
when
you
have
the
opportunity
it
seems
like
it
is
a
user
facing
like,
from
the
user
point
of
view,
it's
a
better
experience.
B
C
D
C
Something
that
we
should
consider
is
upgrades
like.
Currently,
we
are
fixed
with
the
version
of
copernicus
and
it
makes
it
makes
it
easier
for
us
to
like
to
pick
the
the
couplet
it
matches
the
version
of
Kapadia
in
the
ideal
scenario,
and
also
we
can
download
the
same
question
for
the
control
plane.
If
all
versions
match
that's
great
for
us,
if
we
decouple
queue
medium,
we
now
have
to
tackle
the
scenario
where
okay
is
the
couplet
newer
than
the
control
plane
which
is
going
to
break,
and
we
have
to
start
considering
things
like
that.
C
A
A
C
A
A
The
release
would
be
a
follow
on
step
and
I
haven't
checked
back
on
where
that
timeline
might
be
I
think
initially,
it
was
targeted
around
sort
of
this
time,
like
113
114
when
it
was
written
a
year
ago,
but
I
think
we
were
also
planning
on
being
a
release
behind
somebody
else.
I
think
they'd
be
cute,
cuddle
moving
out
and
I,
don't
I
haven't
seen
a
lot
of
movement
on
anybody
moving
out
of
the
main
tree,
except
for
the
API
missionaries
like
trying
to
break
stuff
up
in
the
staging
directory,
suggesting.
B
A
Cool
all
right
so
on
along
the
same
theme,
the
there's
gonna
be
a
series
of
blog
posts
for
1.13,
so
I
just
shared
this
stock
with
our
cig.
So
everybody
should
all
to
see
it
now.
The
plan
is
to
have,
as
we've
done
in
past,
releases
sort
of
a
big
blog
post,
announcing
the
release
and
then
a
follow
on
sort
of
series
of
blog
posts
for
I,
think
5
or
so
days,
highlighting
different
things
as
part
of
the
release
and
with
the
cube
admin
being
promoted
to
GA.
A
Like
that's
one
of
the
big
headlining
features
for
the
113
release,
so
it's
gonna
be
I,
think
at
the
top
of
the
main
blog
post,
and
also
the
contents
of
probably
the
first,
but
maybe
the
second
sort
of
daily
blog
post
following
up
there.
So
again,
I
think
that
Lucas
and
Tim
have
been
involved,
and
maybe
other
folks
but
I've
been
commenting
on
the
dog.
So
I
know
they've
been
involved
in
crafting
both
like
the
description
for
the
first
day
and
it
also
sort
of
signing
up
to
write
the
daily
blog
post.
A
So
if
people
want
to
take
a
look
at
that,
I
think,
unlike
the
main
release
notes,
this
is
probably
a
place
where
we
it's
less
useful
to
highlight
our
other
sake
sub
projects.
But
if
people
are
you
know,
have
you
know
helping
on
cubeb
in
like
the
roomier
and
Liz
and
other
folks
on
the
call
and
they're
not
aware
of
these
blog
posts?
Docs,
you
should
probably
be
looped
in
and
take
a
look
at.
C
A
Writing
them
Lucas,
probably
also
the
main
text
here.
I
think
that
Caitlin
had
sketched
something
up
there,
maybe
copied
it
from
the
past.
A
past
dark
Lucas
went
through
and
edited
yesterday
looks
like
those
edits
have
all
been
accepted
because
I
don't
see
a
bunch
of
like
in
flight
to
text
changes
like
I
did
yesterday
when
I
looked
so
he's
sort
of
massaged
the
words
there
but
feel
free
to
also
take
another
pass
and
there's
a
link
at
the
bottom.
A
If
you
scroll
down
for
the
5/5
date,
features
blog
series
and
I,
don't
know
who
is
going
to
be
writing
that
blog
posts,
so
that's
not
clear
from
here
and
I
haven't
heard
anything
through
backchannels
about
that
either.
So,
if
you're
interested
in
helping
with
that,
you
should
probably
sync
up
with
Tim
or
Lucas
I
think
they're
driving
driving
that
so.
C
A
And
it's
not
really
broken
unbiased
by
siga,
throwing
up
my
feature,
but
those
features
tend
to
sort
of
come
from
sake
right.
So,
like
the
day,
two
blog
post
is
from
the
storage
Zig.
The
day
three
one
I
would
assume
is
from
the
networking
sig
or
someone
related
to
networking
today,
for
one
is
gonna,
be
from
the
scheduling
sig
and
in
the
day,
five
one.
A
It's
probably
from
sixty
I
write
so
I
mean
because
if
each
of
those
things
is
sort
of
pursuing
these
big
features
and
as
they
sort
of
roll
into
different
levels
of
maturity,
it
makes
sense
to
highlight
them
as
part
of
the
release
so
yeah.
But
the
first
day
is,
is
us
and
like
I,
said,
if
you're
interested
in
helping
contribute
to
that
blog
post
or
potentially
writing
the
blog
post?
A
C
C
A
C
A
Circle
back
and
see
if
he
was
in
the
meantime,
I
guess
the
only
other
thing
that
I'd
stuck
on
the
agenda
was
a
link
to
PR
that
Jordan
Lee
get
started
working
on
related
to
version
skew-
and
this
is
you
know
our
Sigma
si
si,
but,
along
with
a
whole
bunch
of
other
people,
I,
don't
know
if
people
have
actually
been
paying
attention
to
this.
There
is
a
sort
of
hidden
page,
that's
kind
of
hard
to
find
that
people
occasionally
link
to
that
describes
our
existing
version.
A
Ski
policy
in,
like
the
proposal
section
of
some
documentation
site
from
kubernetes,
which
talks
about
how
we
support
the
skew
between
the
Masters
and
the
cubelets
and
the
skew
between
the
API
server
and
Q
petal
and
Jordans,
basically
extracting
the
relevant
bits
of
that
cleaning
it
up,
making
it
clearer
and
adding
it
to
the
website
and
I.
Think
based
on
his
response
to
my
comments
yesterday,
it
sounds
like
we'll,
probably
delete
the
other
page
or
just
turn
it
into
a
link
to
the
website.
A
It
is
particularly
interesting
also
because
it's
this
talk,
not
the
old
doc.
This
doc
describes
sort
of
the
upgrade
flow
that
we
support
in
particular
for
multi
master,
or
you
know,
multi-instance
control
planes.
However,
you
want
to
say
that,
so,
if
you
have,
you
know
multiple
API
servers,
if
you
have
multiple
controller
managers,
etc,
and
so
I
think
that's
particularly
relevant
to
us
to
make
sure
that
we
agree
with
the
sort
of
proposed
supported,
upgrade
order
which
is
sort
of
halfway
down
the
page.
So
people
haven't
taken
a
look
at
that.
Please
do
go.
A
C
I
wanted
to
make
an
announcement
related
to
that.
So
this
is
part
of
the
bigger,
like
the
bigger
plan,
to
eventually
support
longtime
releases
in
colleges
and
new
working
group
was
formed
about
that,
and
the
meeting
of
the
working
group
is
Attucks
at
the
exact
same
time
of
this
meeting
but
next
week.
So
it's
we
have
a
basically
we
skip
next
week,
but
you
can
join
the
same
meeting
about
LTS
next
week.
C
C
A
A
You
know
I
think
it'd
be
useful
for
people
that
have
started
doing
that,
maybe
advertise
a
little
bit
more
widely
to
get
more
folks
looked
and
especially,
like
you
said,
I
think
there
were
a
lot
of
people
that
responded
to
the
email
saying.
This
is
a
great
idea.
I
want
to
help
and
if
they're
only
a
couple,
people
at
the
meeting
I
think
it's
it's
probably
at
least
partly
due
to
lack
of
advertisement
for
the
meeting
and
not
due
to
lack
of
interest.
A
A
A
You
know
and
-2
might
be
different
if
we
have
a
release
that
we
support
for
much
longer,
because
maybe
we
support
you
know
wider
compatibility
ban
with
that
release,
or
it's
maybe
even
as
a
narrower
compatibility
band
with
just
you
know,
masses
to
keep
us
must
be
it.
You
know
just
different
patch
versions
that
same
minor
release,
instead
of
actually
supporting
different
minor
versions.
So
there's
a
lot
of
interesting
things
that
would
come
along
with
us
changing
our
release,
cadence
in
terms
of
how
we
test
upgrades
and
all
of
those
sorts
of
things,
yeah.
C
There'll
be
a
lot
of
question
marks
about
this,
so
I
think
the
current
one
that
everybody
agrees
upon
is
that
we
should
basically,
for
instance,
113
releases
in
December,
and
we
decided
ok.
This
is
going
to
be
an
alts
and
we
basically
support
it
with
security
fixes
and
critical
bug
fixes
for
maybe
two
two
years
from
one
year
for
releases
and
and
then
we
start
like
claiming
okay,
you
can
easily
upgrade
after
these
four
releases
to
the
to
the
release
you
want
upgrade.
C
A
And
that's
one
questions
right
now
we
explicitly
tell
people,
you
can't
jump
over
versions
right
when
you're
operating
a
control
plane.
You
have
to
go
through
every
intermediate
version,
because
we
do
things
like
you
know:
two
data,
conversions
and
so
forth,
and
especially
when
we
get
to
API,
deprecations
and
whatnot,
and
if
we
are
saying
now
we're
gonna
support
you
jumping
from
114
to
118,
that's
a
sort
of
a
huge
shift
in
how
we'd
need
to
deal
with.
A
C
Up
for
Cuba
Diaz,
specifically
I
mean
the
unofficial
plan
is
to
to
do
incremental
upgrades.
Like
you
are
saying
we
have
to
jump
one
miner
at
a
time
so
from
113
we
jump
to
1415
going
to
118,
and
this
can
be
executed
in
a
single
sit
down
like
you
apply
all
these
incremental
updates
one
at
a
time,
and
we
can.
We
can
basically
already
like
have
end-to-end
test
for
that
incubating,
but
the
problem
we
don't
have
a
good
deploy
or,
like
you
know,
we
we
are
using
kubernetes
anywhere.
B
A
Interesting
thing
about
kind,
I
was
gonna
say:
is
it
it?
It
doesn't
rely
on
any
particular
cloud
environment
right.
So
something
like
QA
DM
that
isn't
tied
to
a
cloud
environment
might
be
a
good
thing
to
try
and
test
with
kind.
Although,
since
it
is
more
tied
to
like
the
image
in
the
machine,
you're
running
out,
I
don't
know
if
that
fits
well
with
the
sort
of
kind
model
of
will
give
you
these
virtual
cubelets
right.
C
C
Yeah
I
mean
kite
is
great,
is
gonna,
be
great
for,
like
vocalizes
tasting
without
the
court
provider
stuff,
because
you
have
to
spawn
here
to
machines,
credentials
and
stuff
in
kubernetes
in
docker
is
like
really
the
easiest
way
to
test
things,
except
that
kite
is
not
yet
supporting
multimode,
and
this
is
something
that
we
have
to
support
eventually
as
well.
If
you
want
to
test
for
scenarios.
A
So
to
look
back
to
the
version,
speed,
documentation,
I
think
it
might
be
worth
just
walking
through
the
support,
upgrade
order
thing
quickly,
because
obviously
I
haven't
been
paying
attention
to
the
H
a-cube
admin
plans,
or
maybe
Loomer.
If
you
can
give
me
an
update
on
how
cube
admin
is
doing
H
a
and
we
can
see
how
that
fits
in
with
the
supported
upgrade
order
proposal
that
just
that
Jordan
wrote
up.
C
Mean
it's
slow
the
ideal.
How
so
I
I
basically
created
a
couple
of
diagrams
the
other
day
and
I'm
planning
to
post
him
up
the
current
documentation
that
we
have
for
H
a
because
I
wanted
to
see
people
to
show
people?
How,
basically,
that
we
have
a
couple
of
scenarios.
One
of
them
is
a
stacked,
ed
CD.
This
is
basically
each
control,
a
know,
those
cars
and
HCD
member.
That's
the
first
scenario
and
the
other
one
is
where
you
have
an
external
HDD
question
completely
external
to
your
control.
E
That
Cooper
the
mean
when
you
scale
the
control,
pain,
the
complain
and-
and
you
are
a
local
city
scales-
also
eighty
city-
and
this
was
implementing
in
this
already
now.
There
is
an
issue
and,
and
then
we
are
discussing
this
will
be
implemented
in
the
next
step,
is
how
to
automate
the
the
certificate
moving
from
one
quarter,
plane
node
to
another.
That
is
the
last
manual
step
that
that
is
in
charge
of
the
user.
E
A
Okay,
so
then
you've
you've
deployed
your
either
stacked
at
the
qubit
hiq,
medium
or
external,
at
city,
q88,
QA
d,
MH,
a
control
plane
you've,
either
manually
or
written.
Some
automation
to
shuffle
asserts
around
now
what
happens
when
you
want
to
upgrade?
How
does
how
does
that
work
and
how
is
it
compared
to
a
normal
QA.
E
Team
are
very
great.
You
have
today
either
one
control
plane
at
time
and
the
first
quarter
plane
take
charge
of
executing
most
of
the
grade,
so
creating
the
new
config,
Maps
or
cupola
that
up
critical
proxy
and
renewing
certificates
and
so
on.
The
the
secondary
control
plane
makes
only
a
light,
upgrade
changing
the
the
manifest
on
on
the
disk.
E
So
so,
basically
they
like
in
it
likely
in
the
for
the
ending
workflow.
You
have
a
boost
remastered
and
then
you
join
secondary
control.
Plane
in
the
present
will
flow.
You
ever
you
start
from
one
master
can
be
the
most
rebuttal
any
of
the
the
master
and
you
execute
upgrade.
And
then
you
a
case
we
could
upgrade
note,
which
is
the
light.
We're
shown
that
take
care
only
the
the
local
stuff.
A
Right
so
that's
kind
of
what
I
was
gonna
get
at
is.
If
you
read
Jordan
description
of
how
the
upgrade
should
work.
Basically,
the
supported
upgrade
flow.
Is
we
upgrade
all
of
the
API
servers
before
we
upgrade
any
of
the
controllers
or
any
of
the
cubelets
and
I
think
what
you're
describing
is,
is
sort
of
doing
it.
A
One
machine
at
a
time,
instead
of
one
component
at
a
time
and
saying
on
the
first
master
machine,
we're
going
to
upgrade
the
API
server,
the
controller
manager
of
the
scheduler
controller
manager
and
then
we'll
go
to
the
second
machine
and
we'll
upgrade
the
API
server,
scheduler
magic,
our
controller
manager
and
what
are
the
third
machine
and
we'll
do
it
in
the
same?
Do
the
same
thing,
but
actually
in
during
that
process
puts
you
into
an
unsupported
state.
According
to
this,
this
PR
no.
E
No
I
commented
to
the
to
the
PR
about
versus
true,
and
we
are
not
going
in
an
unsupported
scenario
because
and
also
played
on
made
some
adjustment
on
the
PR
for
for
giving
evidence
of
these.
Because
we
are
not
going
in
an
exported
scenario,
because
every
instance
of
scheduler
controller
manager,
torques
of
only
to
the
local
etcd.
E
A
Okay,
so
the
argument
is
that,
because
we're
only
talking
to
the
local
one,
the
local
scheduler,
it's
gonna
be
the
same
version
is
the
local
API
server.
So
even
if
another
API
server
that
is
part
of
a
distributed
control
plane
is
an
older
version
where
I'm
going
to
be
talking
out
API
server.
So
we're
not
going
to
be
out
of
compatibility
by
trying
to
talk
to
any
passer,
that's
older
than
the
local
one.
Exactly.
E
A
A
As
long
as
you
have
a
way
to
force
them
to
only
talk
to
API
servers
that
have
already
been
upgraded
right
and
so
in
the
cuvette
admin
case,
you're
forcing
that
by
using
localhost
I
could
imagine
in
other
ways
you
can
force
that
also,
but
I
think
a
easy
way
to
think
about.
It
is
by
forcing
it
using
localhost,
so
I
think
I
haven't
read
through
all
the
comments
on
the
PR,
because
there
were
so
many
I
just
read
to
the
actual
text
that
Jordan
had
written.
But
it
sounds
like
there's
an
outstanding
comments.
C
George
came
to
the
channel
and
asks
as
basically
aureole
is
your
Wako.
Apis
are
talking
to
external
controller
managers.
Sister
Veda
and
I
said
that
we
don't
support
this
topology
at
all.
We
basically
supported
the
topologies
I
said
earlier,
and
we
I'm
not
sure
how
are
we
going
to
handle
this
into
the
into
his
new
PR,
because
we
cube
a
DM.
We
think
that
what
we
are
doing
is
should
be
the
canonical
way,
the
most
basic
way
of
doing
it,
but
he
is
proposing
something
that
is
slightly
more
complicated,
at
least
in
my
opinion.
Well,.
A
It's
it
depends
on
how
you
think
about
it
right,
because
if
you
have,
you
know,
higher-level
tooling,
like
cups
or
OpenShift
or
something
then
I
think
the
other
way
is
actually
probably
a
simpler
way
to
think
about
it
in
terms
of
components.
Q
right,
where,
if
you
can
say
I,
can
guarantee
that
all
my
API
servers
are
upgraded
before
I.
A
Do
anything
else,
then
that's
a
simpler
model
for
the
people,
maintaining
the
API
server
because
and
the
controllers,
because
now
they
can
ASSU
that
invariance
over
time
right,
I
think
from
the
cube
ATM
perspective,
because
it
is
sort
of
locally
focused
on
on
the
machine
that
it's
running
on
and
doesn't
have
visibility
into
the
other
parts
of
the
H,
a
control
plane.
It
becomes
very
difficult
to
orchestrate
the
upgrade
in
that
order
and
it
becomes
easier
to
think
about
it
in
terms
of
doing
like
these
stacks
of
one
machine
at
a
time.
A
A
C
So
the
the
Keefe's
great
folks
were
great
created.
The
survey
that
they
wanted
to
expose
to
everyone.
I
wanted
to
ask
you
Robert
look
historically,
is
copper.
It
is
had
copper,
it
is
had
a
some
sort
of
channel
for
surveys
where
basically,
people
can
okay.
This
is
an
unofficial
survey.
Now,
if
I
want
to
submit
my
own
survey
or
like
a
su
project,
if
they
want
to
submit,
should
we
talk
to
country
backs
or
easier
channel
for
this,
like?
How
was
it
done
in
the
past
as.
A
Far
as
I
know,
all
the
surveys
have
come
through
contributes
so
I.
Think
going
through
then
makes
a
lot
of
sense.
I,
don't
think
individual
SIG's
have
sort
of
spearheaded
their
own
surveys
and
I.
Think
having
it
flow
through.
A
single
place
is
probably
better
for
end
users
because
they
don't
get
bombarded
by
a
whole
bunch
of
surveys
like
if
you
know
five
SIG's
want
to
send
out
a
survey
and
the
113
really
cycle.
Maybe
control
X
can
consolidate
those
into
a
single
survey
right
and
they
can
become
through
the
the
survey
day.
C
A
I
think
it's
probably
useful
for
us
to
try
and
bundle
up
the
multiple
set
of
questions
we
want,
even
if
we
have
them
started
off
in
separate,
separate
surveys
and
send
them
to
contrived
acts
and
say,
like
hey,
here's
a
bunch
of
questions
who
want
to
ask
users:
can
you
help
us?
You
know,
find
the
users
get
the
survey
sent
out
consolidate
them.
If
that's
the
right
way
to
do
it.
C
A
Da
wall,
I
hope,
I'm
pronouncing
your
name
correctly
posted
and
chat
about
being
an
organizer
for
the
LTS
working
group.
But
apparently
microphone
is
not
working.
So
there's
a
link
to
the
Google
group,
which
was
posted
in
chat
I'll.
Also,
stick
it
in
here
into
our
meeting
notes,
please,
if
you're
interested
go
ahead
and
join
that
mailing
list
and
they're
also
applying
to
make
announcements
that
very
sick.
So
lumira,
thankfully,
did
that
for
us
today
and
and
try
to
help
encourage
participation
there.