►
From YouTube: SIG Cluster Lifecycle 2021-08-24
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
Hello
folks
and
welcome
to
the
sea
cluster
life
cycle
meeting
today's
august
24th
tuesday
nine
a.m.
Pacific
time
we
have
what
light
agenda
lugomir
have
the
first
few
topics.
C
D
Can
tell
you
just
a
little
bit
hello,
everyone,
I'm
hi
yodu,
that's
kind
of
like
my
first
meeting
on
this
team.
I
have
been
working
for
a
few
years
with
worse
close
to
the
openstack
project,
and
now
I'm
like
work
a
little
bit
more
with
the
kubernetes
more
focus
on
like
the
kubernetes
when
you
are
using
openstack
clouds,
so
learning
a
little
bit
on
how
class
api
works
with
the
openstack
provider
and
comparing
with
the
others
and
see.
How
can
I
help
the
community
on
that?
D
So
I
basically
I'm
in
brazil
working
in
a
company
called
loser
labs.
It's
basically
working
now
private
cloud
based
on
pay,
stack
and
running
some
kubernetes
stuff.
E
I
can
go
next,
hi
everyone,
my
name
is
chung,
so
I
used
to
join
this
sig
a
couple
of
years
ago
and
when
I
was
at
vmware
now
I
work
at
apple
and
we
use
the
kubernetes
extensively
on
our
internal
infras
and
we
are
looking
for
to
use
a
classic
api
type
of
related
project
to
to
orchestrate
our
classroom,
provisioning
and
management,
and
we
just
started.
E
And
also
like
my
team
and
I
we
have
built
a
internal
keyword
provider
and
we're
looking
for
the
process
to
donate
it
to
the
upstream.
That's
why
we're
here.
E
F
I
can
go
next,
hello,
everyone,
my
name
is
alex
also
working
at
apple
together
with
chang
actually
on
cluster
api
started
on
that
about
several
months
ago,
and
we
using
it
for
primarily
for
ephemeral,
cluster
provisioning
in
the
last
several
months
and,
like
chang,
said
looking
to
donate
our
keyword
provider
to
the
community.
A
E
Not
not
not
yet
so
we
asked
you
doing
our
internal
legal
processing
to
make
it
upstream
to
apple
namespace
first
and
then
we
can
spend
time
on
polishing
the
ci
parts
and
then
we
can
make
the
like,
and
during
the
same
time
we
are
making
the
proposal
to
merge
into
the
like
a
kubernetes
six
namespace.
That's
called
that.
B
B
All
right,
so
tips
is
clear
to
step
down.
You
might
know
tim.
He
has
been
with
sequence
life
cycle
for
a
very
long
time,
almost
after
the
inception
of
this
group,
and
he
is
very
busy
nowadays
with
downstream
work.
He
decided
to
step
down
and
pass
the
ball
to
this.
As
you
can
see,
this
is
already
leading
this
meeting,
he's
our
new
co-chair.
So
congratulations
and
welcome.
B
B
B
A
couple
of
surprises
was
were
that
the
code
phrase
one
was
not
something
that
the
developers
expected
and
the
other
one
was
that
the
enhancement
phrase,
which
is
basically
the
as
you
might
not
know,
kubernetes-
requires
you
to
submit
a
proposal
document
which
is
a
cap,
kubernetes
enhancement
proposal
before
a
certain
deadline
and
a
certain
amount
of
time
required
for
this
document
to
be
reviewed,
approved
and
so
on,
and
to
a
lot
of
people's
surprise.
B
The
enhancement
freeze
was
very
close
to
the
beginning
of
the
cycle,
which
does
not
leave
enough
room
for
people
to
work
on
their
proposal
documents.
So
if
you
are
interested
about
this
ongoing
discussion
of
how
we
manage
the
kubernetes
release
cycle,
please
check
them
out
if
you
participate
in
bigger
projects
in
the
past.
You
know
leave
your
comments.
B
If
you
have
any
that's
pretty
much
this
psa
any
comments
about
it.
B
Okay
check
it
alex
your
topic
should
be
right.
Now
we
should.
We
should
talk
about
it
right
now,
instead
of
the
subproject
updates,
because
your
provider
is
sort
of
super
project
yet
but
yeah,
please
go
ahead.
E
E
And
currently
we
have
that
repo
in
good
shape
and
we
plan
to.
We
were
in
discussion
of
donating
that
repo
to
the
upstream.
However,
there's
like
also
legal
process
for
affordable
department
to
review
the
ripple
and
also,
I
know,
there's
also
like
a
casa
api,
specific
requirements
and
what
what
our
current
plan
is.
E
We're
gonna
after
the
legal
review,
we're
gonna,
donate
and
like
like
forklift
the
repo
into
the
apple
name,
space
first,
and
also
set
up
the
corresponding
prong
ci,
and
then
we
also
make
the
official
proposal
to
the
class
api
panels
and
go
through
the
review.
Whatever
process
we
need,
and
hopefully
we
can
get
accepted
under
under
the
sick,
kubernetes
namespace.
E
F
So,
to
add
to
the
chunks
points,
maybe
our
general
questions
are
what
is
involved
in
creating
or
requesting
a
new
repository
under
kubernetes
6
namespace.
F
So,
given
we
have
the
code
and
sufficient
unit
test
coverage
and
the
code
is
generic?
Is
there
like
what
is
the
path
of
the
least
resistance
to
open
source
it?
I
understand
that
a
lot
of
people
come
with
great
suggestions,
great
new
projects
to
the
to
the
seek
to
the
group,
but
obviously
there
is
no
bandwidth
to
accommodate
everyone.
F
So
how
so,
should
we
create
a
cluster
api
enhancement
proposal
for
it
and
formally
bring
it
to
the
next
sig
meeting?
Would
that
be
a
good
course
of
action.
B
By
my
first
comment
is
that
it's
it's
a
question:
have
you
looked
at
the
open
shift
cube
word
provider
because
there's
already
a
provider
for
that
and
we
have
fragmentation
in
the
ecosystem
because
of
that
red
hat
developed
their
own
apple
developed
their
own,
and
I
I
don't
think
we
can
accept
either
of
those
unless
there
is
unification.
E
Yeah
so
a
couple
of
months
ago,
we
do
contact
the
open,
openshift
folks
regarding
their
class
api,
and
they
are
mostly
based
on
the
actuator,
the
old.
I
think
the
old
mechanisms
and
yeah
you're
right,
like
we
will
talk
to
the
maintainer
of
the
openshift
class
api
provider
and
orgasm
on
board.
So
the
reason
why
we
developed
another
class
api
for
keyword
is
the
the
one
under
the
net.
E
The
open
shift
only
works
for
openshift,
it's
not
for
the
generic
kubernetes
so
and
you're
right
that
we're
gonna
have
them
on
board
and
maybe
and
for
this
repo
is
more
like
a
a
like,
a
upstream
compatible
version
of
a
classic
via
keyboard
provider.
So
that's
what
that
is
for
whatever
we
are
in
for,
and
we
already
split
the
apple
specific
stuff
into
our
internal
repos
and
for
the
repo
that
we
want
to
donate
is
purely
for
upstream
compatible.
One.
B
I
don't
think
we
have
anybody
from
red
hat
on
the
meeting
currently,
but
perhaps
tomorrow
we
can
have
someone
in
the
costa
rica
meeting,
so
you
can
continue
the
discussion
there,
but
in
general,
if
apple
takes
over,
you
know,
quote-unquote
takes
over
this
provider
and
the
red
hat
already
have
one
that
that
doesn't
feel
ideal.
I
ideally
red
hat,
should
contribute
their
existing
ideas
to
your
provider
yeah
and
it
should.
B
E
G
Yeah,
so
I
think
this
project
sounds
awesome.
I
think
it
sounds
really
cool.
I
think
I
I
don't
think
I
necessarily
agree
entirely
on
whether
we
need
full
buy-in
from
I
mean
it's.
G
It
would
be
great
to
have
full
buying
from
red
hat,
but
I
think
unless
red,
unless
the
other
projects
are
under
the
kubernetes
six
umbrella,
if
you're
proposing
putting
something
under
the
kubernetes
on
umbrella
and
under
that
governance,
then
that
is
how
we
achieve
consensus,
sometimes
obviously
be
better
if
everything
was
friendly
and
everyone
agreed,
but
it
isn't
always
the
way,
and
so,
if
you're
willing
to
to
work
under
the
community
sigs
and
the
cluster
api
provider
project
is
willing
to
to
accept
that
work.
G
G
E
The
plan
was
since
openshift
already
started.
That
and
but
does
it
didn't
like
follow
the
upstream
very
closely
recently,
so
we
what
what
we
want
to
do
is
like.
We
want
to
have
one
of
the
maintainers
from
the
openshift
version,
and
I
have
one
of
them
like
to
to
also
be
the
maintainer.
So
at
least
like
a
to
have
some
sync
between
the
two
ripples
and
that's
like
a
like
embrace
open
source
spirit,
whatever
yeah
yeah.
If
we
can
achieve
that,
that
would
be
wonderful
sure.
G
I
have
another,
oh
sorry
for
brits.
Are
you
good.
H
No,
I
I
was
just
echoing
giving
a
plus
one
to
your
search
assertion,
so
my
opinion
on
it
will
be
ideal
to
get
more
company
to
work,
but
we
have
precedence,
for
instance,
think
thinkable
provider,
which
was
maintained
by
only
one
company,
and
so
if
we
have
a
provider
that
is
going
is
going
to
be
donated
to
the
siege.
H
We
have
a
asset,
a
group
of
maintainers
that
want
to
adhere
to
the
to
kubernetes
contributor
guidelines
to
the
to
the
kubernetes
governance
and
stuff,
like
that,
in
my
opinion,
we
should
favor
them
and
the
provider
is
really
sticks
to
the
kubernetes
upstream
version,
not
to
a
product
version
of
kubernetes.
In
my
opinion,
we
should
favor
them.
I'm
plus
one.
G
Justin
thanks
yeah,
I
actually
just
want
to.
I
want
to
just
clarify
my
understanding
of
what
this
provider
does,
because
I
I
think,
I'm
assuming
I
know
what
it
does,
but
I
think
it,
and
so,
as
I
understand
it,
you
have
some.
You
have
a
kubernetes
cluster
that
runs
some
fairly
big
nodes,
and
then
you
want
to
run
the
cluster
api
against
that
to
provision.
I
guess
smaller
clusters
on
that
is,
that
is
that
correct.
E
Yeah,
so
we
have
a
kubernetes
class,
we
have
kubernetes
clusters
run
like
runs
on
bare
metals,
and
we
use
kubernetes
to
expose
the
virtualize
the
virtual
machine
interfaces,
and
then
we
also
use
those
virtual
machines
to
create
another
layer
of
kubernetes
distribution
that
we
are
currently
using
to
test
our
our
change,
then
to
do
the
quality
controls,
that's
the
original
goal
of
the
project
and
then
maybe
later
we
can
develop
like
make
it
a
more
like
a
persistent
like.
E
Currently,
the
cluster
only
serves
like
for
the
testing
purpose,
and
but
we
we
already
say
like
it,
can
serve
more
like
a
if,
like
a
more
persistent
usage
than
just
like
a
firmware.
So
that's
yeah.
Your
assumption
is
totally
correct.
G
To
clarify,
because
it's
a
little
bit
of
a
you
know
head
like
the
the
yes
clusters
on
clusters
are
always
confusing,
and
that
sounds
awesome,
so
yeah.
Thank
you
yeah.
Thank
you.
A
Awesome
so,
let's
add
like
a
group
topic
for
cluster
api
meeting
tomorrow
and
because
there's
usually
right
have
folks
there,
so
we
can
ask
for
their
like
collaboration
on
that
as
well.
If
they're
interested
but
yeah,
I
do
agree
like
we
should
probably
not
block
on
that,
because
their
current
provider
is
actually
based
on
a
different
machine
api
which
is
not
clustered
api
necessarily
and
it's
based
on
alpha
one
approaches
and
also
plus
one
because
cube
vert
is
a
sandbox
project
for
the
cncf.
E
Yeah
well
we'll
get
some
like
documentations
tomorrow
to
discuss
awesome.
Thank.
B
It's
next
wednesday
september
1st.
If
you
wish
to
join
and
participate
in
the
discussion
for
the
cycle
for
kubernetes,
please
go
ahead.
B
The
the
next
point
I
wanted
to
make
is
that
the
kubernetes
docks
are
kind
of
broken.
Currently
the
upgrade
looks
broken
and
it
it
manifested
a
problem
in
sick
dogs.
Basically
they're
currently
lacking
a
progress
interviewers.
So
if
you
know
somebody
that
is
a
tech
writer,
somebody
that
wishes
to
contribute
to
documentation
in
communities,
you
can
give
them
a
pink
and
they
should
join
the
sigdocs
meeting
to
offer
their
help,
because
it's
a
bit
of
a
pity
that
we
have
so
much
content
in
the
website.
B
But
one
of
the
most
active
groups
historically
is
pretty
much
getting
thin
in
terms
of
reverse
and
approvals,
which
means
that
if
you
set
a
change
or
somebody
has
to
work
on
something
that
is
like
a
problem
in
the
website,
there's
pretty
much
nobody
to
fix
it
or
if
there's
somebody
to
fix
it,
they're
a
third-party
contributor.
B
They
send
a
change
and
there's
nobody
to
review
it
and
approve
it.
So
it
we
have
some
examples
of
things
getting
blocked
indefinitely
and
at
this
related
to
cuba,
cuba
dm
this
might
be
hinting
to
potentially
one
day
move
the
documentation
outside
of
the
website,
because
q,
some
of
you
may
know,
kubernetes
documented
at
the
website.
B
But
if
the
maintainers
learning
running
low
on
numbers,
it
has
to
move
to
the
hands
of
the
developers.
G
Specifically
I'll
it's
not
cuba
en,
but
I
mean
that
I
would.
I
would
classify
that
as
a
sort
of
project
risk.
I
mean
I
I
don't
know
like
chaos,
has
its
own
documentation
website
and
it's
not
the
end
of
the
world,
but
I
think
in
general,
like
you,
should
make
that
decision,
because
you
want
a
separate
website
not
because
of
review
bandwidth,
and
I
I
don't
know
who
we
could
surface
that
to
that.
B
Yeah,
but
if
you
look
at
all
of
these
super
project
projects,
including
cop
sky,
api,
I
I
would
guess
that
one
of
the
reasons
they
have
their
own
websites
for
documentation
is
that
because
of
the
ownership
problem,
you
don't
want
to
be
blocked
on
a
reviewer
and
approval,
and
essentially
it
ends
up
in
a
situation
where
you
don't
own.
Your
documentation,
you're
just
a
contributor
to
it.
G
Yeah
I
mean
I
typically.
I
have
absolutely
no
objection
if
you
want
to
do
your
own
dark
side
right
that,
but
I
I'm
just
concerned
in
general
about
the
idea
that
it
felt
a
bit
like
you
were
being
forced
to
do
it
so,
but
I
mean
fully
support
if
you
want
to,
if
you
wanted
your
own,
but.
B
Yeah,
it's
certainly
not
something
we
want
to
do
because
it's
a
lot
of
work
and
if
you
look
at
the
cubed
maintainer
roaster.
Currently
it's
like.
We
have
three
people
and
it's
a
lot
of
work
to
migrate,
all
the
docks,
but
if
we
are
blocked
in
changing
them,
it
is
going
to
be
a
forcing
function
for
us
and
anybody
else.
If
minicube
see
this
is
a
problem.
Many
people
have
some
dogs.
If
the
dogs
are
on
our
updates,
you
just
you.
Basically,
it
forces
the
maintainers
to
migrate
documentation.
B
It's
it's
unfortunate,
but
that's
what
we
have
to
do.
Maybe.
A
I
guess
you
know,
alternatively,
like
we
need
to
get
some
more
approval
power
on
the
docs
site,
at
least
for
the
qb
section.
I
would
rather
not
split
this
out
like
in
a
different
because,
like
cubarium
is
released
within
kubernetes
and
there's
a
lot
of
machinery
right
like,
for
example,
to
create
the
120
dogs
like,
and
it's
gonna
take
a
lot
of
work
for
us
to
actually
move
this
out,
and
it's
also
great
that,
like
when
folks
go
here,
can
they
can
see
that
you
know?
A
Cubitium
is
still
the
de
facto
tool
to
that
the
ships
with
with
kubernetes
to
spin
up
kubernetes
clusters
at
the
end
of
the
day.
So
if
it's
a
matter
of
reviewers
like
on
the
docks
like,
maybe
we
should
get
some
of
the
this
group.
Some
of
us
like
in
the
approval
list
for
the
at
least
the
dock
section
assume
that
there's
a
folder
structure.
B
That's
part
of
the
problem:
approvers
in
subfolder
owner
files
were
never
something
accepted
by
sigdocs.
There's
always
the
concept
of
there's
always
has
been
the
concept
of
fruit
proverbs
that
are
from
the
english
section.
For
the
you
know,
for
the
indian
section
filipino
section,
the
dark
side
is
multilingual,
but
there
was
never
a
concept
of
approvers
from
the
developer
side
of
things.
There's
always
has
been
this
concept
of.
B
Only
sick
dogs
can
approve
the
docks
and
in
the
past
we
we
really
didn't
like
this,
but
we
kind
of
started
living
with
this
concept
for
years,
but,
like
I
said,
if
it
becomes
a
walker,
we
have
to
take
action.
I
Yeah,
I'm
just
curious.
Does
sick
dogs
know
that
this
is
slowing
us
down
like?
Are
they
aware
that
this
is
a
problem.
B
Yeah
recently,
actually
the
chair
of
one
of
the
chairs.
I
think
they
only
have
one
currently
explained
that
what
is
the
situation
in
sick
dogs
and
by
saying
that
he
also
said
that
he
wants
to
step
down
as
a
chair,
which
is
also
an
indication
that
he
doesn't
have
the
bandwidth
to
help
with
this
work.
B
There's
a
lot
to
maintain
in
the
website,
and
it
feels
it
feels
like
companies
are
not
providing
sufficient
stuffing.
I
spoke
internally
with
some
vmware
people.
I
would
say
that
there
is
no
big
interest
currently
to
spend
resources
on
contributing
to
the
website,
maybe
in
the
future.
I
saw
some
peers
march
recently,
but
it's
in
the
end
of
the
day.
It's
a
staffing
problem.
The
companies
that
develop
products
don't
contribute
back
to
the
upstream,
with
some
of
the
developer
resources
to
maintain
these
upstream
documents.
I
Yeah,
this
is
a
really
quick
one,
just
an
update
that
we
renamed
the
default
branch
to
main
in
cabsie
cluster
provider,
a
cluster
api
provider
azure
and
yeah.
It
was
a
pretty
easy
and
smooth
process
if
anyone's
contemplating
doing
it
in
their
own
project.
I
think
do
it.
It's
pretty
easy
and
straightforward.
A
Awesome
thanks
for
doing
that.
I
think
we
should
probably
prioritize
this
in
cluster
api
as
well
soon,
because
that's
something
that's
up
our
laundry
list
for
sure.
Are
there
any
other
sub
project
updates.
A
A
Should
we
upgrade
to
beta
work,
both
types,
we're
thinking
about
the
core
types
first,
and
you
know
give
time
time
for
the
providers
to
move
over
time
and
another
thing
that
we're
thinking
about
is
to
make
sure
that,
like
as
we
get
to
beta,
we
also
like
release
more
often
and
smaller
releases
as
well.
A
Given
that
right
now,
like
every
mind,
release
it's
like
packed
with
changes,
we
want
to
do
more
minor
releases,
also,
like
one
point,
one
two
three
and
maybe
continue
with
zero
point
x
on
alpha
four,
so
zero
five
and
alpha
four
one,
zero,
six
et
cetera,
so
that
folks
can
adopt
the
breaking
changes
that
we
make
over
time
and
like
even
more
often
at
the
end
of
the
day.
A
This
will
also
give
us
the
ability
to
upgrade
our
dependencies
more
often
so
as
an
example,
zero
three
is
still
using
116
or
something
as
a
dependency,
which
is
really
old
right.
So
again,
it's
on
go
113,
for
example,
so
that
will
give
us
the
ability
to
do
a
lot
of
more
things,
but
at
the
same
time
you
know
like,
as
soon
as
we
have
beta
types
and
one
point
x
versions.
We
also
have
more
release
branches
and
more
like
releases
to
support
as
well
over
time.
A
A
A
I
think,
like
our
one
point
x,
series
like
would
be
kind
of
like
considered
that
until
we
got
to
ga
at
least
I
don't
know
if,
like
we're,
gonna
have
like
an
lts
per
se,
we
are
like
having
an
lps
right
now
with
with
zero
three
and
the
alpha
three
types,
and
it
has
been
really
yeah
like
it's
been
in
support
for
one
year
for
an
alpha
version.
It's
like
a
lot.
H
E
H
At
the
end,
it
is
a
a
big
problem
for
the
for
the
course
for
the
entire
ecosystem,
so
maybe
the
the
route
down
this
path
will
be
to
have
a.
B
Yeah,
because
if
you
want
to
support
upgrade
for
lts
version,
let's
say
you
have
a
version
of
the
api
that
is
supported
for
three
years,
something
like
that,
which
is
a
long
period
of
time,
upgrade,
becomes
very
difficult
and,
as
you
may
know,
upgrades
in
kubernetes
only
work
between
minor
versions
of
kubernetes,
so
it's
like
impossible.
There
were.
B
You
end
up
in
a
situation
where
there
are
periods
of
time
where
a
certain
api
isn't
supported
and
shared.
This
is
like
we
cannot
do
that,
so.
Instead
they
started
playing
with
the
release
cycle
and
that's
what
that's
the
reason
why
we
have
like
four
months
of
a
release
nowadays,
instead
of
three
and
also
the
support
window
shifted
one
year
so.
A
Good
to
know
yeah,
this
is
something
like
we'll
have
to
discuss
as
well
once
we
get
there,
but
yeah
just
wanted
to
call
out
that.
That's
if
you're
interested
in
how
do
we
get
the
beta
like
definitely
reach
out
and
if
you
can
join
our
meeting.
That
would
be
great
too.