►
From YouTube: SIG Cluster Lifecycle - Cluster API 22-04-27
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
and
welcome
to
the
cluster
api
office
hour
meeting
today
is
april.
27Th
2022.,
just
as
a
reminder.
Cluster
api
is
a
project
of
state
blaster
lifecycle.
We
adhere
to
the
kubernetes
code
of
conduct
so
which
you
know
can
be
summarized
but
just
be
kind
to
each
other.
We
use
the
race
and
feature
in
zoom
you.
You
can
find
it
in
your
zoom
window
under
reactions.
A
A
All
right:
well,
let's,
let's
keep
going
open
proposal.
Readout.
Is
there
anything
we
should
discuss
in
in
this
meeting
that
we
should
be
called
out?
You
arrive.
B
B
A
It
seems
stefan
is
saying
the
same.
It
is
for
topology
mutation,
which
I
assume
is
this
other
proposal
you're
actually
changing
the
title
of
this
doc
so
that
it
it
matches
the
title
here.
A
Perfect
christian.
C
But
yeah,
if
we're
there,
the
cluster
api
state
matrix
proposal
is
in
emerging,
it's
approved
and
just
waiting
for
the
markdown
check
to
succeed,
which
is
currently
getting
fixed.
So
I'd
like
to
thank
everyone
which
did
review
and
yeah
and
participate.
A
Perfect,
thank
you,
let's
see
so
this
broke.
I
guess.
D
E
Hey
thanks,
I
just
wanted.
Yet
again
we
tried
to
set
up
a
review
meeting
to
kind
of
get
over
the
hump
with
machine
pull
machines
proposal
and
last
week
didn't
work
out.
So
I
have
another.
I
have
a
link
there
to
a
doodle,
and
hopefully
people
who
are
interested
can
get
together
tomorrow
or
friday
or
maybe
monday
or
tuesday,
and
and
then
we
can
hash
out.
Hopefully
the
final
few
things.
A
Thanks
sounds
great
I'll
post
this
in
chat
as
well.
So
if
you
want
to
please
enter
times
and
perfect
any
other
things
to
call
out
in
terms
of
pause,
we
have
a
huge
list
of
proposals
here
so
but
it's
great
that
we're
keeping
track
of
all
of
them.
F
Jack
real
quickly
on
the
cluster
api
add-on,
orchestration
proposal,
fabrizio
myself,
jonathan
and
additionally,
stefan
and
guillermo-
are
going
to
be
doing
a
sort
of
ad
hoc
zoom
session
tomorrow,
11
pacific
time
to
go
over
the
current
state
of
a
prototype
that
jonathan's
been
working
on
and
maybe
lean
in
a
little
bit
to
the
proposal
itself,
which
I
have
been
spending
some
time
on.
So
it's
just
an
invitation.
If
folks
want
to
join
that
conversation,
it's
an
open
conversation.
You
can
find
there's
a
thread
on
campy
slack.
A
Sounds
great
for
both
of
these
meetings
like
it
might
be
helpful
to
just
send
the
calendar,
invite.
I
can
help
you
with
that.
If
you,
if
you
need
through
the
sig,
so
that
everybody
gets
the
invite,
not
everybody
has
to
join,
we
can
mark
as
optional
and
we
can
reuse
the
same
two
meetings
as
well.
A
That
works
just
send
me
the
details
on
both
the
meetings
like
once
this
doodle
is
completed
and
the
other
one
for
tomorrow
now
I'll
send
the
invite
cool
awesome.
Any
questions
on
any
of
these
proposals
or
topics
that
we
have
chatter,
about
comments,
concerns
fabrizio.
G
Just
one
note,
echoing
what
cecile
said
last
week,
I
think
that
for
the
proposal
outlet,
the
the
first
thing
to
do
in
order
to
gather
feedback
is
to
ping
reviewers
in
the
reviewer
list.
And
of
course,
if
everyone
is
that's
destined
to
review,
we
can
add
them.
But
let's
start
getting
feedback
from
reviewers.
A
No,
all
right,
let's
and
actually
like
anything
else
to
it
seems
like
ipam
has
lasting
consensus
until
friday,
and
this
one
is
merging
should
be
fixed
soon
and
then
the
other
ones
there's
still
need
review.
A
Okay,
anything
else
to
call
out
before
we
move
on.
A
Going
once
twice
three
times
all
right
fabric,
you
have
the
only
discussion
topic
for
today.
G
Thank
you
so
last
week
we
had
a
discussion
about
serve
manager
and,
while
looking
at
the
server
manager
version,
basically
we
realized
that
they
are
now
as
a
very
aggressive.
G
G
The
the
other
side
of
the
this
coin
is
that
if
we
try
to
keep
up
with
certain
manager,
version
might
be
that
that
we
incur
in
search
manager,
basically
changing
the
the
minimal
kubernetes
version,
which
is
supported,
and
this
could
indirectly
basically
impact
the
minimal
kubernetes
version
we
are
supporting
in
in
the
management
cluster.
G
So
I
opened
an
issue
to
to
start
a
discussion
about
these,
but
while
writing
this
issue,
I
realized
that
it
is
really
hard
to
find
a
solution
for
this
problem
unless
we
define
a
sort
of
release,
currents
for
for
copy,
which
could
be
interesting
not
only
for
some
manager,
but
also
for
everyone
which
build
the
on
topic
on
top
of
cluster
api.
G
G
A
H
Hey,
I
think
this
is
a
cool
topic
fabrizio.
I
don't
know
the
cert
manager,
release,
process
or
cadence
that
well,
but
do
they
do
they
have
any
notion
of
like
long-term
support
versions
or
anything
like
that.
G
You
know
each
release
being
supported
for
a
period
of
four
months
and
a
new
release.
Every
two.
This
is,
and
by
the
way,
the
their
documentation
page,
which
is
linked
in
the
issue,
is
really
well
done.
We
have
to
copy
from
them
about
how
to
document
this
process,
but
yeah
they
don't
have
a
notion
of
lts.
I
I
I
think
we
could
potentially
try
to
do
a
bit
more
often
than
three
releases
a
year.
I
think
the
current
two
releases
a
year
is
not
really
a
true
reflection
of
what
we
want
to
be
at
it's
more
of
like
what
has
happened
due
to
releases
being
delayed
many
times.
I
don't
think
we
intentionally
wanted
to
do
two
releases
a
year
for
alpha
4.
We
it
took
us
a
year
to
release
between
alpha
3
and
alpha
4,
which
was
way
too
long,
and
we
ended
up
with
release
notes
that
were
completely
impossible
to
digest.
I
So
I
think
you
know
kubernetes
is
pretty
mature
at
this
point.
They
have
a
release
team
in
place.
They
have
a
release
process
with
proposal.
Freeze,
I
don't
think
we're
there
yet.
I
think
cluster
api
is
a
bit
earlier
in
its
maturity
stage,
and
so
it
would
make
sense
to
do
a
bit
more
lightweight
releases
still,
and
you
know,
release
often
are
really
smaller
and
help
us,
you
know,
keep
the
momentum
of
the
feature
building
that
we've
been
on
recently,
especially
since
there
are
a
lot
of
proposals
and
progress.
I
Lots
of
big
changes
happening,
so
my
my
opinion
would
be
to
try
to
release
smaller
releases
more
often
and
also
try
to
aim
to.
I
like
the
idea
of
a
release
cadence
and
having
the
emphasis
on
release
like
time
and
more
than
like
what
the
release
is
going
to
contain
and
so
kind
of
driving
releases
by
the
deadline
and
by
the
time,
we're
planning
on
releasing
it
rather
than
what's
making
it
into
the
release
and
waiting
for
features
to
get
in.
I
A
Yeah
and
I'll
add
to
that
that,
like
I
think
like,
I
would
agree
with
cecil
here
like
and
as
as
long
as
like,
we
can
make
our
release
process
like
fully
automated
we've
talked
about
in
the
past
like
here
and
there
there
are
like,
maybe
a
few
more
things
to
automate
like
we
can
have
a
cadence,
but
also
like.
I
guess,
like
complement,
that
with
like
more
releases
as
we
go
as
we
see
fit
so
like
we
will
guarantee
some
sort
of
like
you
know.
A
Maybe
three
releases
period
like
we're
discussing
here,
but
also
maybe
do
even
more,
if
needed
in
that
way
like
for
big
features
like
they
could
have
their
own
release.
It's
also
like,
at
that
point
easier
to
talk
about
it.
For
example,
like
we
have
have
machine
machine
in
like
one
three,
no
pressure,
just
as
an
example
like
and
that
gets
delivered
like,
and
it's
like,
maybe
accompanied
by
something
else
like
it's
much
easier
to
talk
about.
It's
like.
Oh,
that's
one.
Three
of
these.
A
I
know
what
went
into
it
and
you
know
we
can
all
get
in
the
same
page.
Alpha
four
was
a
big
big,
really
really
big
release
like,
and
it
contained
way
too
many
things
to
digest.
I
would
agree
with
that:
apprecia.
G
G
I
think
that
what
is
we
still
have
to
to
figure
it
out
is,
for
instance,
I
don't
know.
Are
we
going
to
have
a
feature,
something
like
enhancement
freeze
or
how
can
we
solve
the
problem
of
proposal
laying
around
for
so
for
so
long.
G
How
to
make
the
effort
to
support
all
the
release
sustainable,
so
this
is
these
are
the
two
concern
one
is
to
make
everything
to
adapt
to
the
new
release.
Currents
and
second,
is
how
to
support
all
the
release.
This
is
why
I,
I
will
prefer
to
start
with
three
release
instead
of
four
etc.
So
let
me
say
improve
one
step
at
time,
but
I'm
open
to
every
option.
I
Yeah,
I
so
first
of
all
the
thing
that
fabrica
said
about
how
do
we
fix
the
problem
about
proposals
being
opened
for
so
long?
I
don't
have
the
answer
to
that,
but
I
think
that's
a
very
interesting
topic
and
question,
and
I
think
we
should
talk
about
that
maybe
separately
and
have
a
retro,
because
it
is
a
problem
that
you
know.
Proposals
are
stagnating
and
standing
there
for
like
months.
So
we
should
talk
about
that.
I
But
what
I
wanted
to
say
is
stefan's
point
in
the
chat
is
also
very
important
is,
with
you
know,
defining
a
release
cadence.
We
should
also
define
how
many
releases
we're
supporting
at
a
time
and
more
specifically,
how
many
releases
we're
backporting
to
with
bug,
fixes
and
critical
changes
that
need
to
go
in
before
the
next
miner.
A
Yeah
this
problem
comes
often
like
in
various
communities,
like
I
think,
for
kubernetes,
given
like
how
complex
it
is
like
to
have
like
a
very,
very
fixed
cadence
like
it's
definitely
valuable.
There
is
some.
A
There
is
some
sort
of
like
hybrid
and
more
fluid
approach
that
we
can
also
take
like,
but
you
know
we
could
put
all
these
thoughts
within.
You
know
this
issue
that
february
raised
in
terms
of
like
how
many
will
support
like
buy
our
current.
I
guess
application
policies
like
would
support
like
the
latest
of
every.
A
Api
version,
if
I
remember
correctly
so
in
that
case,
like
you
know,
if
we
stay
for
beta
one
for
for
a
little
longer
like
we'll,
keep
that
up
and
but
the
other
side
of
this
is
like
we
can
also
like
it.
Just
consider
that
one
point
x
is
like
more
of
like
a
rolling
release.
So,
like
you
have
you
have
to
update
because
supporting
like
a
lot
of
it's
also
like
you
know,
comes
with
a
cost,
and
I
don't
know
if
we're
honestly
staffed
like
to
take
that
on
cecil.
I
Yeah,
I
just
wanted
to
answer
to
that
yeah,
I
think
in
practice
we
haven't
really
been
doing
that,
though,
we've
been
saying
we're
only
supporting
the
latest
patch
of
v1,
but
then
we've
been
patching,
the
1.0,
v1.1
and
v1.2
at
the
same
time,
because
we
had
users
that
were
vulnerable
to
those
bugs
that
were
on
those
older
versions
that
we
wanted
to
help
out,
and
so
our
yavy
1.1.1.0.
I
I
You
know
I
have
the
right
expectations
around
what
is
going
to
be
supported
and
what
isn't,
but
also
like
if
we're
doing
releases
three
times
a
year
or
you
know,
even
if
it's
a
bit
more
often
than
that,
let's
say
I'm
on
v1.1
right
now,
as
a
user
and
v1.2
comes
out,
and
it's
like
every
feature
and
every
change
that's
gone
into
the
cluster
api
repo
for
the
last
four
months
and
that's
going
to
be
a
lot
of
changes.
I
Let's
say:
there's
a
critical
bug
that
happens
like
the
next
week,
and
I'm
told
like
your
only
way
to
get
this
bug
fixed
is
to
upgrade
to
b1.2-
that's
not
very
user
friendly
as
a
response,
because
I'm
gonna
have
to
take
in
all
these
features
for
the
last
four
months
within
a
week.
Just
to
get
that
bug
fix.
That's
been
there
in
my
current
version.
So
maybe
we
need
to
be
a
bit
more
flexible
and
give
users
more
time
to
upgrade,
because
we
know
that
upgrading
kubernetes
clusters
can
be
complicated.
J
Yeah,
so
we're
in
the
linux
distribution
business.
So
I'm
not
sure
how
much
of
our
experience
translates
to
to
class
api.
But
we've
made
extremely
good
experience
with
relatively
rough
release
cycle
every
two
weeks.
J
We
have
a
new
version
out
and
minor
changes
and
I
think,
supporting
those
apis
and
so
basically
the
the
major
versions,
the
major
religious
releases
of
class
api
and
adding
patches
to
fixed,
bugs
and
ingesting
the
new
features,
are
kind
of
lateral,
so
they're
they're,
not
they're,
not
directly
connected
in
that
the
the
older
releases
will
only
receive
like
fixes
security,
stuff
and
so
on.
So
there
aren't
even
many
changes.
J
It
might
be
worth
to
split
that
into
some.
I
don't
know
next
and
the
current
release
version
thing,
and
I
mean
the
release-
never
gets
new
features
right.
It
only
gets
patches.
J
So
I
think
it's
not
even
a
situation
where
any
given
user
would
be
forced
to
ingest
major
new
features
just
to
get
to
the
latest
patch
stage,
but
it
makes
a
lot
of
sense
to
only
support
the
latest
patch
stage,
and
I
mean
the
benefit
that
you're
getting
from
from
a
regular
release
cycle.
It's
plannable,
so
people
can
adjust
their
their
maintenance
routines
to
that.
You
get
the
the
stuff
that
is
stable.
J
You
get
it
out
and
you're
not
holding
back
on
a
lot
of
valuable
stuff
that
has
already
merged,
with
just
waiting
for
for
more
features
to
get
ready.
A
D
Yep
just
comments,
the
first
one.
I
think
our
current
policy
was
sailor
too,
that
we
have
multiple
api
versions
and
we
only
want-
and
we
only
want
to
support-
essentially,
I
think
three
versions
and
one
for
every
api
version.
But
right
now
I
think
we're
at
the
state
looking
at
those
supported
until
dates
and
that
we
actually
only
support
1.1,
and
I
think
we
should
adjust
our
policy
because
I
mean
now
we
support
1.1
with
1.2.
We
would
immediately
drop
support
for
1.1.
D
I
think
that's
not
a
good
way
moving
forward
and
additionally,
I'm
not
one
percent
sure,
but
I
think
whenever
we
do
a
release
of
core
capi,
then
there
is
at
least
some
testing
to
be
done
in
info
providers
that
they
make
sure
that
they
also
work
with
our
version
and
create
a
new
version
there,
and
I
think
something
like
if
you
release
every
two
or
four
weeks
that
might
put
a
lot
of
pressure
on
info
providers
to
verify
that
all
the
time,
maybe
too
much
but
yeah.
I
guess
discussion
on
the
issues.
One.
A
Thanks
folks,
I
would
suggest
like
to
put
these
thoughts
in
in
here,
like
I
think,
like
just
for
action
item.
One
thing
that's
like
not
clear
at
all
like
while
I
was
reading
this
like
I
just
you
know,
realized
that
that
we
do
really
don't
have
a
guarantee
when
the
new
release
of,
for
example,
beta
1,
is
released.
How
long
we're
going
to
like
support
the
older
ones
like
yeah,
so
1.0,
which
I
guess
should
have
stopped
february,
2nd,
which
I
don't
think
it
actually
happened
so
like.
A
I
would
rather
not
put
a
date
in
here
like
if
we
don't
stick
to
it
and
so
like
if
we
want
to
put
something
in
here
that
says
like
we
want.
This
is
our
deprecation
policy,
so
I
guess:
release
cadence
deprecation
policy
in
contributing.
D
Guide,
stefan
go
ahead.
Yeah
just
comment:
can
you
tap
back
to
the
contributing
mp?
I
think
they
actually
have
a
sentence
there,
which
says
how
long
is
supporting
all
the
versus
the
same
api
version?
That's
the
last
bullet
point
for
each
given
api
version.
Only
the
most
recent
associated
response
support.
All
the
brands
are
immediately
unsupported
right
means.
As
soon
as
you
release
a
new
one.
The
old
one
is
immediately
that's
the
date,
but
yeah
you
don't
know
it
up
front.
Of
course,
if
that
was
yeah.
A
It's
not
immediately
clear
so,
like
I
would
say
like,
maybe
what
we
could
do
is
we
do
need
like
a
combination
of
both
the
api
version
and
the
actual
miner
version,
because,
like
those
are
connected,
but
they're,
you
know
we
also
like
don't
want
to
keep
like
supporting
like
an
api
version
forever.
So
that's
kind
of
the
other
point.
A
No
one
knows
what
the
next
release
is
going
to
be.
So
I
guess,
like
you
know
that
goes
into
release
cadence,
so
we
can
provide
some
stability
on.
You
know
predict
predictability
like
to
this
project,
at
least
so
that's
that's
for
one
and
then
let's
put
the
deprecation
policy
and
let's
figure
out
figure
out
n
minus.
I
guess
x
x,
to
the
side.
G
A
A
All
right,
so
any
other
action
items
that
I
should
capture
here.
Stefan
no
wait.
I
guess
that's
just
here.
Go
ahead!
All.
I
Right,
yeah,
just
one
more
action
item,
maybe
continue
evaluating
what
improvements
we
can
make
to
the
release
process
to
automate
things
and
require
less
human
effort.
K
Yeah,
just
adding
on
to
what
cecile
said
about
the
release
process
I
found
in
other
projects.
It's
sometimes
useful
if
you
get
a
new
person
to
work
through
the
documented
release
process.
What
we
found
when
we
did
that
for
helm,
for
example,
is
many
gaps
in
the
documentation
that
we're
able
to
solve
just
by
having
a
new
person,
try
to
cut
the
release
and
an
existing
person
who
had
done
it
before
sit
there
on
their
hands
going.
Oh,
oh!
This
is
the
place
in
the
docs
that
it's
not
quite
right.
A
Yeah,
we
should
definitely
try
that
there
is
some
permissions
that
we
can
just
give
out
just
like
to
cut
tags
and
things
like
that,
because
they
need
right
permission
on
the
repo
and
I
think
you
need
to
be
a
container
yeah.
K
It
would
have
to
be
a
maintainer,
of
course,
I'm
just
saying
a
maintainer
who
hasn't
got
the
release
for
before,
should
yeah
be
in
the
driver's
seat
and
have
somebody
who
is,
I
don't
mean
a
completely
new
person.
I
mean
like.
I
K
A
So
here's
already
scheming
on
how
to
cut
tags
through
pi
yep.
G
D
What
was
important
to
say
is
the
problem
is
not
to
cut
the
actual
release.
The
problem
is
what
we
have
to
do
to
bump
our
version
and
that's
a
lot
more
than
just
the
release.
The
release
itself
is
pretty
much
automated
as
far
as
we
can,
but
I
linked
an
issue
in
the
chat,
and
there
are,
I
don't
know,
15
other
tasks
that
we
usually
do
per
miner
release
to
bump
our
tests,
whatever
there's
a
lot
of
stuff
in
our
book-
and
I
think
that's
actually
the
effort
that
we
have
for
every
release.
D
A
I
think
so,
for
these,
though
like,
and
I
think
what
was
mentioning
is
like
what
can
we
do
to
automate
all
of
these
or
you
know
most
of
them
at
least,
for
example,
mangling,
some
yamo
intestine.
That
could
probably
be
done
at
least
open
the
pr.
Then,
if
someone
has
to
change
something,
you
can
do
it
offhand,
but
you
know
that
could
also
be
automated.
For
example,
you
know.