►
From YouTube: 20180731 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
A
A
A
A
Okay,
so
they
just
see
the
web
browser
right
now.
Yes,
is
it
alright
cool?
Let's
walk
through
the
deets
here
and
if
folks
want
to
change
things,
please
please
comments
speak
up,
otherwise
we're
gonna
we're
gonna
go
with
what
we
have.
Our
single
cluster
lifecycles
objective
is
to
improve
the
deployment
configuration
management,
an
upgrade
story
of
kubernetes
clusters
and
relevant
infrastructure.
I
had
a
problem
with
the
relevant
infrastructure
statement
here,
because
I
think
we
we
might
want
to
put
like
it's.
Some
things
are
out
of
scope.
Does
anyone
have
comments
there.
D
Well,
we
we
are
already
seeing
which
things
are
I
was
called
the
wall.
Like
I
mean
I,
saw
a
couple
of
charter
piers
that
got
rejected,
because
the
first
sentence
is
not
enough,
like
they
wanted
more
of
more
text
in
the
scope,
section
and
I
think
we
already
cover
what
what
is
in
scope
and
I
was
cold,
but
maybe
we
should
add
another
sentence
in
the
start.
A
The
purpose
of
group
wordsmithing
is,
you
know
we
got
something
a
speaker
because
I,
if
you're
looking
for
me
to
to
rephrase
sentences,
I
am
NOT
your
person
I'm
a
good
idea.
Person
I
am
a
terrible
wordsmith
there.
So
whole
purpose
of
doing
this
together
is
to
to
facilitate
your
vernacular
into
the
document.
So.
E
To
Tim
I
think
this
Chris
know
added
this
part
right,
I'm,
guessing
that
it
was
added,
because
if
you
look
at
something
like
what
Cuba
does
or
what
we
need
to
do
to
make
the
test
temperature
go
much
less
friend
users.
We
do
things
like
provision,
you
know
load
balancers
when
creating
clusters-
and
you
know
provisioning
VMs
right.
If
you
look
with
the
scope
of
the
cluster
API,
it's
sort
of
that
layer
below
cube
admin
right
on
Lucas's,
layered
diagram.
E
My
guess
is
that's
what
this
is
meant
to
cover
is
it's
meant
to
cover,
like
the
first
part
of
the
sentence
as
sort
of
pieces,
that
sort
of
cube
admin
does
and
the
second
part
of
the
cluster,
the
second
or
the
sentence
is
sort
of
the
cluster
API
pieces.
So
I
know
if
there's
a
better
way
to
phrase
that
but
I'm
guessing
that.
That's
why
that
part
was
added.
A
Yeah
I
agree
that
the
question
is
that
I
had
in
my
head
was:
where
does
it
stop
right
like
because
relevant
infrastructure
could
include
anything
like
you
get
your
f5
configurations?
You
have
your
all
your
you
know
like.
Where
does
the
boundary
line
the
cut
line
end
right,
because
they're
there's
so
much
configuration
that
could
go
on
beyond
the
scope
of
what
we're
trying
to
do
that?
A
A
A
Because
you
want
to
make
sure
your
scope
is
bounded,
so,
like
cig,
apps
is
a
really
bad
example,
a
counter
example
where
their
scope
is
way
too
broad.
So
you
want
to
know
that
the
purpose
of
the
scope
being
focused
enough
is
such
that,
like
when
people
are
trying
to
hunt
or
the
the
steering
committee
is
trying
to,
like
you
know,
say
who
is
responsible
for
what
it's
clearly
defined
the
roles.
A
C
So
we're
sure
I
just
think
that
it's
sort
of
sort
of
quick
comment.
We
have
a
list
of
out
of
scope,
things
I
think
what
we
wanted
to
be.
You
know
legally
correct.
It
would
take
a
lot
more
words
and
I
guess
that
was
what
I
was
saying
this
day.
I
don't
think
we
have
to
be.
We
don't
have
to
enumerate
every
single
detail.
Some
amount
of
moodlerooms
is
okay,.
A
E
I
think,
if
you
look
at
the
cluster
API,
it's
it's
really
sort
of
two
things:
it's
machines,
which
I
think
is
sort
of
a
pretty
common
thing
across
all
cluster.
So
all
clusters
are
gonna
need
some
notion
of
machines,
the
other
half.
If,
if
you
look
at
the
cluster
api
cap
is
sort
of
nebulous,
it
says
other
infrastructure
and
I
think
that
that's
meant
to
imply
things
like
a
load
balancer,
especially
if
you
have
an
H
a
cluster
and
on
a
cloud
platform,
you
want
to
put
a
load
balancer
in
front
of
it.
E
That's
part
of
cluster
provisioning.
You
know,
you
know
disks
for
a
persistent
storage
of
read
C
database,
those
sorts
of
things
so
I
think
that's
sort
of
the
other
infrastructure
part.
If
we
want
to
be
more
specific
and
maybe
expand
our
scope
later,
when
those
things
become
sort
of
clear
what
they
are
and
what's
consistent
across
platforms,
we
could
say
you
know
we
could
sort
of
more
focus
on
sort
of
the
machines,
API
part
of
the
cluster
API
project
and
say:
basically,
you
know
the
machines
necessary
to
run
through
at
ease
or
something
here.
I.
A
Think
the
statement
is
okay.
Why
don't
we
go
on
to
the
next
bits?
Like
you
know,
I
have
I,
don't
like
it.
So
if
people
have
an
idea
of
how
they'd
want
to
phrase
it
better
I'm
game
for
that,
so
it's
it's
okay
in
my
mind,
but
it's
not
the
I'm
sure
you
know
if
I
were
to
talk
with
my
wife
who's.
You
know,
like
English,
Lit
slash,
you
know
other
background.
She
she
probably
needed
me
to
death.
A
A
B
A
Kubernetes
cluster
lifecycle
related
features
and
issues,
yeah
that
seems
obvious
tools
that
assist
in
bootstrapping,
mutating
and
upgrading
kubernetes
clusters.
That
also
seems
fine
kubernetes
tools
used
for
cluster
and
infrastructure
management.
That's
one
of
those
things
that
I
think
if
we
provide
the
UI
portion
exemption
down
below.
That
seems
fine
tools
that
assistant
management
of
communities,
components,
configuration
that
said,
that's
making
a
brain
bleed.
F
G
You
can
just
basically
see
go
ahead,
I
think,
there's
a
distinction
to
me.
Cluster
and
infrastructure
management
is
concerned
with
the
the
servers
the
routers
to
whatever
that
run
the
cluster,
whereas
bootstrapping,
mutating
and
upgrading
refers
to
the
control
plane
itself,
but
I
don't
quite
have
a
way
to
express
that
distinction.
Should
we
say:
control,
plane.
A
E
Do
destructing,
I
think
I
think
if
you
look
at
Justin
Santa
Barbara's
proposal
for
the
mission
statement
that
I
wrote
a
little
while
back
you
he's,
separated
us
into
infrastructure
management
and
control,
plane
management,
so
I
think
I'd
like
to
change
the
control
plane
and
our
infrastructure
management.
It
was
really
how
do
I
set
up
my
machines
and
how
do
I,
you
know,
make
them
talk
to
each
other
and
so
I
think
that
includes
things
like
configuring.
E
A
A
A
D
A
A
E
Can
we
just
change
it
to
say
infrastructure
management?
You
would
have
cluster
here,
cuz
I.
Think
cluster
here
does
actually
have
a
lot
of
overlap
with
managing
the
control
planes.
I
think
that
when
people
think
of
the
cluster
half
of
this,
they
think
of
the
control
plane.
If
we
split
those
apart
and
say
we
manage
the
control
plane
and
then
we
also
manage
the
machines.
Those
are
sort
of
two
separate
efforts
or
sort
of
two
separate
thrusts.
I
think
that
that
separation,
it
makes
a
lot
of
sense
for
people.
I
E
Yes,
I
saw
that
I
agree.
The
Machine
the
API
is,
is
closed
for
specific,
but
I
think
that
the
intent
here
was
more.
If
you
look
at
like
the
large
number
of
projects
that
are,
are
configuring
machines
there
they're
sort
of
mostly
related
to
or
driven
by
people
from
this
thing
right?
So
the
you
know,
the
legacy
cube,
op
scripts
were
written
by
people
in
the
say.
Cops
was
written
by
people
in
this
saying
the
cube
spray
and
all
of
the
other
tools
that
people
were
building
when
they
went
through
the
incubation
process.
E
I
E
A
All
right,
and
so
let's
put
a
pin
in
that
one
and
then
loop
back
to
it,
I
want
to
get
this
submitted
this
week.
If
we
can
and
just
so
it's
off
of
our
to-do
list
right
tools
that
assist
in
in
management
of
Cabernets
component
configuration
I
didn't
like
the
components
configuration
even
though
it's
grammatically
correct.
It
just
sounds
terrible.
E
D
D
E
I,
don't
think
we
want
to
claim
to
own
that
ons
themselves,
it's
more
at
on
management
or
if
we
ever
build
one
out
on
API
right
and
it's
in
the
same
way
that
the
API
machinery
team
doesn't
own
kubernetes
api
is,
or
the
controller
so
is
API
is
that
they
own
the
API
management
infrastructure
and
they
make
it
possible
for
other
people
to
write.
Api
is
right,
and
so,
if
we
can
reduce
sort
of
the
core
control
plane
and
make
more
things
add-on.
E
A
E
E
E
A
E
A
The
next
section
is
ambiguous
to
me
because
it
says
code,
binaries
and
services
list
what
qualifies
now.
The
key
word
here
is
qualifies
a
piece
of
code
binary
service.
Now
and
that's
what
that
perspective?
That's
everything
that's
in
scope,
so
it's
kind
of
like
it's
kind
of
redundant.
We
could
just
say
something
that
says
any
binary:
any
non
UI
based
binary
that
falls
within
scope.
A
So
again,
the
purpose
of
this
section
is
it's
a
little
ambiguous.
It's
not
to
say
the
actual
details
that
should
be
stored
in
sync
is
that
yeah
mo
of
what
binaries
and
artifacts
are
produced.
The
purpose
of
this
statement
is
to
say
like
when,
when
you're
making
a
decision
like
what
what
what
are
the
criteria
that
you
would
use
to
say
that
this
binary
it
falls
underneath
your
purview
and
I
think
the
the
general
statement
should
be.
You
know,
as
falling
into
the
scope
of
the
sig,
like
you
have
some
generic
statement.
A
C
A
D
H
E
I
mean
it's
kind
of
an
assemble
to
the
first
line
right,
like
tools
for
infrastructure
management,
so
that
could
include
provider
specific
tools
for
infrastructure
management,
right
or
provider.
Specific
colon
tations
of
infrastructure
management,
well
I
mean
where
they
have
sort
of
enough.
You
know
support
momentum
with
within
the
sig
to
be
maintained,
right,
I.
Think
that
that's
why
we
vote
and
make
sure
that
there
are
people
that
are
going
to
maintain
it,
and
not
just
say
yes,
we'll
take
every
provider
implementation
that
one
person
wants
to
build.
A
A
D
A
A
D
A
A
D
E
A
Who's
gonna
even
do
the
work
items
like
I.
Don't
think
anyone
from
this
SIG
is
signing
up
to
do
their
own
those
work
items.
It's
not
even
our
responsibility
right,
so
I,
don't
think
it
should
be
I
don't
want
to
get
the
phone
call
when
somebody
somebody
MUX
a
component
configuration
and
then
now
we're
on
the
hook
for
all
of
the
consequences
of
that.
D
A
A
E
You
could
probably
make
a
similar
statement
about
like
upgrade
tests
where
at
least
historically
people
have
always
come
to
our
Sagan
said.
Why
is
he
upgrade
tests?
Broken
I
mean
it's
often
not
that
the
tests
upgrade
test
is
broken,
but
a
feature
is
broken
during
upgrade,
and
we've
tried
to
make
the
upgrade
test
more
self-describing
saying
the
upgrade
finished
and
the
ingress
test
broke,
so
that
people
can
go
directly
to
Signet
working.
But
again,
people
still
sometimes
tag
us
as
well.
E
D
A
D
E
I
think
it's
interesting
actually
that
this
is
under
out
of
scope
because
in
some
ways,
I
think
cloud
provider.
Specific
issues
is
actually
in
a
cross-cutting
issues,
because
if
someone
is
creating
a
cluster
say
on
AWS
or
on
GCP
and
the
cluster
creation
fails,
then
they're,
probably
going
to
come
to
us
first
write
in
the
same
way
that,
like,
if
cube
admin,
fails
regardless
of
what
the
problem
is.
E
They
come
to
us
first
and
then,
and
as
the
premier
put
in
the
above
statement,
we
end
up
having
to
sort
of
triage
and
often
and
delegate
those
issues
out,
so
I
think
that's
likely
to
happen
with
the
cloud
provider
issues
as
well,
especially
when
you
split
up
the
cloud
controller
manager.
If
you
create
a
cluster
and
you're,
you
know,
ingress
rules
aren't
creating
load,
balancers
or
your
services
aren't
creating
load,
balancers
are
gonna,
say
I
created
my
cluster
or
my
cluster
doesn't
work.
E
It's
not
necessary
to
be
clear
who
they
should
talking
to
so
I
feel
like
that,
might
end
up
being
more
of
a
cross-cutting
issue
than
an
out
of
scope,
issue
bakery
and
similarly
for
the
cluster
API
providers.
You
know
we
put
above
that
those
are
in
scope
from
their
own
by
the
sig.
So
at
some
level
we
have
some
responsibility
for
those,
but
most
or
all
of
them
are
also
sort
of
co-owned
by
the
cloud
specific
sig
select,
the
GCP
one
is
co-owned
by
sig,
GCP
and
open.
E
A
A
G
G
A
A
H
H
E
A
E
E
E
I
would
also
love
for
this
to
be
pushed
down
and
say
it's
not
the
chairs
responsibility
to
do
this.
It's
the
sub-project
owner
and
we
should
just
be
more
clear
about
the
sub-project
owners.
I'd
rather
have
the
chair,
have
fewer
responsibilities
and
sort
of
delegate
that
responsibility
down,
especially
as
we
have
more
sub
projects
that
if
the
state
is
adopting
yeah.
J
A
A
A
A
D
D
E
All
right,
we
might
have
lost
Tim,
we'll
keep
going
additional
responsibilities
for
tech
leads
so
right
now,
I,
don't
think
we
actually
have
tech
leads
to
find
in
City
MO.
So
if
we
want
them
to
have
additional
responsibilities,
we
should
probably
define
who
they
are.
E
Bed
out
and
just
say,
you
know
basically
that
maybe
just
leave
it
out
all
together
and
say
that
in
our
sig
that
that
job
is
crowd-sourced,
I
think
there.
There
are
specific
people
who
have
been
driving
it
in
the
past,
but
that
doesn't
mean
other
people
can't
stuff
up
and
drive
in
the
future
without
having
to
be
sort
of
officially
tech
lead
right.
A
E
So
I
think
the
intent
here
is,
you
know
we
have.
We
want
the
user
experience
to
be
good
for
equal
to
contributing,
and
we
want
the
donors
to
sort
of
be
on
the
hook
for
making
sure
that
the
the
contributor
experience
is
good
by
addressing
open
PR.
So
we
don't
want
to
have
the
number
of
open
PRS.
Just
balloon.
Stale
old,
older
PRS
are
much
harder
to
figure
out
emerge.
A
A
Know
we
haven't
set
that
up
yet
I
think
the
first
pass
is
just
to
get
it
written
down
because
it
needs
to
be
a
rationalization.
We
have
e
to
mini
SIG's
and
you
know
we
need
to
rationalize
some
of
this
by
by
clearly
defining
what
is
in
what
is
out
and
then
I
think
over
time.
There
will
be
a
second
step
of
rationalization,
which
would
be
like
okay.
We
need
more
organizational
structure
around,
you
know
what
are
some
projects
or
what
are
those
rules
etc?.
D
E
A
D
A
Do
that
independently
the
signal
changes
in
our
company?
That's
the
Turner
they're
they're,
totally
independent.
So
we
should,
if
somebody
wants
to
take
on
points
to
adjust
the
zoom
stat.
You
know
file
and
to
update
that
that
would
be
great
one.
Two,
three
nine
it
Hydra
of
the
Charter
here.
So
getting
getting.
This
going
was
thick
enough.
E
Do
we
think
really
need
to
be
I
mean
we
need
be
nice
about
owners
on
some
projects.
We
can
try
to
paint
people
who
created
sub
projects
and
ask
them
to
add
the
correct
owner,
because
I
don't
know
if
anybody
knows
who
all
those
people
are
which
other
parts
do,
we
think
he
need
updating.
We
already
have
a
decent
list
of
links
to
prod
sub
projects.
I.
D
A
E
A
Well,
thanks
everybody
for
a
wordsmithing
I
think
it
was
helpful,
informative.
Hopefully
those
who
are
new
to
this
whole
sequestered
lifecycle
business
kind
of
get
an
insight
into
some
of
the
what
were
responsible
for
and
not
responsible
for
and
with
that
I
think
we'll
call
it
thanks.
Everybody
thanks.