►
From YouTube: Kubernetes SIG Release - 2019-08-12
Description
A
Hey
all
sorry
running
late,
trying
to
get
logged
in
to
zoom
correctly
with
the
right
credentials,
so
I
think
everybody
is
here
for
a
cig
release
meeting
and
this
meeting
will
be
recorded.
It
is
August
12th.
The
notes
are
in
the
invite
link
and
for
anybody
on
the
zoom
right
now
who
doesn't
have
them.
I
will
drop
this
in
the
chat.
Please
behave
according
to
the
code
of
conduct.
A
Obviously,
since
this
is
being
recorded,
your
actions
will
be
there
for
all
to
see
and
if
anybody
is
interested
in
taking
notes,
I
see
people
are
typing
their
names
already
in
the
agenda
doc.
That
would
be
awesome
if
folks
could
do
that
feel
free
to
also
put
your
name
under
note-taker
if
you're
wanting
to
to
take
that
on
so
in
terms
of
agenda,
we
are
just
kind
of
reeling
reorganizing
our
agenda
to
do
some
walkthroughs
of
project
board
and
then
desk,
rats,
test
grid
status
and
our
standard
sub
projects.
A
But
two
weeks
ago
we
had
a
fair
amount
of
conversation
about,
if
for
which
of
the
sub
projects,
maybe
we
should
shuffle
out
elsewhere
so
we'll
see
what
we
have
for
updates
today
and
other
than
that.
Nobody
has
suggested
anything
that
they
want
to
talk
about
today
on
the
open
agenda.
So
we'll
we'll
see
what
we
have
so
the
first
thing
that
we're
trying
to
do
is
make
a
point
of
welcoming
our
any
new
attendees.
It
looks
like
we
might
have
a
couple
in
the
participants
list.
B
Hi
I'm
Angela
Lewis.
This
is
my
first
ever
meeting.
I
was
invited
from
by
Stephen
who's
on
the
team
with
us.
Sorry,
I'm
from
VMware,
so
I'm
a
project
manager,
support
the
communities,
architects,
team,
VMware
and
being
wanting
to
get
into
upstream,
so
I
probably
be
observing
for
a
while
I've
met,
Kenny
ozone.
A
B
A
Going
once
going
to
all
right,
well,
I
guess,
then
we
can
move
on
so
sub-project
updates.
One
of
the
big
questions
two
weeks
ago
is
whether
we
need
to
have
hypercube
giving
out
its
status
here
and
then
there
were
some
other
questions.
They
came
up
during
the
release
engineering
meeting
and
subsequently
so
I'm,
just
gonna
write
in
the
an
agenda
like
TBD.
C
Yeah
that
should
be
me
so
I
don't
have
too
many
updates
there,
but
we
need
to
first
set
up
a
licensing
sub-project
meetings
because
it
doesn't
exist
today.
It's
on
my
list
for
this
week,
so
you
should
be
hearing
about
a
doodle
on
the
mailing
list.
Soon
it's
moving
a
little
slow
because
there
are
so
many
other
things
to
do,
but
hopefully
it
should
pick
up
the
pace
in
the
next
few
weeks.
One.
A
Of
the
problems
were
having
is
also
finding
time
where
people
are
available
for
meetings,
because
there's
so
many
different
community
ones.
Plus
people
often
have
day
jobs
as
well,
so
just
to
throw
it
out
there.
If
you
struggle
to
find
an
agreeable
time
for
folks
on
the
doodle,
we
could
also
combine
it
in
with
the
release
engineering
meeting
and
make
sure
that
we
have
a
dedicated
block
of
time
that,
where
we
always
talk
about
the
licensing
related
things
as
well,.
D
Say
I'll
say
for
this
meeting:
I
love
one
vote
for
actually
having
a
licensing
status.
It's
just
because
if
there
is
stuff
to
report
there,
it's
somewhat
different
from
a
question
of
you
know,
building
binaries
etc
and
may
require.
If
there's
an
issue
coming
from
the
licensing
subgroup.
It's
probably
something
we'll
have
to
escalate
to
the
steering
committee.
So
I
think
we
should
have
a
separate
status
for
licensing.
C
C
So
first
thing
is
publishing
what
is
well,
not
it's
a
project
by
itself
anymore.
It's
under
release
engineering
now,
but
I
can
just
give
a
quick
update
anyway.
So
I've
created
a
PR
to
add
rules
for
the
release,
1.16
branches
and
removes
the
1.12
one,
because
the
one
out
sixteen
branch
will
be
created
tomorrow
and
why
not
well
jobs
will
be
removed.
C
So
yeah
I
just
wanted
the
publishing
what
PR
to
be
ready
once
the
branches
are
good
to
go,
and
one
more
minor
point
is
that
we
recently
moved
the
publishing
bot
images
to
use
the
GTR
staging
repo
instead
of
Dr
Hubbs.
So
it's
now
completely
running
on
CN
CF
infrastructure,
which
I
think
it's
sort
of
nice
and
overall.
Well,
it's
happy
it's
running
and
it's
doing
its
job
right
now,
so
yeah,
that's
pretty
much
it
I'm
publishing,
but.
A
Awesome,
so
that's
our
first
bullet
point,
I
suppose
technically
under
release
engineering,
so
for
folks,
I
think
a
large
part
of
the
folks
on
the
call
are
probably
aware,
but
for
a
long
time
we've
had
just
a
sig
release
meeting
and
we've
focused
on
a
few
high-level
sig
release
things,
but
often
there's
been
a
chunk
of
things
within
that
that
were
related
just
to
the
release
team,
which
is
a
separate
sub
project.
But
we
were
neglecting
the
tooling
behind
a
lot
of
this
and
process
discussions,
and
things
like
that.
A
So
we've
set
up
a
sub
project
called
release
engineering
and,
as
of
last
week,
we've
had
our
first
meeting
to
talk
about
our
kind
of
roadmap
for
updating
and
revamping
the
tools
there,
there's
kind
of
a
big
to
do.
At
this
point
to
document
the
global
plan
of
action,
we've
had
a
fair
amount
of
brainstorming.
We've
had
some
investigations,
and
but
the
sort
of
general
status
is.
A
Yeah,
the
the
high-level
big
picture
we
have,
you
can
look
at
it
from
a
couple
ways
on
the
the
starting
initiating
of
the
build
side
of
the
pipeline
historically
like
a
year
ago
and
prior
that
was
always
done
by
Googlers.
So
we've
been
trying
to
make
it
so
that
the
community
can
run
the
process
of
starting
things
and
getting
them
out
to
publishing.
If
you
go
all
the
way,
the
other
end
of
the
pipeline,
the
way
we
publish
things,
especially
in
terms
of
Deb's
or
rpms,
but
to
some
extent
also
the
containers.
A
It's
been
kind
of
opaque.
There
haven't
been
a
lot
of
people
with
visibility
so
on
that
Ingleside
again
getting
more
people
on
the
front
end
but
on
the
end,
be
publishing
to
the
CN
CF,
funded
or
hosted
infrastructure.
That's
coming
up
through
the
working
group,
Cates
infra,
shifting
that
output
side
more
out
from
Google
and
there
in
particular
right
now.
We
just
publish
for
the
Deb's
and
rpms
AM
repo
and
a
Deb
or
apt
repo,
and
that's
really
problematic
for
version
control
on
the
consumption
side.
A
So
one
of
the
big
things
that
we
want
to
do
is
split
that
out.
There
should
be
a
repo
for
you
on
there
for
app
to
whichever
distinct,
obviously
because
they're
different
ecosystems,
but
the
should
be
one
for
115.
There
should
be
another
one
for
116.
I
should
be
one
for
117,
so
that
you
can
subscribe
to
the
thing
that
you're
in
and
obviously
we
probably
also
have
a
latest.
So
you
could
subscribe
to
latest.
A
If
you
wanted,
and
at
the
point
that
say,
116
was
stable
latest
would
become
116
s
content,
but
the
idea
that
we
have
the
that
kind
of
promotion
ability
then
would
also
flow
into
the
individual
repo.
So,
instead
of
having
a
116
repo
for
yum,
we'd
actually
have
something
like
a
nightly
attesting
and
a
stable,
so
the
night
leaves
would
be
akin
to
what's
going
on
in
test
grid
for
the
periodic
testing,
whether
we
be
doing
periodic
continuous,
build
and
integration
and
where
we
are
happy
with
the
outputs
there.
A
We
would
promote
that
to
testing
such
as
a
alpha
beta
RC
release
and
where
those
have
passed.
That
thing
would
get
pub
promoted
up
into
the
the
stable
repository,
so
the
idea
is
to
do
more
in
a
CI
CD
pipeline
sort
of
direction
have
promotion
of
artifacts
that
have
tested
good,
have
community
members
running
that
on
the
input
have
community
hosting
on
the
output,
that's
kind
of
a
high-level
does
that
make
sense
so.
A
A
C
E
Don't
know
if
lock
is
on,
but
since
I'm
doing
the
next
meeting
I
figured
I
would
do
this
one
as
well,
quick,
so
just
from
a
high
level
overview
we're
doing
the
116
branch
cut
as
Nikita
said,
and
we
are
also
going
to
remove
the
112
jobs
and
create
the
116
jobs.
Next
week,
burndown
begins
code
freezes
at
the
end
of
the
month.
We
have
had
one
more
enhancements
exception.
That
was
the
metrics
overhaul,
that
Bob
Kenny
and
Lackey
did
a
lot
of
work
to
move
through
and
yeah.
E
E
A
So
for
anybody
new,
this
is
test
grid.
Kate's
do
this
is
where
our
CI
results
are
visible.
It's
loosely
organized
by
sig
and
depending
on
how
you
pull
this
up,
these
cards
show
up
in
in
different
places,
but
sig
release
being
here.
I
can
go
tunnel
into
that
and
you
have
sort
of
navigation
tabs
across
the
top.
So
what
what
Jeff
was
talking
about
would
be
sig
release
master
blocking
the
things
on
the
master
branch
that
are
potentially
blocking
release.
So
you
can
see
that
we
have
a
couple
of
failings.
A
The
other
thing
for
folks
that
are
new,
that
you
can
do,
maybe
not
so
obvious
in
the
UI,
is
you
can
click
on
a
green
box
and
drag
over
to
a
red
box
and
when
your
release
you're
gonna,
search
for
changes
and
for
people
who
are
triaging
issues,
you
can
see
the
basically
the
get
difference
between
those
two
points,
and
potentially
you
have
a
performance
issue.
Wojtek
normally
is
doing
performance
related
things.
It's
interesting
that
it's
around
PVCs
since
the
test,
that's
failing
is
around
dynamic
TVs.
A
So
that's
that's
kind
of
how
we
tend
to
your
triage
things
on
the
release.
Team
would
be
going
through
these
specifically
looking
for
a
way
to
get
into
connection
with
folks
who
are
doing
things
there
with
respect
to
sig
release,
though
so
sig
release,
weekly
or
daily
is
going
through
their
their
boards.
For
the
overall
sig,
we
have
the
release
miscellaneous.
Those
are
looking
green
today.
These
are
just
some
initial
simple
test
cases
we
have
publishing
bot,
as
Nikita
said,
is
running.
A
A
A
Well,
if
I
look
at
115
blocking
it's
okay,
we've
got
some
flakes
in
there,
but
we
made
a
change
to
the
go
link
to
a
tool
chain
and
we
wanted
to
get
as
broad
a
possible
this
feedback
on
how
that
went.
So
if
we
want
to
look
at
sig
release
115
all
we
again
have
a
ton
of
tests
that
are
failing.
I
did
some
debug
there
last
week
and.
A
We
could
choose
to
promote
some
of
these
up
into
release
blocking
potentially
the
we're
kind
of
in
a
weird
in-between,
fort
space.
I
feel
like
initially
all
the
tests
coverage
we
had
was
GCE
using
the
cluster
scripts.
That
weren't
well
maintained,
I,
guess
to
to
euphemistically
describe
it
and
six
lesser
lifecycle
didn't
want
to
touch
those.
So
that
was
a
gap
and
there
wasn't
somebody
else
to
touch
them
enough.
Keep
them
well
petted
and
purring
along.
A
So
that's
why
we
kicked
them
out
initially.
The
other
thing
that's
happening
between
Cuba
DM
is
cluster
API
work,
I'm
hopeful
that
between
those
two
we're
gonna
get
to
a
point
where
we
have
more
feedback
from
non
GC
or
non
kind
test
cases
for
upgrade,
and
then
the
third
gap
there
is
with
respect
to
downgrade
people
want
to
ensure
downgrade
coverage.
But
sig
cluster
lifecycle
has
very
explicitly
said.
No,
so
we're
evolving
into
a
slightly
better
place,
but
we're
we've
definitely
lost
coverage.
We
used
to
have.
A
Across
the
broader
concept
of
us
being
sort
of
a
distribution
and
having
potentially
more
things
that
we
publish-
and
we
definitely
in
our
changelogs,
we
published
the
set
of
things
that
we
tested
together.
Those
components
are
not
under
tight
control,
much
less
upgrade
or
downgrade
to
be
I
mean
we
hardly
even
specify
them
consistently.
In
the
first
place,
much
less
lifecycle
manage
them.
D
Okay,
anyway,
I've
just
added
myself
on
there
to
follow
up
I'm
gonna
delve
into
some
of
the
seed
clusters
since
they're
having
more
green
stuff.
Now,
sitting
cholesterol,
lifecycle
tests
to
see,
if
there's
a
couple
of
upgrade
tests
that
we
could
potentially
cross
over
to
the
sig
release
boards
and
put
it
in
forming
and
then
maybe
in
blocking
for
the
next
cycle.
If
they
proved
reliable,
a.
A
A
A
A
A
A
Now
one
thing
that's
come
up
and
that
we
should
possibly
consider
is
whether
we
have
two
different
time
meetings.
When
we
finish
the
doodle,
a
few
people
said:
oh
I
haven't
seen
the
doodle
or
at
that
time
is
really
bad
for
me.
I
definitely
cannot
make
it
so.
We've
we've
gained
a
good
number
of
people
by
shifting
the
time,
but
we've
also
lost
a
cluster
of
folks
who
were
active
or
intending
to
be
active
in
the
coming
period.
So
we
may
have
some
future
refinement
yet
to
do
on
the
time
zones
meetings
are
hard.
A
Next,
one
in
progress,
a
t715
failing
tests
on
test
grid-
if
we
just
had
these
open
and
I
think
those
are
least
mastered
for
me,
I
was
expecting
to
see
them
in
cig
release
mist,
so
those
are
still
failing,
and
this
isn't
going
to
change
for
bits.
Stevens
assigned
it
to
himself.
That's
basically
a
right.
We
need
to
kind
of
rewrite
these
tests
as
a
part
of
the
other
rewriting
we're
doing
around
the
yum
repos.
A
A
A
B
A
Okay
and
check:
let's
go
ahead
and
double-check
I
know
we
talked
about
it
in
sick
release
but
double-check
with
the
release
team,
I
I
feel
like
it
was
discussed
there
and
people
had
given
the
thumbs
up,
but
let's
double
check
and
then
obviously
the
PR
will
get
reviewed
as
well.
For
confirmation,
correct.
A
H
G
A
I
For
this
cube
con,
it's
gonna
be
sort
of
like
an
ad-hoc
process,
sort
of
like
it
has
been
in
the
past
in
the
future.
Right
now,
it's
looking
like
it
will
probably
use
the
same
forms
and
processes
for
the
diversity
scholarship,
and
essentially
you
know
if
it
will
just
go
down
the
list
of
if
they're,
not
for
the
diversity,
scholarship
or
one
of
the
other
things
that
sort
of
comes
out
of
that
pool.
It
will
then
go
to
us
for
review.
A
I
A
A
A
A
A
A
A
A
A
Here's
one
that's
actually
probably
partly
in
progress.
This
is
issues
73
to
86,
update
all
active
kubernetes
released
branches
to
latest
go.
This
is
actually
something
that
should
be
sort
of
a
standing.
Part
of
our
processes
is
like.
If
we
have
an
issue
for
this
look,
we
could
open
this
issue
every
month,
probably
and
reopen
it.
A
A
A
A
Erin
had
had
some
things
that
he
wanted
a
little
more
clarity
in
our
Charter
before
sig
release
changed
our
sig
sig
steering
committee
formally
said
that
there
are
ok
with
the
change
here,
but
I
think
or
maybe
ok
there,
but
let's
we
should
be
able
to
just
get
that
closed
and
then
that
relates
then
to
the
next
issue.
Here,
I've
got
a
number
of
non-blocking
things
this
is
assigned.
J
J
The
third
year
of
this
ticket,
I'm,
proposing
as
part
of
the
template
to
have
machine
readable
bits
that
the
law,
the
release
in
to
fetch
metadata
from
github
tickets
and
dump
this
into
some
system
that
can
track
the
progress
of
individual
features.
That
are,
you
know
in
que
enhancements
something.
But
this
was
just
a
proposal
at
this
point:
I'm.
Okay,
with
closing
this,
if
there
are
better
alternatives,
I'm.
A
J
A
A
Now,
alright,
well,
shall
we
call
it
a
meeting
then
for
the
week
all
right,
seeing
no
objections,
a
reminder
and
we're.
In
the
past
week
release
has
been
bi-weekly.
We
continue
to
be
bi-weekly,
but
in
the
off
weeks
we're
having
the
release
engineering
meeting.
So,
if
you're
interested
in
diving
in
on
some
of
the
tooling
and
coding
and
hacking
around
on
that
the
same
time
in
a
week
on
Monday
all
right
thanks,
everybody
have
a
great
day.