►
From YouTube: Kubernetes SIG Release Bi-Weekly Meeting for 20220712
Description
Kubernetes SIG Release Bi-Weekly Meeting for 20220712
A
Hey
everyone
welcome
to
the
july
12th
sig
release
meeting.
My
name
is
jeremy
and
I'll
be
the
host
today
before
we
get
started,
just
a
reminder
that
this
meeting
is
covered
by
the
kubernetes
code
of
conduct,
so
in
a
in
essence,
just
be
excellent
to
one
another
and
approach
this
meeting
with
positive
intent.
A
This
meeting
will
also
be
recorded
and
available
on
youtube.
I
see
in
the
chat
jason
says
this
meeting
wasn't
on
his
calendar.
Did
anybody
else
have
that
problem
is
everybody
here
just
because
they
they
know
that
it's
the
time?
Okay,
so
jason,
you
probably
need
to
check
your
sig
release
membership
on
the
dl
and
follow
up
after
the
meeting.
A
For
that
that's
cool,
I
dropped
the
agenda
into
the
chat
if
you
could
go
ahead
and
add
your
name
as
an
attendee
that
would
be
super
dope
if
anybody
would
volunteer
to
take
notes.
That
would
also
be
super
awesome,
and
with
that
we
can
go
ahead
and
get
started.
I
will
take
notes
unless
anybody
else
is
good
for
it.
First
off
we'd
like
to
open
it
up
to
welcome
any
new
attendees.
A
If
anybody
here
has
never
been
to
a
sick
release
meeting
or
it's
been
a
while-
and
you
like
to
say
hello
again,
give
you
a
opportunity
to
do
so
see
a
lot
of
familiar
names.
But
if
anybody
is
not
reoccurring,
character
here
go
ahead
and
come
off,
mute
and
say
hello
or
just
say
hello
in
the
chat.
If
you'd
like.
A
B
I've
recently
created
the
issues
and
have
started
the
threads
right
now,
trying
to
write
a
message
to
google
build
admins
to
mention
their
availability
tomorrow
and
other
than
that
we
are
not
doing
any
more
releases
of
1.21,
because
that
is
that
is
out
of
support
right
now.
I
recently
noticed
that
the
test
grade
still
contains
1.1
jobs,
probably
I'll
create
an
action
item
later
to
remove
those-
and
that's
all
on
my
side.
I
think
veronica,
if
you
have
any
updates
from
the
branch
management
side
for.
C
C
A
D
Oh
thanks
for
the
release.
We
started
the
apac
friendly
meeting
since
last
friday
and
due
to
the
low
participant
rate,
so
I
might
double
confirm
with
the
time
again
on
today's
meeting.
I
double
checked
with
the
last
time.
The
first
meeting
seems,
like
all,
participants
are
okay
with
the
time,
but
I'm
gonna
double
take
again,
since
we
are
hard
this
cycle
because
we
have
like
both
from
japan,
indian
and
europe,
so
it's
a
little
bit
harder
to
schedule
the
time
yeah.
A
A
E
E
So
there
is
a
road
mapping
session
this
thursday
from
4
to
5
p.m.
My
time
I've
done
the
time
zones
in
our
slack
channel
for
other
areas,
but
you're
all
welcome
to
join
that
it's
a
link
is
posted
in
the
slack
channel.
Oh,
I
asked
I
asked
a
sig
release
the
lead.
If
someone
can
help
me
put
a
gcal
invite
so
that
we
can
send
out
the
invite
that
way.
E
E
We
already
had
one
session
on
that.
A
couple
weeks
ago
we
broke
some
tasks
out,
got
some
clarity
on
what
we
need
to
do.
What
are
some
milestones,
but
we
will
go
further
on
that
topic
and
then
I
reached
out
earlier
today
to
adolfo
to
get
the
next
item
on
our
list
get
a
session
for
that
one.
The
signing
of
release
artifacts.
E
That
one's
in
progress,
so
that's
good
and
then
there's
a
couple
items
on
this
roadmap
that
don't
really
have
any
description,
caps
or
maybe
insufficient.
Given
the
survey
that
we
did
recently
to
figure
out
some
how
these
ideas
respon
resonated
with
community,
so
some
some
of
the
items
are
not
clear
to
the
survey
respondents,
so
we
would
need
to
create
some
documentation
about
what
what
the
goal
is
of
those,
especially
the
making
cluster
api
first
class
signal
and
one
other
one.
F
G
Essentially
this
is
we
have
a
bunch
of
tests
that
are
generated
for
for
the
for
kubernetes
kubernetes
and
the
tests
are
regenerated
kind
of
as
we
cross
the
boundaries
between
release
cycles,
but
they're
in
various
states
of
decay
really.
So
there
are
some
primary
tests
that
use
like
the
cluster
directory
within
kubernetes
kubernetes,
and
that
is
primarily
targeting
gcp
right.
G
But
the
interesting
thing
about
many
things
within
kubernetes
kubernetes
is
that
some
of
some
items
have
no
owners
or
no
like
true
sig
owners
right.
So
the
idea
is
like
if
we
can
get
cluster
api
provider
variant
tests
running
across
multiple
multiple
environments
to
make
it
make
it
the
right
signal
for
for
releases
I'll
put
right
in
quotes,
but
that
I
think
you
know
some
of
that
is
dependent
on
whether
or
not
people
want
to
do
it.
Who
wants
to
own
it?
Who?
F
G
I
haven't
I
haven't,
so
I
haven't
done
any
estimation
on
this
because
again,
we
are
not
actually
the
owners
of
this,
so
we
can.
We
should,
I
think,
I
think
the
one
of
the
first
steps
for
this
whole
thingamajig
is
deciding
if
it's
something
that
we
actually
want
to
do
and
where
we're
at
from
the
time
that
we
first
wrote
this
down,
because
maybe
this
is
not
even
a
need
anymore.
F
G
H
G
Yeah
presenting
the
signal
around
release
blocking
you
know
a
test,
so
this
is
part
of
the
reason
that
it's
in
our
area,
but
it's
not
specifically
owned
by
us
right
so
part
of
this-
would
be
reaching
out
to
individual
owners
of
release,
blocking
tests
and
kind
of
trying
to
make
a
determination
on
where
their
tests
are
at.
If
we
feel
it's
something
that
needs
to
be
shored
up.
F
A
E
G
E
A
H
H
So
I
did
some
scoping
work,
which
I
noted
down
on
the
gist
things
that
I
looked
at
and
what
I
think
the
next
steps
are.
So
it
would
be
nice
to
get
some
approval
to
deploy
the
next.
The
stuff
I
mentioned
in
the
next
steps
and
there's
also
a
couple
of
diagrams-
I'm
not
just
kind
of
that
kind
of
visualizes
where
we
are
and
we
want
to
get
to
and
the
intermediary
journey
that
we
need
to
take.
G
B
H
I
H
E
G
I
E
J
C
H
H
J
Okay,
muhammad,
I
can,
I
can
probably
take
a
take,
a
look
and-
and
we
can
discuss
it
offline,
because
I
need
to
understand
the
from
the
first,
the
the
from
the
first.
From
the
first
time
we
I
saw
the
plan,
I
had
misunderstood
what
you
were
trying
to
to
heal
but
happy
to
to
think
offline
and
after
a
meeting
and
and
find
some
time,
people
understand
that
and
yeah
I
can.
I
can
jump
on
that.
H
A
A
A
We
set
a
doodle
out
to
try
to
gauge
interest
in
new
times
for
this
meeting,
to
kind
of
go
along
with
our
discussion
about
condensing
or
combining
sig
release
and
release
engineering
meetings
into
just
basically
one
meeting,
because
we
we
go
back
and
forth
on
the
topics
like
like
this.
Quite
often
there
wasn't
a
lot
of
turnout
on
the
on
the
ish
and
the
the
doodles
seems
like
9
a.m.
Pacific
is
the
best
u.s
time
there
are
only
five
votes
and
it
seems
like
12
p.m,
cest,
which
is
6
a.m.
A
Eastern
time
is
the
best
time
and
again
there
are
only
five
votes.
So
there's
not
a
huge
turnout
on
either
one
of
those
things.
I'm
not
sure.
That's
enough
information
to
really
make
a
change
or
decision
about
meeting
times.
I
would
love
to
hear
what
other
folks
think
about
that.
Should
we
just
stick
with
this
time
for
now
and
just
do
the
change
like
so
we
don't
alternate
release
engineering,
sig,
release,
real
estate
engineering
and
just
go
to
one
one
meeting.
G
A
E
G
Discussing
what
are
we
discussing
aws,
the
s3
blogs
replication
and
whether
it
needed
to
be
whether
it
needed
to
be
a
synchronous
or
asynchronous
process?
The
last
I
heard
are
the
first
things
that
we
were
discussing.
I
think
a
while
back
was
that
it
we
wanted
it
to
be
a
part
of
the
image
promotion
process,
treating
the
treating
the
s3
assets
as
first
class
citizens
in
the
release
process.
Since
then,
I
hear
that
that
has
changed.
The
proposal
has
changed.
J
And
then
we
started
working
on
that.
And
so
my
objection,
if
you
all
remember
the
mega
thread
on
on
ck
cinfra,
was
that
whatever
we
do
should
not
increase
want
the
complexity
of
the
as
well
as
much
as
possible.
Do
not
try
to
not
to
increase
the
the
complexity
of
the
of
the
promotion
process
or
or
the
of
the
time
it
takes
to
promote
images
as
not
to
add
more
time
to
the
release
manager
involved.
J
That
was
the
first
one
and
then,
after
the
the
thread,
one
of
the
things
that
came
up
was
that
we,
it
was
possible,
but
it
was
not
desired
to
to
do
the
replication
async.
So,
in
our
view,
at
the
time
and
replication
should
be
handling
of
mirrors,
which
should
fall
under
the
ck
team
frame,
responsibility
and
then
the
first.
D
I
I
J
Yeah
and
I
think
that
that
that's
some
of
the
tests
that
caleb
and
jay
have
been
working
on
making
sure
checking
how
much
how
long
it
takes
for
the
the
full
bucket
replication
making
sure
it's
it's
happening
in
a
consistent
and
dependable
way.
So
that's
that's
what
I
know
that
the
effort
currently
sense.
I
G
I
E
G
I
I
Yeah,
because
they
are
too
impact,
they
are
too
dark
impact
about
about
the
migration
aspect
registry.
The
first
thing
is,
we
lose
the
gcs
bracket
that
report
those
staging
repository,
and
we
also
need
to
ensure
we
do
the
replication
between
three
new
artifact
registry
repository
for
a
station
project.
G
J
Yeah
but,
but
I
mean
access
to
the
actual
bucket
backing
gcs
gcr
is
not
important
for
staging
right,
because
the
the
promoter
itself
does
not
need
access
to
the
pocket.
It'll
do
everything
just
by
querying
the
registry
apis
right
right.
So
on
that
side
and
another
important
thing
is
it's
not
one
I
mean
it,
I'm
not
sure.
I
think
it's
all.
Staging
projects
are
in
the
in
the
same
registry.
I
think,
but
we
should
not
consider
like
one
registry
but
yeah
we
can
migrate
those.
J
I
I
think
some
of
the
testing
that
you
did
steven
confirmed
that
the
promoter
will
will
run
on
okay,
so
we
have
the
because
it
relies
on
some
extensions
of
google
registry.
So
so,
if
those
are
present
on
the
on
artifact
registry,
then
we
should
be
fine
just
shifting
promoting
from
wherever
we
want
from
the
source,
whatever
it
is,
be
it
container
registry,
the
current
gcr
or
artifact
registries-
it's
it's.
It
should
be
transparent
for
us.
We
can
start
testing
on
a
project
basis.
J
It's
we
can
potentially
set
up
one
project
to
start
promoting
from
them
and
if
it
works
it
it
may
it's.
It
should
be
easy
easy
to
to
move
that
on
the
on
the
target
registry.
It's
it
should
potentially
work.
I
just
need
to
go
through
the
research
that
mohammed
did
to
to
fully
understand,
and
that
should
be,
I
mean
just
a
shift
in
targets
and
destinations,
but
we
need
to
check.
I
Yeah,
I
put
the
basically
the
idea
of
the
project
we
can
use.
I
think
the
the
first
thing
we
need
to
do
is
ensure
we
can
safely
migrate
from
gcr
to
actual
registry
for
sp
station
bracket,
and
we
do
that
in
the
next
phase
is
to
do
that
for
all
the
station
bracket
and
later
we
look
at
gates,
artifact
problem.