►
From YouTube: SIG Cluster Lifecycle 2021-09-21
B
B
B
Okay,
can
you
hear
me.
B
Okay,
good
hello,
everybody
and
welcome
to
the
bi-weekly
sync
cluster
life
cycle
meeting
today
is
tuesday
the
21st
of
september
2021.
I
am
your
moderator,
justin
santa
barbara.
I
work
at
google
a
reminder.
This
phoenix
is
being
recorded
and
will
be
put
on
the
internet
and
please
be
mindful
of
our
code
of
conduct,
which
is
essentially
to
be
a
good
person.
There
is
a
link
or
there
will
surely
be
a
link
in
the
chat
to
our
agenda.
B
I'm
just
pasting
it
now.
Please
do
feel
free
to
add
your
names
to
the
attendee
list,
so
that
people
watching
the
video
can
can
figure
it
out.
I
can
do
that
right
now
and
we
have
a
couple
of
things
on
the
agenda.
We
will
not
do
a
normal
in
a
minute,
we'll
do
a
call
for
any
new
meeting
participants
we'll
go
through
group
topics.
We'll
do
separation
updates.
Please
do
feel
free
to
add
your
items
to
the
agenda
at
the
appropriate
section.
B
C
Hello,
everyone,
my
name,
is
mustafa.
I
was
attending
segregas
meetings
recently
and
I
saw
the
tweet
about
the
necessity
of
new
contributors
here.
So
I
came
to
discover
more
about
available
issues
and
stories.
B
I
think
I
recognize
everyone
else,
so
otherwise
we
will
go
straight
into
the
first
group
topic.
It's
all.
I
think
it's
from
anyway,
the
our
kubecon
north
america
sixth
session
kubecon
north
america
is
in
october.
I
believe-
and
it's
gonna
be
virtual,
because
I
think
no
very
few
people
are
able
to
attend.
Unfortunately,
we
were
sort
of
planning
more
of
a
panel
type
discussion.
B
There
was
when
we
were
planning
all
of
this.
It
was
the
happy
days
before
delta
started
the
uptick
again,
and
so,
at
the
time
it
looked
like
we
were
all
going
to
attend
in
person.
The
the
planned
talk
doesn't
make
as
much
sense
in
the
virtual
format,
because
in
the
virtual
format,
these
things
have
to
be,
or
the
request
is
that
the
the
talks
are
pre-recorded.
B
We
were
thinking
about
asking
if
we
could
have
a
discussion
panel
or
birds
of
feather
session
instead,
and
if
that
is
allowed,
we
could
ask
all
the
subprojects
to
be
represented
if
they
would
like
to.
I
see
most
of
the
subjects
represented
here
so
it'd
be
good
to
hear
from
them
to
see
if
they
would
like
to
attend
a
birds
of
a
feather
discussion.
B
Panel
type
thing
more
along
the
lines
of
our
initial
proposal,
which
was
sort
of
the
initial
proposal
by
the
way,
was
around
opportunities
for
collaboration.
I
think,
if,
if
they
don't,
if
the
organizers,
don't
so
opportunities
for
collaboration
across
projects
in
c
cluster
lifecycle,
I
should
spell
that
out.
B
Yeah.
If
the
organizers
aren't
willing
to
have
us,
do
a
recording.
I
think
we
will
probably
say
sorry
aren't
willing
to
to
allow
us
to
to
do
a
discussion
panel.
I
think
we'll
probably
say
that
we're
unable
to
provide
a
recording
and
ask
for
our
truck
to
not
happen
at
this
particular
kubecon.
B
If
there's
anyone
that
has
any
input
or
thoughts
or
anyone
that
has
a
standby
record
of
sick
cluster
lifecycle
talk,
they
would
like
to
give
then
please
let
us
know
or
speak
up
now
or
otherwise.
We're
gonna
see
if
we
can
do
this
discussion
panel
and
if
there
are,
if
there
are
some
projects
that
would
like
to
or
would
not
like
to
participate.
Please
speak
up.
B
It's
tricky
I
I
feel
like
they
probably
won't
on
their
rules,
but
on
the
other
hand,
when
we,
when
we
submitted
the
talk,
it
was
very
much
around
essentially
a
a
discussion
forum,
so
we're
either
we're
breaking
the
rules
one
way
or
the
other
right
we're
either
completely
changing
our
talk
to
something
which
wasn't
what
we
suggested
or
we
are
breaking
the
rules
around
pre-recording
and
like
swapping
out
something
else.
Instead,
so
it's
a
difficult
situation.
B
I
think
everyone
would
be
much
happier
if
we
could
all
attend
in
person,
both
the
organizers
and
us,
I'm
sure,
but
that's
sort
of
where
we
are.
A
If
they
allow
us
to
have
this
as
a
final
discussion,
we
may
have
some
attendees
that
virtual
attendees
that
are
interested
in
what
we
do.
They
may
ask
some
questions,
even
if
we
don't
have
full
participation
by
all
the
subprojects,
we
can
still
have
some
discussion
going,
but
I
think
we
should
it's
worth
asking
the
cncf.
A
I
guess
my
question
would
be
who
would
like
to
take
the
actual
item
to
ask
them
and,
depending
on
that,
I
think
it's
independent
from
that.
Sorry,
if,
if
we
have
the
panel,
we
can
have
the
we
can
host
this
session
and
people
can
ask
questions
participate
in
the
meantime,
we
can
ask
our
super
project
leads
to
join
the
same
session
if
possible.
B
I
think
that's
the
right
thing
I
mean
we
were.
We
were
talking
about
like
talks.
We
could
put
together
very
quickly
because
they're,
you
know
things
that
we're
all
familiar
with.
We've
done
the
intro
to
sig
cluster
lifecycle
enough
times
that
I
don't
think
that
has
a
a
ton
of
value.
Anyone
that
wants
that
can
just
get
it
on
youtube.
I
I
think
one
of
the
ideas
I
spit
bold
was
the
sub
project
owners
talk
about.
B
Like
you
know,
if
I
were
building
again,
what
would
I
do
differently
right
like
if
I
was
building
cops
again?
What
would
I
do
differently
or
what
mistakes
I
made
along
the
way
that
that's
the
sort
of
thing
I
can
sort
of
just
spit
out
in
like
one
take
type
thing.
So
it's
it's
not
too
hard
to
you
know
it's
the
things
we've
been
working
on
fixing
for
the
past
two
years
or
five
years.
So
that's
pretty
easy
to
to
do.
But
you
know
it's,
it
is
it's
not
as.
B
I
think
I
think
the
forum
is
should
be
our.
That
is
the
talk
with
the
sort
of
forum.
Birds
of
another
thing
is,
is
what
we
or
the
panel
is.
What
we
submitted
and
or
more
like
we
submitted
and
probably
is
what
we
should
probably
do
as
our
primary
thing,
unless
there
are
other
people
that
also
have
want
to
do
that
or
have
another
great
idea,
but
yeah
the
default
would
be.
If
we
don't
get.
B
The
panels
approved
that
we
would,
in
the
absence
of
some
compelling
talk,
we
will
want
to
do
and
can
throw
together
today.
Then
we
would,
we
would
forfeit
our
our
spot.
D
D
B
B
B
It's
it's
a
it's
a
nice
way
to
to
achieve
both
right.
We
we
upload
a
video
and
then
we
cut
to
questions.
The
downside
is
which
was
as
close
as
we
will
get
to
a
panel.
I
guess
unless
they
say
we
can
have
a
panel.
The
downside
is
that
the
question
format
was
has
in
the
past,
not
been
ideal
for
two-way
interaction.
B
Right
and
I
don't
know
if
that's
getting
any
better,
but
the
the
format
in
the
past
has
been
that
the
audience,
and
it
is
very
much
like
a
divide
between
the
audience
and
the
speakers,
like
the
audience,
submits
their
questions
via.
It's
actually
like
a
chat
type
thing,
and
you
see
them-
and
I
don't
think
you
even
know
who
was
who
asked
the
question
but
like
the
possibilities
for
two-way
interaction,
are
very
limited.
So.
A
A
I
may
have
missed
them
talking
about
the
sig
as
a
whole,
but
sue
project
sessions
might
have
gained
new
contributors,
that's
possibly
true,
but
the
siginter
itself,
like
justin,
is
saying
we
have
been
repeating
the
same
story,
the
same
diagram
all
the
time.
I
think
that,
in
a
virtual
format,
somebody
can
share
their
screen,
show
the
same
diagram
and
that's
it.
We
don't
have
to
have
a
presentation.
We
can
explain.
A
We
have
and
pretty
much
open
the
discussion
from
there
and
we
can
have
some
project
maintenance.
I
think
it's
going
to
be
pretty
good
if
some
project
materials
are
there
to
answer
questions,
but
also
there's
a
concern
that
some
of
the
people
that
joined
this
talk
are
just
going
to
ask
project
specific
questions
which
are
more
appropriate
for
a
particular
session
of
the
super
project.
A
Instead,
I
think
the
discussion
topic
should
be
like
what
are
we
doing
exactly
like?
How
is
the
whole
picture
coming
together?
I
think
this
is
it's
it's
worth
discussing
that
it's
just
that.
A
B
If
no
one
else
wants
to
I'm
happy
to
reply
to
the
cncf
and
ask
them
if
they
will
accept
us
to
to
do
that,
I
can
also
I
don't
know
where
we
should
offer
the
fullback,
but,
like
you
know,
some
sort
of
like
five
minute
intro
video,
which
I
could
easily
put
together
today.
Right,
you
know:
here's
the
before
we
go.
You
know
that
that
might
meet
the
letter
of
the
law
for
them,
but
it
would
be
a
it
would
be
a
five
minute,
intro
video
and
not
a
not
a
full
session.
B
If,
if
there
were
no
questions,
so
they
might
not
be
happy
with
that,
if
no
one
else
is
is
if
anyone
else
feels
strongly,
I
can
I
can
reply
with
that
and
see
where
we
go
from
there,
but
yeah.
It
would
be
great.
I
it
would
be
great
if
one
way
or
another
we
we
are
able
to
have
some
people.
Other
people
attend
as
well.
B
A
I
mean
I
don't
think
we
should
even
prepare
a
five-minute
video.
I
don't
think
I
have
the
time
to
work
on
that
this
week.
If
we
can
just
ask
them
hey,
can
we
open
a
share
a
screen?
I
think
it's
possible
using
the
at
least
the
previous
platforms.
It
was
possible
to
share
a
screen.
I
think
I
don't
know
if
the
platform
is
the
same,
but
instead
of
you
know
broadcasting
a
video.
A
We
can
just
share
a
screen
and
talk
about
what
we
have
like
it
could
be
a
you
know,
a
jpeg
with
a
with
a
diagram
and
pretty
much
one
screen
of
a
summary
in
a
google
doc.
Something
like
that.
Instead
of
slides
in
a
video.
B
Okay,
well,
I
will,
I
will
open,
I
will.
I
will
send
them
an
email
asking
if
we
can
just
do
more
of
a
for
more
of
a
panel
with
screen
sharing
and
now
prepared,
and
if
they
push
back,
we
can
fall
back
to
the
five-minute
idea,
and
then
we
can
fall
back
to
cancellation.
B
B
All
right,
then,
moving
on
next
up
is
something
that
lumiere
you
added
to
the
the
minutes.
It
is
around
graduating
api
and
conflict
of
v1.
I
don't
know
if
you
want
to
talk
us
through
that
sure.
A
This
is
a
topic
that
came
after
some
discussions.
We
had
with
vince
and
fabricio
about
the
potential
to
graduate
the
cuba
dm
component
conflict
to
v1,
potentially
graduating
the
coaster
api
api
to
v1
at
some
point
as
well.
A
It
seems
like
we
have
a
lot
of
users,
but
most
of
them
are
confused.
Why
we
have
these
apis
pre
v1
for
such
long
periods
of
time,
and
it
will
be
beneficial
to
eventually
graduate
them
on
our
side.
We
have
to
maintain
them
and
not
break
the
rules
with
breaking
changes,
so
the
user's
side.
They
will
be
happy.
A
In
particular,
I
wanted
to
talk
about
what
does
a
v1
api
really
mean,
and
does
it
actually
mean
something
different
from
one
of
you,
one
api
in
kubernetes?
A
Now,
if
you
look
at
the
core
v1,
which
is
the
obviously
the
most
popular
out
there,
the
core
api,
for
instance,
has
some
rules
such
as
you
can
add
a
field
to,
for
instance,
in
the
bot
spec
of
a
pod,
and
you
just
add
added-
and
this
is
the
continuation
of
the
v1
api
itself.
A
This
is
common
in
other
projects
out
there
rest
apis,
you
can
basically
add
new
stuff
to
them,
and
as
long
as
it's
not
breaking
change,
you
don't
iterate
on
the
version
of
course,
I've
seen
some
apis
that
whenever
they
add
a
new
feature,
you
bump
the
version
to
indicate
that
this
is
something
very
important
you
know
following
somewhere.
If
a
v1
is
something
that
is,
you
know
a
stable
api.
What
happens?
If
you
add
a
big
new
feature?
Is
it
like
a
v2?
A
Then
I
hcd,
I
think,
is
a
good
example,
except
that
you
know
lcd
v3
had
breaking
changes
compared
to
v2,
but
it
still
is
a
major
increment
and
something
big
happened.
A
The
discussion
I
wanted
to
break
here
is
whether
we
are
going
to
want
to
follow
what
the
core
kubernetes
api
is
doing,
which
is
iterate
on
the
same
api.
You
know
it's
very
complicated
to
migrate
users,
away
from
core
v1
to
a
core
v2.
Now
imagine
the
complexity
around
that.
A
So
people
are
saying
that
the
core
v1
api
and
commodities
will
never
go
away.
They
there's
no
plan
to
ever
deprecate
it.
It
will
continue
to
exist
indefinitely
according
to
some
people,
but
at
some
point
it
will
happen.
A
A
A
But
there
I'm
seeing
that
the
core
api
materials
have
realized
that
there's
a
complexity,
maintaining
the
same
api,
just
incrementing
with
new
fields
inside
of
it,
but
yeah
I've
been
pushing
for
the
for
the
other
option,
which
is
to
always
increment
the
version
which
is
essentially
setting
an
api
install.
A
Now,
I'm
pretty
sure
the
quest
api
folks
will
not
like
this
model
very
well
because
of
the
complexity
of
migrating
users.
Potentially,
when
you
add
a
new
small
field,
small
feature,
maybe
to
v1
b21,
and
you
don't
want
to
increment
the
api
version
because
of
the
consumption
complexity
and
this
understandable.
But
what
are
we
going
to
do
with
v1?
Like?
Are
we
going
to
continue
the
practices
in
core
qualities,
or
do
we
want
to
do
this
like
the
cube
adm
model,
which,
in
my
opinion,
is
just
better?
A
I
just
wanted
to
open
the
discussion
here.
It's
a
very
meta
topic,
but
it's
still
worth
the
you
know
talking
about
it.
E
Thanks
yeah,
so
just
just
two
cents
on
this,
like
it's
well,
first
of
all,
like
cuba,
em
has
been
around
for
a
long
time
like
I'm
moving
it
to
b1.
It's
like
a
definitely
a
great
signal
that,
like
we
want
to,
we
definitely
won't
support
the
current
api
for
a
long
time
to
users
with
regards
to
like
how
you
know
that,
that's
a
good
question
right
like
that
like
how
do
we
go
from
there?
Where
do
we
go
from
there?
E
If
you
don't
make
breaking
changes,
you
can
just
add
things
to
the
current
api,
so
we're
like
at
feature
gates
or
things
like
that,
which
100
helps
the
maintainer
side
from
the
user
side
like
things,
can
be
confusing
from
one
minor
release
to
the
other,
where
there
are
like
changes
that,
like
folks,
need
to
keep
up
with,
but
to
be
super
realistic
at
down
to
earth
like
it's
something
that
I've
learned
just
right
now
like
to
drive
the
beta
1
api
types
in
cluster
api,
there's
tons
of
work.
E
That
needs
to
be
done
to
just
do
one
revision
like
tons
and
tons
of
work,
and
it's
really
costly
and
so
like.
I
guess
like
until,
like
we
probably
have
a
really
good
user
base
that,
like
can
do
a
bunch
of
these
chores.
I
see
it
like
really
invisible
to
upgrade
an
api
type.
Every
time
we
need
to
add
a
feature
edition.
E
So
from
from
a
sig
perspective,
like
I
guess,
should
we
let
each
sub
project
aside
depending
on
you
know
their
user
base,
because
if
they
do
have
the
help
like
to
grab
an
api
version,
I
guess
sure
why
not?
But
potentially
like
each
project
should
decide
on
its
own,
or
do
we
want
to
make
a
decision
where,
like
all
subprojects
like
have
to,
I
don't
know,
maybe
meet
the
standard
before
they
can
rev
an
api
type?
B
Yeah,
I
I
will.
I
will
echo
what
what
vid
said.
If
we
follow
the
the
rules
on
effectively
once
you
hit
so
there's
a
difference
between
alpha
beta
v,
one
right
v,
one
alpha
one
v,
one
beta
one
v,
one
right
once
you
hit
v,
you
are
not
allowed
to
break
that
anymore,
so
a
v1
yaml
file
should
work
indefinitely.
B
I
don't
have
never
heard
of
like
people
removing
a
stable
version
and
I
feel
like
that
would
be
bad
for
users
in
terms
of
the
promise
of
v1
continuing
to
work
forever
right,
but
the
reason
you're
allowed
to
add
fields
as
long
as
they
aren't
the
reason
you're
about
to
add
fields
is
that
generally-
and
there
are
exceptions
generally,
when
you
add
a
field,
it
doesn't
change
the
meaning
of
the
existing
yeah,
more
just
isn't
specified,
and
so
we
we
make
the
defaults
for
the
field.
B
So
if
the
field
is
unspecified
that
the
behavior
is
basically
as
it
was
before,
even
if
like
it
is
clearly
a
better
option
to
like
to
change
the
defaults
right,
if
we
discover
a
mistake
and
one
of
the
goals
of
the
beta
alpha
beta
process
is
to
discover
those
mistakes
in
when
they're
in
alpha
beta
and
we
are
more
allowed
to
change
them
than
we
are
in
v1.
I
think
the
machinery
is
hard,
I
think.
B
Also,
if
you
end
up
with
you,
know
six
versions,
you're
gonna
be
in
a
place
that
no
one
else
is
in
and
you're
probably
gonna
find
all
sorts
of
additional
problems
with
the
machinery.
So
I
would
be
very
wary
of
us
making
a
a
blanket
statement
in
the
sig
that
you
know
we
should
all
go
and
explore
this
area
of
multiple
major
versions
of
the
api.
I
think,
if,
if
a
project
wanted
to
explore
it,
I
don't
think
we
should
stand
in
their
way.
B
I
would
I
would
echo
vince's,
like
be
cautious
sentiment.
I'd
echo,
the
idea
that
you
know
you
don't
want
to.
As
far
as
I
know,
you're
not
going
to
get
rid
of
those
older
versions
and
I
would
hesitate
to
say
that
I
mean
kubernetes
is
still
in
tree
so
and
it's
pretty
important
to
a
lot
of
people.
So
I
would,
I
would
say,
maybe
kubernetes
isn't
the
project
to
to
be
the
guinea
pig
on
this
one
either.
B
F
Is
is
how
how
much,
how
much
feedback
has
the
project
gotten
from
users
right?
F
So
so,
if,
if
the
project
is
error
so
like
that
the
whole
point
of
right,
alpha
and
and
beta
right
is,
is
to
be
able
to
respond
to
to
pass
some
past
mistakes
or
or
unmet,
let's
say
use
cases,
and
if
you
yeah,
if
you,
I
guess,
if
you,
if
you
move
too
soon
to
to
to
v1
or
or
you
have,
if
you
limit
your
ability
to
to
change
the
api,
you
you,
I
think,
limit
your
ability
to
to
actually
like
deliver.
F
Maybe
the
features
that
your
users
want,
or
even
address,
like
gaps
that
that
your
users
report
so
yeah.
I
it's.
F
I
get,
I
guess
what
you
know,
what,
whatever,
whatever
api
version,
a
project
has
it's
like,
if
you,
if
you
end
up
at
at
a
stable
version,
you're
you're,
basically
saying
like
that.
Not
only
not
only
do
you
do
you
sort
of
you
promise
to
maintain
that,
but
you
also
essentially
you,
I
think,
effectively
promise
to
not
not
fix.
You
know,
potential
bugs
or
or
or
add
features.
B
D
Opting
in
in
arriving
also
being
said
so
opening
arriving
major
release
frequently
is
kind
of
unusual,
and
I
we
we
don't
have
to
be
the
the
guinea
pig
of
in
it
and.
D
D
I
think
that
we
can
start
trying
to
share
that
best
practice,
so
why
we
don't
organize
sig
api
reviews
when
a
new
api
is
generated,
so
we
can
basically
share
knowledge
from
one
group
to
the
another,
so
we
can,
for
instance,
there
are
common
problems
like
supporting
down
conversion
or
up
conversion
when
a
field
is
removed,
or
there
are
common
naming
that
that
will
be
interesting
to
have
consistent
occurs
across
the
project.
D
So
I
think
that
we
should
not
stop
changing
api,
but
we
should
put
some
effort
in
making
sure
that
api
that
we
create
are
better
designed
for
looking
and
then
whatever
we
can
put
on
top
of
as
best
practice.
I
think
that
this
will
make
our
api
more
stable
in
an
indirect
way,
but
better
one.
B
You
for
rich.
I
think
that
is
a
that's
an
excellent
idea.
Our
accent
suggestion
if
there
is
a
if
the
kind
api
change,
if
there
is,
if
there
is
anything
of
that
nature
it'd
be
great
to,
we
could
try
that
right.
That
feels
like
a
great
first
step,
is
to
if
there
is
an
api
change
coming
and
someone
wants
to
bring
it
to
this
group.
I
think
that
would
be
a
wonderful
thing
to
do.
B
Please
do
feel
free
to
put
it
on
the
agenda.
If
you
would,
if
you
have
such
a
thing,
we
can
at
least
like
you
can
at
least
point
people
to
the
to
a
pr
or
cap
or
your
equivalent,
and
then,
if,
if
you
want
a
deeper
discussion,
if
anyone
wants
any
discussion,
please
like
we
can,
we
should
try
that
I
think,
if
everyone's
agreeable
with
that
idea,
but
yeah,
that's
a
wonderful
suggestion
for
brazil.
B
A
So
sorry,
I'm
continuing
on
this
topic
a
little.
If
we,
if
we
decide
to
increment
apis
without
bumping
the
version,
what
is
the
best
practice
we're
going
to
establish
when
if
we,
what
if
we
want
the
users
to
track
the
changes
in
the
same
way,
for
instance,
if
you
have
a
project
that
is
0.5
and
you
have
made
additions
to
a
particular
v1
api.
B
This
act,
I
think
it's
a
great
question.
I
I
think
actually
ties
nicely
into
the
next
topic
is
also
sales
which
is
coming
up,
but
around
versioning
of
the
add-ons
themselves.
I
I
think
the
api
machinery,
so
the
apa
shooting
for
crds
in
particular,
was
particularly
lacking
because
by
default
they
didn't,
they
didn't
exclude
undefined
fields,
so
they
they
preserve.
B
They
allowed
unknown
fields
if,
if
with
a
v1
crd,
that
is
no
longer
the
default,
so
at
least
that's
a
little
bit
better
and
a
hopefully
we're
all
using
crds.
B
He
says
thinking
about
his
projects,
hopefully
we're
using
crds
that
block
additional
fields,
so
the
user
will
get
immediate
feedback
if
they
try
to
use
something
a
field
that
was
introduced
in
a
later
version
of
the
crd
that
was
defined,
I
believe,
if
they're
putting
a
new
value
into
an
enum
or
something
that
should
be
called
by
validation.
Hopefully
I
don't
think
it's
perfect
like
what
happens
if
the
crd,
if
you
install
the
latest
crd,
but
I
think
in
general,
it
is
tended
to
work
out.
B
There's
a
you
know
by
the
time
you
applied
to
the
cluster.
It's
a
little
late,
maybe-
and
so
yes,
as
fabrizio,
says
in
chat
that
there
is
perhaps
a
kep
defining
annotations
for
this
purpose,
in
other
words
adding
metadata
or
additional
metadata
to
the
open
api.
I
imagine
and
vince
thinks
that
nikita
was
working
on
it.
I
don't
know
if
anyone
has
a
link,
but
there
could
be
a
gap
in
api
machinery.
B
I
don't
think
this
situation
is
as
dire
as
it
as
it
could
be
because
of
the
way
that
we
typically
have
all
those
apis.
But
it's
not
there's
certainly
room
for
more
hints
for
users.
E
A
Yeah,
I
think
I've
looked
at
this
kept.
This
was
the
same
I
this
was
basically
tinkerine's
idea.
Nikita,
I
think
believe
executed
in
it.
But
it's
not
clear
to
me
is
how
the
escape
is
going
to
help
the
consumer.
A
E
I
don't
know,
but
I
mean,
but
at
least
like
we
would
have
the
data
to
when
we
publish
like
documentation
to
show
the
users
that
they
feel
was
added
in
a
certain
release.
A
Yeah,
I
think
it's
ultimately
mitigating
the
fact
that
we
don't
want
to
increment
on
apis,
but
I
guess
it's
a
feasible
solution
as
long
as
it's
consumable
consumable
by
the
users,
if
it's
not
easily
consumable,
then
we
have
the
same
problem.
B
I
I
agree,
I
think
I
think
we
should
raise
so
I'm
excited
to
this
cap.
I
think
we
should
also
raise
we
should
try
to
pursue
whatever
it
offers
and
like
raise
any
difficulties
with
them
right.
You
know,
like
things,
become
much
more
real
when
we
ask
you
how
to
use
them.
I
think
one
of
the
nice
things
that
this
cap
implicitly
does
is.
It
says
that
there
are
version
different
versions
of
a
v1,
crd
or
different
versions
of
a
v1
api.
B
I
think
obviously
they're
thinking
about
the
built-in
types
of
kubernetes,
but
effectively
now
a
the
v1
pod
api
will
have
a
semver
associated
to
it.
That
is
our
well,
not
a
semver,
but
a
version
associated
to
it.
That
is
our
kubernetes
version
and
in
the
same
way,
maybe
we
want
to
do
that
and
say
you
know
cluster
api.
B
Well
we're
really
going
to
the
next
conversation
now,
but
look
this
version
of
this
version
of
the
the
chaos
cluster
object
is
defined
against
the
schema
is
a
v1,
but
it
uses
function,
fields
that
are
in
the
v
1.22
version
of
chaops
and
not
the
v1
21
version
of
caps.
So
there
can
be
now
two
crds
or
a
different
crd
for
each
version.
B
That's
really
confusing,
but
it's
a
step
in
the
right
direction
is
to
sort
of
start
to
add
the
metadata
where
we
say
define
where
we
are
defining
the
versions.
B
A
Yeah,
I
guess
kubernetes
as
a
project
is
going
into
the
direction
of
meta
compilers
can
help
us
with
everything
which
is
fine.
Of
course,
you
know
I've
seen
other
projects
increment
apis
when
they
make
changes.
I
at
one
point
I
heard
that
I
briefly
spoke
with
daniel
smith
about
this.
A
He
said
that
they
they
had
a
had
an
idea
to
increment
api
versions
in
a
with
like
a
patch
format,
which
is
something
that
they
called
micro
versions
at
some
point,
but
it
was
a
lot
of
work
according
to
them,
and
I
think
it
still
requires
the
extra
conversion
between
apache
of
the
api
and
apache
data.
A
A
I
think
this
should
be
our
recommendation.
I
I
know
it's
not
clear
to
me
whether
we
should
document
it
or
not.
I
think
at
that
point
it's
probably
not
worth
it.
We
don't
have
justin.
Actually,
what
is
the
do?
You
have
a
api
in
cops
that
is
ga
already.
B
We
doubt
we're
still
happily
on
our
alpha
version.
Sort
of
opting
out
of
this
whole
whole
problem.
There
are
some
people
in
the
community,
though,
that
are
actually
trying
to
take
it
to
v1
that
have
decided
that
that
is,
it
is
no
longer
we
are.
We
are
acting
like
it's
a
v1
api,
but
we
just
haven't
actually
taken
it
to
v1,
and
some
people
are
rightly
pointing
out
and
doing
the
work
to
bring
it
to
v1
yeah.
B
I
think
I
think,
if
we
wanted
to
pursue
the
let's
call
it
december
tag
for
crds.
That
would
be
something
that
you
could
try
in
a
project
and
it's
reversible.
B
B
A
Yes
sounds
good
yeah,
I
guess
cubed
will
inevitably
experiment
in
this
field,
because
it's
the
probably
the
project
that
will
approach
va
everyone
sooner
than
other
projects,
but
yeah.
I
will
keep
you
updated
in
terms
of.
B
This
topic,
thank
you
thanks.
I
was
just
the
nice
thing
about
q8m.
Is
you
have
the
kubernetes
version
while
you
are
in
tree,
so
you
don't
have
to
define
a
new
version,
and
that
brings
us
nicely
on
to
cecil's
topic,
which
is
coming
up
now,
which
is
cecio.
You
want
to
talk
about
add-ons
and
out-of-tree
components,
lifecycle.
G
Yeah,
so
this
is
just
a
follow-up
from
a
topic
that
came
up
at
cluster
api
office
hours
and
we
thought
it'd
be
good
to
bring
it
up
here,
because
it's
a
conversation
that
concerns
everyone
on
this
group
so
with
the
more
and
more
components
being
out
of
tree
and
have
the
user
becoming
kind
of
responsible
for
managing
more
things.
G
Besides,
just
the
kubernetes
version,
like
cloud
provider
and
csi
drivers,
and
things
like
that,
I
was
just
wondering
as
a
sig:
do
we
see
that
being
part
of
our
scope
and
mission
to
handle
the
life
cycle
of
add-ons
since
it's
directly
related
to
the
life
cycle
of
the
cluster?
And
I
don't
expect
us
to
like
come
to
an
answer
today,
but
just
something
that
we
should
maybe
start
thinking
about.
I
know
there's
an
add-ons
project,
I'm
not
very
familiar
with
it.
G
B
I
I
can
give
a
quick
summary
of
like
it
is
the
cluster
add-ons
project,
specifically
because
we
are
not
trying
to
tackle
the
generic
add-ons
problem.
We
are
only
trying
to
tackle
the
problem
of
things
that
are
bound
to
the
life
cycle
of
a
cluster.
The
add-ons
pro
a
generic
add-ons
project
would
sort
of
go
into
like
sig
apps,
or
something
like
that.
So
that's
why
it's.
It
is
directly
focused
on
that.
From
that
point
of
view,
I'd
say
it
is
in
scope.
B
I
think
the
cluster
add-ons
project
is
mostly
exploring
operators
to
make
the
management
of
those
sort
of
compartmentalized
and
reusable.
B
In
other
words,
if
we
you
know,
if
we
have
these
things
and
we
don't
want,
it
would
be
a
shame
if
cube,
adm
and
k,
ops
and
cluster
api
and
any
other
tool
in
cube
spray
all
had
to
like
write
the
same
supervision
logic
for
the
cloud
controller
manager
for
whatever
cloud
you're
using,
so
that
that's
sort
of
why
it's
gone
down
the
path
of
operators,
sort
of
fettering
federating
out
the.
How
do
I
manage
these
like
the
who
knows?
Who
best
knows
how
to
run
these
components?
B
Hopefully
it
is
the
teams,
writing
them,
and
so
that's
why
we
are
hoping
that
the
teams
themselves
that
are
writing.
You
know
the
aws
cloud.
Controller
manager
will
write
an
operator
to
run
it.
Ideally,
of
course
those
will
just
be
simple:
yaml
that
can
be
cuddle
applied,
and
then
we
don't.
We
don't
have
a
great,
I
think
we'll
get
there,
but
we
don't
currently
have
a.
B
We
haven't
really
investigated
that
that
path.
Yet
you
know
whether
it's
feasible
to
say
like
actually
yaml
is
the
is
the
format
it
feels
like
it's
not
sufficient,
which
is
why
we
need
the
operators,
but
we
can
see
there's.
There
is
some
work
in
that
in
that
group,
so
that,
if
add-ons
are
just
a
straight
yaml
file,
then
we
can
have
a
very
simple
operator
that
is
minimal
and
perhaps
even
shared,
which
will
hopefully
encourage
people
to
put
their
their
operators
into
just
the
yaml.
B
In
terms
of
where
that
project
is,
you
know,
you're
obviously
welcome
to
attend,
as
is
everyone.
The
the
plan
is
to
we're
trying
to
get
integrated
into
tooling.
It
looks
like
chaops.
Will
be
the
first
to
integrate
it?
Unless
someone
wants
to
beat
me,
please
do
and
I
see
shaking
effects,
and
so,
but
the
hope
is
that
once
we
get
the
first
one,
it
was
sort
of
a
chicken
and
egg
situation
right
and
so
hope.
B
Hopefully,
once
we
get
the
first
one
add-ons
done
as
operators,
then
there
will
be
a
a
way
to
there'll,
be
a
reason
for
the
projects
to
write
operators
and
there
will
be
then
other
projects
will
feel
a
reason
to
consume
the
operators
so
like
in
chaos,
I'm
trying
to
break
the
the
deadlock,
but
that
is
sort
of
where
we
are
that
we
are
still
waiting
on
the
first
operator
to
actually
make
its
way
all
the
way
in.
G
Okay,
so
the
scope
of
that
project
that
includes
out
of
tree
cloud
providers
and
out
of
tree
csi
drivers.
B
Yes,
so
the
the
add-ons
cluster
adams
project
is
effectively
saying
we
know
we
can't
actually
write,
we,
we
can't
actually
like
manage
them
all,
so
we
will
create
the
tooling
and
the
procedures
by
which
the
the
csi
driver
for
openstack
can
write
an
operator
and
it
can
be
consumed
by
the
tooling,
in
other
words,
sort
of
the
machinery
by
which
we
can
glue
these
things
together
and
is
seeding
a
couple
of
those
operators
in
the
hope
of
sort
of
creating
the
marketplaces
that
were
seeding.
The
marketplace.
G
Got
it,
and
so
in
terms
of
timeline,
sounds
like
we're
not
quite
there,
yet
the
csi
migration
is
becoming
more
urgent
because
that's
being
enabled
by
default
in
123..
G
B
You're,
obviously
you
know
no
one's
gonna.
Stop
you
building
your
own
tooling.
I,
if
you,
if
you're,
also
very
welcome
to
contribute
to
operators
if
that's
a
good
fit
what
the
recommendation
I
give
for
people,
don't
necessarily
ready
to
do.
That
is
if
you
are
able
to
express
it
as
yaml
or
as
close
as
you
can
get
to
yaml,
then
it's
not
hard
from
yaml
to
go
to
an
operator.
B
If
that's
what
you
want
to
do
in
the
later
on,
so
to
the
extent
that
we
can
persuade
the
the
the
csi
drivers
to
publish
or
artifacts
that
are
effectively
either
an
operator
or
just
a
simple
yaml
file
that
can
be
applied,
then
we
will
all
be
better
off.
Yaml
is
is
great
because
you
know
yaml
with
no
templating
is
the
ideal,
but
it's
pretty
much
impossible
for
most
of
the
complicated
providers,
but
the
closer
we
can
get
the
better.
B
We
should
encourage
them
to
talk
to
us
in
in
cluster
add-ons
and
have
them
like
work
with
us
to
write
an
operator
if
they
are
just
producing
yaml,
then
that's
great,
and
if
we
can
encourage
that
that's
great
the
middle
ground
is
where
it
gets
tricky
like
what,
if
you
have
one
variable
you
want
to
substitute,
I
don't
know
we
have
a
bunch
of
hands
up.
I
don't
know
who
was
first
seeing
the
premiere
and
for
brazil.
B
The
answer
is,
basically
that
is
the
the
role
of
the,
so
the
operator
itself
should
be
coop
cuddle,
appliable
right,
it
should
be,
it
should
not
have
a
complicated
life
cycle
and
the
role
of
the
tool
is
to
coordinate
the
operators.
B
So
if
you're
using
kubernetes
and
refusing
chaops
that
those
tools
will
be
responsible
for
installing
the
operators,
and
we
can
try
to
make
that
easier
and
try
to
build
operators
of
operators,
but
the
general
hope
is
that
you
shouldn't
as
a
tool
have
to
do
much
more
than
specify.
You
know
I
want
this.
B
I
want
the
aws
csi
driver
and
maybe
I
put
a
an
instance
of
a
crd
that
has
some
options
that
the
user
has
provided,
but
hopefully,
ideally
not,
but
like
some
simple
crd
instance
to
describe
maybe
the
version
that
you
want,
but
not
much,
not
a
lot
of
hooking,
hopefully
required
we're
still
exploring.
I
would
say
instances
where
there
is
state
that
has
to
go
back
and
forth.
So
the
two
examples
that
we
know
of
are
we
are
read
over
time.
I
apologize.
B
The
two
examples
that
we
know
of
are,
for
example,
cube.
Dns
needs
the
ip
address
of
a
service
that
could
be
an
s
service
that
has
to
also
be
funded
into
cubelet
for
no
good
reason,
as
far
as
I
can
tell,
but
it
that's
that's
the
case
today.
So
that's
relatively
straightforward
and
you
know
we're
looking
at
ways
to
describe
that
using
yaml
would
be
nice,
in
other
words,
passing
objects
into
the
operators,
that
sort
of
thing
or
the
operators
can
discover
it
at
runtime.
B
The
other
problem,
which
is,
I
think,
thornier,
is
if
you
are
the
aws
csi
driver
not
pick
on
it
os.
You
need
some
iam
for
permissions
or
you
are.
You
very
likely
need
some
iem
permissions
to
actually
do
the
course
of
the
ec2bs
api
and
how
do
we?
How
do
we
do
that?
And
we
don't
have
a
great
answer
for
that
yeah
we
just
did.
A
Just
a
quick
question
from
me:
I
mean
also
a
comment.
I
guess
when
me
fabricio
and
me
investigated,
potentially
the
whole
concept
of
cooking
operators
into
cubadiem.
We
acknowledge
that
a
lot
of
distributions
users
building
on
top
of
kubernetes
need
air-gapped
solution,
air
gap
solution,
which
means
that
something
has
to
pipe
the
required
operator
images
to
the
deployer,
which
was
we
kind
of
realized.
A
One
of
the
more
complicated
aspects
of
this
I
mean
I
don't
want
a
response
right
now,
but
it's
probably,
I
think
you
also
saw
this
as
a
problem.
I
guess.
B
We
I'll
quickly
say
what
we
we
did
manage.
We
had
a
a
user
who
championed
this
use
case
in
chaops
as
well,
and
we
managed
to
satisfy
them
by
effectively.
We
have
a
a
mode
of
operation
which
we're
going
to
add,
which
pre-renders
the
yaml
so
runs
the
operator
to
completely
client-side.
It
does
therefore
require
or
brings
the
dependency
on
docker
in
order
to
run
that
operator.
But
the
idea
is
that,
if
you
want
the
sort
of
traditional
behavior,
you
can
run
an
operator
client
side,
have
it
in
this
one-shot
mode.
B
Have
it
generate
the
yaml?
Maybe
it
can
generate
the
iem
permissions
as
well.
Maybe
that's
the
way
around
that,
but
that's
how
we
can
do
that
and
then
we
can
use
the
same
way.
We've
always
done
it.
Where
you
know
we
can
spit
out
a
list
of
images
if
you
want
to
sidelit
them
or
upload
them
to
your
cache
or
mirror.
B
G
Yeah
just
a
question
on
what
you
said
earlier:
if
we
did
have
a
simple
yaml
for
the
let's
say
the
csi
driver,
how
would
we
go
about
like
making
sure
the
version
is
in
sync,
with
the
kubernetes
version?
Is
that
on
the
user
to
go
and
reapply
or
how
does
that
work?.
B
In
my
opinion,
that
is
on
the
the
packaging
tool,
so
you
could
argue
cluster
api
would
take
that
responsibility
like
it
should
be
specified
in
the
cluster
and
the
like.
You
probably
have
a
list
of
you
know
this
kubernetes
version
with
this
csi
driver
and
this
like
controller
manager
or
cloud
controller
manager.
B
You
could
also
put
that
logic
into
the
operator.
I
feel
like
that's
not
ideal,
but
you
know
if
you
have,
if
you
have
additional
requirements
like
you
know
that
you
can't
work
with
a
particular
kubernetes
version.
You
are
very
welcome
an
operator
to
verify
that
it's
a
little
confusing
to
to
do
that.
I
think
so.
My
guess
would
be
that
we
should
probably
have
some
form
of
manifest
which
describes
you
know:
hey,
I'm
going
to
install
kubernetes
124
and
it's
going
to
have.
B
You
know
obviously
the
kubernetes
components,
but
it's
also
going
to
have
on
aws
this
set
of
this
set
of
deployments
and
demand
sets,
and
ideally
that
would
be
what
we
end-to-end
test
so
that
you
know
we
we
have
to.
We
have
to
figure
this
out
in
general
in
the
project.
B
If
we're
going
to
have
end
to
end
testing,
that
includes
cloud
providers,
it's
now
going
to
have
to
be
some
combination,
so
we
should
also
publish
if
we're
going
to,
if
we're
going
to
go
to
all
the
expense
of
doing
the
testing,
we
should
probably
publish
what
it
is
that
has
passed
the
testing,
but
that
is
getting
into
lumiere's.
Previous
discussion
of
you
know
a
distro
type
thing
we
are.
We
are
being
pushed
down
that
path.
I
think.
B
We
are,
I
have
I've,
done
a
terrible
job
of
time
management,
so
I
apologize
we're
not
gonna
have
time
on
for
the
subproject
updates.
I
probably
just
do
them
next
time
and
we
use
the
last
minute
for
lubemirs
hand.
F
A
F
A
You
found
some
r
related
problems
in
when
you
try
to
write.
The
coordinates
operator
is
is,
is
that
was
that
something
that
cube
builder
like
a
cube
builder
artifact,
or
what?
What
was
the
underlying
problem
there
like?
I
have
a
suspicion
that
when
we
write
an
operator,
it's
not
slim
enough,
it's
just
too
much
stuff.
We
are
adding
too
much
stuff
into
the
operator
unnecessary
stuff,
and
this
is
like
a
framework
problem.
The
framework
we're
using
is
potentially
too
heavy.
What
do
you
think
about
that?.
B
One
of
the
things
that
has
evolved
in
the
way
we've
done
operators
is,
we
we
don't
encourage.
We
are.
We
are
moving
away
from
the
idea
that
the
operator
should
install,
for
example,
the
cluster
role,
because
there's
no
point
the.
If
you
want
to
install
a
cluster
role,
the
rbac
rules
mean
that
the
operator
you
have
to
give
that
role
to
the
operator.
So
you
can't
change
the
cluster
role
anyway.
So
effectively.
B
You
end
up
with
a
situation
where
the
the
custom
role
is
a
property
of
the
version
of
the
operator,
and
we
can
enforce
we
can
in
the
operator.
We
can
verify
that
these
things
are
in
place,
but
there's
no
point
in
trying
to
and
block
upgrades
if
they're
not
in
place,
but
there's
no
point
in
trying
to
apply
them,
and
we
do
end
up
with
much
slimmer
things
that
we
actually
apply
and
we
end
up
with
a
sort
of
side,
a
bigger
description
of
the
operator.
B
The
are
back
type
permissions
for
the
things
which
are
going
to
be
running
so
from
that
point
of
view
it
is,
it
is
nice,
it
is
slimmer,
it
makes
the
operator
itself
less
like
simpler
and
it
it
does
tend
to
push
people
hopefully
more
towards
playing
yammel,
which
would
not
be
a
bad
thing,
and
then
the
operator
can
maintain
fairly
small,
just
like
hopefully
just
including
code
like
the
knowledge
of
the
rules.
So
if
the
user
does
deviate
from
the
default
tested
manifest,
it
will
say.
B
B
I
think
that'll
be
a
great
thing
and
in
terms
of
the
so
that's
sort
of
the
complexity
of
the
operator
in
terms
of
the
weight
of
the
operator,
you
know
they're
they're,
getting
pretty
small
and
we're
like
doing
some
optimizations
to
try
to
make
them
that
little
bit
smaller,
a
basic
process
that
that
is
only
like
picking
the
kubernetes
api
server
and
watching
a
couple
of
objects
can
be
very
lightweight.
It's
still
much
more
heavy
than
we
would
like,
but
we
are
making
progress
there.
B
Of
time,
thank
you
all.
I
apologize
for
not
saving
enough
time
for
the
subprojects
and
we
will
see
everyone
in
two
weeks.