►
From YouTube: Kubernetes Release Engineering Meeting for 20220301
Description
Kubernetes Release Engineering Meeting for 20220301
A
A
We
have
two
topics
in
the
agenda:
they're
not
in
the
agenda
right
now,
but
I
would
like
to
share
them
with
you
and
and
if
anyone
else
has
any
any
other
topics
to
add
to
today's
meeting
feel
free
to
add
it
in
the
in
the
agenda
which
I'm
updating
right
now.
As
a
reminder,
this
meeting
is
governed
by
the
kubernetes
sort
of
conduct
and
it's
going
to
be
now
which
basically
boils
down
to
be
awesome
to
each
other.
A
It's
going
to
be
recorded
and
and
and
shown
on
the
install
on
the
on
the
youtube
channel
of
kubernetes,
so
we
might
hold
whatever
you
say
into,
or
it's
gonna
give
you
one.
If
you
don't
want
your
face
to
show
on
camera.
A
A
Okay,
so
mostly
familiar
phrases
today,
then
we
would
usually
do
a
release,
manager's
update
and
I
don't
see
any
of
the
current
release
managers
in
the
meeting
today
and
not
not
the
branch
manager
for
release,
at
least
so.
I
think
we
can
skip
that
part.
A
A
So,
okay,
now
moving
on
to
the
to
the
first
thing
I
wanted
to
share
with
all
of
you
is
we've
been
working
today.
Well,
as
of
last
week,
we
did
some
pretty
substantial
changes
to
the
container
image
promoter,
which
is
the
the
the
the
the
tool
that
copies
all
of
the
artifacts
from
staging
to
the
production
registries.
A
We
are
working
on
on
a
lot
of
changes
to
the
promoter,
because
there
are
two
efforts
currently
that
involve
the
container
image
promoter,
which
is
one
the
signing
of
images
and
artifacts
and
the
other
one
is
the
new
distribution
schema
that
we're
working
on
to
allow
more
other
cloud
providers
to
to
share
the
load
in
distributing
the
images
and
artifacts.
A
So
last
week
we
had
several
refactors.
Some
of
them
are
still
appears
in
flight,
but
the
idea
is
that
to
lower
the
some
of
the
complexity
in
the
in
the
in
the
promoter,
there
were
several
code
reorganizations,
one
of
the
one
of
the
changes
involved
in
involved,
adding
support
for
local
registered
credentials.
So
previously
you
had
to
to
use
the
account
keys
that
that
the
promoter
used
to
to
use
as
identity.
But
now
it
will
read
your
local
docker
register
credentials.
So
you
can.
A
This
means
that
you
can
more
easily
run
the
promoter
in
your
local
machine,
which
has
speed
up
the
development
and
improvements
substantially,
because
you
can
now
run
the
promoter
on
your
machine,
set
up
two
test
registries
and
start
promoting
things
locally,
and
so
that
that
that's
the
first
one
I
wanted
to
share.
I
don't
know
if
there
are
any
questions
around
that
effort
or.
A
Okay,
that's
that
was
the
first
one,
the
second
one
I
wanted
to
share
with
all
of
you
was
so
we
are
currently
doing
a
big
effort
to
to
sign
all
of
the
container
images
and
the,
and
also
the
the
binaries
and
other
artifacts
that
we
have
without
that
with
every
release,
and
the
project
involves
signing
not
not
only
the
kubernetes
images,
but
we
will
also
work
with
all
of
the
smaller
projects
to
to
sign
their
images
and
other
artifacts.
A
So
if
you
are
part
of
a
project
under
the
kubernetes
organization
that
releases
images
or
artifacts,
we
will
also
be
covering
and
extending
the
kubernetes
chain
of
trust
to
your
artifacts
and
and
ensuring
that
your
images
get
signed
when
whenever
we
promote
them
to
release
them.
A
The
trust
in
the
in
the
several
google
cloud
projects
and
service
accounts
that
the
promoter
uses
the
promoter
and
also
the
kubernetes
release
process
so
that
it
can
take
on
the
necessary
identities
of
the
of
the
accounts
that
will
eventually
do
the
signing
of
the
artifacts.
A
Yes,
okay,
cool,
so
this
is
the
way
we're
structuring
the
service
accounts
and
and
the
way
we
need
the
impersonation
to
work
in
order
to
sign
the
images.
So
every
time
you
sign
an
image,
the
the
key
to
signing
it
is
that
we
need
to
to
generate
all
the
ic
identity.
Tokens
from
a
service
account.
A
The
I
and
the
the
designer
libraries
will
use
that
token
to
do
the
the
to
do
to
request
the
keys
and
to
sign
the
images
and
record
into
the
transparent
to
603
the
transparency
log,
the
the
the
identity
and
the
operation
that
we
just
did.
So
you
can,
in
the
future,
go
back
to
the
transparency
log
and
check
that
the
signature
took
place.
A
Who
did
it
and
all
of
that,
and
so
in
gcp,
whenever
you
want
to
generate
identity
tokens,
you
have
to
impersonate
a
service
account,
so
you
have
to
run
your
credentials,
impersonate
the
accounts
and
generated
so
the
identity.
Token,
and
then
use
that
so
we've
been
thinking
about
ways
to
to
how
to
structure
how
to
structure,
especially
concerning
security
and
access
to
the
designer
accounts.
A
We
feel
thinking
what
what
what
is
the
best
way
to
structure
that.
So
I
would
like
to
start
with
the
first,
the
the
the
the
one
in
the
middle,
which
is
the
impersonation
flow,
the
during
image
promotion.
A
We
have
three
scenarios
where,
where
we
will
be
signing
things,
one
is
the
public
images
that
happen
during
image
promotion.
Those
signatures
will
be
the
signatures
that
will
get
eventually
to
downstream
users,
and
those
are
the
signatures
that
that
then
users
will
eventually
verify
to
ensure
images
are
haven't
been
tampered
with.
A
The
other
two
are
the
end-to-end
tests
of
the
image
promoter
and
the
other
one
is
the
staging
flow
when
we
what
the
staging
phase
of
the
release
process.
So
whenever
we
do
a
kubernetes
release,
we
build
everything,
the
stage
it
and
if
artifacts
look
good,
we
release
them
in
the
release
phase.
So
all
of
those
images
during
staging
are
going
to
be
signed
and
eventually
the
promoter
will
check
those
signatures
before
accepting
them
for
promotion.
A
So
the
first
one
I
would
like
to
to
talk
about
is
the
most
the
most
important
one,
which
is
the
impersonation
flow
that
happens
during
image.
Promotion-
I
don't
know
if
you
can
see,
I
I
think
I,
if
I
zoom
into
the,
if
I
zoom
into
the
the
graphic
it
doesn't
grow.
I
don't
know
if
it's,
if
you
can
read
it
or
or
it's
too
small,.
A
Okay,
we
can,
we
can
go
over
it
anyway,
so
when
the
the
most
complex
part
of
of
the
identity
flows
is
the
flow
that
happens
inside
of
the
promoter.
This
is
because
there
are
several
several
identities
that
come
into
play
when
an
image
promotion
happens.
A
So
if
you
think
about
it,
you
run
the
promoter,
and
so
the
first,
the
first
one
is
the
promoter
stats,
and
it's
like
I
don't
know
kindly
pointed
out
to
me
last
week.
It
starts
in
a
pod
that
is
another
annotated
with
cloud
identity
and
that
takes
an
identity.
So
the
process
is
running
as
a
gcp
account.
A
So,
during
the
during
the
whole
image
promotion
process,
the
promoter
will
run
with
that
service
account
and
it
will
switch
to
various
identities
depending
on
the
thing
it
needs
to
do
so.
The
first
one
is
the
first
identity
that
comes
into
play
is
reading
the
source
registries.
So
the
promoter
is
going
to
take
images
from
a
source
registry
and
move
those
and
copy
those
to
one
or
more
destination
registries.
A
So
the
first
the
first
identity
needs
to
take
on
is
the
identity
that
it's
going
to
read
from
the
source
registries
generally.
Those
source
registries
are
open
in
public
and
read
and
read
only
for
everyone,
so
usually
there's
no
need
to
have
an
identity
there,
but
you
can.
You
can
specify
one
if
you're,
if
you're,
if
your
registry
is,
is
not
open
and
and
written
and
open
to
and
to
the
public
for
reading.
A
So
that's
the
first
one.
Then
the
second
identity
is
when
the
promoter
is
going
to
write
to
each
of
the
target
registries,
so
you
can
specify
one
identity
for
all
or
each
registry
can
have
its
own
so
that
those
are
the
first
two.
Those
are
important
because
the
promoter
will
shift
and
activate
saves
internally.
It
will
activate
service
accounts,
who
you
know,
gcp
service
accounts
to
do
the
the
container
reading
and
the
from
from
the
from
the
source
registries
and
then
activate
another
service
account
for
writing
to
the
registries.
A
Once
the
the
promotion
takes
place
and
then
we
need
to
have
another
identity
which
is
going
to
be
the
signer
account
that
all
the
all
of
the
kubernetes
artifacts
are
going
to
be
signed
with.
A
So
our
current
proposal
in
this
issue
is
to
create
one
main
project
to
hold
all
of
the
things
that
have
to
do
with
signing
at
first.
It
will
only
contain
basically,
the
service
accounts
than
the
promoter
will
use
to
sign
things,
but,
depending
on
how
things
evolve
in
the
next
few
months,
and
mostly
depending
on
how
the
kubernetes
delegation
of
trust
from
six
or
ends
up
working,
we
may
have
to
use
the
kms
in
that
project
for
for
storing
keys.
A
So
our
proposal
is
to
to
restrict
all
of
those
things
and
services
and
resources
cloud
resources
that
have
to
do
with
with
signing
in
that
project.
A
A
I
mean
I,
I
personally
think
that
that's
the
best
way
to
go
so
whenever
the
promoter
is
going
to
sign
things,
it's
going
to
personate
that
service
account
from
that
project,
and
we
can
later
on
when
we
do
the
the
top
delegation
from
sixer
specify
that
that
account
is
going
to
be
the
official
that
identity
is
going
to
be
the
official
identity
for
all
kubernetes
artifacts
that
we
send,
and
if
anyone
has
other
suggestions
of
how
to
structure
and
or
where
to
or
where
to
to
set
the
accounts
that
are
going
to
be
the
identity
of
the
artifacts
were
to
to
host
them.
A
I'm
happy
to
hear
them
and
so
continuing
on
the
flow
the
promoter
will
run
through
the
promotion
and
then
once
the
the
images
are
stored,
it
will
pick
the
first
one
sign
it
using
the
identity,
so
it
will
generate
identity.
Tokens
of
the
designer
account
use
those
to
sign.
A
Then,
once
the
signature
is
on,
it
will
store
the
signature
inside
of
the
of
the
registry,
the
first
target
registry,
for
that
it
needs
to
take
the
identity
of
the
of
the
of
the
writer
of
the
registry
and
then
once
it's
stored,
it
will
copy
to
any
additional
registry
stand
you're
promoting
to.
A
I
don't
know
if
that,
if
that's
that's
a
clear
overview
of
how
we
want
to
do
this
or
if
there
are
any
questions
on
this
part
of
the
of
the
promotion
and
flows.
A
Okay,
so
I'll
move
to
the
next
one,
okay,
the
next
one.
I
would
like
to
do
an
overview.
Okay,
maybe
just
briefly
going
on
the
on
the
impersonation
flow
of
the
of
the
image
promoter
end-to-end
tests.
This
is
simpler.
The
here
during
end-to-end
testing
the
promoter
uses
a
fixed
service
account
to
do
all
of
its
testing
it.
It
will
do
actual
promotions
of
artifacts
and
images
using
a
service
account
that
is
defined
in
a
json
key
file.
A
Htw
token,
that's
that's
stored
in
the
in
the
in
the
cluster
and
there
our
proposal
is
to
keep
using
that
and
simply
generate
another
dummy
service
account
to
use
for
identity
and
signing
during
the
test.
Now
this
is,
I
think,
trivial
and
not
much
controversy
or
debate
here
this
all
of
these
would
be
on
the
same
testing
project
and
and
there's
no
complexity
there
and
finally,
the
other
one
we
are
looking
at
here
is
the
impersonation
flow
during
the
staging
of
the
artifacts.
A
So,
once
again,
when
we
run
our
kubernetes
release,
we
build
everything
stage
the
artifacts
and
then
we
we
want
to
sign
those,
and
we
want
to
sign
them
because
before
releasing,
we
want
to
have
them
signed
so
that
the
promoter
can
actually
verify
the
signatures
that
staging
generated
and
if
they
check
then
allow
them
for
promotion
and
and
copy
them
to
the
registries.
By
the
way
this
verification
is
already
in
place.
A
So
if
we
were
to
cut
a
new
release
of
the
of
the
image
promoter
right
now
it
will,
it
will
check
for
signatures
in
every
image
that
gets
promoted.
If
it
doesn't
have
an
image.
If
it
doesn't
have
a
signature,
it
will
accept
it,
but
if
it
has
one
and
there's
a
problem
with
it,
it
will
reject
it
for
promotion.
So
that's
already
running
and
and
working
not
running,
because
we
haven't
made
a
new
version,
got
a
new
release
of
the
promoter.
A
Okay
and
then
so
in
this
case,
what
we
want
to
do
is
we
want
to
have.
We
need
to
have
a
service
account
that
the
also
all
of
the
kubernetes
image
promotion
runs
inside
of
cloud
build,
and
this
cloud
build
the
cloud
build
uses
a
file
service
account.
So
what
we
need
to
do
is
to
create
another
service
account
that
will
serve
as
identity
for
the
signatures
that
are
generated
during
staging,
and
we
need
to
add
permissions
for
the
cloud.
Build
service
accounts
to
generate
tokens
with
the
identity
of
designer
accounts.
A
I
opened
up
here
for
that
last
night,
and
this
is
basically
the
only
thing
we
need.
I
think
there
was
a
comment
around
the
project
where
this
account
may
leave.
To
be
honest,
I
I
have
no
preference,
since
this
is
like
an
internal
project,
I
don't
think
it
should
be.
A
It
doesn't
necessarily
have
to
be
part
of
the
bigger
topmost
kubernetes
identity,
because
if
you
were
to
see
it
in
a
more
tree-like
way,
there's
a
top-most,
kubernetes
identity,
and
this
could
be
like
a
project
of
of
release
engineering,
so
it
doesn't
have
to
be
part
of
that.
I
mean
we
can
store
the
story
there
if
there
are
other
needs,
but
we
don't
need
to
have
that
account
anywhere.
Really.
A
A
So
that's
the
basic
overview
of
the
of
the
flows
we
are
building.
There
are
pr
super
open
for
some
of
these
and
the
the
I.
I
would
like
to
hear
more
comments
about
the
establishing
the
signer
project
and
to
see
if
anyone
has
other
ideas.
That's
why
I
haven't
yet
opened-
or
I
don't
know
how
to
request
a
new
project
for
that,
but
I
still
haven't
started
on
that,
but
I
would
like
to
hear
if
others
have
any
other
project,
other
ideas
about
around
the
hosting
those
those
identity
accounts.
B
I
I
have
a
comment,
a
question.
I
will
start
with
my
comment.
The
first
comment
is:
we
should
stop
use
kubernetes
test
gcp
gcp
project
for
the
release
process,
because
it's
a
google
project,
not
a
community
owned
one,
and
we
did
some
change.
I
think
three
weeks
ago
about
fast
forward.
We
basically
decided
to
stop
using
that
project.
That's
that's.
My
first
comment.
B
Welcome
to
sasha
also
my
question
right
now:
is
it's
not
directly
related
to
the
image
signing
but
more
like
to
the
binaries
in
general?
Okay,
so.
A
Okay,
so
the
first
one
I
I'm
I
so
what
you're
saying
is,
as
part
of
the
fast
forwarding
of
the
wrenches
we're
going
to
move
the
release
process
to
a
new
project.
Is
that
it
it's.
B
Already
done
so
right
now
we
don't
we
stopped
with
the.
I
think.
The
first
world
job
use
the
staging
his
engineering
test
pressure.
A
B
A
Okay,
okay,
I'll
switch
the
pr
to
use
that
one.
Okay,
no,
no
problem
there.
We
still
need
to
add
the
permissions
for
the
current
release
process
account
because
changing
that
release
process
is
not
trivial,
because
we
have
to
make
sure
that
all
of
the
identities
permissions
and
everything
match.
A
But
but
it's
a
good
thing
and
happy
to
also
look
for
to
moving
that
in
the
future.
A
Yes,
definitely
we
are
signing
the
binaries
as
well,
and
the
currently
all
of
the
effort
has
been
on
the
signing
mvp,
and
so
we
are
making
a
huge
strides
to
to
go
from
basically
no
code
for
signing
to
getting
out
that
public
public
image
sign
and
all
of
the
there
are
other
things
in
the
middle
which
we
need
to
fix
and
ensure
happen
like,
for
example,
signing
the
the
images
during
staging.
A
But
right
now
the
goal
is
to
get
the
public
images.
Science,
that's
the
first
one
and
there's
at
the
same
time,
there's
the
the
designing
of
files
and
artifacts
and
blogs.
Also
going
on
this.
One
is
a
little
bit
more
behind,
but
work
is
going
on
and
it
will
be
basically
the
same
process.
So
you
have
your
artifacts
and
you
should.
Whenever
you
release
them,
you
will
run
them
through
the
to
the
promoter,
which
is
not
just
an
image
promoter.
A
It
also
promotes
files,
for
example,
the
ko
apps
kops
project
already
uses
that,
and
so,
whenever
you
publish
your
artifacts
via
the
promoter,
they're
going
to
get
a
signature
and
it's
going
to
be
stored
in
the
in
the
buckets
along
them
for
verification
proposed
purposes.
So
right
now
the
tool
we're
using,
which
is
cosine.
It
allows
you
to
verify
those
signatures.
A
Once
we
get
the
kubernetes
delegation
in
place
for
files
you're
going
to
have
to
specify
the
exact
delegation
that
you're
going
to
to
to
do,
for
which
you're
going
to
use.
So
whenever
you
you
verify
using
cosine
and
image,
for
example,
you
get
like
a
clear
path
of
the
block
that
you're
verifying,
so
you
get
a
domain
and
then
a
path
which
stuff
uses
to
calculate
the
the
the
the
trust
chain
all
the
way
up
to
the
to
the
full
to
your
roots.
That
gives
you
that
chain
of
trust.
A
When
you
have
like
a
an
artifact
that
you
downloaded
from
somewhere,
you
can
verify
that
signature
is
valid,
but
in
order
to
ensure
the
full
chain
of
trust
all
the
way
up
to
the
to
the
six
or
roots,
you
will
need
to
pass
a
flag
to
specify
the
kubernetes
delegation
that
you
do.
Basically,
you
have
to
tell
cosine
that
you're
using
the
kubernetes
validation
to
check
that
artifact,
but
it's
going
to
to
to
work
as
well.
A
Not
necessarily
because
you're
going
to
have
a
a
signature
which
you
can
use
it
to
to
check
the
signature
against
the
binary.
You
can
absolutely
do
that,
but
one
thing
that
so
it's
one
thing
it's
is
to
to
ensure
that
the
signature
matches
the
artifact.
A
That's
one
thing,
but
then,
in
order
to
to
to
give
you
a
little
bit
more
trust
us.
If
that
person
who
signed
the
artifact
is
allowed
to
sign,
said
artifacts,
you
have
to
go
all
the
way
up
to
the
to
the
trust
chain,
all
the
way
up
to
the
to
the
root
of
trust,
and
then
you
have
to
to
pass
the
the
the
actual
delegation
for
cosine
to
use.
A
I
don't
know
if
that's
that's
clear
or
maybe
frame
it
in
another
way
to
to
understand.
So
you
you,
you
get
your
signature
and
you
can
check
that
it's
valid,
so
the
signature
will
tell
you
if
the
lot
you're
looking
at
has
been
tampered
in,
any
way
that
that
that
will
allow
you,
but
but
the
chain
of
trust,
which
is
the
toughest
location
which
we
were
talking
about
last
friday.
A
That
allows
you
to
ensure
that
the
kubernetes
organization
says
it's
okay,
for
an
identity
to
sign
that
account.
So
you
can,
we
will
be
able
to
assign
certain
designers
to
to
projects
and,
for
example,
people
will
not
be
able
to
sign
artifacts
from
one
project.
A
People
from
one
project
are
not
going
to
be
able
to
sign
artifacts
from
another.
That's
the
point
of
the
of
the
tough
delegation,
so
you
may
you
may
sign
the
thing
and
you
may
produce
a
valid
signature
which
matches
a
block,
but
the
truth
of
the
root
of
the
chain
of
trust
will
not
be
completed
all
the
way
up
if
you're
not
allowed
or
designated
as
a
as
a
signer.
B
B
A
Cool
and
all
right
and
the
so
so
it's
okay
all
right.
So
I
wonder
I
know
if
there
are
any
any
other
concerns
about
around
the
the
infra
changes,
then
that
we're
moving
on
here.
Do
you
have
any
well
you
or
any
anybody
else,
any
other
comments
around
establishing
that
root
project
for
the
signatures
and
storing
keys
and
things
in
there.
B
I
want
to
be
cautious
about
this,
because
if
we
basically
set
up
the
gcp
project
for
sign
mutual
with
directly
going
production,
so
I
want,
I
think
I
think
we
should
start
have
it.
We
test
firstly
in
the
same
project
and
see
how
this
is
happening,
because
we
have
before
we
get
a
production
project
for
signature
during
the
image
promotion.
B
The
the
first
thing
we
should
be-
we
should
do
right
now
is
make
sure
we
can
basically
sign
the
image
in
the
station
project.
I
think
that's
the
first
thing
we
need
to
make
sure
in
station.
That's
the
first
thing
we
do
once
we
are
sure
we
basically
can
sign
and
possibly
verify
kls
container
images.
We
can
talk
about
promotion
and
basically
say:
okay,
we
are
ready
to
go
in
production
and
we
can
basically
do.
We
can
basically
promote
sign
image
during
the
release
process.
A
Okay,
okay,
so
yeah
we
can.
We
can
absolutely
work
on
that,
so
I'm
so
currently
the
both
so
signing
is
basically
done
for
the
image
promoter.
It
doesn't
run
not
even
the
tests,
because
the
accounts
to
do
that
are
not
there.
A
And
but
we
can
certainly
complete
the
the
signing
during
staging
yeah
absolutely
and
we
can
test
those
in
in
the
mock
releases.
A
B
B
Exactly
because,
if
you
basically
sign
an
image
in
case
station
kubernetes
every
time,
the
every
time
you
do,
the
signature
you
impress
on
it,
it's
like
an
energy
project
and
once
you
do
the
promotion,
you
need
to
impress
on
it
another
project.
I
know
the
service
icon
in
a
different
project
for
promotion.
A
Exactly
yeah
and
these
signatures
will
be
carried
over
from
staging
to
release
and
then
after
promotion
they
will
still
be
available.
That's
the
idea,
but
but
yeah.
Definitely
we
can.
We
can
work
on
finishing
the
release
process
signing
part,
but
we
need
we
need.
We
need
the
permissions,
otherwise
it
will
break.
B
Yeah
I
can
I
can
we
can
look
into
that
this
week
and
I
will
I
treat
the
stream.
A
Okay,
yeah,
that's
that's
the
that
would
be
the
the
permissions
on
two
four
four
five.
A
A
Okay,
so
any
any
other
questions
around
around
the
impersonation
flows
and
or
the
tough
delegation-
I'm
not
I'm,
not
a
tough
expert,
but
I've
been
to.
I
know
that
some
release
managers
jumped
into
the
into
the
tough
goal.
Last
week
I
probably
got
caught
in
not
knowing
what
the
effort
was
all
about,
but
I'm
too
happy
to
answer
my
using
my
limited
knowledge
of
stuff
or
how
we
plan
to
structure
that.
C
Yeah,
maybe
just
one
comment
for
clarification:
if
we
look
at
the
at
the
second
image
on
the
impersonation
flow
during
image
promotion,
then
then
it
mentions
that
we
sign
images
and
we
need
the
impersonation
for
that
on
designer
project.
Do
we
want
to
update
this
one?
I
mean
we.
We
were
thinking
about
copying
over
the
signatures
right
that
it's
more
clear
that
we
don't
actually
design
in
that
step,
but
we
copy
around
signatures.
C
Yeah,
probably
I
mean
I
mean
for
me
personally-
it's
kind
of
it's
kind
of
confusing,
but
I'm
not
sure
how
how
to
express
it
more
clearly
right.
A
C
A
Let's
go
over
that
again
really
quickly.
So
whenever
you
have
a
you,
have
a
service
account
which
will
serve
as
the
identity
of
the
signatures.
The
proposal
here
is
to
create
a
new
project
where
that
account
lives,
and
it's
there
that
account
should
have
permissions
specifically
token
creator.
Permissions
for
the
promoter
service
account
the
main
account
that
runs
the
promoter.
A
A
A
Okay,
yeah
but
yeah
we
can
yeah
just
like
we
are
attaching
the
s1
in
the
in
the
image
we
can.
C
C
A
Yeah,
okay,
so
point
taken
on
that
and
and
I'll
do
the
shift
of
the
of
the
pull
request
or
not
to
the
to
the
other
project
and-
and
we
can
start
working
on
setting
during
staging.
So
the
the
good
thing
about
signing
things
during
staging
is
that
we
can
run
as
many
mock
releases
as
we
want
so
to
ensure
that
things
are
getting
inside
properly
and
maybe
have
some
some
images
to
work
with
and
test
the
promoter,
copying
the
signatures
and
everything.
A
B
So
basically,
I
think
three
weeks
ago
we
were
talking
about
basically
stop
not
stop,
take
over
the
release
process
of
the
system
packages
from
google,
and
in
order
to
do
that,
we
need
to
have
new
gpg
case
and
build
a
web
of
trusts
between
the
different
release
manager.
B
For
that
so
I'm
trying
to-
and
the
question
is
how
we
do
that
and
where
are
the
signing
party
doing
valencia
or
do
we?
Can
we
do
that
online?
So
I'm
trying
to
basically
understand
how
we
can
generate
a
new
chippy
cheeky
who
is
sick,
our
teacher,
the
person
responsible
for
that
those
new
jpg
and
how
we
build
some
kind
of
web
of
trust
between
the
radius
manager.
B
Want
to
I
volunteered
to
work
on
that
two
weeks
ago,
I
got
recently
I'm
gonna
be
busy
in
the
coming
weeks,
but
just
want
to
make
some
progress
about
this.
B
Signing
party,
I
want
to
call
it
basically
a
standard
process
to
basically
build
trust
about
during
this
release,
process
yeah
and
also
how
we
need
to
do
that
communication,
because
it's
breaking
change.
We
need
to
ask
everyone
the
entire
planet
that
they
need
to
import
at
gpg.
A
Yeah,
so
I
think
the
first
one
would
be
to
write
a
gap
on
how
this
could
work,
because
it
involves
lots
of
changes
and
basically
I
would
think
that
we
would
need
to
to
have
like
a
like
the
two
repos
working
together
for
some
time
and
then
have
a
policy
of
deprecation,
and
all
of
that
I
think
it
should
go
into
a
gap,
but
we
can
start
throwing
ideas
around
that
and
and
seeing
if,
if
how
feasible
and
how
much
amount
of
work
is
keep
in
mind.
A
Also
I've-
I
don't
know
if
you,
if
you
got
it
from
the
tough
talk
on
friday
there's
there
are
some
people
that
are
interesting
interested
in
extending
all
of
this
six
third
route
of
trust
chain
of
trust
into
the
signatures
in
the
packages
themselves.
There's
no
like
a
concrete
effort
right
now,
but
that
would
be
an
interesting
thing
to
to
keep
an
eye
on
as
well.
B
B
A
Yeah
yeah
I
mean
so
gem,
but
just
so
I
I
would.
I
would
say
that
considering
the
amount
looking
at
them
at
the
amount
of
work,
we
need
to
do
for
the
system
packages
in
the
kubernetes
empire,
just
to
having
our
our
own
distribution
and
roots
and
all
the
policy
applications,
and
all
that
and
seeing
how
some
of
the
projects
in
sixer
have
been
moving
probably
would
be
a
good
way
to
keep
under
consideration.
A
But
we
can
definitely
start
working
on
on
detached
signatures
and
keys
and
then
see
see
if
we
can
have
any
progress.
I'm
happy
to
to
chat
over
it
that
slack
and
we
can
start
building
a
cap.
If
you
want.
A
Okay,
thank
you.
Thank
you,
anna
thanks
everyone.
So
I
will
be
seeing
you
in
two
weeks
from
now
and
any
questions
please
be
sure
to
sound
over
in
slack.