►
From YouTube: Kubernetes Release Engineering 20211123
Description
For more info, see https://git.k8s.io/community/sig-release
A
A
B
So
they
can
go
across
multiple
cloud
providers
as
far
as
the
registries
for
downloading
it
and
the
artifacts
that
we
produce
as
a
community
and
so
we're
everyone
is
probably
also
here
from
ii.
It's
4
30
in
the
morning,
so
apologies
for
the
the
not
much
video
I'm
driving
into
the
office
in
order
to
maybe
get
some
better
life.
A
E
A
F
Yeah
hello,
so
we're
yeah
we're
preparing
today,
neverend
and
I
are
preparing
today
to
cut
the
branch
and
we
have
a
list
of
duties
that
we
haven't
started
yet
because
we're
optimizing
for
to
overlap
with
american
schedule,
but
yeah
so
far,
no
no
interesting
updates
other
than
but
we're
busy
with
that.
Hopefully,
everything
goes
smoothly
and
yeah
we'll
let
you
know
if
we
need
anything
or
something
goes
wrong.
D
One
thing
to
call
out
there
is:
there
was
some
discussion
around
the
publishing
bot
rules
and
all
that
stuff
in
the
channel.
There
is
a
pr
open
for
this
vr
open
discussing
like
what
to
do
where
to
put
the
rules
and
stuff,
but
there's
some
stuff-
that's
already
documented
in
the
in
the
release,
engineering
handbooks.
So
if
anything
is
missed
or
like
during,
like
that,
it's
happening
around
the
time
that
the
branch
is
cut.
D
A
Okay,
awesome,
so
I
I
see
an
item
in
the
open
discussion
items
by
leo
to
discuss
the
the
to
go
over
the
ci
signal
project
board.
But
I
propose
that
we
open
the
floor
to
the
to
hippie
and
re-end,
because
it's
really
late
for
them
so
to
to
discuss
a
little
bit
and
then
we
can
go
over
the
the
the
see
a
signal
project
so
that
they
can
and
go
to
have.
Some
sleep
sounds
good.
B
For
example,
people
in
china
cannot
get
to
the
artifacts
of
the
community
because
it's
only
with
a
single
vendor.
However,
if
we
were
to
start
allowing
our
community
to
have
multiple
mirrors
for
things
that
were
able
to
be
accessed
in
our
our
the
rest
of
the
of
the
planet
in
china
would
also
be
able
to
participate.
B
D
B
Thank
you
very
much
as
far
as
different
pieces
of
software
and
ways
to
orchestrate
that.
But
we
need
the
right
handles
from
this
team,
and
I
would
look
forward
to
trying
to
find
what
those
handfuls
are
as
a
group
and
also
maybe
have
someone
step
up
as
a
liaison
between
these
different
groups
that
can
coordinate
with
iowa.
In
order
to
make
sure
that
this
process
includes
every
team's
needs
and
evolves.
As
our
community
does.
D
So
liaison
wise,
you
have
multiple,
for
I
mean
at
the
bare
minimum.
You
have
the
the
the
the
leads
that
are
focused
on
the
release
engineering
side,
so
myself
sasha,
carlos
and
adolfo.
I
think
in
particular
a
release
manager
of
note
that
that
would
be
a
good
liaison
potentially
if
he
is
willing
and
interested
and
has
the
time
is,
are
no
because
our
now
is
like
the
perfect
crossover
between
kate's
infra
and
release
engineering.
J
J
Some
folks
like
the
idea
of
publishing
everything
to
different
clouds.
So,
instead
of
like
the
replication
thing,
it's
like
here's,
the
list
of
all
the
the
providers
we
publish
to
so
there's
pros
and
cons
for
all
of
them.
But
that's
one
of
the
things
we're
going
to
have
to
come
up
with
is
the
policy
aspect.
It's
like
people
are
going
to
come
to
us
from
different
orgs
different
cloud
providers.
J
They're
going
to
ask:
do
we
provide
you
with
a
you
know,
s3
bucket
a
gcs
bucket
for
you
to
push
to
do
we
provide
credentials
for
a
registry?
Do
we
have
to
provide
a
contact?
So
those
are
the
types
of
things
we
really
need
to
dig
into
it's
like
who
owns
this
account.
That
is
replicated
too,
and
is
this
done
through
a
credits
program?
Is
this
done
through
a
you
know,
stand-alone
community
thing
a
lot
of
unanswered
questions,
but
specifically
on
the
policy
side.
D
So
I
so
you
know,
I
think
you
know
part
of
it
to
your
point.
Is
you
know,
there's
the
credits
program
which
I'm
curious
to
see
with
what
the
current
steps
are
and
I'm
sure
that's
a
longer
discussion
policy,
wise
workflow
wise.
I
would
love
to
see
every
registry
be
treated
equally
right
so
for
pushing
to
if
we're
pushing
to
all
like
we
have
the
set
of
the
registries
and
we're
pushing
to
them
and
that's
it.
D
D
D
As
you
know,
there
is
also
a
google
artifact
registry
which
we
need
to
build
and
support
for
that
as
well.
So
there's
I
mean
there
there.
I
think
I
I
see
a
few
phases
of
this
right.
I
I
think
supporting
artifact
registry
makes
a
lot
of
sense
next
and
then
like
and
then
everything
else
right
and
then
everything
else.
If
everything
else
is
a
replication
job
of
you
know,
and
we
do
it
per
provider
that
way
we
can
kind
of
like
play
around
with
you
know.
D
If
the
provider
has
specific
needs,
or
you
know,
access
things
that
that
may
differ
from
may
differ
from
the
existing
jobs
on
on
gcr.
Then
we
can
address
them
in
a
separate
job
and
then
find
a
way
to
kind
of
merge
the
streams
eventually
I
at
the
same
time
we
could
also
just
figure
it
out
in
totality
for
the
promotion
tools
for
all
registries,
because
really
it
you
know,
the
promotion
tool
should
support
any
any
oci
compliant
registry
right
that,
like
that,
should
be
the
goal
right.
D
B
D
Yeah,
I
know
I
I
think
it
makes
a
lot
of
sense
to.
I
think
it
makes
a
lot
of
sense
to
collaborate
on
it.
What
I
want
to
make
sure
of
is
that
anyone
coming
into
it
like
that
this
is,
I
only
say
it's
to
say
like
this-
is
one
of
the
more
critical
pieces
of
infrastructure
for
the
project
so
that
anyone
coming
into
it
is
aware
of
the
the
warts
of
the
existing
tool,
yeah
yeah.
A
B
I,
since
I'm
driving,
can
you
drop
the
summary
to
the
five
or
six
different
things
that
we
put
together
and
load
tested.
That
caleb
did,
I
think,
the
that
particular
document
kind
of
outlines
all
the
different
approaches.
As
far
as
like
conversation
and
feedback,
I
think
that's
been
in
slack
and
I
don't
know
that
there's
been
a
strong
decision.
B
I
think
we
were
kind
of
pulling
off
doing
anything
with
that
engineering
side
until
for
at
least
for
ii,
we
got
past
the
cloud
credits
launching,
because
that
is
now
there
and
I
think,
ryan,
if
you
can
get
a
chance,
go
ahead
and
drop
that
link
to
the
the
cncf
cloud
credits
program.
Url,
it's
like
on
the
front
of
the
cncf,
there's
a
blog
post,
a
couple
other
things,
but
we
can.
This
is
kind
of
important.
B
I
would
like
to
have
this
provider
in
order
for
these
things
as
a
community
and
then
that
that
actually
goes
to
ihor
and
myself,
and
then
we
can
turn
around
and
coordinate
the
connection
and
relationship.
It's
all
relationships,
but
we
end
up
having
a
contract
in
place
to
be
sure
that
where
the
community
is
left,
when
people
change
jobs
and
stuff
that
the
commitment
is
a
formal
one
between
us
and
the
vendors.
J
J
D
D
We
need
to
have
a
reasonable
level
of
control
over
any
infrastructure
that
we
get
as
a
result.
So
I
see
this
more
as
a
funding,
as
opposed
to
a
pure
ownership
thing.
Ideally,
there
is
also
a
level
of
support
from
from
vendors,
because
this
is
you
know
it.
It's
a
you
know
becomes
an
ask
to
learn,
you
know,
learn
gcp
and
aws
and
azure,
and
you
know-
and
the
list
goes
on
and
on
so
how
can
we?
How
can
we
ease
that
burden?
D
Ideally,
you
know,
I,
I
think,
for
you
know,
azure
and
aws,
for
example
right
we
we
we
get
some
credentials
right
and
and
an
account,
and
we
kind
of
like
go
about
our
business,
but
there
would.
It
would
be
nice
to
have
a
level
of
support
from
the
vendor
right.
The
I
think,
I
think,
where
we
expand
to
first,
is
like
where,
where
is
the
biggest
need?
D
Like
how
do
we
answer
that
question
where's,
the
biggest
need
where's
the
biggest
cost
coming
from,
and
if
that
is
you
know,
if
that's
china
say
right,
you
know
we
we
want
to.
We
want
to
try
to
address
that.
First,
the
I
still
think
that
you
know
replication
to
start
makes
sense,
and
that
is
until
which
time
you
know
until
such
time
that
the
tooling
supports
pushing
to
registries
that
are
not
gcr.
D
D
D
B
D
D
I'm
next
minute,
I'm
gonna
jump
in
here.
I
stuck
something
in
the
release.
Manager
updates.
So
I'll.
Do
this
one
really
quick?
It's
just
about
ownership
overall,
so
open
up
a
pr,
that's
kind
of
like
built
off
of
me,
being
pr
myself
out
of
out
of
certain
things
and
then
also
trying
to
kind
of
shift
the
the
review
obligations
to
certain
people
right.
D
What
this
pr
does
is
a
few
things
for
anyone
who
is
for
the
top
level
of
k,
release
we're
removing
the
release
engineering
approvers
as
reviewers,
which
means
the
you
know,
the
the
the
de
facto
reviewer
for
k
release
if
a
a
if
a
an
owner's
isn't
specified
in
a
subfolder
will
be
the
release
manager
associates.
So
if
you're
a
release
manager
associate,
please
be
aware
of
that
for
any
areas
where
aliases
did
not
for
any
aliases.
D
I
dropped
the
reviewer's
alias
and
added
the
release
engineering
reviewers
instead,
so
that
means
is
so.
I
think
you
know,
for
anyone
who
is
doing
apr,
who
is
kind
of
in
and
around
these
teams.
The
tendency
is
to
like
assign
a
few
people
and
then
cc
release
engineering
anyway
right.
So
it's
not
like
it's
not
like
the
entire
team
isn't
seeing
the
pr.
D
But
what
we
want
to
say
is
the
the
you
know
the
the
first
responsibility
of
doing
the
pr
review
should
go
to
the
the
release
manager
associates
or
anyone
who's
been
with.
It
is
in
the
reviewers
tab.
This
is
this,
is
you
know
a
little
bit
to
federate
out
the
workload,
but
also
to
so
to
give
release
manager,
associates
opportunities
to
do
more
reviews
and
build
up
that
approver
muscle
right
we'd
like
to
see
all
of
you
in
approvers-
and
this
also
goes
for
folks
that
are.
D
This
also
goes
for
folks
that
are
not
necessarily
on
the
release.
Managers.
Release
manager
associates
groups,
but
want
to
become
so
if
you
ever
are
interested
in
one
of
our
areas,
and
you
feel
you
have
the
time
to
dedicate
to
it
feel
free
to
pr
yourself
into
a
reviewers
within
owners,
and
we
can
have
a
discussion
about
it.
D
I
think
I
think
that
you
know
this
kind
of
you
know
a
tangential
conversation
was
you
know
around
the
ci
reporter
tool
which,
with
which
leonard's
going
to
get
into
in
a
second
and
the
I
I
wrote
kind
of
a
close.
You
know
a
closed
statement
on
that
issue.
To
say
like
if
you
never
get
to
review,
you
will
never
review.
D
You
will
always
essentially
be
beaten
by
the
people
who
are
assigned
by
a
bot
to
do
the
reviews
right
so
putting
the
the
ci
signal
team
in
that
review,
spot
is,
is
meant
to
to
have
them
build
up
that
reviewer
muscle.
The
same
is
true
for
the
you
know,
for
the
release.
Notes
team
in
you
know
that
are
marked
as
reviewers
on
the
changelog
in
kubernetes
kubernetes.
D
So
the
idea
is
that
you
know
if
you're,
if
the
bot
is
tagging
you
that
it's
not
you
know
it's
not
a
question
of
like
do.
We
think
you
have
the
ability
to
do
the
review
or
not.
We
are
saying
that
we
do
believe
you
have
the
ability
to
do
the
review,
which
is
why
you
are
in
the
owner's
file
in
the
first
place
right.
So
so
you
know,
if
you
ever
have
questions
about
how
to
do
reviews
should
I
do
the
review.
If
the
bot
is
tagging
you
you
should
do
the
review.
D
If
you
feel
like
you
cannot
do
the
review
feel
free
to
escalate.
You
know
or
ask
some
questions.
Like
the
you
know,
a
perfectly
reasonable
review.
Is
this
look
sound?
I
don't
know
this
code
area.
Well,
I
you
know
I
have
some
questions
about
xyz
right
and
all
the
people
that
you
you
have
tagged
will
see
that
you
know
during
their
review
process.
So
asking
questions
is,
is
also
a
great
way
to
do
review
right
and
it
may
be
a
question.
D
Maybe
several
sets
of
questions
that
we're
not
thinking
of
as
we're
doing
our
reviews
right.
So
don't
don't
be
afraid
to
do
reviews
if
the
bots
are
telling
you
to
do
reviews,
you
should
do
reviews
and
I
will
be
unless
there
are
blocking
concerns,
and
I
don't
believe
so
because
I
discussed
with
the
leads
already
sasha
and
carlos
have
already
approved
if
there
are
no
blocking
like
super
super
super
blocking
concerns.
I'm
going
to
merge
this
pr
during
this
meeting,
so
I
will
leave
it
there.
A
K
K
K
So
there
is
one
column,
so
this
is
the
under
discussion
column,
which
at
the
moment
contains
the
ideas
at
the
moment
only
myself
provided
some
some
ideas,
and
but
we
already
discussed
this
also
in
the
ci
signal
team.
So
this
is
not
only
like.
My
ideas
is
also
reflecting
from
like
the
discussion
that
we
had
previously.
K
L
Just
one
quick
update
from
my
side,
jose
is
speaking
so
yeah.
This
board
initially
was
on
my
private
user
space
and
github,
so
I
yeah-
I
put
it,
you
know
in
under
k
user
space.
So
not
all
the
user
stories
which
are
closed
are
fully
migrated
here,
so
it
doesn't
really
represent.
Our
current
status
just
want
to
add
that
up
update
regarding
it
yeah.
D
Yeah,
I'm
gonna
jump
in
for
a
hot
second
here
and
and
say
that
it's
great
to
see
this
board,
but
the
work
technically
does
not
exist
because
it
is
only
stored
as
cards
and
not
as
github
issues.
So
I
think
my
first
request
before
we
continue
with
this
board
are
obviously
offline
to
transform
all
of
these
into
into
issues
so
that
we
can
actually.
D
L
K
K
K
Yes,
yes,
so,
and
we
that
we
get
a
bit
more
transparency
behind
the
ci.
You
see
a
signal
report
tool,
so
we
don't
only
have
like
the
numbers
like
five
hour
flakey
or
so
because
sometimes
tests
are
flaky
but
they're
like
temporary
tests.
So
they
will
disappear
again.
So
maybe
they're
not
so
significant
and.
D
Yeah,
so
I
guess
a
question
here:
have
you
I.
I
know
that
I
know
that
y'all
have
been
working
on
integrating
some
of
the
review
suggestions
that
I
made
on
the
initial
migration.
Pr.
One
of
them
is
around
integrating
this
with,
like
the
existing
test
grid
package
that
we
have
so
when,
prior
to
running
releases,
the
the
the
release
managers
will
run
a
command
that,
I
guess
is,
is
it
still
test
grid
shot?
It's
not
test
grid
shot
anymore.
It's
krell
test
grid
or
something
right.
D
So
we
had
we
had
a
tool
called
test
grid
shot
which
would
essentially
snapshot
all
of
the
test
grid
boards,
as
well
as
let
you
know
or
the
relevant
test
grid
boards
as
well
as
let
you
know
what
was
failing.
So
I
think
it
would
make
a
lot
of
sense
to
see
how
to
integrate
that
functionality,
because
it
sounds
like
it'll
give
you
what
you
need
just.
A
D
Yeah,
so
not
so
much
the
the
we
like
the
the
snapshot.
Functionality
matters
less.
The
the
readout
of
the
the
boards
is
what
they're
looking
for
right.
So
I
think
I
think,
if
you're
looking
for
a
readout
of
the
board,
it's
already
solved
with
one
of
our
tools.
So
I
think,
within
the
I
think,
of
care
release
package
test
grid
is
probably
what
what
you
need.
K
D
Exactly
and
okay
yeah
there
was
another
question
around
what
was
it
around
the
the
usage
of
that
table
writer
package
and
I
think
someone
said
that
they
didn't
want
to
use
it
because
it
did
not
display
well
in
slack,
I
think
posting
yeah
yeah,
so
posting
in
slack
is
not
what
we
want.
I
ideally
we
want
something
that
has
like
higher
fidelity
right
so,
like
so
posting
a
link
to
a
pr
that
has
a
markdown
file
attached
to
it.
K
I
think
humanity
is
in
for
like
a
cluster,
where
we
have
current
job
running,
to
just
push
basically
or
trigger
the
ci
signal
report
cli
so
that
we
publish
these
reports
automatically
like
with
the
bot.
Basically,
if
that's
what
you
meant
yeah,
so
this
is
planned.
Yeah,
awesome,
okay,
so
yeah,
so
maybe
the
first
card
would
be
still
like
is
still
valid,
that
we
want
to
have
like
more
details,
but
we
don't
need
to
rewrite
a
lot
of
logic.
We
can
just
reuse
already
existing
packages.
Libraries,
okay,.
K
Yeah,
I
guess
so
right,
okay,
so
so
the
next
card
is
about
the
github
report
part.
So
currently
we
are
scanning
one
project
board
under
kubernetes
issues.
So
there's
like
the
see
a
signal
report,
see
a
signal
project
board.
So
basically,
all
issues
that
are
on
that
project
board
will
be
scanned
by
this
tool
at
the
moment,
and
the
problem
is
that
we
do
not
discover
issues
that
somebody
else
reported
or
opened
up.
K
K
Yeah,
so
basically,
I
think
we
already
have
like
a
package
available
to
use
github
the
api
and
so
on.
So
this
would
basically,
I
briefly
went
over
the
package
that
we
have
and
it
does
not
have
right
now
the
ability,
the
the
option
to
scan
all
issues
on
kubernetes.
I
think
so
there
will
be
probably
a
new
method
or
like
a
new
package
under
it,
so
that
we
are
able
to
scan
all
github
issues
and
then
yeah
so
yeah.
A
K
Yeah
exactly
you
can
you
can
sort
by
labels
and
you
can
also
sort
by
date.
So
if
it's
like
older
than
a
year
a
year
or
half
a
year
or
something
like
that,
you
can
or
like
have
this
filter
applied,
and
then
I
mean
we
could
also
think
about,
maybe
that
we
format
the
header
of
an
issue.
But
I
don't
know
if
this
is
something
that
we
want
to
do,
but
this
could
also
lead
to
like
that.
We
have
like
a
more
or
less
like
that.
K
D
K
D
K
D
Opens
up
yeah,
it
is
not
currently,
and
so
unfortunately,
so
the
the
you
know
one
of
the
one
of
the
the
gripes
that
I
have
about.
You
know
the
the
the
github
issues
and
project
boards
and
stuff
like
that
that
for
in
for
a
project
level
for
a
project
level,
project
board
or
a
repo
level
project
board,
you
can
do
some
nice
things.
D
You
can
have
issues
like
automatically
like
jump
onto
the
board
and
stuff
based
on
what
status
they're
in
right,
but
for
an
org
level
board
which
the
the
ci
signal
board
is
like.
You
have
the
upside
of
being
able
to
collect
issues
from
multiple
repos,
but
the
downside
that
it
doesn't
necessarily
listen
to
some
of
like
the
repo
triggers
as
much
as
a
repo
level
board.
D
Would
so
the
the
issues
won't
automatically
jump
onto
the
board
for
you,
unfortunately,
but
I
do
think
that
on
any
one
day
week
cycle
there
are
not
so
many
issues
on
the
board
that
we
would
need
to
solve
them
via
automation.
I
think
I
do
think
that
this
is
a
process
thing
right
scanning
making
sure
that
they're
on
the
board
and
then
moving
into,
I
think
you'll
you'll
find
greater
improvements
to
the
process
in
in
different
areas
than
than
then
skipping
triage.
I
K
But
okay
question
now,
or
maybe
we
have
to
think
about
it
or
I
have
to
think
about
it
or
see
a
signal
team
has
to
think
about
how
we
can
update
or
like
change
a
bit
the
process,
how
we
discover
new
issues
or
like
interact
with
our
project
board
to
make
sure
it's
up
to
date.
So
this
is
like
more
the
direction
you.
D
D
You
know
the
kind
failing
test
or
kind
flake
and
then
see
whether
or
not
it's
on
the
project
where
there's
also
a
filter
like
negative
project
colon,
whatever
the
project
number
is
and
it'll
give
you
whether
or
not
it's
on
the
project
board
and
then
from
there
you
do
it
you,
you
do
a
daily,
you
know-
or
you
know,
every
two
days
or
something
triage
of
that,
make
sure
they're
on
your
project
board
and
then
it's
in
the
report
right.
Okay,
so
this
is.
K
K
D
So
you
know
I
I
think
I
think
a
a
win
would
be
transforming
these
into
issues
and
and
setting
them
up
for
the
next
team
or
if
you
know
folks
on
this
team
are
still
interested
in
working
on
them.
Afterwards,
that's
absolutely
fine,
but
the
al.
All
I'm
saying
is
think
about
the
the
things
that
you
you
will
be
able
to
accomplish
by
the
end
of
the
release
cycle
and
and
towards
the
latter
part
of
the
release
cycle,
it's
less
than
you
might
think.
K
We're
thinking
yeah,
because
this
is
like
kind
of
in
the
middle
of
the
process
and
next
release
will
be
a
different
team
and
I'm
not
sure
who
will
work
on
this
team
and,
if
they're
interested
into
improving
this
part
so
yeah.
I
think
it
makes
sense
to
like
prioritize
also
the
issues
that
we
can
like
be
able
to
finish
in
next
weeks
and
then
yeah.
A
Yeah
final
notice,
so
we
were
discussing
on
your
on
your
pr
about
the
owners
that
it
should
be
a
good
thing
to
add
some
a
little
bit
of
go
experience
required
for
the
next
exiting
of
dms.
You
now
welcome
the
signal
there
now
owns
the
the
tool,
so
would
be
good
to
have
the
update
on
the
handbook
with
this
one
about
that,
so
that
the
next
folks
that
come
on
board.
I
know
that
yep.
D
And
just
just
to
you
know
just
to
be
a
little
specific
about
this.
Make
sure
that
any
updates
to
that
are
a
request
for
knowledge,
not
necessarily
a
requirement
these.
These
prs
can
and
will
still
be
approved
by
release
engineering.
That
has
the
go
experience.
I
just
want
to
make
sure
that,
as
we
invite
new
people
to
the
team,
as
new
people
consider
the
team,
they
don't
feel
that
that
is
that
that
is
a
blocker
for
them,
that's
something
that
will
disqualify
from
them
from
the
team.