►
From YouTube: 20180828 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
folks,
this
is
August
28th
2018.
This
is
the
standard
Sig
Buster
lifecycle,
meaning
we
have
a
pretty
sparse
agenda.
I
think
the
first
enemy
wanted
to
discuss
was
follow-up
from
last
week
that
we
want
to
make
this.
This
call
be
more
meta
across
the
entire
sig
sig
cluster
life
cycle
is
growing
in
the
number
of
sub
projects.
A
That
has
we
want
to
make
sure
that
we
have
a
venue
to
clear
out
the
meta
topics
and
we
want
to
make
sure
that
the
sub-project
leads
have
a
location
where
they
can
address
some
of
the
issues
that
occur
across
these
different
sub
projects.
That's
like
test
automation,
processing,
release,
cycle
stuff
because
I'm
sure,
as
sub
projects
grow
and
grow
and
grow.
We're
gonna
need
some
grand
unified
field
theory
for
how
we
curate
these
artifacts
together
for
any
given
release,
so
I
sent
off
an
email
we
talked
about
it
last
week.
A
B
So
I
don't
have
all
objection
about
that.
My
concern
was
that
we
spent
a
lot
of
time
for
cube
ATM
in
this
meeting
and
cubed
M
needs
a
lot
of
work
and
I
think
the
office
hours
are
most
of
the
time
not
sufficient
in
time,
and
maybe
before
cubed
e,
f
g
a
we
need
to
spend
more
time
on
it
like
allocate
more
time.
I'm,
not
sure
how,
because
everybody
is
busy,
so
I
mean
like
an
hour
and
a
half
a
week
is
probably
better.
A
C
So
live
Amir,
I
guess
the
question
I
have
around
that
is.
Is
the
concern
more
about
having
this
kind
of
forum
to
actually
work
through
issues,
or
is
there
some
things
that
we
can
better
do
kind
of
asynchronously?
Is
it
blocked
on
decision-making?
You
know
what
what's
the
blocker
that
that
you're
mainly
concerned
about
there?
Oh
so.
C
B
I
mean
this
is
mostly
a
topic
before
we
get
the
config
being
solid
and
before
GA,
and
at
that
point
we
can
reduce
the
amounts
of
these
private
meetings.
But
the
problem
with
the
private
meetings
is
that
nobody
has
them
in
the
calendar
and
we
have
to
chat
a
lot
about
these,
like
what
is
the
best
time
for
them,
and
people
cannot
attend.
D
Yeah
concerned
with
a
couple
of
issues,
pre
GA-
and
that
seems
like
scheduling-
is
difficult
with
those
it
might
be.
Then
those
are
just
one-off
meetings
that
you
can.
We
would
have
to
deal
with
bad
scheduling
issues
for
a
little
bit
before
GA,
but
I'm
not
sure
warrants
making
the
meetings
longer,
because
sometimes
those
meetings
are
ineffective
with
large
groups
of
people.
C
A
C
C
Interrupt
it
to
him,
but
I
think
you
know
it
was
I
think
we
want
to
keep
that
meet
like
the
topic
there
more
high
level.
I
think
this
was
more
about
kind
of
in-depth
technical
discussions
and,
and
things
like
that,
and
one
of
the
things
mayor
said,
is
we've
done
a
couple
of
private
meetings
for
these
types
of
topics
in
the
past
and
I
think
we
can
get
away
with
kind
of
spinning
off
those
meetings
as
needed
to
kind
of
go
into
those
topics
more
in
depth,
but
we
had
discussed
also
publishing.
A
I,
did
you
think
we
should?
We
should
publish
those
meetings
because
they
they
have
impact
I
know
like
the
conversation
that
Chuck
little
mirror
myself
and
Teresa
had
last
week,
is
germane
to
everyone
who
works
on
committee
em
and
probably
should
have
recorded
that
and
published
that,
because
that
basically
spelled
out
what
we
plan
to
accomplish
for
the
rest
of
the
112th
cycle.
So
I
do
think
that
it's
it's
the
responsibility
of
the
the
leads
to
make
sure
that
that
information
is
recorded
for
broader
dissemination.
B
A
You
can
do
it
ad
hoc
as
needed,
because,
like
the
one
thing
I
don't
want
to
do
what
I'm,
what
I'm
kind
of
worried
about
with
sig
cluster
lifecycle
right
now,
and
the
reason
why
I
want
to
move
this
to
bi-weekly
is
it's
kind
of
becoming
fractal
with
meetings
and
there
is
a
meaning
for
every
provider.
There
is
a
meeting
for
them.
The
main
cluster
API
meeting,
there's
also
a
meeting
for
these
there's
two
separate
meetings
for
office
hours.
So
it's
kind
of
getting
fractal.
A
It's
kind
of
getting
a
little
out
of
hand
in
my
opinion,
and
we
kind
of
need
a
way,
a
better
process
for
dealing
with
issues
across
these
different
implementations,
different
cloud
provider,
implementations-
and
we
just
want
to
make
sure
that
we're
respectful
of
people's
time
I
do
think
there
will
be
I
do
think.
There
will
be
instances
where
we
probably
should
have
some
reserved
spot
and
use
it,
but
try
to
use
it
like
it
as
a
as
needed
basis.
Only
right.
B
A
Iii
I
understand
your
concern.
I
agree,
I,
think
I
think
we
can
address
it
as
needed
and
I
think
we
should
try
to
be
a
little
bit
ruthless
to
with
our
agenda
animus.
So
if
we
need
to
we'll
break
it
out
and
definitely
address
it,
but
I
also
think,
like
you
know,
let's
make
sure
that
we
we
get
stuff
on
the
radar
and
we're
constantly
as
a
sig.
You
know
making
sure
we're
kind
of
ruthless
with
our
time.
So
we
so
we
can
be
gracious
with
people.
A
B
A
A
All
right,
this
doesn't
have
to
be
me
talking
about
it.
This
can
be
anybody,
but
I
wanted
to
start
to
like
at
least
have
the
recording
here.
So
we
can
disseminate
it
for
the
broader
Sigmund
lifecycle,
and
maybe
somebody
maybe
I
can
just
share
my
screen
and
and
I
want
other
people
to
talk
about
it.
To
about
how
we
do
grooming
within
said,
cluster
lifecycle,
because
it's
not
uniform
across
the
project
of
kubernetes,
but
I
would
like
it
to
be
uniform
across
Equestria
lifecycle,
because
we
are
in
many
different
repos.
A
I
think
the
one
thing
that
was
really
successful
with
this
group
is
to
have
a
way
have
a
means
by
which
we
can
bring
folks
on
board
and
for
them
to
be
able
to
see
the
backlog
and
to
know
what
the
backlog
is
and
be
able
to
contribute
over
time
and
that's
not
consistent
across
other
things.
Inside
of
kubernetes.
A
Don't
miss
for
hear
this
all
right,
so
let's
go
to
the
Canadian
repository
one
of
the
first
things
we
do
is
we
always
make
sure
that
the
milestones
are
consistent
so
and
we
try
to
clear
out
the
milestones
so
I've
cleared
out
the
old
milestones,
so
they
no
longer
exist
right.
Every
cycle
I
try
to
make
sure
that
the
milestones
are
upstate
and
Chuck.
Keeps
me
honest
periodically
and
says
like.
Why
are
we
maintaining
these
milestones
so
currently
for
given
milestone?
A
B
F
F
A
F
I
mean
if
you
want
it
for
all
the
repos,
that's
the
best
route
but
like
having
having
labels
created
by
repos
themselves
as
fine,
of
course,
and
there
I'm
not
sure
if
the
tooling
is
actually
ready
for
this
now.
But
there
has
been
a
desire
to
also
have
the
tooling
support
labels
or
repo
I
think
there's
some
there's
some
labels
that
kubernetes
uses
for
issue
management
that
we
don't
necessarily
want
for
autumns
that
are
more
related
to
the
like.
The
release
life
cycle.
A
A
Here's
where
it
gets
a
little
bit
fuzzy
for
me
I
think
we
should
probably
have
sig
cluster
lifecycle.
Maintainer
stew,
in
teams
that
apply
across
there's
a
meta
problem
that
exists
with
github
in
hierarchical
organizations.
I
think
that
this
solved
in
get
lab
but
doesn't
exist
in
github.
So
the
permissions
model
is
all
kinds
of
weird
and
funky
there's
a
little
bit
more
loose
in
the
past,
but
they've
tried
to
lock
it
down.
So
if
you
don't
have
label
access,
just
let
me
know,
but
we
can
fix
that.
A
So
once
the
what's,
the
issue
is
inbound.
We
usually
try
to
assign
a
kind,
a
relative
priority.
You
can
assign
an
area
I
think
it's
up
to
you.
We
don't
no
one's
really
strict
about
that.
It's
not
consistent,
at
least
but
the
the
one
thing
we
do
is
if
it's
ambiguous
or
if
there's
a
question
one
of
the
things
that
I
think
that
we
do
better
than
other
folks
is
we
have
this
priority
awaiting
more
evidence
right,
because
sometimes
there
might
be
back
and
forth.
It's
an
incomplete
bug
report.
A
So
at
right
now,
if
anything's
at
the
end
of
one
12
cycle
and
hasn't
been
addressed
for
like
two
weeks
from
the
original
reporter
I'm
going
to
close
them
out
at
the
end
of
the
cycle,
just
because
it's
too
difficult
to
maintain
that
there's
enough
churn
in
this
repository
that
I
don't
want
to
keep
those
things
open.
Now,
that's
how
I
manage
this!
What
other
folks
think
right
there?
That's
a
reasonable
approach
to
apply
to
all
of
the
cluster
lights
that
go.
B
A
A
If
there's,
if
it's
been
greater
than
like
two
weeks
and
they
haven't
responded
back
and
it's
clear
that
it's
kind
of
a
dangling
issue
of
whether
or
not
it's
actually
a
bug
or
not
and
I
I,
don't
close
them
out,
typically
for
for
approvers
or
leads
or
chairs,
but
I'm
going
to
call
it.
I
do
try
to
assign
a
milestone,
and
when
we
can
address
things
for,
if
they're
a
bug
I,
it's
usually
prioritized
to
try
to
get
it
within
the
milestone
if
it's
filed
at
a
reasonable
time
unless
dates
prevent
us
from
doing
so.
A
A
B
E
A
Well,
that's
part
of
it.
Help
Wanted
typically,
is
someone
who's,
not
a
science
issues.
I
usually
use
Help
Wanted,
specifically
for
no
one
is
tasked
with
addressing
this
issue.
It's
not
on
anybody's
backlog.
I,
don't
nip
eclis
use
help
one.
It
isn't
like
I,
don't
understand
this
area,
I
only
use
help
on
it.
It
when
I
do
that.
I
do
CC.
Whatever
sig
owns
that
space,
like,
for
example,
like
there's
an
issue
with
this
core
DNS
one
right,
I
would
CC
Signet
working
on
the
core
DNS
issue
right:
the
sizing
of
core
DNS.
A
There
was
a
problem
if
there's
a
separate
PR
to
address
that
one
where
it's
like
they're,
they
default
size
at
170
megabytes
it
crash
loops
on
some
folks
environments.
It's
not
consistent,
so
we
want
to
be
able
to
address
that
instead
of
me
having
a
Help
Wanted
label,
I
would
use
a
CC
that
sig
and
that
SIG's
label
would
then
be
applied
to
the
issue
too,
as
well.
B
A
It's
kind
of
where
the
sigelei
link
kind
of
occurs
right,
so
there
is
I
know
there
should
be
one
and
if
it's
not
I'm,
going
to
fix
it
right
now
on
the
bug
that
existed
for
a
long
time,
you
provider
right
here,
it's
not
necessarily.
We
are
it's
not
independent
of
us.
We
need
to
track
it
because
we
need
to
have
links
in
our
Doc's
to
the
proper
location
for
the
with
the
state
of
cloud
provider
documentation.
A
B
A
Then,
typically,
as
we
get
in
lockdown
mode
for
the
end
of
the
cycle,
a
cig
lead
as
a
cig
meat,
I
triage
this
pretty
hard
to
try
and
make
sure
it
represents
accuracy.
So,
and
we
talked
about
it
during
the
office
hours
pretty
regularly
to
make
sure
that,
if
anything's
missing,
we
get
it
into
the
milestone
right
now,
we
are
starting
to
enter
into
lockdown
mode.
A
It's
good
to
federate
this
responsibility.
This
is
not
what
other
SIG's
do.
I've
given
Luba
mere
access,
probably
early,
because
he's
been
doing
a
bang-up
job
to
help
me
maintain
this
stuff
and
I.
Think
having
this
job
federated
actually
helps
everybody,
because
having
a
canonical
list
of
states
and
backlog,
it's
super
duper
helpful
for
because
you
never
know
when
somebody's
going
to
come
into
a
project
like
there's
a
different
party
that
comes
in
and
be
like.
Well,
how
can
I
help?
B
We
had
a
session
about
that
exactly
which
checking
lists,
and
we
moved
a
lot
of
issues
to
to
the
GA
Mouse
home
actually,
and
we
basically
estimated
what
is
realistic
for
112
and
so
yeah.
The
good
thing
about
that
is
that
anyone
can
help
with
this
like
make
a
decision
and
move
into
the
next
milestone.
If
it's
not
feasible
or
possibly,
consult
with
the
cig
leads
as
well.
All.
A
Right,
I
think
for
some
things
you
do
need
to
consult
with
the
Cyclades
like
major
feature
additions,
as
well
as
like
critical
bugs,
but
if
it's
one
of
those
things
where
it's
like
important
long
term
and
it's
been-
it's
been
labeled
appropriately-
then
go
to
town
right
like
I'm
not
going
to
I'm,
not
gonna,
you
know
be
upset
by
and
folks
helping
me
basically
mind.
The
fences
there
I
would
be
I
would
gladly
help.
I'll
gladly
be
happy
if
anyone
were
to
help
on
that
effort.
B
A
Are
features
this
cycle,
the
work
that
liz
is
doing
on
for
certificate
rotation
is
one
of
them,
so
there's
been
a
long-standing
set
of
issues
that
have
occurred
about
people
wanting
to
be
able
to
rotate
their
certificates
asynchronously
outside
of
the
upgrade
process,
as
well
as
the
transition
to
alpha
3,
as
well
as
the
control
plane
join.
So
those
are
the
three
major
features
in
this
cycle
that
I
can
think
of.
A
A
No
because
it's
alpha,
so
that
was
the
that
was
the
line
that
we
deleted
was
that
we
will
not
do
document
formal
documentation
for
alpha
things,
because
they
churn
so
much.
It
becomes
a
maintenance
burden
on
our
side
and
and
one
of
the
things
that
I
wanted
to
push
back
on
with
regards
to
documentation,
especially
for
code
that
is
in
config
configuration
that
is
in
code,
especially
the
type
stuff.
Is
that
it'd
be
super
useful?
If
we
did
a
better
document,
go
better,
go
documentation
and
leverage
go
Docs
and
point
it
to
that
reference.
A
B
He
mentioned
me
one
of
the
issues
or
put
poor
requests.
I
was
participating
in
and
he
told
me
that
they
don't
want
to
automate
this
with
variable
system
like
having,
because
we
changed
the
the
the
version
of
the
config
all
the
time
like
from
version
one
to
version
3
for
alpha,
and
he
was
telling
me
that
we
don't
have
to
they
don't
want
to
automate
this
version
and
I
said
that
we
at
the
same
time
we
we
want
to
maintain
this
in
wine
documentation
only
when
we
call
ga.
A
Linking
to
go
doc
makes
a
ton
more
sense
and
having
examples
directly
embedded
in
the
code,
because
then
it's
maintainable
right
from
a
from
a
coding
perspective,
I
think
if
we
were
to
do
it
internally
or
externally,
that
it
becomes
a
maintenance
burden
and
we
already,
we
already
paid
down
that
debt
in
1:11
and
I.
Don't
want
to
pay
down
that
debt
again
of
trying
to
maintain
these
separate
set
of
docks
which
don't
get
updated
all
the
time
or
as
part
of
the
release
process
right,
yeah.
B
There
was
also
I
also
suggested,
like
we
automate
the
generation
of
MD
files
or
basically
generate
the
like
the
output
of
configure,
bring
defaults
like
the
output
of
this
command.
We
can
possibly
like
embed
this
automatically
on
each
release,
but
we
don't
have
the
tooling
for
that.
That
I
don't
want
to
say
how
to
do
it.
Yeah.
A
I
think
I
think
nearing
the
end
of
the
cycle.
I
think
we
can
have
a
whole
separate
conversation
about
documentation,
structure
how
we
want
to
maintain
that
going
forwards.
I
do
think
that
there
isn't
good
examples
that
exists
inside
of
kubernetes
kubernetes
that
serve
as
sort
of
like
shining.
You
know
beacons
of
what
we
would
like
in
the
future.
I
I
do
think,
as
we
federate
more
within
this
sig,
we
will
kind
of
we
will.
A
We
will
run
into
this
problem
pretty
fast
and
we
are
gonna
need
a
unified
process
for
dealing
with
some
of
the
stuff.
That's
exactly
what
the
meta
meta
meeting
should
be
about
right.
The
that's
kind
of
the
reason
part
of
the
reason
why
I
want
to
have
like
pushing
that
to
be
a
meta
meeting.
Is
that,
like
there
we're
gonna
need
to
clear
out
some
of
these
unified
processes
to
make
sure
that
we
have
consistency
with
release,
artifacts
documentation
and
process
right?
A
A
A
B
A
Not
super
process
heavy,
it's
pretty
light
and
kind
of
slightly
ad-hoc,
we're
not
like
super
strict
about
anything,
but
we
we
don't
have
dangling
issues
in
sequester,
Larkspur
in
committee
and
repository.
So
if
you
look
in
the
upstream
repo
there's
a
bunch
of
dangling
issues
like
thousands
of
them
and
that's
what
I
strive
to
avoid
I
think
we
would
sneak
into
that
state.
It's
it's
very
difficult
to
find
history
and
to
maintain
it
over
time.
B
A
F
A
That's
a
little
concerning
I,
don't
want
to
enable
all
this
stuff
by
default,
yet
I
know
there's
PRS
and
I
unblock
them.
Perhaps
we
can
synch
on
sync
release
with
dims
and
then,
if
you're,
there
too
sounds
good.
B
B
This
is
this
fixes
a
number
of
hopefully
fixes.
A
number
of
our
failing
tests
are
related
to
cost
a
life
cycle,
I'm.
B
B
So
what
we
also
did
a
team,
what
we
did
with
Liz
and
Chuck.
We
also
went
inside
every
single
issue
that
in
the
Mousehole
we
we
started
discussing
if
this
is
doable.
Who
is
designed,
if
you
don't
have
information
for
this
particular
issue,
we
skipped.
So
it
was
a
nice
session
to
like
basically
discuss
the
back
room.
A
Yes,
I
think
periodically.
We
should
be
doing
that
I
kind
of
do
it
asynchronously
well,
like
I,
did
it
on
Friday
and
Monday,
so
I
went
through
what
I
did
two
parts
I
went
through
the
entire
PR
backlog
of
upstream
as
well
as
I
went
through
my
review
backlog.
They
cleared
that
all
out
and
then
I
did
a
triage
pass
through
112
and
I'm
going
to
do
another
one
next
week
after
the
freeze.
So
perhaps
next
week.
A
Are
there
any
other
that
folks
would
like
to
bring
up?
I
have
a
quick
question
for
Ben
to
see,
if
he's
seen
any
CIA
signal
that
we
should
be
aware
of
I,
don't
think
we
hooked.
I
did
not
have
time
to
PR
the
automation
for
emails
for
some
of
these
test
failures
and
also
I'm
kind
of
glad
I
didn't
because
we
get
looped
in
things
that
we
shouldn't
be
looped
into.
F
Yeah
so
I'm
not
sure
at
the
moment
we
had
a
pretty
big
problem.
Where
leave.
We
realize
we're
running
pretty
much
everything
in
one
GC
period
in
zone,
for
whatever
reason,
and
that
zone
actually
had
some
stock-out
issues,
so
that
kind
of
made
a
lot
of
things
have
a
flip
there
test
failures
that
was
unrelated.
That
should
be
fixed
now,
but
it
means
I'm
I
haven't
followed
back
up
on.
Her
are
everything
in
since
then.
A
Okay,
well,
I
can
I
can
sync
with
the
it's
my
job
to
sync
anyways
with
the
CI
signal
needed,
so
I
will
do
the
release.
I'll.
Do
the
release?
Wrangling
start
that
now
so
Bluebird
mayor?
If
you
want
to
part
of
the
conversation
we
had
about,
you
know
grooming
folks,
to
take
over
to
be
approvers
and
stuff.
This
is
part
of
the
job.
A
Well,
the
doc
was
the
signal
need
yeah,
we're
nearing
the
end
of
the
cycle
and
in
fact
we
should
probably
start
a
document
with
what
it
means
to
triage,
as
well
as
what
what
it
means
to
to
be
an
approver
for
for
kuba
diem.
I
know
that
Lucas
started
vac.
We
have
some
of
these
things
documented,
but
we
should
probably
like
be
fill
out.
Some
of
the
other
details.
B
A
No,
it's
just
the
responsibility
at
the
end
of
the
cycle
for
the
sig
leads
to
make
sure
that
it's
green
right
so
like
once
we
head
into.
What's
we're
getting
closer
to
the
release
milestones,
we
need
to
make
sure
that
everything
is
green
across
the
board
and
that
we've
there's
a
couple
other
finagling
things
that
only
relate
to
sync
list
or
life
cycle
and
Kuby
diem
in
particular.
That
are
explicit,
like
updating
the
specific
version
and
realizing
that
certain
tests
fail
and
make
sure
not
over-index
and
some
of
that
stuff.
A
B
A
I'm,
okay,
with
it
Ida
I,
think
it
would
be
on
SLO
guarantees
from
other
folks,
I
think
from
sequester
lifecycle.
I
think
we're
fine
from
a
comedian
maintainer
perspective,
because
it's
out
of
support,
so
by
definition,
so
that
I'm.
Okay
with
that,
because
we
only
support
1,
9,
110
111
and
then
once
we
go
into
112
that
that
will
shift
again
I'm.
Okay,
with
maintaining
the
signal
for
a
period
of
time
into
the
next
release
and
then
deprecating
from.
F
Test
imprisoned
on
that
we've
been
looking
to
make
this
part
of
the
test
up
for
a
lead
role
that
we
have
an
official
point
during
the
cycle
where
we
drop
support
for
a
previous
cycle,
but
at
least
from
the
side
of
all
the
tests
that
we're
running
that
hasn't
been
super
clear.
Exactly
when
that
happens
in
the
past,
we're
trying
to
actually
codify
that
I
think
it's
going
to
be
around
when
we
do
the
branch
cut
or
possibly
code
slush.
F
F
F
Yeah
I'll
have
to
think
more
about.
The
owners
of
the
test
should
be
notified.
I
think
they
would
be
at
least
see
seed
on
the
PR
automatically
by
being
in
had
by
the
owners
files
for
the
configs
now,
which
is
a
recent
improvement,
but
we
might
need
to
explicitly
CC
all
the
owners
for
that
type
of
pure
okay.
A
All
right,
so
if
there
are
no
more
group
topics,
I
think
and
no
one
has
said
no
to
the
meeting.
Push
will
push
this
to
a
biweekly
meeting
going
forwards
and
will
try
to
talk
with
the
other
sub-projects
as
well
to
try
and
loop
them
into
coming
to
this
meeting
with
a
more
set
of
meta
topics
that
sort
of
cut
horizontally
across
the
different
sub
projects.
A
And
you
know
feel
free
to
add
agenda
items
over
the
course
of
the
week.
Everyone
should
have
write
access
if
you
are
a
member
of
the
mailing
list,
so
go
forth
and
add
things
to
the
list.
I'm
sure
that,
as
you
mentioned,
Lumiere,
the
the
testing
documentation
and
release
artifact
structure
will
be
a
set
of
thorns
for
some
time
to
come.
B
Yeah
hacker
made
a
promise
to
help
with
that,
but
I
guess
he
doesn't
have
the
time.
We
need
a
a
pretty
solid
documentation
of
what
we
change
each
cycle
because,
as
I
already
said,
I'd
it's
still
not
clear
to
me
what
I
should
change
it
so
yeah
we
need
the
docs,
and
hopefully
we
improve
this
over
time.