►
From YouTube: SIG Cluster Lifecycle 2021-01-12
A
A
A
We
should
have
the
sig
name,
always
sequence,
life
cycle,
the
name
of
the
meeting,
for
instance,
I
don't
know
kubernetes
office
hours
and
after
that,
it's
the
year
month
and
day,
I'm
not
going
to
show
the
playlist
right
now,
but
it's
all
over
the
place,
pretty
much
everybody
is
doing
their
own
thing,
since
we
don't
have
that
much
presence.
Today,
if
you
participate
in
some
of
our
sub
projects,
we
can
at
least
you
can
at
least
notify
your
su
project
in
the
appropriate
meeting
and
say
hey.
A
B
A
A
A
A
Okay,
next
item
is
kubecon
eu
2021.
You
may
have
seen
the
email
already
it
feels
like
you,
one
keep
going
after
the
other.
Basically,
the
submissions
for
the
maintenance
track
is
due
to
february
the
7th
again.
The
procedure
is
similar.
We
have
to
fill
a
form
and
for
history
we
in
the
the
cube
cons
from
last
year
we
had
the
sig
intro
and
a
couple
of
project
highlights
which
in
separate
sessions
last
time
we
highlighted
costa,
api
and
image
builder
I
brought
this
is,
I
think,
tim
wanted
to
discuss
this
topic.
C
C
More
that
I
think
we've
talked
in
the
past
about
how
the
the
talks
that
the
virtual
coupons
are
very
sort
of
broadcast
right.
You
don't
get
a
lot
of
feedback
from
the
audience.
The
talks
are
pre-recorded.
The
question
medium
is
not
great
for
high
bandwidth,
like
it's
able
for
the
audience
to
participate,
and
I
think
you
know
like
certainly
the
sub
projects
I'm
most
involved
in,
like
I
think
most
of
the
value
comes
from
interaction
with
the
audience
and
sort
of
a
bidirectional
thing,
and
I
think
we've
talked
about
like.
C
Is
there
going
to
be
more
of
a
like
open
forum
type
platform?
In
addition,
I
guess
to
the
talks
right
to
me.
The
the
maintainer
track
sessions
don't
have
as
much
value
the
the
maintenance
tracks,
just
as
we've
been
doing
them
virtually
don't
have
as
much
value
as
we
got
in
person.
We
were
able
to
have
more
of
a
discussion.
A
A
B
Yeah,
I
think
this
goes
back
a
little
bit
to
kind
of
what
justin
mentioned
as
well
and
in
the
past
you
know
they
gave
us
a
lot
of
leeway
to
have
a
lot
of
maintainer
track
sessions
for
the
various
sub
projects
that
the
group
that
this
group
has
and
they've
recently
kind
of
tightened
that
up
a
bit
and
and
brought
in
more
restrictions.
And
it's
created
this
kind
of
weird
tension
about
what
projects
do
we
highlight?
What
projects
do
we
not
highlight
during
these
sessions
and
that
led
to
some
vague
discussions
about?
A
B
A
C
Actually,
I
think
I
mean
we
have
the
intro
sessions
uploaded
right,
they're
there
for
anyone,
anybody
wants
a
an
intro
to
cluster
life
cycle
can
go
and
watch
those
videos.
I
don't
think
a
ton
has
changed
in
terms
of
our
mission
or
the
projects
that
we
have.
Maybe
what
we
could
do,
therefore,
is
say
like
look.
If
you
want
an
intro
go
watch
a
video
on
youtube
from
like
last
six
months,
and
then
we
can
devote
a
couple
of
minutes
to
each
project
to
just
like
describe
what
they
did.
That
is
new.
C
C
A
A
C
I
mean
I'm
happy
to
collate
to
like
chase
people.
I
I'm
not
going
to
chase
them
too
much.
In
other
words,
if
they
don't
send
an
update,
they
won't
have
a
slot,
but
I'm
happy
to
do
that
and
either
you
know
what
what
you
and
I
did
live
in
mirror
we
uploaded
our
recordings.
I
think
worked
well,
but
we
otherwise
I'm.
I
can
just
like
read
out
what
someone
wrote
if
they
don't
want
to
make
a
recording.
A
C
And
the
other
problem
is
like
in
the
last
coup
con
free
kubecon,
like
I
I
didn't
know
something
like
we
had
one
like
in-depth
question
about
topic.
I
didn't
know
anything
about
and
like
it's
difficult
because
then
we're
like
effectively
opening
ourselves
up
to
like
be
experts
on
all
these
things.
I
guess
we
just
have
to
try
to
attack
people
attending
in
chat
in
slackchat
and
see
what
we
can
cover.
E
B
C
F
A
It's
a
vag
jason
explained
earlier.
We
were
back
and
forth
with
the
cncf
deciding
how
many
sue
projects
we
can
send.
Ultimately,
I
think
they
nowadays
they,
I
think
they
are
wars
to
like,
like
it
says
here
that
the
war
was
to
send
one
for
each
project,
but
like
do
we
want
to
communicate
all
that
or
like
how
should
we
proceed?
I
can
just
send
the
email
to
the
mailing
list
and
allow
our
subprojects
to
send
transparently
without
the
knowledge
of
the
the
sick.
F
B
C
A
I
think
we
should
just
interpret
the
wording
here
as
all
the
sub
projects
are
about
to
send
if
they
wish
we
are
going
to.
I
am
going
to
send
an
email
to
the
mailing
list
and
pretty
much
delegate
to
subprojects
to
send
if
they
want
to-
and
you
know
the
six
chairs
and
leader
should
not
care
about
who
is
sending
eventually,
we
will
see
who
has
sent.
A
A
F
E
F
I
guess
so.
I
saw
your
email
in
the
mailing
list
and
that
that
basically
the
scalability
test
kubernetes
is
migrated
to
kubernetes.
I
remember
our
own
discussion
I
beg
paired
on,
but
but
today
I
didn't
manage
to
to
grow
through
the
the
thread
and
go
back
to
the
decision
why
we
decided
to
propose
kubernetes.
F
But
my
consideration
is
that,
should
we
possibly
try
to
move
them
to
cluster
api
instead
of
kubernetes,
given
especially
the
work
that
was
done
recently
on
the
kuber
test
provider
and
the
kubernetes
provider
for
cluster
api?
So
it
I.
I
don't,
have
the
full
context,
because
I
didn't
have
time,
but
I
think
that
we
should
carefully
consider
because
this
is
a
big
opportunity
for
cluster
api
being
used
by
the
scalability
test.
A
A
It
does
all
the
things
the
the
problem
with
the
gcp
provider.
So,
first
of
all,
six
scalability
once
you
want
to
use
gce
for
scalability
testing,
which
means
that
we
have
to
use
the
gcp
provider,
which
is
unmaintained
mostly
right,
it's
a
great
opportunity
for
constant
api,
but
we
have
to
convince
safe,
scalability
somebody
else
to
start
contributing
to
the
gcp
provider.
A
C
With
the
resent
I
mean
yeah,
I
was
gonna
say
like
I
think
it's
it's
often
hard
for
googlers
to
justify.
You
know
what
they
work
on,
if
we're
not
directly
using
it
type
thing,
and
I
think
I'd
rather,
that
we
like
had
the
googlers
work
on
cluster
api
provider
gcp,
which
is
generally
valuable,
then
on
something
like
some
other
script
right
like
we're,
basically
creating
another
another
deployer
like
either
way.
They're
gonna
have
to
maintain
something.
C
Why
don't
they
maintain
the
thing
that
people
want
to
use
and
I've
actually
started
sending
some
prs
gradually
to
classify
the
upper
writer
gcp
and
from
some
of
my
stuff,
and
thank
you
for
the
review.
So
people
did
that
and
yeah.
I
think
it's
in
it
might
not
be
supported,
but
it's
in
it's
in
reasonable
shape
and
it's
close
close
enough
that
we
can
probably
get
it
there
wherever
there
is
I'd
I'd,
be
in
favor
of
effectively
saying
look
we're
not
going
to
build
another
deployer
or
another
cube
up.
B
G
I
get
it
on
hi,
so
we
don't
want.
We
don't
have
to
ensure
that
every
ci
job
can
be
migrated
right
away
right
like
so
that
that's
number
one.
So
I
would
focus
on
what
do
we
have
in
pre-summit?
What
do
we
have
say
in
release
blocking
and
scalability?
Those
would
be
like
where
I
would
basically
look
first
for
guidance.
G
G
A
F
B
Yeah,
so
the
other
concern
that
I
would
have
is
is:
should
we
get
feedback
from
the
previous
couple
of
release
teams
to
feel
about?
You
know
how
they
felt
about
the
signal
that
we're
providing
out
of
the
current
conformance
test
and
if
there
are
issues
that
they
potentially
have
with
those
being
moved
to
release
blocking
as
opposed
to
release
informing
and
then
that
would
help
with
making
the
case
for
moving
additional
jobs
over
there
and
the
work
and
support
required.
B
You
know,
there's
there's
some
level
of
effort
that
we
can
do
as
a
say
to
help
move
some
of
these
tests,
but
at
the
end
of
the
day,
we're
not
the
ones
relying
them
relying
on
them
for
the
work
that
we're
doing
and
we're
not
the
ones
necessarily
supporting
the
underlying
fixes
for
those
tests.
So
we
we
also
do
need
to
make
a
case
to
the
folks
that
are,
you
know,
on
the
supporting
end
of
this.
G
A
A
And
that
is
one
of
the
reasons
we
haven't
promoted
the
keyboardim
jobs
to
release
blocking,
because
we
had
a
strange
failure
where
docker
is
not
writing
properly.
Some
of
the
settings
on
the
nodes
or
it's
flaky,
and
this
alone
was
a
novel
subject
to
decline.
The
request
to
promote
them
to
blocking
it's
just
a
random
flick
that
we
cannot
explain
in
the
currently
in
the
gcp
job.
A
B
Yeah,
I
think
the
difficulty
there
is
is
that,
right
now,
it's
a
whole
bunch
of
folks
that
are
generally
over
subscribed
with
a
lot
of
other
work
like
right
now.
It's
I
think
myself
justin,
vince
and
recently
carlos
has
also
become
a
maintainer,
and
it's
just
a
matter
of
folks
are
currently
spread
too
thin.
If
we
had
somebody
who
was
more
had
more
time
dedicated
to
the
project,
it
would
be
a
lot
easier.
I
think.
A
A
A
Okay,
we
are,
we
are
like
writing,
cube,
adm,
beta
and
corporate
beta
configuration
inside
of
this,
so
it
will
require
version
branching
eventually-
and
this
is
something
that
we
try
to
remove
from
kubernetes
anywhere,
but
it
was
unavoidable
and
all
the
projects
you
know
kind
mini
cube.
Everybody
is
doing
the
version
branching
because
of
changes
in
the
api.
A
We
are
still
discussing
this,
but
if
you
have
comments,
please
chime
in
at
this
point,
I'm
in
a
position
where
I'm
going
to
do
whatever
they
want.
If
they
say.
Okay,
we
are
going
to
drop
this
idea.
I
will
happily
close
the
peers.
If
somebody
says
okay,
we
shouldn't
use
this.
We
should
use
cap
g
instead
again
I
I
will
present
my
argument
there
that
we
shouldn't
propose
something
that
is
not
maintained,
and
I
guess
that
that
is
the
somebody
that
I
have
for.
A
A
A
A
A
G
A
Scalability
testing,
due
to
some
complexities
around
how
you
configure
nodes,
but
I
I'm
not
sure
cuba
dm
is
exactly
not
applicable,
because
I
think
kubernetes
will
still
be
able
to
do
some
of
these
things
that
cubop
is
doing
but
yeah.
It's
again.
It's
everything
is
experimental
here.
At
this
point,.
A
All
right,
let's
move
to
the
subproject
updates
for
cube
idm.
We
have
a
planning
session
for
1
21
that
is
going
to
be
on
wednesday.
The
20th
of
january.
This
is
during
the
office.
Hours
for
brits
was
something
that
I
realized
after
we
decided
on
the
date
is
that
I
think
the
deadline
for
caps
is
the
end
of
january,
which
leaves
whoever
is
going
to
want
to
write
some
caps,
something
like
10
days
to
prepare
the
cap
after
we
complete
the
planning
yeah,
it's
a
bit
of
a
limitation
that
we
imposed.
F
A
Potentially,
yes,
let's
see
we
also
we
are
discussing,
which
is
related
to
the
cape
discussion
is
we
are
discussing
the
cube
adm
operator
me
and
fabrizio
had
some
meetings
already
about
this.
We
are
going
to
continue
the
discussions
about
in
the
kubernetes
office
hours.
I
guess-
and
also
we
are
discussing
the
topic
of
exposing
parts
parts
of
kubernetes
library,
which
is,
I
think
the
operator
is
going
to
depend
on
that
and
also
costa
api
too.
A
We
I
I
mean,
for
we
are
also
going
to
deprecate
and
remove
some
alpha
features.
I
think
some
of
the
pr's
are
already
ready
for
that.
We
graduated
some
alpha
commands
to
ga
which
pretty
much
moves
them
in
a
top
level
command.
For
instance,
we
had
cubed
mouthful
certs,
which
is
now
cubed
inserts
and
the
cubed
m
alpha
come
out
will
be
empty
after
121,
but
we
are
still
living
it,
leaving
it
for
the
future.
A
H
H
We
had
we
added
a
bunch
of
we
upgraded
to
like
container
dv2
and
case
120,
and
a
bunch
of
other
stuff
multi-node
is
ga
now
and
so
is
scheduled
stop.
So
if
you
want
to
clean
up
your
mini
cluster
in
the
future,
if
you're
like
in
an
embedded
system,
then
you
can
do
that
so,
like
like,
like
caps,
this
release
coming
up
is
going
to
be
a
lot
smaller.
It
should
be
either
next
week
or
the
last
week
of
january.
A
So
it
takes
something
related
to
container
d.
We
I
already
started
discussing
how
users
can
migrate
to
from
docker
to
container
the
on
the
miracle
mini
cube
sides.
I
guess
you
you
will
not
have
that
much
problem,
but
if
somebody
is
persisting
a
mini,
cube
question:
are
you
looking
at
giving
them
a
guide
how
to
migrate?
Somehow.
H
We're
so
right
now
the
big
issue
is
that
we
default
to
the
docker
runtime,
because
a
lot
of
users
use
the
internal
daemon
for
building
images
and
stuff.
So
as
long
as
we
when
we
default,
when
we
move
over
defaulting
to
container
d,
we
just
need
to
give
them
a
way
to
do
that.
So
we're
going
to
like
probably
write
a
shim
to
to
imitate
building
docker
images
and
container
dating,
and
then
it
should
be
transparent
to
them.
H
A
Yeah,
I
saw
a
compiler
bug
for
arm
the
other
day.
It
was
started
in
the
kubernetes
kubernetes
issue
tracker.
Somebody
found
a
book
on
armed,
32-bit,
okay
and
I
eventually
described
it
to
a
bug.
There
is
also
I
386
and
finally
on
iamd64,
so
it
was
pretty
much
a
full-time
compiler
backing
goal,
but
it
originated
from
the
arm
community.
A
I
I
No,
I
mean
you
know
it
would
be
great
to
you
know.
I
guess
I
was
always
looking
for
for
more
contributors.
There
are,
you
know,
a
handful.
We
have
prs
now
and
again
from
from
people
that
kind
of
outside,
I
guess
the
community
and
yeah.
If
you
know,
I
guess,
that's
yeah,
I'm
always
looking
for
for
more
contributors.
I
Yeah
for
something
like
for
something
like
justin
was,
I
think,
proposing
or
I
yeah
I'd
be
happy
to
do
that.
I
I'm
yeah,
I'm
not.
I'm
not
sure
that
I
like,
if
there's
one
sort
of
big
chunk,
that
you
know
that
that's
supposed
to
go
to
one
project,
then
you
know
something
like
something
like
cluster
api
is
probably
the
I
I
would
say
the
maybe
the
better
candidate
but
yeah.
A
A
Basically
we're
going
to
let
all
the
super
projects
submit
the
session
it
and
if
the
cnc
I
feel
like
we
have
way
too
many
projects,
they
can
block
us
but
yeah.
I
think
if
you,
if
you
think
that
it's
beneficial,
you
should
check
this
email
from
the
cncf
and
just
submit
the
session,
or
maybe
you
you
can
also
ask
some
of
your
contributors
to
do
it
instead
of
you.
If
you
want
to.