►
From YouTube: Kubernetes SIG Release for 20221213
Description
Kubernetes SIG Release for 20221213
A
A
Yeah,
it's
recording
good
morning
good
evening.
Everyone.
This
is
December
the
13th,
and
this
is
the
weekly
release
secret
release
meeting.
My
name
is
Adolfo
and
I'm
gonna
be
your
host.
Today,
I
see
we
have
a
light
agenda
I
think
for
today,
but
well.
If
someone
can
help
taking
notes,
it's
always
really
welcome
and
appreciated
and
we'll
start
by
giving
new
members
any
chance
their
chance
to
say
hello.
A
All
right
so
no
worries
just
we
want
you
to
know
that
you
are
welcome
here
and
if,
at
any
time
you
want
to
pop
in
and
say
hi
we're
more
than
welcome
to
to
give
you
space
and
hear
what
you
have
to
say
all
right.
So,
let's
turn
to
some
of
the
sub-project
updates.
Anybody
would
like
to
give
an
update
on
release
engineering.
B
D
B
And
it
had
been
delayed
from
Thursday
to
Friday.
126.0
is
finally
here
it
is
working
and
everything
is
fine.
Shout
out
to
the
team
that
work.
We
need
to
be
run
into
some
serious
issues
that
we
had
a
conflict
with
the
fast
forwarding
job
that
caused
some
later
issues
in
the
release,
step
because,
for
instance,
fast
forward
move
subcoming,
since
we
had
batch
releases
on
the
same
day
and
that
caused
that
caused.
B
The
issue
is
later
on,
because
there
were
new
commission
about
26
the
starting
stage,
and
then
it
failed
to
push
when
doing
release
there
is
some
I
can
show
you
to
zoom
chat,
a
message
that
Sasha
sent
out
today,
thanks
for
that
for
some
more
details
and
huge
thanks
to
support
actually
took
care
of
this
and
managed
to
unblock
those
release
and
yeah
pretty
good
job.
Thank
you.
This
is
for
126.0.
We
also
had
petrolysis
about
22.17,
123,
15,
I,
think
or
24
9,
and
about
25.5.
B
Those
Specialists
went
mostly
successfully
the
we.
We
ran
into
some
issues
for
Easters,
like
some
flakes
in
the
release
that
that
have
that
made
us
to
have
to
retrigger
Stage
or
release.
We
created
issues
at
GitHub
for
this,
and
we
will
try
to
triage
this
to
actually
fix
those
issues,
hopefully
before
the
next
release,
so
that
we
avoid
those
place
other
than
that
I.
Don't
think
that
he
had
major
problems.
B
Rc1
is
available,
I
see
that
Carlos
picked
it
up
so
I
guess
we
will
soon
start
incorporating
it
on
master
of
kubernetes.
So,
let's
see,
how
is
it
going
to
work?
Let
me
see:
do
we
have
anything
else
for
the
OBS
World
copybin
Service
I
certainly
didn't
have
much
time
to
finish
the
cap,
but
this
is
something
that
I
am
planning
to
do
this
week
and
let's
hopefully
be
able
that
I
will
be
able
to
finish
everything
that
we
can
start
discussing
it
there.
So
yeah
thank.
E
So
I
want
to
do
some
like
some
quick
process,
things
just
for
the
release
managers,
so
the
I
think
the
first
is
work-life
balance.
I'll
do
the
work
life
balance
thing.
First,
we
have
a
global
team.
I
want
people
to
keep
that
in
mind
as
we're
kind
of
running
through
the
anytime
we're
doing
releases,
and
we
know
it's
gonna,
it's
it's
kind
of
a
depending
on.
What's
going
on
in
the
day,
it's
a
it's
a
potentially
a
follow.
E
The
sun
situation
right
so
recognize
that
you're
on
a
global
team.
If
you
need
to
hand
something
off,
that
is
completely
fine.
That
is.
That
is
why
the
team
is
staffed.
This
way
recognize
those
problems
early
or
or
the
the
time
constraints
early,
communicate
that
that
to
the
team,
and
then
we
and
then
we
pick
it
up
from
there.
E
No
one
should
be
no
one
should
be
hey.
It's
it's
1am,
my
time
and
and
I
think
I've
got
to
go
to
bed
or
something
like
that
like.
We
should
be
stopping
well
before
that
point
right,
the.
If
we
have
issues
with
releases.
The
first
thing
that
we
want
to
do
is
identify
if
it
is
an
issue
that
is
going
to
stop
the
release
for
that
day,
right,
first
and
foremost,
right
communicate
with
the
team
figure
out
if
it's
going
to.
E
E
The
first
is
the
fast
forwarder
I
believe:
we've
already
got
an
issue
filed
about
making
sure
that
the
fast
forwarder
is
shut
off
around
the
time
that
we're
getting
ready
to
release
right.
So
rc0
is
cutting
the
new
branch
and
somewhere
between
RC,
zero
and
official
we're
continuing
to
fast
forward
content.
We
need
a
stopping
sign
to
turn
off
the
fast
forwarder
right
so
that
that
conversation
is
already
happening.
That's
one
when
patch
releases
and
official
releases
or
or
GA
releases
are
happening
in
quick
succession.
E
I
think
that
we
should
prioritize
the
ga
release
if
it
is
if
it
means
a
delay
in
the
patch
release.
I
think
I'm.
Okay
with
that,
but
as
a
result
of
as
a
result
of
the
the
issues
with
the
fast
forwarder
as
well
as
the
patch
release
is
happening,
we
effectively
blocked
a
ga
release
for
patches
this
time
around
I.
E
A
Yeah
thanks
Steven
well
to
from
what
I
read
this
morning.
I
think
the
issue
with
the
fast
forward
is
done
from
what
I
gather
from
such
as
a
message
and
but
yeah,
absolutely
so
I
feel
we
still
have
a
little
bit
of
a
gap
between
the
time
the
America's
crew
needs
to
go
to
bed
and
the
folks
in
the
EU
start,
and
that
sometimes
causes
us
to
drag
a
little
bit
longer,
but
yeah.
Definitely
I
I
feel
that
we've
been
really
good
at
handing
off
problems.
A
So
far,
sometimes
emergencies
happen
like
the
with
the
last
release,
but
I
I
feel
that
we're
doing
a
really
good
job
I
mean
in
especially
for
the
ongoing
release
management
work.
I
feel
that
work-life
balance
has
been
improving
a
lot
and
I
and
I'm
really
grateful
that
for
having
my
to
fulfilling
my
back
supported
by
people
in
other
latitudes
and
what
I
also
wanted
to
to
add
to
what
Stephen
just
said
is
that
this
was
like
a
great
thing
to
see
happening.
A
I
mean
it
was,
unfortunately,
that
we
hit
a
snack
during
the
release,
but
I
I
think
it
was
a
great
experiencing
how
the
fast
forwarder
came
into
play
during
this
release.
Saving
a
bunch
of
people
a
lot
of
work
during
the
last
leg
of
the
release,
so
the
the
the
branch
managers
and
yeah
I
mean
sometimes
unexpected
things
happen,
and
but
seeing
the
team
respond
and
making
things
work
to
ensure
that
in
the
future
we
have
this
great
Automation
in
place.
Is
that
accurate
that
an
example
of
great
great
teamwork.
E
E
The
there
are
certain
things
that
we
have
added
to
the
process
or
changed
in
in
certain
processes
that
cause
things
to
take
longer
and,
as
a
result,
we're
we're
seeing
we're
seeing
occasionally
when,
when
those
things
bump
up
against
each
other
right.
So
the
fast
forward
are
running
into
the
deadlines
of
of
you
know
are
running
into
the
the
release
cycle
of
the
patch
releases
or
the
fact
that
we've
added
more
regions
to
replicate
images
too,
which
raises
the
time
that
the
image
promotion
takes
right
bills
and
promotions.
E
Take
the
the
changing
the
promotion
time
also
triggers
can
trigger
a
conflict
between
the
post
submits
for
the
promotion,
jobs
and
the
periodic
for
the
promotion
jobs.
So
so
we're
starting
to
see
some
like
interesting
issues
pop
up
around
timing.
So
I
would
ask
that
the
team,
just
like
keep
an
eye
on
like
how
long
we
think
things
are
going
to
take
I.
Think
it's
really
easy
to
it's
really
easy
to
turn
things
on
it's
much
harder
to
turn
them
off.
E
F
We
moved
them
up
a
week
because
it
was
going
to
be
the
end
of
the
year
and
people
are
going
to
be
going
on
vacation
and
availability,
and
then
the
go
thing
happened,
so
we
delayed
them
a
little
bit
and
then
I
think
just
everything
kind
of
smushed
together
and
the
increased
time
that
it
takes
for
some
of
those
things
just
exacerbated
it.
A
little
bit
so
I
think
considering
how
long
it
takes
for
some
of
those
things.
D
But
you
know,
like
you
know,
it's
always
a
challenge
with
cdes,
because
we
know
we're
always
going
to
get
some
things
dropped.
So
what
is
our
criteria
to
deviate
from
our
schedule,
which
then
caused
like
a
really
compressed
amount
of
activities
and
I'm
short
of
a
period
of
time,
meaning
the
release?
We
have
these
patch
Cuts
Like?
D
How
do
we
you
know?
Does
every
cve
Force
us
to
change
our
schedule
or
does
it
you
know
like
because
that
that's
where
it
kind
of
felt
like
if
we
would
have
kept
their
Cadence?
You
know?
Yes,
we
know
we
still
got
to
get
that
CDE
in
you
know,
and
have
you
look
Downstream
who
our
consumers
are
like
I?
Don't
think
any
of
them
are
there's
not
many
that
are
rejected
from
the
fire
hose.
You
know
getting
that
CV
if
they
got
that
patched
in
or
in
another
couple
weeks.
E
I
would
ask
you
to
file
an
issue
to
to
discuss
this
in
more
detail,
but
I
mean
the
the
the
short
list
is
the
things
that
will
block
a
release
right,
a
a
large
feature
being
incomplete,
a
a
regression
and
an
existing
API
that
may
that
you
know
that
may
need
to
be
fixed.
A
critical
test
failures,
release
engineering,
tooling
breakages.
E
E
On
security
we
are,
you
know,
we're
tapping
into
so
we
have
a
a
separate
channel
for
like
the
security
release
team,
which
is
basically
the
aggregate
of
the
fully
fledged
release
managers,
as
well
as
the
security
response
committee
right
when
things
are
coming
to
the
Forefront
that
will
affect
release
timelines
or
or
are
there.
There
are
things
that
are
hitting
kubernetes
kubernetes
and
and
may
require
action
on
the
release
manager
side.
E
We
usually,
we
usually
tap
in
there
and
and
try
to
figure
out
like
what
would
be
a
justification.
For
you
know.
Even
let's
think
about
like
out-of-band
releases
right,
there's
something
that
has
come
out
that
is
so
critical
that
that
we
need
to
fix
it
now
and
I.
Think
that
you
know
in
in
part
of
kind
of
your.
You
know
your
vulnerability
assessment
you're
also
doing
what's
the
likelihood
that
this
issue
is
going
to
impact
people
based
on
the
way
based
on
the
way
something
is
implemented
right.
E
If,
if
there
is
a,
you
know,
go
will
the
the
go
security
Engineers
will
also
they'll.
Give
us
they'll,
give
us
a
bit
of
a
highlight
on
you
know,
either
on
the
mailing
list
or
or
out
of
band
on
the
the
criticality
of
something
right.
If
it
is,
if
it
is
a
minor
security
fix,
they
will
pre-announce
that
it
will
be
a
it
will
be
a
minor
and
and
roughly
the
timeline
if
it
is
something
more
critical,
they
might
reach
out
to
a
few
people.
E
You
know
off
list
for
that
something
else
around
the
go
updates
in
general,
because
we
are
again.
This
is
a.
This
is
a
fun
timing
thing
right.
So
initially
we
were,
we
were
releasing.
You
know
little
in
the
past
2019
or
so
right
we
were
releasing.
We
were
doing
four
releases
for
the
year
right,
condensing
you
know,
or
extending
the
the
release
schedule
and
and
condensing
the
amount
of
releases
for
the
year
means
you
know
we
roughly
know
what
goes
release.
Cadence
is
right.
E
We
have
to.
We
have
to
Overlay
that
with
our
release,
Cadence
and
think
about
so
usually
for
go
releases.
Part
of
the
reason
that
you
know
120
the
you
know
the
120
RC
one
is
out
right
now
and
we're
already
starting
to
pick
it
up.
The
reason
is
that
we're
kind
of
always
racing
the
clock
against
a
go
release
right.
If
the
we
we
don't
want
to
have
major
go
changes.
So
goes
you
know
semantic
versioning
wise.
E
Do
you
kind
of
shift
right
a
bit
for
the
the
go
releases
right,
so
they're
they're
major
releases
are
on
the
the
1920
Etc
right
when
a
major
release
drops,
we
we
tend
to.
There
needs
to
be
a
really
good
reason
for
us
to
change
the
go
major
version
within
a
release,
Branch
right,
which
is
why
we
try
to
make
sure
that
we
are
current
on
the
release
Branch,
because
we
essentially
have
to
maintain
that
release
Branch
for
the
the
year
and
change
within
the
support
period
right.
E
D
That
makes
a
lot
of
sense.
It
just
sounds
like
you
know,
like
maybe
one
of
the
things
learnings
is
just
kind
of
like
like
if,
outside
of
like
this
release,
like
we
always
have
swim
lanes,
because
there's
unplanned
work
when
you're
in
these
Opposite
Worlds
and
you're
also
trying
to
release,
and
it
sounds
like
that's
kind
of
what
we
hit
here
with
and
then
the
compressed
timeline
at
the
end
of
the
year.
E
Yeah
for
for
sure,
I
think
the
the
the
end
of
the
year
is.
It
is
a
tricky
one
too
and
I
think
we're
still
kind
of
calibrating
on
timing
to
end
the
releases
or-
or
you
know,
timing
to
I
guess
maybe
like
cut
the
first
one
of
the
year
or
start
the
cycle
right,
because
every
you
know
now
the
you
have.
You
have
optimizations
in
between
schedule,
but
because
we
have
fewer
releases
for
the
year,
we
have
less
opportunities
for
those
optimizations.
E
A
G
I
can
I
can
give
some
updates
all
right.
So,
as
we
all
know,
we
released
on
Friday,
1
or
26
was
quite
quite
late
in
the
evening
on
the
Friday,
maybe
not
so
optimal,
but
but
we,
but
we
made
it.
It
took
quite
some
time
for
us
to
get
docs
ready.
It
was
a
little
bit
surprising
to
me
that
it
was
kind
of
challenge
or
not
challenging,
but
it
took
a
lot
of
effort.
G
So
we
took
a
lot
of
notes
and
want
to
improve
also
the
handbook
so
in
the
future,
that's
the
docs
lead
can
take
those
tasks
a
little
more
easily.
Hopefully
right
so
comms
is
also
out.
We
wrote
A
Few
emails
and
dropped
in
general,
like
some
comms
today
is
the
first
retro
thanks
to
Jeremy
and
James
for
hosting
that
and
writing
the
notes.
G
We
also
have
another
retro
for
tomorrow,
but
depending
it's
unsure,
if
we
need
it
depending
on
on
on
the
discussion
items
today,
maybe
we
will
cancel
it
or
not,
and
we
have
one
last
thing
to
do
or
one
of
the
last
things
is
to
write
the
exception
request
yaml
file.
So
usually
we
have
also
like
a
file
in
in
the
release
about
the
exception
requests
and
we
need
to
update
that.
But
this
is
should
not
be
an
issue
and
about
1
or
27.
G
H
It
is
coming
along
nicely
in
terms
of
the
Roll
things
I'm
going
to
steal,
number
rooms
Thunder
and
talk
about
this
I
believe
we
have
role,
nominations
for
everyone
other
than
docs
and
CA
signal,
and
we
are
working
on
those
two.
The
people
people
in
mind
and
people
have
been
spoken
to
so
it
is.
It
has
been
worked
on.
E
E
We
need
to
effectively
rework
some
of
that
associate
program
to
kind
of
encourage
people
through
the
latter.
So
that
is
something
that's
active.
We're
still
kind
of
knocking
around
ideas
there
and
there's
an
open
PR
on
on
the
process
that
is
overdue,
for
an
update
is
the
short
version,
but
stay
tuned
for
that.
I
I
hope
that
you
know
I
I
think
we
can
close
that
discussion
out
by
by
end
of
year.
E
Our
you
know
next,
two
weeks
or
something
like
that.
The
related
to
that,
if
there
are
people
who
have
served
on
the
release
team
in
the
past
or
have
been
working
in
Sig
release
for
a
while
and
have
interest
in
becoming
a
release
manager
associate,
please
let
us
know
you
can
reach
out
to
one
of
the
the
Sig
release
leads
via
DM
and
and
we'll
we'll
chat
about
it,
a
bit
just
to
gauge
interest
I.
E
E
And
yes
to
Marco's
point:
that
is
the
pr
that
I'm
referring
to
that.
That
first
commit
just
describes
the
process,
as
is,
and
then
I'll
start
layering.
Some
commits
on
top
of
that
that
describe
what
we
want
going
forward,
but
there's
some
discussion
there
already
and
feel
free
to
chime
in.
If
you
have
opinions.
I
We
would
typically
kick
off
around
two
weeks
after
the
last
release,
which
puts
us
January,
2nd,
which
I
don't
want
to
do
so.
I've
kicked
that
to
January
9th
to
start
the
release,
which
also
has
us
concluding
the
week
before
kubecon
EU,
so
yeah
feel
free
to
go.
Take
a
look
at
any
comments
and
yeah
appreciate
it.
B
C
A
A
When
is
the
proper
time
to
stop
pushing
new
text
to
the
older
GCR
backed
Registries,
and
the
discussions
around
that
happened
during
kubecon
suggested
that
we
should
try
to
take
the
opportunity
of
126
to
stop
bullishing.
Those
so
I
think
the
feeling
was
that
since
we
already
deprecated
the
the
old
registry
by
switching
the
the
name
back
in
125.,
we're
fine
to
move,
but
it
126
was
like
a
kind
like
a
good
breaking
point
of
to
stop
pushing
the
the
attacks.
A
A
But
the
new
tax
for
126
and
future
releases,
including
125,
which
was
kind
of
the
controversial
one,
would
no
longer
be
pushed
to
GCR
and
we
already
have
the
backboards
and
we've
tried
to
do
some
communication
around
the
registry
change.
But
well,
if
you
see
the
issue
now
we're
past
126
and
other
things
came
happen
that
well
didn't
make
that
possible.
But
well
we
need
to
have
the
discussion
on
when
to
to
do
the
the
actual
Sunset
of
the
old
registries.
E
We
also
need
a
communication
plan
for
this.
The
given
that
we
are
already
in
you
know
100
broadcast
126.
At
this
point,
we
need
to
make
sure
that
we're
we're.
We
give
people
plenty
of
leeway
to
to
understand
how
this
change
is
happening.
I
think
that
you
know
some
of
the
the
posts
that
we've
put
up
recently
are
kind
of
a
step
in
the
direction
just
making
sure
that
we
have
a
plan
in
place
just
on
on
comms,
as
well
as
the
technical
components.
C
Yeah
just
to
be
clear:
we
don't
we
don't
really
sensitive
registry
case.g
said
that
I
will
still
be
running
for
for
a
while,
because
GCR
is
deprecated,
it's
not
going
anywhere
for
the
next
I
think
two
to
three
years.
What
we
basically
want
to
do
is
stop
newer
tag
for
kubernetes
and
the
sub
project
to
be
pushed
to
basically
GCR.
C
If
we,
if
anyone
wants
to
want
to
basically
pull
anything
before
December
2022,
it's
they,
they
can
pull
those
images
the
old
one,
because
we
are
not
changing
anything
but
because
it's
difficult,
the
idea
is
to
make
sure
we
push
exclusively
to
artificial
three
and
save
from
that
and
the
batteries
or
last
we
made
sure
in
the
future.
If
we'll
basically
get
new
patch
releases,
we
will
push
from
regency.gets
attire,
so
I
agree
with
different,
like
I
would
like
to
basically
start
doing
that
in
120,
basically
meta
communication,
so
we
start
doing
that.
C
So
that's
why
I'm
like
yeah?
That's
what
I'm
saying
it's
about
consensus
on
how
the
most
I
think
the
most
important
thing
is,
like
communication,
make
sure
everyone
as
everyone.
Basically,
people
watching
the
news
of
humanities
know
we're
doing
this
and
we
can
distribute
that
information
everywhere
like
we
can
even
start
doing
this
communication
now
and
do
the
implementation
from
120
128.
C
E
C
A
C
C
Yeah
because,
like
the
lattice
patches
released,
have
now
the
new
version,
so
next
next,
my
song
with
next
month
for
the
battery,
we
still
use
the
old
one,
but
in
128
we
basically
say
because
we
spend
three
months
I
hope
we
spend
three.
We
spend
three
months,
communicate
everywhere,
Tick
Tock
YouTube
whatever
to
say.
Oh,
we
have
a
new
version.
Three.
We
will
be
announced
that
for
months
now,
in
his
time
now
to
put
cuts,
we
get
using
that
and
the
duplicate
one.
C
C
C
C
Make
sure
we
communicate
well
about
basically,
we
stop
pushing
the
tags.
The
old
one
will
will
still
be
there,
but
we
stop
pushing
the
tags
to
the
new
one.
We
do
this
for
specifically
answers
of
doing
this,
because
GCR
costs
now
more
than
it
used
to
be
because
in
October
GC
bench
was
in
your
building
about
the
service
we
use.
So
we
are
kind
of
impacts.
That's
why
I'm
saying
I
want
to
cut
extra
cost
for
next
year,
because
we
also
we
take
another
risk
to
be
out
of
project
next
year.
A
The
way
I
see
it,
we
need
to
do
some
changes,
so
it's
unrealistic
to
to
hope
to
have
them
this
year,
so
we
would
start
building
them
in
January
February,
and
then
this
puts
us
like
almost
at
127,
so
128
makes
the
most
sense
by
128.
All
of
the
batch
releases
that,
where
officially
being
pushed
to
GCR
Ariel
with
my
math,
is
right.