►
From YouTube: Kubernetes SIG Cluster Lifecycle 20171031
Description
Meeting Notes: https://docs.google.com/document/d/17J496IR2tXKw7k97fxwz2KUWOf9rpBD3pIEsmDiJQSw/edit#heading=h.jjllw2gnm0ai
Highlights:
- 1.9 feature freeze
- 1.10 planning
- doc update
- cluster api update
A
Hello
and
welcome
to
the
Halloween
edition
of
the
cig
cluster
lifecycle
meeting
today
is
the
31st
of
October
2017
Rene
started
today
by
talking
about
1.9
features.
So
last
Friday
I
first
mention
this
last
week.
Last
Friday
was
the
feature
freeze
deadline
for
1.9,
my
I
pinged
Lucas
over
slack,
and
we
went
through
the
feature
list
and
tried
to
kick
things
out
of
the
1.9
milestone
that
shouldn't
be
there
and
pull
stuff
into
the
1.9
milestone
that
maybe
it
was
still
marked
as
1.8
but
needed
to
be
addressed
again
during
this
release.
A
A
A
A
A
And
while
people
are
pulling
that
up,
I
will
just
mention
that
this
is
a
short
release
cycle
due
to
the
large
number
of
holidays.
During
this
part
here
and
so
code.
Complete
is
scheduled
pretty
soon
it's
less
than
4
weeks
away
on
November,
22nd,
so
yeah
so
I
think
you
know
if
you're
working
on
something
we're
trying
to
shoot
to
get
it
wrapped
up
pretty
quickly
for
the
1.9.
B
A
B
I
addressed
all
the
comments
in
the
original
PR
there's
some
there's
some
inter
inner
stuff
I
need
to
deal
with
with
the
coup
blitz
because
of
its
kind
of
difficult
to
follow
how
it
actually
does
its
updates.
So
I
need
a
little
bit
of
guidance
from
you
jus
there.
Outside
of
that,
the
other
pieces
are
all
in
place.
A
A
C
Architecture
for
the
win:
no,
actually
this
is
them.
This
is
an
attempt
to
reboot
the
the
PM
process,
essentially
that
the
features
repo
is
feels
like
a
deprecated
clunky
thing
that
doesn't
really
service,
and
so
this
is
an
essentially
an
attempt
to
try
and
empower
SIG's
to
do
their
best
work
by
taking
the
burden
of
the
project
and
other
types
of
management
off
of
their
plate
and
help
them
with
a
facilitation
role.
C
So
it's
basically
instead
of
trying
to
have
somebody
in
from
the
sig
try
and
be
on
board
with
everything
sig
p.m.
is
doing
it's
like
hey.
Let's
give
somebody
to
the
safe
from
say
p.m.
it's
not
revolutionary,
but
it's
something
that
needs
to
be
done,
and
so
consequently
sakes
own
their
own
feature
backlogs,
and
there
isn't
a
centralized
point
of
failure.
C
You
guys
certainly
got
a
handle
on
what
you're
doing
so
in
that
spirit,
what
I
want
to
do
is-
and
I
will
probably
volunteer
to
do
this
myself
for
1:10
I
would
love
to
facilitate
a
planning
session
with
you
all.
So
basically,
I
can
do
whatever
serves
the
the
sig
best
in
terms
of
organizing
a
document
or
or
helping
prioritize.
What
you
want
to
work
on
writing
up
the
you
know
an
issue
in
the
SiC
cluster
lifecycle
domain.
So
we
we
have
a
tracking
issue
for
where
you
come
and
deliver
in
110.
C
B
It
be
possible
to
pilot
an
idea
of
potentially
using
a
kubernetes
project,
because
a
lot
of
our
stuff
will
span
components
and
repos
and
everything
else,
but
they're
all
in
the
kubernetes
proper
domain
and
instead
of
us
trying
to
create
yet
another
features.
Repo
item
which
doesn't
get
maintained
very
well
in
tracked,
if
we
could
actually
assign
the
project
as
part
of
the
issues
and
PRS
and
use
the
process
that
exists
there.
I
don't
know
if
this
will
work
for
everybody
else,
but
I'm
just
trying
to
throw
out,
gets.
C
It
in
fact,
as
far
as
I'm
concerned
after
1/9
I'm
I'm
pushing
hard
on
this,
that
the
features
repo
will
be
completely
deprecated.
So
those
those
things
should
be
tracked
in,
however,
is
best
for
the
sake.
The
thing
that
we
we
want
to
make
sure
is
that,
if
there's
deliverables
for
the
release
like
release,
notes
or
documentation
or
whatnot
that
you,
you
have
some
way
to
track
that
and
and
I'm
I
would
love
to
experiment
with
works
best.
C
And
that's
what
that's
a
great
that's
a
great,
a
great
suggestion
and
I
actually
use
that
myself
for
sig
release
for
the
release
process
last
time
and
Anthony
is,
is
doing
that
for
this
release
as
well.
So
we're
moving
toward
a
much
more
github
centric
thing
and
not
having
duplication
elsewhere.
Timbi.
D
About
project
projects
in
on
a
github,
their
only
problem
that
we
have
they're
not
visible
to
anybody
else,
a
set
of
cabinets
organization,
so
we
it's
soon
unlikely
for
us
to
use
the
project
wide
projects
on
github.
We
may
try
to
use
them
for
some
repo,
like
for
the
features
repo
or
for
the
community
repo
for
some
extra
repos,
but
not
not
not
the
organization-wide
yeah.
C
B
A
That's
largely
the
same
one
thing
we're
doing
at
the
features
repo,
because
all
of
our
individual
tracking
issues
for
cube
admin
are
already
outside
of
the
main
repo.
So
unless
we
have
an
org
level
project,
things
like
you,
bad
men
like
cluster
API
is
outside
the
main
route
from
the
start.
So,
like
a
lot
of
things
are
working
on
are
not
necessarily
in
the
main
repo
and
they
have
dependencies
there.
A
So
like
the
code,
that
Tim
is
writing
for
the
bootstrap
checkpointing
m-19
as
a
good
example,
that's
in
the
main
repo,
so
you
can
create
an
issue
in
the
main
repo
saying
we
want
good
job
check
point
but
when
you
say
like
cube,
M
cube,
admins
self
self,
hosting
your
cube,
abdun
AJ
right.
Oh,
that's!
All
those
issues
and
design,
Docs
and
so
forth
are
going
to
the
cube
admin
repo.
A
So
you
wouldn't
be
able
to
have
sort
of
cross
tracking
against
those
unless
the
prod
the
project
was
crossed
across
the
whole
world,
and
it's
gonna
get
more
complicated
as
we
shake
out
sort
of
the
incubator
process,
because
you
ready
Thank,
You
Bader.
Is
that
even
a
different
org?
And
if
we
decide
to
stick,
you
know
things
outside
of
the
main
karate
zorg
tend
to
get
tricky.
C
A
One
other
thing
to
consider
is
at
some
point:
we
might
want
to
start
divorcing
release
timelines.
So
right
now
cube
admin
gets
released
with
the
Cooper
days.
Release
right
and
that's
rain
I
mean
it
code
is
tightly
coupled
it's
in
the
main
repo,
that's
sort
of
the
only
way
to
do
it
as
we
move
it
out.
We
might
want
to
consider
releasing
it
a
different
cadence
where
we
can
release
it
whenever
we
want
and
like
release.
A
C
C
I
think
that
this
is
a
step
in
that
direction
is
certainly
to
have
the
SIG's
own,
their
own
quote/unquote,
feature,
backlog
and
and
I
do
want
to
stop
thinking
of
things
as
quote-unquote
features,
because
they're,
really
not
it's
really
enhancements
into
the
kubernetes
ecosystem.
So
Kouga
ATM
is
a
is
a
major
crown
jewel
of
the
the
ecosystem.
So
it's
like
saying
saying
something:
additional
enhancement
to
jakku
medium
as
a
features
and
may
or
may
not
be
accurate.
So.
A
In
terms
of
the
the
planning
session
in
the
past,
we've
done
for
the
next
round
of
planning
pretty
pretty
late
in
the
release
cycle.
If
you
want
to
pull
that
earlier,
as
if,
like
alot
cool,
if
we
think
a
lot
of
people
might
be
out
in
December,
it
seems
like
the
most
likely
dates
for
doing
it
are
the
week
of
November
13th,
which
is
a
week
before
Thanksgiving
or
the
week
of
November
27th,
which
is
the
week
after
Thanksgiving
and
a
week
before
coupon.
A
C
Yeah
I'd
imagined
that
it
would
happen
somewhere
in
the
code
freeze
realm
just
because
then
in
theory,
it's
you've
got
a
little
more
bandwidth
to
devote
to
project
type
stuff.
So
but
that's
is
sick
organizers.
Why
don't
you
decide
works
for
you
and
I'll
just
be
your
elf.
I
will
serve.
However,
I
needs
you
to
make
that
happen.
A
Okay,
I'm,
not
sure
all
of
the
stakeholders
are
here
today
and
I'm,
not
sure
the
best
way
to
to
kind
of
that
input.
I
guess
we
could
set
up
like
a
like
a
quick
like
Google
forum
or
something
to
have
people
vote
on
which,
which
week
they
think
is
better
I
would
propose.
We
do
it
during
this
meeting,
because
I
think
this
meeting
has
the
the
highest
attendance
level
of
any
of
our
Sigma
teams,
and
if
we
do
it,
one
off.
C
A
C
Have
that
issue
that
we're
basically
tracking
with
you
know,
could
be
blocking
I'm
lucky
and,
depending
on
how
it
went
I
would
love
to
see
that
created
again
for
1.9
just
so,
we
can
stay
on
the
same
page
about
what
the
status
of
it
is
without
having
to
necessarily
traverse
into
the
conveniently
Club.
If
that's
okay,.
A
I
mean
I
think
right
now.
That
issue
would
just
be
a
placeholder,
because
we
wouldn't
know
what
to
put
in
it
yet
as
like
what
what
we
think
is
blocking
right,
yeah
I
think
it
was
useful
last
time
because
Lucas
said
these
are
the
five
issues
in
the
other
repo
that
we
need
pointers
to
yeah.
So
once
we
know
what
those
those
are,
we
can
create
an
issue
yeah.
C
A
C
A
Can
give
a
quick
update
on
the
cluster
API?
We
had
another
breakout
meeting
last
week
where
we
spent
some
time
reviewing
the
proposals
for
both
the
the
Machine
object
and
also
the
the
sort
of
control
plane
at
the
top
level.
So
we
walked
through
those
little
bits
and
I
guess
another
PSA.
If
people
weren't
at
the
community
meeting
last
Thursday
this
this
Thursday
after
the
community
meeting,
there's
a
sig
cluster
ops
meeting
where
I'm
gonna
give
a
presentation
and
demo
of
whatever
we
have
so
far
for
the
cluster
API.
A
So
if
people
are
interested
in
joining
that,
the
goal
is
to
try
to
gather
sort
of
cluster
operators
and
get
some
feedback
from
them
in
terms
of
requirements
in
terms
of
what
they
think
would
be
boo
useful
for
the
API
to
support.
So
we
have
a
notion
based
on
our
experience
at
Google,
running
gke,
of
what
we
think
the
cluster
api
should
do.
A
B
A
A
A
B
A
A
All
right
that
was
a
good
point.
I
will
dial
back
in
at
ten
o'clock
this
morning
and
see
if
people
show
up
for
the
ten
o'clock
version
of
this
meeting
and
point
them
at
the
recording
and
I
won't
record
that
meeting
we're
gonna
do
this
again,
but
just
to
let
people
know
that
the
videos
already
happened.