►
From YouTube: 20190908 sig cluster lifecycle
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
today
is
september,
8th
2020..
This
is
the
standard
seed
cluster
lifecycle
call.
We
have
fairly
low
attendance
today,
so
we
might
keep
it
short.
There's
a
couple
of
items
in
the
agenda.
The
first
one
is
actually
from
craig
peters,
but
he
doesn't
appear
to
be
here.
B
I
do
in
the
shadow
for
war
group
lts.
There
was
a
discussion
like
what
is
the
general
opinion
about
blue
green
coaster
upgrades
and
a
few
people
dropped
a
comment,
and
I
guess
craig
said
that
this
should
be
brought
to
the
sequest
lifecycle
meeting
for
an
opinion.
I
did
not
object.
A
B
A
I
think
the
problem
here
is
that
it's
totally
up
to
the
people
managing
the
environment,
about
what
their
tolerance
for
risk
is,
and
we
don't
really
have
formal
opinions.
We
might
have
like
practices
that
people
could
adopt,
maybe
a
documentation
about
like
best
practices
that
we've
seen.
But
I
don't.
A
I
don't
expect
us
to
have
formalized
opinions
because
the
way
people
use
it
our
tooling
in
the
wild
is
so
varied
that
I
think
it
would
be
wrong
for
us
to.
A
You
know:
try
to
have
opinions
versus
sort
of
like
guidelines.
I
guess
is
probably
a
better
term.
What
do
you
think
lubamir
or
justin,
or
anyone
for
that
matter?.
C
I
I
think
one
of
the
things
we
can
maybe
say
is
because
of
volumes
and
storage.
We
can't
say
you
must
do
blue
green
right.
We
have
to
work
in
place,
is
a
valid
kubernetes
upgrade
strategy
and
for
some
people
it
is
the
only
realistic
kubernetes
upgrade
strategy.
B
I
guess
what
the
ask
here
is
to
potentially
have
this
support
path
like
how?
How
can
you
migrate
storage?
How
can
you
migrate
api
objects
that
are
no
longer
supported
in
the
new
version?
You
know
the
green
cluster,
sorry,
which
one
was
the
the
original
question,
which
one
is
the
future
blue
green.
C
B
Yeah
yeah,
the
discussion,
I
think,
was
around
the
who
can
develop
this,
this
migration
tooling,
to
perform
the
migration.
It's
it's
a
big
ask
the
you
know.
Sixth
storage
has
to
be
involved.
Seagate
machine
has
to
be.
A
This
is
kind
of
like
this
kind
of
hits
multi-clustering
right
so
and
multi-clustering
is,
I
mean,
we're
a
horizontal
sig,
but
I
think
that
this
particular
ass
kind
of
hits
multi-clustering
and
but
at
the
same
time
like
there's
this
weird
space
of
asks
that
we
that
kind
of
occur
that
will
touch
everything,
and
I
don't
necessarily
know
that
we
should,
I
don't
know
we
have
enough
problems
just
trying
to
like
we
don't
even
clean
up
our
own
messes
from
the
early
years
that
I
don't
really
want
to
like
tread
near
a
black
hole
and
get
sucked
into
it
when,
like
I
think,
multi-clustering
is
a
highly
opinionated
space,
where
I
don't
think
the
system
has
been
built
from
inception
to
be
able
to
handle
this
in
a
very
clean,
cohesive
manner.
C
B
How
how
are
we
going
to
handle
it,
I'm
not
sure,
maybe
with
a
doc.
Maybe
with
a
guideline
like
tim,
is
saying.
A
But
I
think,
there's
a
whole
slew
of
tooling
required
to
make
some
of
those
practices
for
real
real.
You
know
and
we'll
have
to
basically
punt
once
it
gets
to
that
point.
B
A
Of
course
yeah,
it's
all
theoretical
based
upon
object,
versioning
right
like
because
you
know,
if
the
object
versions
are
stable
and
v1
types,
then
the
answer
is
maybe,
but
if
the
object
versions
are
not
stable,
there's
no
guarantee
that
you
can
have
the
capability
of
being
able
to
do
this.
So
but
again,
I
think
that
this
is
the
wrong
venue
to
do
this
type
of
conversation,
because
it
touches
so
many
other
areas.
C
Yeah,
I
agree
with
that.
I
feel
like
we
to
the
extent
we
have
we,
we
should
make
the
in-place
upgrade
case,
work
well
for
the
supported
scenario,
which
is
like
going
through
every
minor
version,
one
at
a
time,
and
the
other
stuff,
I
think,
is
not
interesting,
but
not
our
remit
and
touches
on
things
that
have
nothing
to
do
with
things
that
we
are
building.
Yep
agreed.
A
I'm
actually,
ironically
enough,
having
a
conversation
with
craig
later
on
today,
so
maybe
I'll
follow
up
with
him
offline
and
see.
If
there's
other
questions
he
had
regarding
this,
and
if
there
are
specific
items
that
he'd
like
to
see,
then
I
can
see
if
we
can
follow
up
with
him
afterwards.
B
The
mirror
yeah.
This
is
a
reminder
that
the
deadline
for
submissions
for
the
maintainer
track
of
kipcon
in
a
2020
is
the
13th
of
september.
That's,
I
guess
monday
is
deadline
next
monday,
so
we
have
again
one
sig
intro
and
through
three
subproject
talks.
B
I'm
not
sure
if
we
are
going
to
be
able
to
decide
which
subproject
talks
to
include
here
or
we
should
do
it
offline.
But
does
anybody
have
any
opinions.
A
A
Usually
one
of
the
things
we
wanted
to
do
with
the
sub
projects
was
to
split
them
across
the
venues.
So
that
way
we
didn't
monopolize.
You
know
the
kubecons
with
one
subproject.
C
I
can
I
can
perhaps
phrase
that
a
different
way
I
think
lumiere
and
I
did
did
the
intro
talk
for
eu
and
I
think
these
sort
of
talks
will
favor
sub
projects
that
don't
want
a
sort
of
two-way
conversation
with
their
users.
So
if
there
are,
if
there
are
some
projects
that
want
to
essentially
do
a
sort
of
state
of
the
union
address,
some
sort
of
like
here
is
where
we
are
some
sort
of
introduction,
if
that
they
can
get
benefit
from
that.
C
That's
who
I
feel
like
would
be
a
good
match
for
that.
Honestly,
I
don't
it's
not
really
like
the
value
I
get
out
of
cops
like
I.
I
don't.
I
don't
feel
like
that's
any
other
projects,
I'm
really
involved
in,
but
if
there
are
ones
like
that,
that
could
actually
use
that
time
well
or
do
a
compelling
like
maybe
cluster
api
could
do
a
really
cool
demo
right
and
that
might
actually
work
really
well,
but
I
feel
like
I
agree
that
there
is
some
missing
thing
for
the
sort
of
two-way
interaction.
A
Did
I'd
be
interested
to
know
like
how
folks
felt
that
or
what
folks
felt
the
value
was
out
of
the
kukan
eu
talks?
Did
they
think
it
was
good?
It
was
bad,
it
wasn't
different.
I
think
that
that
might
be
helpful
information
to
help
guide
the.
A
Well,
attendees
and
speakers
so
like
were
you
able
to
actually
talk?
I
mean
the
biggest
thing
of
kubecon
is
being
able
to
talk
with
people
right
or
to
have
a
dialogue,
and
if
it's
just
you
talking
into
a
video
and
pre-recording
it
without
any
feedback
and
q
a
I
you
know,
we
could
just
record
videos
and
just
be
done
with
it,
because,
but
if
there
is
q,
a
or
follow-up
that
occurred,
I
think
that's
the
biggest
value
of
doing
these
talks.
To
be
honest,.
G
Yeah,
maybe
I'll
just
give
some
feedback
from
duke
on
the
eu.
Given
that
me
and
cecile
did
the
class
api
talk,
we
had
about
eight
questions,
I
guess
in
the
q
a-
and
there
was
a
few
more
in
the
slack,
but
I
would
say
the
majority
of
the
interactions
around
cluster
api
were
actually
in
relation
to
katie.
Comanche's
talk
in
the
cluster
operations
track
less
so
in
the
maintain
maintainer
track.
So
I
I
don't
know
how
much
well.
I
was
too
unfair
from
that,
but
that's
my
impression.
B
B
the
coaster.
Api
meeting
obviously
had
a
good
number
of
questions.
So
it's
for
me.
It's
pretty
much
the
same
in
terms
of
interest.
Also,
apparently,
the
number
of
attendees
that
we
got
from
nancy
were
quite
similar
to
the
live
attendance
people
at
the
live
event.
B
If
we
submit
something,
my
recommendation
would
be
to
focus
on
the
alpha
projects
that
we
have
the
new
the
new
stuff.
A
Well,
I
mean
if
there
is
interest
and
feedback
and
if
you
are
getting
users
and
people
who
are
interested
in
finding
out
more,
that
is
worthwhile
to
be
able
to
get
it
rolling.
I
think
the
standard
policy
we
were
trying
to
adhere
to
before
was
to
make
sure
we
rotated
people
around
rotated
some
of
the
sub-projects
around.
A
I
think
we
could
probably
do
that
as
part
of
this
and
maybe
highlight
some
of
the
the
upcoming
or
newer
efforts.
I
think
that's
a
reasonable
thing
to
do.
It'd
be
nice
to
know
too.
I
wish
we
had
like
survey
results.
That
said
like
we're,
where
the
community
wanted
us
to
give
feedback
on,
I
think
that
would
probably
help
guide
some
of
our
our
choices,
but
I
think,
in
absence
of
that,
maybe
we
can
do
that
as
part
of
north
america.
A
I
don't
know
if
we
if
they
have
like
any
sort
of
feedback
loop
from
the
participants,
but
if
they
do
then
maybe
we
could
try
to
see
what
people
want
to
talk
about.
We
obviously
should
give
the
intro
session,
and
then
we
can
probably
talk
about
the
we
can,
maybe
figure
out
which,
which
talks
we
should
rotate
through
this
cycle.
B
A
Why
don't
we
follow
up
offline?
We
can
send
an
email
today.
I
can
do
that
after
this
meeting
and
we
can
figure
out
what
we're
gonna
do.
A
D
B
B
B
Some
of
these
are
quite
interesting
so
like
what
are
your
roles,
mostly
developers,
operations,
continents,
europe
and
north
america.
B
So
this
I
think
this
was
kind
of
misleading,
because
technology
software
is
also
technology,
so
yeah,
I
did
not
prepare
this.
Aws
is
the
environment,
the
preferred
environment
also
bare
battle.
D
B
Okay.
How
many
questions
do
you
have
in
production,
mostly
below
10.
average
number
of
nodes?
This?
Maybe
this
should
have
been
the
maximum
number
of
nodes
to
be
able
to
estimate
if
people
have
large
scale
clusters
in
production,
but
it's
mostly
below
10,
f,
2050
also
10
to
20.,
however,
ability
this,
in
contrast
to
the
previous
survey
that
we
had
for
cuba.
Dm
high
availability
was
not
really
that
popular
yet
a
couple
of
years
ago-
and
now
we
have
mostly
mostly
all
the
responses
here
using
aj.
B
The
conformal
sweet
people-
22
percent-
are
saying
yes,
mostly.
No,
they
have
plans
to
do
that,
so
maybe
in
a
forward
we're
going
to
see
more
people
doing
that
this
is
probably
the
most
interesting
question
is
the
what
is
the
oldest
version
of
kubernetes
that
you
have
so
this
was
done
before
the
release
of
119
like
exactly
before
the
release,
so
it
doesn't
include
it,
but
I
I
guess
it
might
have
taken
some
people
away
from
the
118
pie
twice
and
have
more
people
in
119,
but
this
is
obviously
a
split.
B
The
concerned
areas
is
obviously
people
outside
of
the
skill.
So
at
the
time
of
the
survey,
115
was
already
out
of
skill,
114
113.
So
this
is
a
or
older.
I
guess.
D
B
12,
that's
20
years,
like
40,
approximately.
A
A
Well,
one
of
the
questions
I
was
posing
to
the
release
team:
is
that
not
just
lts
to
four
but
pushing
out
the
number
of
releases
to
be
three
a
year
to
give
more
absorption
and
have
a
longer
lead
time
because,
like
for
a
year
like,
in
my
opinion,
is
kind
of
worthless
because,
like
that
fourth
release
is
always
a
mess,
it
always
has
been
traditionally
like
we've,
you
know
slammed
in
features.
It's
never
been
a
good
release.
A
It's
it
has
a
bunch
of
issues
with
it,
so
I'm
just
questioning
whether
or
not
we
should
use
some
of
this
data
to
push
back,
to
justify
to
the
release
team.
To
say
that
hey,
you
have
40
of
your
users
doing
this.
You
know,
at
least
in
the
feedback
survey
like
why
don't
we
have
the
serious
conversation
of
potentially
only
having
three
releases
a
year
in
supporting
for
a
longer
time
for
him.
A
It's
interesting,
though,
because
we
manage
our
tooling
manages
a
lot
of
this
stuff
right.
It
doesn't
obviously
manage
some
of
the
breaks
that
we
usually
uncover
as
part
of
release
process,
but
it
it
does
manage
the
actual
upgrade
and
migration
for
them,
both
in
cluster
and
or
both
in
place
and
with
the
immutable
fashion.
So
I'm
curious,
like
we
shouldn't,
really
ask
for
the
people
who
are
out
of
date,
like
what
is
your?
What
is
your
largest
concern,
and
maybe
what
tooling
are
you
using.
B
I
think
some
of
the
responses
later
direct
responses
in
the
survey
indicate
api
as
the
a
breaking
api
changes
as
the
major
factor
around
this,
because
when
you
migrate
sorry,
when
you
upgrade
the
cluster
to
a
new
version,
mutable
or
immutable
upgrades,
that's
fine,
but
you
still
have
developers
and
applications
that
try
to
deploy
on
the
new
version
of
the
question.
All
of
that
is
broken.
A
Yeah,
let's
take
this
particular
item
to
like
sig
release
and
also
talk
with
jordan
because,
like
you
know,
hit
jordan's
effort
to
like
mature
the
apis
and
prune
the
api
surface
area.
I
think
that
this
this
helps
to
justify
that
conversation
to
be
more
aggressive.
B
B
Yes,
how
often
do
we
upgrade?
We
have
18
saying
that
they
upgrade
every
pass
release.
Every
release
is
the
the
highest
numbers
here
with
32
percent
every
two
releases.
We
also
have
some
people
that
never
upgrade,
which
is,
of
course,
a
use
case
or
every
year
and
less
often
it's
a
nine
people
responding
to
that.
B
I
so
I'm
happy
with
this
chart,
but
they're
not
really
happy
with
this
one.
So
this
this
is
showing
us
that
people
are
within
skill,
like
the
majority,
obviously,
but
there's
still
a
lot
of
people
that
don't
upgrade
or
don't
plan
to
upgrade
ever.
A
B
I
think
the
kubernetes
project
in
general
is
lacking
this
direct
direct
feedback,
like
the
only
instance
of
somebody
discussing
how
they
do
large
production
upgrades
in
a
you
know,
a
public
discussion
was
when
or
lts
invited
somebody
from
a
european
company
that
sells.
You
know
shoes
and
clothes
and
they
explained
in
detail
how
they
manage
upgrades
and
what
are
the
problems
they
have?
I
think
we
have
this
disconnect
between
consumers
and
consumers
of
kubernetes
and
the
developers,
and
I'm
not
sure
whose
fault
is.
A
That
it's
kind
of
like
you,
have
a
tool
smith
and
then
you
have
a
tool
and
you
and
we
don't
have
instructions
for
all
the
details
of
the
tool.
So
it's
like
you
know
I
can
use
my
wrench
as
a
hammer,
but
is
that
a
good
idea?
The
answer
is
probably
no.
I
think
that
those
guidelines
we
talked
about
earlier,
I
think,
would
be
really
helpful
to
talk
about
like
here's,
the
different
types
of
deployment
scenarios,
here's
the
different
patterns,
we've
seen
that
are
successful.
A
Here's
what
you
don't
want
to
do!
You
know
I,
I
think
it's
incumbent
upon
us
to
like
really
document
some
of
this
stuff
to
you
know
as
it
is
like
a
user
guide
like
hey,
you
know,
if
you
don't
upgrade
your
cluster
here's.
What
can
happen.
A
You
know
and
and
really
outline
some
of
the
the
user
stories
and
the
user
journeys
and
what
they.
H
H
I
I
found
hinting
jacobs
because
I
attended
several
of
the
talks
that
zolando
presented
about
like
here's,
how
we
do
cluster
lifecycle
management
and
I
went
down
the
path
of
like
what
they
do
for
crystal
cycle
management
and
they
have
their
own
go
application
that
they've
written
that
does
their
own
process
and
that's
how
I
ended
up
here,
because
that
is
neat
for
them.
But
man
there's
no
documentation,
no
good
support
and
no
clear
road
map
and
no
way
to
openly
contribute
to
that
right.
H
A
A
Like
you
know,
here's
well
beaten
paths
that
we've
seen
in
the
community
over
time
and
here's
some
of
the
talks
that
you
can
see
and
here's
some
of
the
horror
stories,
and
we
recommend
you
do
these
things
and
we
we,
we
generally
don't
recommend
you
do
these
other
things,
and
we've
never
really
taken
that
stance
in
documentation
because
it
was
always
fractal,
but
I
think
that
we
need
to.
I
think
what
this
conversation
today
is
pointing
me
at
is.
We
really
need
to
do
that.
A
Just
like
two
years
ago,
we
knew
h.a.
We
had
to
get
aha
everywhere
and
particularly
opinionated
versions
of
aj
everywhere.
So
we
we
got
that
done.
I
think
this
survey
is
pointing
out
to
like
people
are
using
the
knife
wrench
and
stabbing
themselves.
So,
let's,
let's,
let's
give
them
guidelines
for
how
to
use
the
knife
or
the
wrench.
B
B
So
this
is
a
direct
question
like
what
problems
people
faced.
We
have
some
responses
here,
critical
patches,
each
version.
I
think
this
is
the
most
accurate
answer
that
people
basically
should
do
this.
The
reasoning
behind
it
is
security
fixes
and
making
sure
that
you
don't
fall
outside
of
the
skew.
B
Upgrade
what
challenges
have
you
faced,
like
I
mentioned
that
we
see
a
number
of
mentions
about
api
problems.
B
Api
may
block.
B
So
this
is
a
question
around
how
many
times
people
would
like
where
it
is
to
release,
and
I
was
surprised
that
not
so
many
responded
with
either
yes
or
no.
A
lot
of
people
are
not
sure
what
this
implies.
Well,
it
also
implies
a
higher
support
window,
because
if
you
release
left
software,
you
give
you
create
a
basically
once
this
particular
release
is
over.
D
A
This
is
all
about
language.
I
think
that
if
they
don't
understand
what
the
implication
is,
I
think,
if
you
were
to
ask
most
people
like,
would
you
prefer
a
nine-month
support
window
or
a
one-year
support
window?
The
answer
would
probably
be
overwhelmingly
one
year
instead
of
nine
months,
so
I
think
it's
just
they
don't
understand
the
context
of
the
question.
So
I
think
that's
what
the
not
sure
is
about
a
lot
of
people
don't
understand
what
the
upstream
support
policy
is
yeah,
but.
B
Also,
the
one
release.
Sorry,
one
year,
support
window
change
already
happened,
so
we
are
assuming
that
people
already
know
about
it.
A
Well,
that's
not
in
perpetuity
if
you
read
the
the
doc
that
that's
only
for
the
119
release
the
so
in
order
for
us
to
do
the
this.
I
talked
with
steven
about
this.
I'm
like
I'd.
Much
prefer
us
to
have
like
a
a
uniform
policy
for
all
of
kubernetes
to
be
consistent,
and
you
know
to
make
sure
that
we,
when
we
release
artifacts,
we
release
them
more
stably
and
do
less
releases
every
year.
A
But
that
policy
is
not
it's
only
for
119.
right.
It's
not
necessarily
for
the
rest
of
kubernetes
and
forevers.
B
Personally,
I
would
prefer
if
this
change
actually
happens
one
day,
because
for
the
same
argument
that
you
brought
that
the
fourth
release
is
always
a
bit
rushed
and
during
the
holidays,
it's
really
not
a
like.
Like
a
normal
release,
it
feels.
B
Also,
I'm
going
to
discuss
this
with
you
know.
Working
group
lts
see
what
they
think
about.
B
B
This
is
the
operating
system.
Question
operating
system,
slash,
distro
ubuntu
is
winning
with
62.
These
are
pretty
much
the
same
numbers
we
got
a
couple
of
years
ago.
B
B
But
still
possibility,
this
is
the
the
cri.
The
container
runtime
question
docker
is
currently
at
56
percent
compared
to
the
kubernetes
survey.
This
has
dropped
with
four
percent.
Only
but
container
d
has
increased
its
presence
before
that
we
had
cryo
container
d,
pretty
much
having
the
same
15
and
the
rest
was
sparse,
but
I
guess
container
d
is
gathering
more
users
from
the
cryo
side.
B
B
This
is
a
very
large
increase
for
calico,
I
believe
in
the
last
survey
we
have
weave
flutter,
calico
and
cilium
having
pretty
much
the
same
numbers,
but
now
we
have
calico
having
almost
40
percent
and
we
have
us
almost
even
split
between
flannel
and
celium.
A
I
would
like
still
like
the
support
capabilities,
for
I
mean
we
removed
flannel
from
our
documentation
because,
like
the
window
of
support
for
flannel
and
their
update
plans
was
just
lagging
because
they
don't,
they
have
people
that
are
kind
of
maintaining
the
project
and
doing
releases.
But
it's
not
like
under
active
development.
A
B
So
because
of
political
reasons,
we
had
to
remove
the
cni
examples
from
the
kubernetes
page
completely.
B
Now,
nowadays
we
just
link
to
the
whole
list
of
cni
from
there.
You
can
pick
the
cni
that
you
want.
Kubernetes
no
longer
prefers.
Flana
was
one
of
its
cni
plugins.
I
agree.
It's
not
well
maintained,
unfortunately,
but
it's.
It
has
a
historic
impact
because
people
just
can't
use
it.
A
Okay,
well
so
long
as
we
don't
have
documentation
on
our
side.
That
calls
it
out-
and
maybe
we
should
put
this
in
the
guidelines
too,
like
you
know,
make
sure
that
you
have
well
supported
cni's
that
are
actively
maintained
and
keep
up
to
date
and
actually
are
tested
as
part
of
upstream
right.
B
B
This
question
was
about
how
do
you
consume
kubernetes?
The
the
winner
is
substring
packages,
which
indicates
to
us
and
sig
release
that
we
should
continue
maintaining
these
packages
and
binaries.
B
B
We
have
still
some
folks
that
are
building
internally,
maybe
applying
patches
varieties.
B
This
is
the
a
very
puzzling
bare
metal
question
that
we
had.
B
I
honestly
all
I
only
know
two
of
these,
like
I
really
don't
know
all
these
bare
metal
providers,
but
the
way
so
the
winner
here
is
not
using.
E
B
And
the
rest
is
a
like:
a
one
percent
split
across
different
providers.
B
How
do
we
prepare
your
operating
system
for
kubernetes
the
winner
here?
Is
we
use
operating
system
images
supplied
by
the
distribution,
which
basically
means
that
you
may
be
taking
a
vanilla
ubuntu
to
sell
communities
on
it?
This
has
a
risk
because,
in
the
past,
ubuntu
did
break
kubernetes
completely
with
systemd
resolve
changes
the
second
place.
Here
we
have,
we
built
our
own
operating
system
images.
B
Now
you
you
can
base
your
kubernetes
ready,
distro
based
on
an
existing
distro,
so
not
surprising
that
this
is
this,
the
second
piece
of
the
chart.
The
second
has
piece
of
the
chart.
A
You
know
we
have
an
image
builder
subproject,
it's
getting
used
pretty
widely
like
we
should.
We
should
implement
or
talk
about
why
it's
the
best
practice
for
immutability
and
just
for
management
of
it,
and
what
that
means.
I'm
going
to
take
note
there
too,
as
well.
This.
A
B
This
includes
some
direct
responses
around
what
people
do
for
preparing
os
images.
Somebody
says
too
many
to
list.
They
use
the
image
builder.
B
Do
you
sell
the
skating
groups
to
manage
your
kubernetes
loads?
The
majority
says
yes
also,
maybe
in
the
future.
So
this
seems
to
be
something
that
we're
going
to
see
more
of
and
potentially
the
whole
chart
can
be.
We
do
use
out.
F
C
Groups-
sorry,
just
on
that
that
one
one
gotcha
with
cops
is
even
if
you're
not
order
scaling.
We
run
in
an
auto
scaling,
aws,
auto
scaling
group
for
resiliency
resiliency,
I.e
to
relaunch
so
some
wiggle
room.
In
that
question,
I
guess.
B
B
B
E
And
would
love?
Is
there
a
way
this
survey
results
can
be
shared
somewhere
that
I
can
access
offline.
B
B
B
Do
you
run
production
questions
with
cube
adm?
We
have
like
65,
yes,
maybe
in
the
future
20
low.
This
is
a
very
detailed
question.
It's
to
pretty
much
explain
what
are
the
most
important
features
to
you,
I'm
going
to
leave
this
to
the
kubernetes,
because
it's
very
specific.
B
Do
you
treat
your
kubernetes
nodes
immutable,
for
example,
delete
all
nodes
and
join
new
ones?
I
was
surprised
that
we
have
40
of
the
users
that
do
that.
It's
really
interesting,
because
qb
really
does
not
support
this
or
or
in
terms
of
documentation.
We
don't
support
it.
So
maybe
we
should.
This
is
an
indication
for
me
that
we
should
write
docs
for
it.
How
how
can
you
perform
immutable
upgrades
using
kubernetes.
B
This
is
a
question
about
the
cube
adm
operator.
This
is
a
custom
management,
really
declarative
approach.
People
are
interested
about
it.
B
B
What
types
of
changes
do
you
want
the
operator
to
support?
I
think
the
highest
response
here
was
ca.
Rotation.
B
B
Yes,
is
it
so
it's
yeah,
it's
this
one.
It's
a
reconfigure
control
play
comparts
such
as
the
cube
api
server.
I
guess
this
was
also
the
same
here
kind
of
obstructions.
Okay.
B
This
is
not
a
surprise
for
the
cuban
maintainers
users
wanted
this
for
a
very
long
time.
It's
a
complicated
use
case,
most
desired
kubernetes
feature.
We
can
leave
this
to
the
cubed
materials.
We
don't
have
a
like
a
theme
here
in
the
the
feature
requests
section
because
challenge.
B
I
think
we
we
are
maybe
failing
around
the
configuration
documentation.
In
fact,
I
have
a
issue
worked
in
the
community's
website
for
that
how
to
find
the
the
docs
for
the
kubernetes
config
file.
B
B
Are
you
running
cluster
api
production,
27,
saying
yes,
no
r27
again
and
maybe
in
the
future,
is
the
majority
how
to
install
and
manage
quest
api?
So
I
funny
funny
thing:
I
was
observing
how
this
pie
chart
evolves
and
it
was
like,
like
a
split
all
the
time
until
we
more
people
joined
with
responses
and
it
it
got
to
a
point
where
kosokoro
was
winning
with
majority.
But
this
it
was
like
a
most
of
the
time.
It
was
basically
even
split
between
different.
B
B
Okay,
also,
we
seem
to
have
people
using
their
own
way
to
do
it.
B
Even
git
pool
do
you
use,
could
kubernetes
control
plate
to
manage
your
control
plane?
Double
sorry,
the
majority
is
saying
no,
but
I
would
like
to
yes
27
what
quasar
api
infrastructure
provider
are
using
the
winner
with
four
responses
is
aws.
B
B
B
B
B
B
So
this
is
for
lcd,
this
section
about
hcd
adm.
I
think
pretty
much
near
the
ends
at
this
point.
How?
How
would
how
do
you
mine
it
manage
hcd?
I
think
the
response
here
is:
does
he
is
a
service,
may
call
it
on
the
hd
cluster?
B
I
The
previous
question:
I
think
it
was
I
I
was
asking:
where
would
you
prefer
to
manage
that
and
I
think
the
that
response
right?
That's
that's
aspirational,
except
in
the
case
of
cops
which
uses
fcd
manager.
Justin.
Would
you
would
you
agree
that
that's
that's
what
that
case
corresponds
to
like.
F
C
B
All
right,
how
would
you
prefer
to
run
hcd?
The
majority
responded
as
a
static
port
managed
by
the
couplet
second
place
and
third
place.
Sorry
second
place
is
with
a
service
manager
like
systemd
and
a
pretty
high
percentage.
B
Don't
think
it
matters
if
your
etsy
requester
fails.
What
would
you
do?
78
percent
almost
responded
that
they
would
like
to
recover
that
sequester.
Instead
of
tearing
it
down
the
most
challenging
aspect
around
the
city
management
is,
this
is
got
13
responses
here
we
have
responsible
search
secrets,
recovery
from
backup.
B
This
is
a
criticism.
I
guess
do
you
have
any
other
comments?
First,
basically,
people
are
saying:
keep
up
the
good
work.
B
A
lot
of
cops
users
in
the
survey
think
somebody
responded
that
they
would.
Yes,
they
wanted
feedback
from
cops.
Maybe
we
should
have
had
a
cop
section
in
the
server
itself,
so
yeah,
that's
it.
We
are
definitely
going
to
draw
some
conclusions
out
of
this.
My
action
item
is
to
talk
to
sig
release
pretty
much
and
also
present
the
survey,
the
cubanium
of
cells.
A
Yeah,
let's
make
sure
that
mirror
you
might
want
to
go
to
some
of
those
other
meanings
to
just
present
the
results
and
then
have
them,
maybe
follow
up
afterwards
or
maybe
talk
with
them
offline
so
that
they
can
present
the
results
to
the
sub
project.
D
B
If
folks
want
to
talk
about
it,
they
should.
I
I'm
not
sure
I
can
join
the
costar
api
meeting
tomorrow,
but
I
can
message
the
slack
channel.
B
A
I
thought
this
was
totally
worth
our
time,
though
I'm
I'm
definitely
gonna
like
pour
over
those
results,
and
I
have
one
key
takeaway
is
that
we
really
need
to
like
outline
guidelines
in
this
next
cycle
and
try
to
like
during
the
next
kubecon
eu,
maybe
even
highlight
some
of
these
guidelines
or
best
practices
and
try
to
drop
links
and
and
handy
information
for
how
people
can
use
the
tooling
and
use
these
best
practices
over.
B
E
Question
on
the
survey:
where
was
this
survey
sent
out
and
like
from?
When
are
the
results
from.
B
We
prepared
the
survey
so
the
survey
preparation
started
a
long
time
ago
with
the
covet
delays.
We
waited
for
cubecom
to
start
and
basically,
we
sent
the
survey
live
or
with
the
start
of
kubecon.
We
collected
results
until
today.
B
The
link
for
the
survey
was
available
in
kubecon
slides,
as
well
as
messages
to
the
kubernetes
mailing
lists
and
slack
channels
and
also
twitter.
I
guess
it
was
advertised
in
a
lot
of
places.
E
E
Oh,
the
server
is
over
right
for
the
next
one.
I
mean.
B
Yeah
this
is
a.
This
is
a
fascinating
question.
I
wonder
how
people
are
going
to
respond,
but
I
I
really
don't
want
to
include
any
mentions
about
products,
but
it
it
can
be
generalized
as
k.
B
E
Okay
sounds
good
yeah
I
mean,
I
think,
sick
cluster
life
cycle
is
doing
a
lot
of
great
work
in
this
area.
So
I
thought,
including
that
question,
would
help.
I
see
what
are
your
favorite
cluster
api
feature
as
one
of
the
responses
as
eks
integration,
so
I
think
it
would
be
good
to
know
from
the
community
if
they
want
you
guys
to
support
that
or
not
I
would
be
at
least
I
am
from
salesforce.
E
I
am
looking
forward
to
having
that
support,
so
I
wanted
to
know
if,
like
people
in
the
community
are
also
in
the
same
boat
as
us,
or
they
don't
care
kind
of
thing,.
B
A
I
wanna,
I
wanna
call
it
we're
at
time
folks,
so
we
should
call
it
and
I'm
sure
everybody's
got
a
hard
stop
for
other
things.
To
do
so.
Thanks
everyone,
I'll
post
the
recording
and
put
it
in
the.