►
From YouTube: Kuberentes SIG Release Meeting for 20230912
Description
Kuberentes SIG Release Meeting for 20230912
A
Hello:
everyone
welcome
to
the
Tuesday
September
12th
secret
release
meeting.
My
name
is
Jeremy
and
I'll
be
the
host
today.
Just
a
quick
reminder
before
we
get
started
that
this
meeting
is
covered
by
the
cncf
code
of
conduct,
so
by
participating,
you
agree
to
abide
by
the
cncf
code
of
conduct.
This
will
also
be
recorded
and
available
on
YouTube,
so
fair
warning
that
you'll
be
on
on
the
internets.
A
B
A
C
Yeah
I
into
this
meeting
hi
there,
everyone
currently
I've,
worked
mostly
for
the
sitcoms
and
which
I
I'm
working
currently
for
the
smart
click
Vlog
in
the
Sync
release
and
I'm,
also
the
Olympics
mentee
under
Marco
as
a
mentor
and
Carlos,
as
I
mentioned,
which
will
be
building
golang
library
and
cla2
for
the
secret
release,
and
this
is
the
first
meeting
for
the
version
1.29
I'm
attending
and
pretty
much
excited
for
all
this
really
schools.
Thank
you.
So
much.
E
A
F
F
All
of
the
leads
were
invited,
but
like
this
context
for
everyone
else,
and
and
we
decided
that,
after
going
through
the
results
of
the
release
manager
and
release
manager,
associates
survey,
a
piece
of
feedback
was
that
people
usually
don't
know
what,
where,
where
to
start
working
on.
So
we
came
up
with
idea
of
instead
of
having
a
single
release,
engineering,
bundled
update.
F
We
should
start
having
a
dedicated
slots
asking
people
to
provide
specific
updates,
for
example,
about
obs
about
the
signatures,
the
s-bombs
and
stuff
like
that,
and
then
General,
it's
very
similar
to
what
we
currently
have,
but
we
at
the
at
this
point.
We
rely
on
on
people
like
Marco,
who
is
very
good
at
giving
updates
of
OBS,
for
example.
F
That
Marco
was
working
very
fast,
which
was
great,
but
then
everyone
else
felt
a
bit
lost.
So,
for
probably
not
this
meeting
or
this
meeting
will
be
our
first
imperfect,
imperfect
attempt,
but
I
will,
as
an
action
item
I
will
set
like
a
new
template
for
I.
Would
let
this
structure
for
a
template
in
the
agenda
to
to
go
through
the
recurring
topics
today
it
as
I
said
right
now
it
would
be
OBS
packages,
it
would
be
release
cards
and
patches.
G
F
So
there's
a
bunch
of
work
that
we
need
to
do
that.
That
doesn't
belong
to
a
specific
project
that
we
need
Cleanup
in
the
repos.
We
need
updating
the
nothing
in
the
documentation,
but
also
in
the
code.
Things
like
that
that
we
even
forget
about
so
having
those,
as
updates
having
a
bit
more
a
structure
without
having
a
full
project,
management
effort
or
anything,
just
being
more
structure
about
it.
We
think
that
it
will
be
better
for
everyone,
so
yeah.
G
B
Is
a
log
period
if
there's
a
lot
of
movie
Parts
it's
hard
to
like
keep
everything
in
mind
to
provide
an
update,
but
while
we
are
there,
I
would
like
I
try
to
prepare
like
like
what
he
has
been
going
on,
and
the
first
thing
is:
go
updates.
We
updated
to
121.1
and
120.8
thanks
to
Carlos,
for
taking
care
of
that
go
update
to
1.21
is
still
ongoing,
there's
still
some
pieces
that
need
to
be
done.
B
Another
thing
is
CUPE,
PKG
and
Rapture
are
considered
deprecated
and
will
be
removed
after
October
perpetually
says,
as
Sasha
sent
an
email
to
mailing
list,
but
it
has
been
decided
because
we
are
now
exclusively
using
OBS
from
October
and
we
don't
really
need
those
tools.
We
don't
need
to
maintain
that
it's
going
to
be
easier
to
get
rid
of
it.
B
It
is
not
really
structured,
there's
going
to
be
a
proper
documentation,
of
course,
but
it
is
like
some
guideline
on
how
it
looks
like
so
folks
interested
can
take
a
look
before
we
get
like
the
proper
docs
in
place,
I
shared
link
or
some
chat
given
patch
releases.
Those
are
scheduled
for
tomorrow,
when
thanks
to
Veronica
for
volunteering,
to
help
with
these
releases,
a
reminder
that
we
are
freezing
the
Legacy
repositories
with
those
patch
releases.
I
have
left
a
link
in
the
notes.
I
am
going
also
to
share
it
on
Zoom.
B
Basically,
the
plan
is
that
September
is
going
to
be
the
last
specialist
that
we
are
going
to
publish
to
the
Google
repos,
the
Legacy
ones.
After
that,
all
packages
will
be
published
only
to
OBS
and
to
packages
get
sio
and
yeah.
We
had
doppable
service
and
packages,
get
sio
introduction
last
week
and
slides
and
recording
are
posted
on
the
release
management
slack
Channel.
If
you
want
to
take
a
look
and
see
what
to
cover
there.
H
F
B
I
B
You
find
any
figure
project
board
that
is
like
interesting
to
you.
They're,
like
21
issues
in
the
backlog
right
now,
I
will
be
taking
care
of
those
Alpha
critical
order,
defaulted
issues,
but
other
than
that.
Everything
that
is
better,
stable
or
not
marked
coachables
are
very
welcome.
I'm
also
happy
to
help
please
reach
out,
and
we
will
see
how
we
can
figure
it
out.
B
F
Yeah
also
because
we
don't
want
sometimes
since
we
are
all
mostly
the
the
release-
managers
are
in
different
time
zones-
Etc,
it's
not
always
possible
for
all
of
us
to
attend
a
meeting,
but
it's
still
necessary
to
provide
updates.
So
with
this
format
we
I
mean
we
always
encourage
people
to
attend,
but
not
if,
if
you
don't
necessarily
come,
the
template
should
be
enough
should
provide
enough
context
and
links
and
whatnot
too,
for
people
to
know
what
to
do
next.
D
A
A
All
right
well
for
the
recording,
we'll
we'll
just
mention,
updates
that
Priyanka
has
put
in
here.
The
lead,
Shadow
onboarding
is
complete.
Shadow
selection
is
done
for
129..
Those
are
all
done.
We
are
scheduled
to
do
our
first
Alpha
cut
for
129
on
Tuesday
19th
of
September
I.
Don't
know
you
just
confirmed
the
branch
manager
availability
Jim
is
on
the
call
Jim's
going
to
be
the
branch
manager
for
129..
Thanks
for
doing
that,
Jim
it'll
be
super
awesome.
A
G
The
one
thing
I'll
just
add
is
that
I
still
need
to
come
up
with
the
patch
cut
timeline.
There
was
some
conversation
around
whether
or
not
we
needed
the
additional
Alpha
cut,
which
sounded
like
we
had
plus
one
I
think
it
was
a
fourth
Alpha
cut
because
of
the
OBS
integration,
and
so
we're
going
to
skip
that
and
then
that's
going
to
hack
together
the
patch
timeline
and
then
I
think
that
that's
the
only
thing
that
we're
waiting
on.
A
A
A
J
J
Okay,
good,
so
the
first
item
is
about
the
release
bucket
used
for
use
by
the
project
to
serve
all
the
binaries
we
built
in
on
each
python.
Historically,
the
bucket's
name
commits
really
and
it's
owned
by
Google
own
in
the
sense
like
it's
great
under
a
Google
project,
we
don't
have
a
full
access
on
that.
So,
with
the
rollout
of
plastic,
we
were
able
to
Shield
that
became
fast.
So
now
we
have.
J
The
possibility
to
switch
to
a
community
on
buckets
main
benefit
is
basically
that
help
us
have
full
control
on
how
we
establish
life
cycle
or,
if
object
we
release.
So
we
can
improve
the
cash
efficiency,
don't
buy
fasting
I
think
that's
the
main
benefit.
The
other
thing
is
like
we
have
full
control
of
the
all
the
binaries
released
on
each
myosins,
so
we
can
do
more
things
like
improve
signature.
J
J
So
I
think
this
is
more
like
a
call
for
action
and
get
some
consensus
on
how,
if
yes
or
no,
we
want
to
proceed
start
to
do
that
in
129.
At
this
it
might
be,
it
might
be
fast.
Then
we
we
are
able
to
basically
use
the
new
bucket
for
129
and
the
applicator
difficult
the
Google
own
one.
So
I'm
not
exactly
sure
about
this,
but
that
also
implies
some
kind
of
communication
and
say
we're
going
to
separate
that
bracket,
and
we
also
want
that
the
new
bucket
to
be
private.
B
Yeah
so
I
agree
with
this
change,
because
I
have
been
following
this
from
the
CKC
for
part
as
well.
I
think
this
is
going
to
be
helpful.
One
thing
that
I
have
concerned
that
we
had
similar
situation
from
obs's.
What
are
we
going
to
do
with
the
existing
data?
For
example,
if
you
are
going
to
start
this
from
bottle
29,
then
we
are
going
to
have
like
maybe
four
or
five
supported
releases,
for
example,
starting
for
about
25
to
129..
B
Are
we
planning
on
doing
some
back
feeling
of
that
new
bucket?
That's
going
to
allow
users
like
constantly
point
to
the
new
bucket
like,
however,
how
is
that
exactly
going
to
work
like
since
we,
when
we
switch
to
the
new
bucket?
Are
we
going
to
be
able
to
access
the
old
binaries
that
we
have
it?
How
is
that
going
to
be
handled.
J
The
battery
is
very
easy
because
it's
about
it's
a
the
GCS
protocol
is
literally
yeah.
We
can
access
to
https,
so
we
just
backfill
anything.
We
release
sounds
1.1
to
the
new
bucket
and
gcp.
Has
a
service
include
that
automatically
synchronization
everywhere?
If
you
want
so
we
we
are
not
delayed
the
old
bucket.
We
just
duplicated,
we
literally
say
the
application
in
the
sense
like
we
stop
pushing.
We
stop
doing
release
doing
with
that
bucket,
but
we
skip
I
have
from
the
conversation
I
have
with
Google.
J
They
are
not
intended
to
delete
that
bucket.
The
only
thing
is
to
put
that
in
read-only
and
just
leave
that
by
himself
into
traffic
is
dropping
people
switch
to
the
new
Community
bucket.
Ultimately,
the
idea
is
not
to
switch
to
the
new
bucket
for
the
release,
but
switch
to
an
end
point
to
our
public
endpoint,
that's
going
too
fastly.
J
So
backfill
is
a
matter
of
basically
doing
air
clone
from
one
source
to
a
destination,
and
we
can
do
that
automatically.
So
there's
no
problem
to
that.
We
even
did
that,
for
we
have
a
we.
We
did
an
experiment,
I
think
two
to
three
years
ago,
where
we
work
in
new
bracket
and
tried
to
see
how
backfit
would
happen.
It's
working
there's
no
really
issue
about
that,
because,
because
the
signature
of
also
those
binary
are
not
attached,
the
battery
itself,
like
in
the
content
registry
battery,
is
very
easy.
It's
just
a
copy
of
this
object.
H
J
H
H
H
As
a
simple
example,
let's
say:
Google
makes
that
bucket
private
right
and
you
start
getting
40
threes
everywhere.
That's
fine!
You
shouldn't
have
been
pulling
it
from
the
address
in
first
place.
We
gave
you
an
address.
It's
been
in
our
docs
for
the
last
five
years.
Every
well
written
installer
should
be
pulling
it
from
that
URL
as
well.
J
H
J
H
J
D
H
J
We
can
move
that
to
another
bracket,
I
think
I'm
focused
on
basically
anything
supported
by
the
community
for
the
moment.
Okay,
anything
related
to
CI
is
a
follow-up
conversation.
We
can
have
and
I
think
that's
going
to
be
with
sick
testing,
not
necessarily
synchronics,
because
then
the
response
secret
is
not
responsible
for
energy
related
to
CI.
At
the
moment,.
H
J
B
I
think
it's
safe
to
assume
that
this
is
the
case
for
the
community
as
well,
since
we
have
been
doing
that
for
a
long
time
so,
making
it
private
or
doing
anything
that
might
break
stuff
is
probably
not
the
best
idea,
but
like
trying
to
communicate
with
it
that
we
are
like
really
encouraging
people
to
use
the
alkate
sio.
Instead,
it's
going
to
be
more
helpful.
We
just
need
to
figure
out
like
what's
the
proper
out
for
doing
that.
B
J
Okay,
I
think
this,
like
we
clearly
have
to
basically
do
some
kind
of
communication
to
the
community
and
or
user
around.
That,
like
there's
need
to
be
a
the
application
notice
foreign
format
for
this.
But
definitely
we
need
to
communicate
about
this
I
don't
know
if
the
I
think
the
question
is
like
do
we
want
to
basically
do
that
in
120
nine,
or
do
we
be
more
flexible
and
announce
the
duplication
in
129
and
switch
to
the
own
to
the
new
bucket
in
one
30.
B
J
It's
it's
completely
doable,
because
when
you,
when
you
switch
your
bracket,
we
have
to
make
sure
we
need
to
switch.
The
bracket
is
one
thing,
but
the
complexity
is
to
make
sure
cairwell
push
build
and
push
the
I
would
say.
The
binary
is
the
new
bracket
and
we
start
publishing
the
old
one.
I
think
this
is
like
the
technical
transition.
We
need
to
make
sure
the
question
is
like:
are
we
confident
to
do
that
in
one
Milestone
or
do
we
want
to
play
safe
and
do
that
in
two
miles?.
B
H
J
J
J
H
D
E
J
Okay,
I
think
it's
fair.
We
can
do
that.
We
can
try
to
do
that
in
one
Milestone,
so
one
thing
is
just
perhaps
doing
trying
to
identify
what's
required
to
do
that
from
a
greatest
engineering
perspective,
come
up
with
something
and
see
what's
happening
and
plan
all
of
this
over
to
Milestones.
So
we
said
we
know
unscribed
like
confidence
about.
What's
the
technical
requirement,
with
what
other
technical
requirement
to
do
that
transition,
we
can
announce
the
phrase
all
the
duplication
and
in
one
it's
only
in
one.
A
J
Right,
so
it
also
relates
to
how
we
do
releases.
Currently
we
use
a
Google
home
bucket,
which
is
called,
create,
kubernetes
release
test
and
we
should
migrate
to
a
community-owned
one
for
any
release.
The
the
question
is
like
this
one
is
kind
of
tricky
because
we
have
to
do
that
at
once,
so
we
have
to
be.
We
have
to
be
fast
like
between
two
release.
What
weather
is
like
Alpha
One
and
also
have
to
do?
We
need
to
do
try
between
those
so
I'm
like
how
we
want
to
do
this.
B
J
Only
only
the
release
manager
can
access
that
version
and
tell
and
tell
us
what
is
inside
the
project.
I,
don't
I
have
basically
I
have
the
legislation
of
permission
but
I
think
the
release
lead
or
the
TL
might
have
access
to
that
project
and
tell
us
what
is
inside.
The
only
thing
I
know
is
like
we
use
Google
Cloud
build.
D
J
B
E
B
A
J
D
J
J
Yeah
I
think
I
think
it's.
This
is
one
of
the
things
where
we
have
to
look
on
how
we
do
the
transition,
because
we
have
multiple
things
tied
together
between
Google
infrastructure
and
community
on
infrastructure,
so
it's
kind
of
tricky
to
figure
out
what's
happening
so
over
time.
We
can
uncover
all
those
relationships.
All
those
obviously
permission,
relationship.
A
B
J
They
didn't
release
them,
they
didn't
release
this
week.
So
but
the
question
is:
do
we
use
that?
Because
over
time
the
release
teams
switch
away
from
the
tooling
and
just
get
up,
get
abroads
or
get
a
project
yeah
and
spend
those
kind
of
things
so
I'm
like
I,
don't
think,
there's
a
value
to
keep
it
at
that
around.
B
I
J
J
A
Would
guess
the
answer?
Is
we
don't
want
to
maintain
it,
but
let's
yeah,
let's
just
put
a
call
out
and
see
if
anybody
is
still
using
it
and
then,
if,
if
so
then
we'll
figure
that
out
but
I
think
we're
going
to
tend
to
the
answer
that
nobody's
using
it
and
we
don't
have
anybody
that
can
maintain
it
for
us
right
now.