►
From YouTube: Kubernetes Release Engineering 20200203
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,
hello,
everyone
today
is
February
3rd.
This
is
the
release
engineering
sub
project
meeting
for
cig
release.
This
is
a
meeting
that
will
be
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and,
in
general,
just
be
awesome.
People,
okay.
A
A
A
A
A
Confusion
around
the
one
Archie
talks
great
question.
So
essentially
what
happened
is
minimize
alright.
A
The
anatomy
of
kubernetes
really
success
through
team
and
tools,
and
you
can
read
the
overview
here
and
the
second
one
will
be
myself
and
Jorge,
and
that
will
be
a
chat
about
CI
signal
and
kind
of
so
didn't.
Demystifying
CI
signal
the
link
between
kubernetes
testing
and
release,
and
that
will
be
kind
of
an
overview
of
some
of
the
work
that
we
do
in
the
cycle
to
kind
of
clean.
B
A
So
I
think
the
the
space
projection
for
those
attracts
had
initially
been
on
the
assumption.
That's
I
guess
their
definition
for
activities
where
SIG's
SIG's
sub
projects,
user
groups,
all
that
stuff
be
counted
as
a
single
talk.
So
that's
that's
where
that
came
from
and
I
think
the
I
think
the
sentence
was
like
put
together
in
a
way
that
was
open
for
kind
of
misinterpretation,
but
I
think
you
know,
we've
got
all
that
sorted
out.
A
Everyone
who
submitted
a
maintainer
tract
proposal
should
have
been
accepted
if
you
are
from
a
different
sig
and
did
not
have
the
opportunity
to
get
one
accepted.
I
think
it's
all
sorted
out.
But
if
that
that's
not
the
case,
but
us
know
what
someone
know
what
you
know
and
we
can
help
escalate
that
any
questions.
A
Maybe
we
can
figure
out
some
ideas.
I
have
one
idea
which
would
be
a
kind
of
birds
of
a
feather
session
between
ourselves
and
and
working
group.
Cates
infra
right.
There
is
some
work
going
on
that
we
kind
of
collaborate
on
not
as
frequently
as
maybe
be
good,
so
I
wanted
to
get
some
ideas
about
like
sitting
down
with
them,
drawing
out
some
some
lines
for
different
projects
and
and
seeing
what
we
can.
We
can
do
in
2022
to
move
things
forward.
I
see,
barb
is
here
actually
and
so
comfort.
If
you
have
opinions.
A
E
A
C
E
Yet
because
I
have
two
topics
which
I'm
currently
discussing
with
working
group-
and
this
is
the
second
one
I
want
to
mention
today,
because
I'm
thinking
about
also
doing
like
taking
some
forgot,
the
name
of
the
program
from
Google
xxx
yeah.
So
this
is
the
thing
which
I'm
discussing
with
people
and
after
that,
I
want
to
start
this
topic
about.
E
E
Can
live
a
later
at
this
point,
we
are
mostly
focusing
on
moving
some
smaller
projects
or
new
infra,
and
the
other
topic
is.
We
are
starting
to
rewriting
the
bar
scripts
for
the
new
automation
for
the
new
infrastructure,
to
terraform
the
point
of
idea
and
discussions
about
what
and
how
much
we
want
to
rewrite
country.
A
F
I
know
that
there
might
be
multiple
sikhs,
interested,
like
secrets
of
life
cycle,
was
interested
in
our
release
doing
to
qadian
stuff.
Maybe
there
was
some
stuff
about
branching,
maybe
have
a
session,
that's
going
to
cover.
All
of
that
and
present
wants
you,
and
maybe
talk
a
little
bit
about.
This
will
be
something
like
that
interesting.
A
That's
a
suggest,
the
same
thing:
Louvre
Amir
should
be
there.
Yeah
that'd
be
really
cool
because
we've
got
you
know,
like
you
mentioned,
cluster
lifecycle
interested
in
the
branching
stuff,
sig
Doc's
interested
in
and
more
branching
stuff.
Those
branch
fast
forward
tools,
I
know
that
you
know
my
side.
I've
used
the
release,
notes
tool
to
generate
release,
notes
for
for
other
projects
as
well
so
and
then
we've
also
got
external
people
who
are
starting
to
get
interested
in
using
the
release
notes
tool.
So
we
can
maybe
get
together
yeah.
B
A
G
Know
where
there's
cutting
a
release
tomorrow,
I
know
we've
done
in
the
past.
--Kavitha
zoom
called
a
shadow
that
would
that
be
something
that
would
be
possible
for
tomorrow's
Royce.
Never.
A
We've
never
done
that
yeah,
so
so
Carlos
and
Sasha
are
the
branch
managers
and
they
are
EU
time-based.
If
they
want
to
do
a
call
for
that,
y'all
can
definitely
feel
free
to
schedule.
So
I
think
Carlos
said
he's
traveling
today,
but
Sasha.
If
you
want
to
set
something
up
for
that,
each
other
again,
yeah.
H
C
Stricken
the
sick
release
meeting
there's
a
fair
amount
of
discussion
about
what
it
would
take
to
have
a
plan
for
when
we
cut
over
on
tools,
we
we've
had
a
fair
amount
of
progress,
but
the
sig
cluster
life
cycle
discussion
around
qadian,
split
out
kind
of
drove
the
discussion
that
we're
we
don't
feel
quite
ready
to
switch
over
yet.
But
what
would
our
criteria
be?
What
are
the
gaps?
What
could
we
try
and
get
targeted
focus
on
to
right,
implement
and
test
like
tomorrow's
release,
the
Alpha
3
we
have.
C
We
got
a
alpha
for
beta
zero,
one,
two
and
probably
RC
as
well.
Each
of
those
become
a
point
where
we
could
run
a
new
tool
post
production
into
old,
collect
a
little
data
in
a
safe
ish
way
compared
to
what
we
have.
But
if
we
have
a
deliberate
plan
for
the
next
eight
weeks,
we
could
probably
get
a
lot
more
out
of
it
and
start
bringing
more
things
online.
C
One
thing
specifically
there
if
you
like,
we,
you
sort
of
start
out
with
the
leaves
or
start
stop
start
out
at
the
top
and
we
can
have
two
ago
or
so.
When
you
and
I
last
talked,
you
were
talking
about
trying
to
rewrite
the
top-level
main
function
and
an
ago
just
to
straighten
it
out,
not
have
it
be
so
speculative
and
loopy.
That
might
be
a
easy
way
to
make
some
points
where
we
could
feel
more
safely.
C
A
A
Yeah
yeah
so
I
think
what
I
want
to
have
happen.
First
is
Tim
and
I,
so,
at
least
on
the
Newell
saw
on
the
new
tools.
Side,
I
think
I
want
Tim
and
I
to
lay
down
the
skeleton
for
that,
and
then
have
people
build
around
that
for
the
for
the
current
iteration
of
it.
I
really
wish
we
could
just
throw
it
and
the
fire
and
cut
it,
but
I
think
we.
A
You
know
we
discovered
a
few
things
that,
were
you
know,
weird
or
not
necessarily
supposed
to
happen,
one
of
which
is
the
kind
of
the
out
of
order
committing
for
the
changelog
and
I
know.
Sasha
you
and
Hannes
are
have
been
working
on
firming
up
or
doing
steady
reviews
of
prx
to
firm
up
the
the
Krell
chain,
flog
tool.
So
do
you
want
to
talk
a
little
bit
about
that.
H
Yeah,
so
we
are
mostly
done
with
the
transition
between
the
change
look
scripting
to
the
colon
based
version.
This
looks
right
now
and
the
next
step
would
be
to
bring
it
into
an
ago
and
we
have
to
pee
ours
up
right
now,
which
are
both
on
hold,
because
we
are
basically
just
waiting
for
the
inacol
skeleton.
H
Maybe
so
we
are
not
completely
sure
which
stretch
you
want
to
choose.
If
you
want
to
do
it
step-by-step,
my
creation
for
men
I
go
to
the
colon
based
twist,
so
there's
one
PR
which
could
be
really
would
it
would
definitely
break
something
because
cred
is
not
in
in
the
past.
For
an
ago
right
now,
mm-hmm.
G
A
Yeah,
okay,
so
yeah
so
I
know
there.
There
was
one
or
two
that
flew
by
that
I
approved
around
this,
but
this
one
is
probably
the
big
one:
I
yeah,
that's
that's
the
meat
and
potatoes
all
right.
So
the
yes,
so
the
first
one
was
making
sure
that
we
have
everything
that
we
need
in
the
path
right.
So
that
was
the
compiled
release.
Tools
update
right.
Yes,
so.
A
Let's
see,
can
we
test
this
some
hope?
Yes
soon
coming
soon,
all
right,
so
we've
got
locking.
Okay,
this
is
updated
to
include
blocking
test
grade
tests,
cube,
pkg
and
release
notes.
We
probably
don't
need
the
release,
notes,
one
though
right
or
no
I,
don't
think
so.
Okay,
all
right
so,
okay,
so
I
can
I
can
take
a
look
at
this
again
and
I
know
you
tweaked
some
of
this,
so
that
it
pulls
in
the
version.
A
Yeah
this
yeah,
this
we
can
get
in
soon
yeah
I.
Think
these
releases
are
the
perfect
opportunity
to
these
alpha
release.
It
was
a
perfect
opportunity
to
test
some
of
this
stuff,
so
what
I
had
done
recently-
and
this
thing
is
horribly-
broken
right
now-
well
and
informing
right,
very
red,
very
red,
so
it's
essentially
so
created
a
new
job
called
CI
released
on
August
age
and
that
job
is
fail.
Failing
for
configuration
issues
but
I
think
it's
I
think
it's
attempting
to
pull
a
credential
that
is
come
on
all
right.
A
A
Adds
a
flag
and
support
for
attended
releases,
ascended
GCV
submission.
So
essentially
all
this
does
is
add
this
new
flag
and
the
flag
will
switch
the
async
flag.
Honor
are
off
for
the
G
C
for
the
G
cloud.
Build
submit,
so
I
want
to
come
back
and
fix
the
flag
name
so
that
it's
clearer
Honus
made
a
good
suggestion,
but
there
are
a
few
things:
I
need
to
tweak
in
the
test
to
make
sure
that
they
work
one
I.
A
What
I
want
to
see
an
actual
test
failure
as
opposed
to
a
test
failure
related
to
CI,
because
I
think
we
still
need
to
wire.
The
are
the
proud
n
chose
to
be
able
to
submit
GCB
runs
within
the
staging
project,
the
two
so
yeah,
the
idea,
the
short
version
was
the
idea
of
putting
that
test
together
is
so
that
we
can
have
staging
consistently
running.
A
In
the
background
on
some
interval
right
now,
every
two
hours
we
can
probably
shorten
that
once
the
test
is,
we
can
probably
increase
that
interval
once
the
test
is
running
properly.
I
just
have
it
at
two
hours
so
that
we
get
a
little
faster
signal.
There
so
the
idea
there
is
for
us
to
be
able
to
safely
all
relatively
safely
tests
the
changes
against
tamago
without
having
to
having
to
have
a
release
manager.
Do
that
so
Sasha.
A
Once
that
works,
we
can
so
I'm
yeah
I
guess
we
can
do
it
sooner
for
an
ALP,
oh
I'm,
I
care
less.
If
things
break
and
I
think
this
is
based
on
what
I'm
reading
it
all
seems,
reasonable
I
would
say,
run
through
a
burn
through
a
mock
stage
and
mock
release
with
that,
because
you
can
do
so
from
your
branch.
If
you
want
to
try
that.
A
Miscellaneous
cig
release
miscellaneous
I've
always
had
a
problem
with
figuring
out
a
name
for
this
board,
because
I
didn't
want
to
call
it
sig
release
release
engineering
because
of
that
stutter,
but
I
was
like
we
should
have
one
that
is
specifically
for
the
release
engineering
tests
and
start
to
pull
out
things
like
release
cluster
up
and
release
tests
and
there's
some
on
the
master
informing
board
that
should
probably
be
over
there
to
you.
There
are
five
packages:
Deb's
rpms
the
build
package
tabs
and
rpms
like
everything
that
is
related
to
you
like.
A
B
A
And
this
will
come
up
soon
for
y'all
Sasha
been
poking
at
removing
the
114
jobs
right.
So
what
I'm
trying
to
do
is
remove
the
114
jobs
ahead
of
a
head
of
the
branch
cut.
I
think
that
we
can
separate
the
process
of
deleting
the
old
branch
and
turning
off
CI,
deleting
the
old
branch
job's,
not
the
branch
itself
and
turning
off
CI
ahead
of
a
head
of
the
branch
cut
and
then
have
the
branch
cut
via
separate
steps,
but
the
the
tools
that
we
have
today
kind
of
assume
that
they're
all
the
same.
A
A
A
This
one
switches,
the
dashboard
tabs
reference,
the
correct,
sudo
versions.
Right,
it's
a
beta.
You
can
see.
There
are
some
older
dashboards
from
the
that
are
used
in
the
generated
tests,
so
they
moved
to
actually
reference
the
version
marker
that
they
targeted
against
lots
of
lots
of
little
tweaks,
also
working
on
something
that
that
allows
us
to
skip
tests
in
the
generation.
So
if
we
I
don't
know
how
much
is
useful
to
show
right
now,
but.
A
A
A
B
A
It's
basically
all
the
way
up
until
we
do
that
beta
cuts,
so
I
think.
Historically,
we
have
not
been
so
essentially
what
will
happen
as
we
cut
a
branch,
we
cut
a
branch
and
that
essentially
starts
to
shift
the
current
release
in
development
into
that
release
branch.
So
essentially
what
we
want
to
start
doing.
This
testing
master
against
that
branch.
So
there
are
a
bunch
of
tests
that
exist.
A
The
test
match
against
that
branch
and
if
we
can
give
you
upgrades,
downgrades
left
grades
right
grades,
all
that
good
stuff
and
then,
after
the
release
happens
essentially
that
beta
stays
beta
right,
even
though
the
next
release
and
development
would
be
so
right
now
when
117
was
out,
117
was
the
the
beta
branch,
and
now
that
118
is
in
development,
so
117
is
no
longer
beta.
117
is
now
current,
stable
right,
so
117
analysis,
a
current
stable
as
well
as
the
beta,
which
kind
of
makes
no
sense,
so
we
should
just
switch
it
off
right.
A
All
right
so
lots
of
pretty
output
so
now
it'll
kind
of
spit
out
that
the
marker
was
not
found
it's
going
to
skip.
It's
gonna
skip
a
test
generation,
Rico's
markers
we're
not
found,
and
my
lovely
lovely
error
messages
here.
But
if
we're
going
to
clean
up
but
essentially
essentially
what
this
does
is.
I
also
have
to
clean
up
some
of
the
spacing,
but
we
can
see
now
that
that.
A
G
Push
build
still
has
some
work
to
be
done,
which
is
one
of
the
reasons
why
I
wanted
to
shadow
the
release
tomorrow,
because
some
of
it,
a
lot
of
that,
is
handled
right
now
by
basil
and
like
that's
kind
of
getting
changed
and
yeah.
So
we
have
to
kind
of
like,
but
it's
not
just
strict
translation,
basically
from
the
bash
scripts.
So
there's
still
a
little
bit
of
work
to
do
on
that,
but
I'm
gonna,
try
and
address
that
once
I
get
a
little
more
insight
as
to
what's
actually
happening.
Yeah.
A
A
A
A
This
is
the
one
that
actually
pushes
the
changes
to
the
the
version
marker
files
that
we
use
the
this
is
the
one
that
pushes
the
latest
the
latest
stop
txt,
so
it
will
so.
The
tests
will
essentially
do
a
no
op
when
it
recognizes
that
that
version
already
exists
in
the
system.
There's
a
little
look
at
the
latest
tag
determining
what
that
version
is
and
then
try
to
think
about
whether
or
not
it
has
to
do
a
build
of
it
right,
so
that
test
doesn't
run
to
completion
all
the
time.
G
A
A
A
A
A
A
A
No
problem
I
also
need
to
figure
out
what's
going
on
with
the
basil
one,
because
we
push,
we
push
different
version
markers
with
the
basil
one.
So
it's
like
latest
basil,
txt
and
then
there's
like
latest
basil,
RVE
txt,
which
is
for
the
remote
bill
of
execution
ones,
and
do
we
need
all
of
them
and
who
actually
uses
those
tags
so
around
the
the
stable,
the
cake,
stable
gates,
beta,
Cates,
dev
version,
markers
I
want
to
work
towards
getting
rid
of
them.
A
The
cycle
as
well,
and
that's
that
quick
demo
that
I
showed
you
for
the
generator
script
and
test
infer
as
part
of
that.
Essentially,
we
want
to
identify
all
of
the
jobs
that
use
odd
markers
or
these
generic
suffix
markers
and
tweak
them
to
not
do
that
to
becomes
either
target
a
latest
or
stable
version,
and
then
we
want
to.
A
Then
we
want
to
remove
any
usage
in
non
generated
tests
of
the
of
those
version
markers
and
once
we're
fairly
confident
of
that
we've
done
a
sweep
of
those
properly.
We
want
to
turn
off
actually
publishing
those
markers
see
if
any
errors
fall
out
of
it
and
then,
while
all
of
that's
going
on
is
so,
if
you
one
more
one
more
screen
share,
so.
A
But
you
can
see
that
the
that
the
generic
suffix
is
are
kind
of
wired
tightly
to
the
job,
to
the
job
name.
So
I
need
to
figure
out
what
we
would
want
to
do.
There
I
think
the
first
step
would
be
to
figure
out
these
kate's
versions
rates.
So
so
in
this,
in
this
version
of
the
config
we
have
the
we
have
the
the
beta
marker
removed
right.
A
So
if
I
actually
never
mind,
but
the
the
beta
marker
essentially
is
listed
at
latest
17
right
now
right,
so
it's
we
have
to
figure
out
what
we
want
to
do
with
these
specific
instead
stable,
1,
2,
3,
and
then
also
there
is
a
node
case
right
and
that
is
we'd
have
to
do
something
similar
there,
where
we
figure
out.
So
this
is
currently
Cates
equals
master
and
then
something
similar
for
the
release,
117
pieces
so
figuring
out
how
we
want
the
generator.
A
It's
really
the
the
interaction
between
the
generator
script
and
and
this
test
config
file
that
would
need
to
be
refactored
afterwards,
but
that
can
happen
in
the
background
and
yeah
but
yeah.
Some
of
this
is
messy
and
the
way
it's
currently
configured
I
think
it's
it's
kind
of
evolved
over
time,
and
maybe
it's
not
the
thing
that
suits
our
needs
anymore,
also,
depending
on
how
many
of
the
how
many
of
the
tests
we
take
a
look
at
and
maybe
deem
that
they're
no
longer
required.
A
A
A
F
A
F
F
B
My
whole
world
was
getting
ready
for
the
exam
and
now
that
that's
behind
me
focusing
on
learning
going
a
little
bit
better,
an
intern,
that's
gonna
leave
to
some
of
the
corral.
You
know
the
docks
fast
forward,
migration
that
we're
talking
about
so
I'm
thinking
over
the
next
week
or
two
here,
I'll,
probably
tenth
and
some
of
y'all
on
the
shoulder
for
some
help.
You
don't
see
and
they
kind
of
go
through
to
completion.
This
cycle.
G
A
A
If
we
figure
out
versioning
for
the
repo,
we
can
essentially
disconnect
push
build
from
essentially
have
the
kubernetes
kubernetes
get
get
push,
build
our
get
krell
push
or
whatever
we're
calling
it
I
think
that's
what
we're
calling
a
curl
push
from
cave
release
instead
of
pulling
it
at
master,
we
can
pull
it
at
versions,
so
we
need
to
need
to
figure
that
out,
but
that
also
like
prevents
us.
It
also
brings
us
someplace
where
we
can
have
certain
branches
use.
A
Certain
versions
of
of
Crowell
push
as
well
like
our,
so
our
pull
release
cluster
up
will
do
does
a
push
build
at
the
end,
because
it's
it's
essentially
doing
its
essentially
doing
what
the
kubernetes
CI
kubernetes
build.
Job
is
doing
it's
just
adding
it's
just
adding
a
fake
focus
so
that
it
kind
of
skips
all
the
tests
in
between
it.
Just
is
it's
enough
of
a
smoke
test
to
determine
if
we've
done
anything
within
that
PR
to
break
kubernetes
kubernetes
or
to
break
the
push
build
process
right.
A
So
that's
that's
what
that's
for
so
yeah
I
think
we
can
vet
out
a
bunch
of
those
changes
in
even
we
can
even
do
like
a
prototype
job
and
that
a
separate
job
that
targets
the
crowd
push
instead
of
instead
of
the
normal
push
build.
Let
me
try
that
out,
sounds
good
all
right
and
did
I
miss
anyone.
Taylor.
D
You
just
hear
a
small
voice
in
the
background,
so
kind
of
like
Jim
and
liking
a
little
bit
behind
in
that
so
I'm
going
for
my
CK
as
well
thing
up
on
that,
as
well
as
some
bill
laying
so
very
excited
going
to
be
jumping
into
some
tickets
and
just
kind
of
feeling.
Some
of
the
things
after
I
come
up
to
speed
on
that
which
I'd
say
t-minus
like
two
weeks
three
weeks
right
now
involved
in
the
118
release
as
a
release,
lead
shadow
very
excited
about
that.
D
A
I
A
I
I
A
I
think
I'll
comment
there:
yeah,
okay
yeah,
so
for
those
clicking
in
we're
essentially
trying
to
figure
out
what
to
do
with
image.
Building
on
kubernetes
kubernetes.
These
images
have
classically
oh
look
a
conflicting
file
already.
These
images
have
classically
then
kind
of
hand-built
and
then
built
based
on
the
the
docker
files.
A
What
part
of
what
that
PR
is
doing
is
cleaning
up
some
of
the
make
files
that
are
and
and
doctor
files
are
involved
and
creating
the
primarily
the
Debian
images
that
we
have
so
that
mean
base
they're
being
iptables,
the
Debian
hypercube
base
and
so
on
and
so
forth
and
making
them
enabling
them
to
run
in
within
our
image,
building
and
promotion
process.
So
I
think
there
are
some
things
that
we
still
need
to
figure
out
about
ownership.