►
From YouTube: SIG Cluster Lifecycle - kubeadm office hours 2021-09-15
A
Hello,
this
is
the
kubernetes
office
hours
today
is
the
15th
of
september
2021..
It's
only
me
for
britsville
here,
but
we
have
an
important
topic
to
discuss
so
fabrizio.
Take
it
away.
B
Yeah,
thank
you
so
so
the
the
topic
is
about
graduating
our
types
to
v1.
So
let
me
see
this
is
a
discussion
that
follows
up
a
similar
discussion
that
happened
in
in
the
capit
community.
B
The
capit
community
recently
agreed
that
we
should
move
cluster
api
types
and
graduating
from
alpha
to
beta
in
in
this
case,
the
discussion
has
been
driven
by
a
strong
community.
Ask
based
on
on
two
on
two
facts.
The
the
first
one
is
that
the
project,
in
this
case
a
copy,
is
already
providing
guarantees
higher
than
alpha.
So
we
are
already
providing
conversion
book.
We
provide
documentation,
test
coverage.
B
And
also
we,
we
maintains
our
apis
for
a
long
time.
Also,
cluster
api
is
already
used
in
production
by
many
companies.
So
in
fact,
we
are
being
alpha
is
just
a
label,
but
the
reality
is
that
we
are
more
than
than
alpha
and
thinking
about
these
basically
the
same
the
same
things
could
apply
to
kubernetes,
and
this
is
even
more
stronger
because
kubern
could
mean
is
used
in
all
in
almost
all
class
api
installation.
B
So
I
think
that
as
a
as
a
project,
we
should
also
ask
ourselves:
okay.
Is
it
the
time
to
to
declare
our
api,
sv1
or
ga
like
we
already
did
for
the
right?
Almost
all
the
the
entire
rest
of
the
code
base
and
yeah
that
that's
the
main
point
of
discussion,
and
then
I
can
comment
also
soon
on
what
I
think
that
should
be
next
steps.
A
Yes,
I
generally
agree
that
we
should
have
this
periodic
discussion
whether
the
api
maturity
is
sufficient
to
go
to
v1.
At
this
point,
the
kuberedium
api
has
been
beaten
for
a
long
time.
It
was
in
alpha
for
a
long
time
before
that
so
yeah.
I
agree
that
we
should
have
the
discussion
and
I
I
have
some
general
comments
about
the
api
maturity
discussion
in
copy.
So
basically,
sometimes
you
you
face
customers
and
users
wanting
to
push
things
forward.
A
This
is
what
I'm
seeing
in
quasar
api
on
the
cubed
m
side.
I
have
not
seen
that
much
demand.
Nobody
is
complaining
about
things
moving
to
v1,
but
at
the
same
time,
I'm
probably
thinking
that
people
just
don't
mention
it,
but
they
really
want
it
so
yeah.
I
think
we
should
definitely
have
this
discussion
and
but
I'm
hoping
that
more
people
participate.
A
We
can
maybe
have
more
of
our
su
projects
like
cube
spray,
even
mini
cube,
coaster,
api,
all
of
them
to
join
and
make
comments,
because
we
have
an
issue
tracker
for
cuba
dm,
but
I'm
assuming
that
most
of
them,
maybe
are
not
even
providing
feedback
because
they
don't
know.
When
we
are
going
to
release,
we
just
released
a
new
api,
they
say:
hey
we're
going
to
consume
it,
but
nobody
is
really.
A
We
are
not
getting
sufficient
participation
from
all
those
consumers
of
cubadm,
even
kind,
which
is
a
sick
testing
project,
so
yeah.
I
think
it
makes
sense
to
announce
this
v1
discussion
to
everybody
see
who
joins.
B
That's
definitely
a
great
point
so
could
mean
now
is
kind
of
suffering,
because
it
is
a
a
layer
in,
let
me
say,
an
internal
layer
of
other
projects,
and
so
we
don't
get
so
much
direct
user
feedback,
and
so
it
is
a
good
point
to
ask
to
those
project.
I
will
take
care
of
asking
in
the
cafe
meeting
that
also
in
the
sikh
cluster
life
cycle
meeting.
B
We
we
have
to
ask
the
other
project
please
well.
What
is
your
opinion
about
this,
and
I
think
that
the
problem,
let
me
say,
goes
into.
B
The
other
direction
is
that,
are
we
happy
with
our
current
api
or
are
there
some
features
that
we
think
min
are
missing,
or
do
we
think
that
some
something
is
not
yet
modeled
in
a
proper
way
and
and
stuff
like
that?
So
it
is
a
good,
quick
discussion.
It
is,
it
is
a
mix
between
being
ready
between,
let
me
say,
taking
a
leap
and
and
decided
okay.
This
is
the
moment,
so
it
is
a
trade-off.
As
you
are
talking,
I
fully
agree.
B
Keeping
them
showing
to
to
the
entire
community,
okay,
we're
moving
forward.
We
we
are
production,
really,
it
is
a
signal,
but
this
is
also
important,
and
I,
like
the
copy
discussion
at
the
end,
showed
up
that
the
community
are
happy
and
they
want
to
use
it
even
more
and
it
signs
some
enterprise,
the
alpha
or
beta
laborer
kind
of
a
blocker,
and
the
other
point
is
that
being
v1
or
ga
is
not
the
end
of
the
story.
B
So
in
capi,
for
instance,
we
are
discussing
a
lot
how
to
con
how
to
not
block
the
project.
Let
me
say:
grow
evolution
future
resolution,
even
if
we
graduate
things
so.
B
B
Second,
is
that
we
should
go
over
something
similar
to
what
we
are
doing.
We
should
have
a
focused,
baccal,
baccalaureate
review
that
goes
through
the
api.
All
the
api
changes
stuff
that
we
have
and
we
have
to
figure
out
what
we
really
need,
what
we
consider
blocker
for
ga,
because
yeah,
maybe
the
change,
could
apply
even
after
we,
we
are
being
v1.
So
the
important
thing
is
to
figure
out
what
are
the
blocking
one
and
the
last.
B
Yeah
this
is
the
let
me
say
my
first
point:
let's
have
these
api
review
focus
back
on
the
grooming
and
then
identify
if
there
are
things
that
we
consider
we
consider
blocking
for
graduating,
and
that's
mean
that
this
will
imply
the
the
end
of
discussion
could
be
okay.
We
have
something
to
do
a
new
v1
beta
release
or,
let's
do
the
the
jump.
A
A
That's
potentially,
this
topic
is
going
to
make
some
of
the
features
that
we
decide
to
not
include
in
the
v1
difficult
to
add
later,
because
we
can
add
it
to
the
v1
and
that's
not
a
breaking
change
to
the
users,
but
if
we
follow
the
existing
practice
of
kubaydm
and
other
v2,
this
means
that
the
potential
consumers
of
the
api
have
to
now
consume
two
apis.
A
The
supporting
the
old
api
and
also
supporting
the
new
api
with
the
new
features
and
that's
a
complexity,
core
kubernetes
is
avoiding
you
know.
That's
that's
the
reason
they
have
the
bot
spec
that
is,
has
been
v1
for
a
very
long
time.
At
the
same
time,
core
kubernetes
has
some
apis
that
are
already
v2.
A
A
I
think
they're
doing
a
pretty
good
job
and
that's
what
I've
seen
in
other
projects.
You
know
v1
is
not
the
end
of
the
day
and
sometimes
new
features
just
have
to
go
in
a
v2,
even
if
they
are
not
breaking
change.
A
So
it's
a
it's
we're
going
to
have
this
this.
For
me,
this
particular
decision
is
the
most
important
one.
I
don't
care.
What
is
what
is
a
a
small
blocker?
What
is
a
feature
that
we
can
omit?
But
if
we
omit
it
like
it's
important
for
me
to
know
where
it's
going
to
land,
it
is
going
to
be
this
iteration
of
v1.
B
There
are
yeah,
there
are
two
different
approaches.
These
and
one
is
being
strict.
One
onsen
api
is
out.
Basically,
it
is
frozen
and
everything
goes
to
the
next
release,
and
the
other
one
is
is
something
that
con
that
allows
not
not
non-breaking
change
on
an
existing
api
yeah.
That's
a
really
interesting
point.
I
think
that
I
I
don't
have
a
strong
opinion.
It
is.
It
is
really
a
matter
of
conventions,
so
I
can
see.
B
B
Kubernetes
is
acting
in
different
way.
I
think
that
we
have
to
pick
up.
I.
It
will
be
great
to
have
a
decision
at
sea
level
about
this
and
and
be
consistent
at
six
level.
Now
in
capi,
we
are
allowing
non-breaking
changes
in
the
within
the
same
api
in
kubernetes
mean
not,
so
I'm
not
really
worried
about
the.
What
will
be
the
end.
The
final
decision,
I'm
more
worried
about
not
being
consistent
at
the
signal.
A
A
I
think
that
that
is
going
to
be
my
preference,
but
if
people
see
it
as
a
big
consumption
blocker-
and
this
is
something
that
we
have
to
discuss
with
all
the
projects
that
use
cube
adm
as
well,
if
they
see
it
as
a
problem
like
maintaining
v1
and
v2
at
the
same
time,
for
example,
if
they
see
it
as
a
problem,
we
should
perhaps
use
v1,
and
that
is
going
to
be
the
version
where
we
add
new
features.
A
Until
we
want
breaking
change,
my
my
preference
again
is
going
to
be
for
all
the
quest
lifecycle
projects
to
follow
the
something
that
is,
I
think,
the
higher
sanity
level
approach,
which
is
to
always
iterate
the
version.
I
think
I
can
give
an
example.
If
you
ask
some
of
the
core
maintainers,
when
was
a
particular
field
added
to
this
prospect,
nobody
remembers
so
they
have
to
start
googling
searching
for
github
prs
and
things
like
that
and
there's
no
way
to
track
some
of
these
additions.
A
I
think
actually,
nowadays,
there's
a
way
with
with
attacks
over
the
basically
the
field
itself.
You
can
have
attack
saying
that,
okay,
this
is
1
23
when
it
was
added,
it
was
out
for
them,
but
it's
still
like
this
meta
meta,
compiler
stuff.
I
much
rather
have
something
that
is
concrete
api
that
is
set
in
stone
and
released
so
that
everybody
knows
a
change
work.
B
Yeah
that
that's
the
red
point
and
probably
the
real
answers
is
yeah
that
there
are
concerns
that
are,
let
me
say
up
to
the
maintainers,
but
probably
we
should
also
try
to
have
to
look
at
this
problem
from
a
use
from
a
consumer
point
of
view.
B
I
don't
have
the
the
answer
now
but
yeah.
I
agree
with
you.
It
is
part
of
this
discussion.
I
I
I
wanted
to
to
raise
the
point,
because
the
cappy
community
took
a
decision
and.
B
As
a
sig,
I
think
that
is
we
we
have
to
yeah
to
to
to
act
consistently,
and
so
I
broke
out
the
topic
here
and-
and
I
agree
with
you
let's
I
I
will
raise
the
point
in
copy
of
this
hour
in
the
next
sig
meeting,
and
then
we
send
out
an
email.
We
try
to
collect
some
feedback
opinion
and
we
ship
out
our
idea
about
what
this.
The
current
state
of
maturity
of
the
api
is
good
state
of
maturity
of
the
api.
A
All
right
sounds
good
by
the
way
the
whole
topic
around
api
increments.
We
can
discuss
in
the
next
sequence
life
cycle
meeting,
which
is
next
week.
We
can
talk
about
that
to
see
the
hopefully
justice
perspective
as
well.
A
I'm
hoping
that
many
cube
representatives
potentially
cube
spray.
People
will
join
as
well
so
that
maybe
we
can
agree
on
this
like
a
policy
but
but
again,
if
koster
api
is
not
happy
with
that
like.
How
do
we
deal
with
the
problem
if
everybody
agrees
on
a
policy,
but
one
of
the
projects
really
doesn't
like
this
and
it's
a
consumption
blocker
for
users
like?
Are
they
going
to
diverge
from
the
policy?
B
I
I
think
yeah
that
that's
a
good
point
and
yeah
more
sick.
Let
me
say
governance
discussion
that
kubernetes
mean
but
yeah
very,
very
briefly.
I
think
that
we
we
we
are
kind
of,
let
me
say,
depend
that
are
linked
or
to
the
main
kubernetes
api
guideline,
but
as
kubernetes
x
for
the
for
the
sig.
I
think
that
the
sig
should
act
for
the
sub
project,
so
this
is
a
recommendation.
This
is
the
best
practice,
and
this
is
something
that
makes
the
entire
ecosystem.
B
B
Let
me
say
it's
not
really
a
policy.
This
is
a
guideline
and
then
there
is
a
the
usual
moral
situation,
things
that
that
comes
but
from,
let
me
say,
seek
leadership
and
and
also
from
the
community
itself,
because
the
user
gets
confused,
that
they
things
behave
differently
in
different
projects.
A
Yeah
agree
this
we
were
discussing
potentially
having
the
topic
of
whether
a
v1
api
should
be
incremented
on
once
it's
out,
or
should
we
basically
recommend
for
our
su
projects
to
go
to
a
v2
and
consider
v1
more
of
something
that
is
set
in
stone
like
today,
kubernetes
is
doing,
but
kubernetes
is
a
bit
of
a
slow
flake.
It's
the
only
project
that
is
doing
that
at
the
same
time,
it's
something
that
is
giving
sanity
to
the
users
and
the
maintainers.
A
At
the
same
time,
the
introduction
of
a
new
api,
the
application
of
loyalty
api,
is
obviously
a
breaking
change
to
the
user.
You
have
to
deprecate
the
old
api.
The
new
api
comes
after
that
so,
but
it's
still
like
it
feels
like
that.
That
is
my
preference.
It's
just
that
with
fabricio
we
were
discussing
whether
we
should
write
some
sort
of
a
guideline
that
is
unique
to
the
sick,
or
should
we
basically
a
wall
so
projects
to
do
whatever
they
want.
A
And
yeah:
this
is
a
potential
topic
for
next
week
on
tuesday
and
also
for
brits.
You
brought
the
topic
about
graduating
the
api
to
v1.
Maybe
it's
time
we
have
to
potentially
do
a
desire.
If
you
look
at
what
is
the
current
state
of
the
api
and
hopefully
more
people
will
join,
we
scheduled,
I
mean
for
now.
A
We
we
scheduled
this
to
be
the
next
cuba,
dm
officials,
which
is
in
a
couple
of
weeks,
and
we
should
have
a
discussion
about
the
graduation
of
cuba
dm
aps
also
in
the
costa
rica
meeting,
which
is
in
30
minutes.
I
guess
to
see
if
anybody
has
comments,
the
I
mean
just
looking
at
the
back
walk,
I
see
things
that
are
potential
brokers.
I
mean
I
can
always
find
things
because
I'm
in
the
project
maintainer
perspective,
but
it's
also
important
to
see
what
the
users
think
think
about
this
and
yeah.
C
Yeah
so
let's
do
a
review
and
then
we
can.
Let's
send
it
like
an
email
to
the
mailing
list
to
like
get
consensus.
And
then
you
know
from
there.
A
All
right
for
british
vince:
do
you
want
me
to
send
the
email
about
the
the
review
and
also
by
the
way,
given
this
meeting
is
only
one
hour.
We
have
to
acknowledge
that
one
hour
is
not
going
to
be
enough
to
do
a
full
review.
So
what
are
we
going
to
do
about
that?
Do
we
want
to
start
scheduling,
regular
meetings
or
just
continue
on
the
bi-weekly
cubanium
office
hours
as
the
time
slot?
For
that.
C
I
was
actually
going
to
ask
like,
if,
should
we
dedupe
this
meeting
with
the
superlative
lifecycle
meeting
as
well,
because
it's
given
there's
more
folks
there
and
also
like
proposed,
like
for
api
reviews,
we
should
do
one-offs,
like
production
readiness
has
done
for
sick
arc.
B
Yeah,
let's,
let's
use
this
time
slot
and
I'm
not
sure
that
we
should
have
to
do
the
meetings,
because
some
time
this
there
are
good
discussion
in
this
one
as
well
and
copy
is
usually
full
of
topic.
So
not
sure
if
we
can
find
a
room
for
both.
Let's
keep
this
one
for
review
and
then,
when
our
review
are
finished,
we
we
decide
if
to
dedupe
the
meetings.
B
B
The
siege,
what
we
would
like
to
have
is
that
the
cig
is
not
a
place.
Let
me
say
a
place
where
we
host
projects
is
a
place,
is
a
is
a.
It
should
be
a
place
where
projects
build
up
an
ecosystem,
a
con,
a
consistent
set
of
tools,
so
we
should
and
get
the
sig
meeting
to
become
a
place
where
all
this
discussion
about
the
the
old
picture,
every
how
everything
gets
together
happens
again.
C
B
Make
an
exam.
I
make
an
example,
a
don
project
which
is
working
with
cops
to
to
the
is
working
with
cop,
but
we
don't
have
feedback
in
the
sig
meeting,
and
so,
as
a
kubert
mean
we
don't
know
if
what
they
are
working
on
is
usable
or
not.
B
A
Just
is
usually
a
problem
of
time
slots
and
time
zones
and
not
enough
people
having
the
swat
to
be
able
to
join
the
meeting.
That's
the
problem
so
that
that's
why
I
really
like
fabricio's
idea
to
potentially
start
collecting
written
updates.
So
people
write
an
update.
They
said
it
was.
A
It
might
seem
like
a
bit
of
a
status
report
like
you
work
for
a
company,
you
have
to
do
a
student's
report,
but
without
that
it's
without
such
a
report,
it's
really
difficult
to
understand
what
people
are
working
on
and
if
they
have
any
brokers,
so
I
think
the
the
sick,
the
six
should
act
like
a
collection
pointer
for
the
issue
projects,
instead
of
just
a
one
hour
meeting
where,
if
people
want
to
join,
they
join,
I
mean
that's
fine,
but
we
should
definitely
start
collecting
some
of
this
information
yeah
next
next
week.
A
We
can
continue
this
this
topic
as
well
like
how
do
we
collect
reports?
It's
going
to
be
something
that
we
have
to
do
eventually,.
A
All
right,
do
you
have
any
more
topics,
or
should
we
call
it
a
meeting.
A
Anything
for
today
none
from
my
side
would
you
be
able
to
join
the
coastal
life
cycle
meeting
next
week
or
maybe
ask
media
or
somewhere
else
right
yeah
I'll
be.
I
will
be
joining
and
asking
some
other
person
to
join
yeah.
Basically,
basically,
the
idea
is
to
discuss
the
future
of
the
cube,
adm
api
and,
since
mini
cube,
consumes
the
kubernetes
api.
We
should
potentially
discuss
the
whole
v1
topic
with
with
you
as
well.
A
Basically,
there
are
some
interesting
points
for
this
discussion.
Yes,
yeah
all
right.
So
after
a
question.
Sorry,
the
question
api
meeting,
I'm
going
to
send
an
email
to
the
mailing
list
to
of
basically
people
to
join
the
next
request,
lifecycle
meeting
and
in
a
couple
of
weeks
to
join
the
cube
meeting
again
to
start
doing
this
audit.