►
From YouTube: SIG Cluster Lifecycle 2021-10-19
A
A
Right,
let's
see
if
somebody
else
joins
later,
moving
to
subproject
updates
for
cube
adm.
I
added
a
couple
of
items
here.
A
Basically,
we
encode
the
version
of
kubernetes
inside
the
config
map,
which
has
proven
to
be
very
complicated
and
problematic,
not
only
for
maintainers,
but
also
for
users
who
wants
to
patch
it
we're
changing
it
to
not
have
the
version,
and
we
were
thinking
of
a
way
to
how
to
do
this
more
gracefully.
So
we
decided
for
to
use
a
feature
gate
and
the
feature
gate
is
going
to
be
added
in
123
as
an
alpha
feature
gate
and
in
the
meantime,
we
are
going
to
deprecate.
B
A
B
0
and
that
release
process
is
now
almost
entirely
gitops,
driven
so
through
the
confusingly
named
kubernetes,
slash,
case.io
repo.
So
that's
good!
It's
no
longer!
You
know
humans
in
the
loop.
Almost
I
think,
there's
like
a
couple
of
legacy,
buckets
that
still
need
some
promotion
or
I'm
not
sure
the
binary
production
is
fully
automatic,
but
we're
very
close.
B
There
is
some
progress
towards
our
api
for
our
effectively
crds,
but
they
are
not
actually
uploaded
to
the
cluster.
Today
are
those
those
versions
are
still
technically
the
one
alpha
one,
even
though
we
don't
treat
them
as
alpha
and
we
are
working
towards
getting
towards
a
beta
and
eventually
a
stable
version
of
that
api
sort
of
taking
up
to
clean
up
some
of
the
crust
that
has
accumulated
over
the
years.
B
We
are
driving
gce
support
to
to
ga
it's
been
in
alpha
or
beta
for
way
too
long.
So,
for
example,
we
added
tpm
support
very
recently,
which
is
actually
really
fun
and
cool
so
yeah.
I
thought
that
was
pretty
interesting
being
able
to
do
that
and
then
we
are
making
progress
on
add-on
operators
as
well,
so
they
should
be
hopefully
landing
in
the
next
couple
of
weeks.
So
I've
been
saying
that
for
a
while,
but
I
think
all
the
pieces
are
aligning.
You
know.
B
If
you
spy
on
my
github
prs,
you
can
see
the
the
pr
is
going
in
randomly
across
the
pseudorandomly
across
the
various
projects
related
to
operators
and
coupe
builder,
and
that
so
it
is
all
it
is
all
converging
and
it's
working
pretty
nicely
right
on
my
private
branch
or
on
my
branch,
which
is
harder
to
find.
B
B
It's
built
on
the
trusted,
proud
cluster
in
a
trusted
project.
So
it's
sort
of
a
little
bit
more
trusted
than
the
general
edesta.
B
Those
artifacts
go
through
testing
as
normal
like
this
is
the
same
way
every
you
know
all
of
our
testing
works,
but
then,
in
addition,
we
can
designate
one
of
those
as
being
promotable,
and
so
we
we
send
a
pr
to
the
kubernetes
kits
io
repo,
it's
actually
more
than
one
pr.
It's
sort
of
promoting
those
artifacts
and
the
image
promotion
process
today
is
the
more
established
one
and
it
is
fully
automated.
B
But
you
basically
describe
the
set
of
artifacts
you
want
to
promote
and
someone
else
approves
it
in
the
sort
of
two-person
rule,
and
then
it
is
copied
automatically
by
the
sort
of
system,
so
users
or
like
even
administrators,
don't
need
to
have
permission
to
write
to
the
gcr
buckets
or
the
gcs
buckets
that
back
the
various
kids,
such
as
ao
and
artifact
stuff
case
studio.
The
almost
in
this
is
that
I
believe
image,
binary
promotion,
sorry
image
permission
is
automatic.
Binary
promotion
is
still
needs.
B
A
little
kick,
I
think,
but
that
that
will
be
getting
resolved
shortly,
but
the
process
is
there.
I
one
of
the
complicated
things
is
tagging
in
particular.
If
you
want
to
embed
the
version
into
the
binary
or
into
your
binary
in
your
image,
so
we
actually
have
to
send
a
tag
through
the
process
and
the
tagged
builds
are
the
ones
which
are
then
promoted,
but
it
doesn't
change
the
overall
flow
but
yeah.
If
there
was
a
way
to
if
there
was
a
way
to
re-tag
a
binary.
B
Well,
I
guess
it
would
break
the
whole
system,
but
anyway,
that
that
makes
it
a
little
like
there's
a
little
chicken
and
egg
going
on
there.
So
we
can't
just
take
an
arbitrary
one
out
of
the
stream,
because
then,
if
you
were
to
type
kop's
version,
you
would
see
the
an
incorrect
version,
so
we
actually
have
to
do
a
little
bit
of
a
dance
to
like
actually
propose
a
tag.
But
it's
it's
the
same
process
just
with
a
little
bit
of
extra
fun.
B
Yeah
I
mean
github
actions
is
nice.
I
think
the
we
are
trying
to
we're
trying
to
create
a
more
auditable
workflow
and
I
think
we've
chosen
to
focus
doing
that,
not
as
a
community
we've
chosen
to
focus
doing
that
on
not
on
github
actions
but
yeah
I
mean
it
still
uses
a
lot
of
github.
So
it's
it's
not
like.
We
don't
trust
the
topics
that
we
felt
that
like
it,
was
easier
to
do
in
this
way.
A
I
I
tried
github
actions,
so
basically,
I
can
put
attack
on
a
certain
commit
and
there
was
an
action
that
looks
for
new
tax
and
pix
attack,
creates
a
build
automatically
pushes
artifacts
to
a
particular
creates.
A
release
based
on
attack
pushes
artifacts
to
the
release.
B
I'd
say
one
of
the
restrictions
we
have
today
is:
I
don't
think
we
can
promote
artifacts
that
aren't
in
a
gcs
bucket.
There's,
nothing
really
technically
about
that.
It's
just
that's
the
only
that's
the
only
source,
that's
written,
the
it
shouldn't
matter
where
it
comes
from,
because
the
the
trust
is
established
when
the
user
approves
when
the
sort
of
trusted
administrator
approves
the
pr
that
that
like
includes
the
hashes.
B
So
if
we
have
reproducible
builds
and
we
and
you
like-
approve
the
build,
you
reproduce
the
build
and
check
the
hashes
and
verify
it
doesn't
really
matter
who
built
it
right.
So
I
think
we
don't
have
a
great
process
around
that,
like
how
do
I
know
when
it's
safe
to
approve
that
pr.
B
So
it
helps
today
to
have
the
bill
be
a
more
trusted
build,
maybe
but
yeah
we
should.
We
should
probably
be
doing.
Reproducible
builds
verifying
them
on
our
own
machines,
verifying
that
we
got
the
same
result
assuming
that
our
own
machine
and
the
build
machine
were
not
compromised
in
the
same
way,
and
so
therefore
it
is
safe
to
turn
the
key
and
do
that.
But
I
don't
know
if
anyone
is
doing
that.
A
Yeah,
it
might
be
more
secure,
I'm
not
suggesting
that
this
is
something
that
should
be
done,
but
if
the
git
github
action,
for
instance,
created
in
a
release
artifact,
you
can
then
tell
the
promotion
process
to
pick
it
from
a
github
release,
url,
which
is
supposedly
trusted
because
it's
maintained.
The
github
action
maintains
the
authenticity
of
the
artifact
right.
B
Yeah,
I
think
that
would
be
great.
I
mean,
I
think
I
think
an
an
ideal
scenario
would
be
to
have
two
builders
right.
So
if
we
had
github
actions
and
cloud
build,
then
we
would
feel
very
confident
or
a
lot
more
confident
that
those
two
produced
like
we're,
not
compromised
in
the
same
way,
which
I
think
is
all
that
we're
trying
to
establish.
B
And
the
artifacts
are
all
promoted,
based
on
hashes
like
shot
two
five
sixes
or
maybe
even
more
sometimes,
but
so
they
are
like
fight
for
byte
verified,
and
one
of
the
things
I
think
is
interesting
is
I
want
to
make
sure
that
those
those,
particularly
in
the
binary
case,
that
we
publish
those
shas
so
that
users
can
use
them
as
references.
B
So,
for
example,
if
kubereum
wanted
to
embed
the
shas
for
cube
api
server,
you
could
do
that
and
you
can
do
that
today
right,
but
just
the
whole
ecosystem.
A
B
Yeah,
it's
reasonable
and,
like
you
have
to
like
think
back
through
the
chain
like
if
you're
going
to
download
it
from
gcs
anyway,
if
you're
going
to
download
the
shop
from
gcs
anyway,
then,
what's
you
might
as
well
assume
that
they
are
that
the
the
shah
is
going
to
match
the
the
artifact?
But,
yes,
you
can
you
can
boost
the
the
integrity
a
little
bit,
but
unless
yeah
the
train,
the
chain
is
not
fully
end
to
end
trust.
It
don't
worry.
B
It
essentially
boils
down
to
the
integrity
of
the
tls
key
signing
artifacts
success
or
case.gcr.o.
That's
the
one.
You
eventually
have
to
trust.
So
it's
hard
it's
hard
to
do
anything
better
than
that.
A
Yeah,
there
are
ways
to
improve
what
we
do
currently
and
something
that
sig
release
is
hopefully
working
on
is
to
also
the
couple
of
the
the
kubrow
cuban
packages
for
the
distributions
the
depths
and
rpms
yeah.
I
think
we
are
still
bound
to.
B
I
will
say
that
the
the
binary
promoter
is
is
now
being
driven
mostly
by
sig
release,
so
that
is,
that
is
the
same
binary
promoter,
but
they're
they're
doing
most
of
the
work.
Now
I
don't
know
if
there
are
additional
requirements
for
deb
and
rpm
signing
like
beyond
file
copying,
but
that
is
that
this
is
all
the
same
stream.
So
there
is
hope
there.
A
B
The
good
news
is
coordinates
is
actually
the
the
first
one,
so
you
might
get
that
way
sooner
than
you
might
expect.
There
is
actually
a
coordinates
operator
and
it's
being
maintained
by.
I
think
someone
who's
pretty
involved
in
the
coordinates
project.
I
mean.
A
Yeah
a
bit,
I
have
two
general
comments
about
the
operator
I
was
debating
whether
we
should
just
call
it
v1
instead
of
d1
alpha
one.
Just
you
can.
A
A
If
we
like
just
another
alpha
api,
that
we
have
to
break
users
when
we
graduated
or
something
like
that,
the
other
topic
was:
how
do
we
support
like
aircraft,
and
I
think
the
solution
you
you
have
with
the
addons
project
is
to
ask
the
container
for
the
I'm
sorry,
I
I
kind
of
I
think
I
forgot
what
mechanism
was
used.
A
B
So
there's
a
there's
a
couple
of
mechanisms,
one
of
which
is
to
try
to
mirror
the
the
images
and
the
other
one
is
to
which
enables
you
to
continue
to
use
the
operator,
the
other
one
of
which
is
to
effectively
remove
the
operator
by
asking
the
operator
ahead
of
time.
To
give
you
the
manifest
to
give
them
to
build
a
manifest,
and
so
that
would
enable
you
to
like
do
the
same
thing
that
you've
done
before,
where
effectively
you've
had
a
static
manifest.
So
between
those
two
I
think
we
are
in.
A
So
effectively
because
we
are
the
point
of
an
operator
on
a
kubernetes
deployer
to
say
this
has
to
be
some
diabolo
that
is
being
deployed,
and
this
inside
this
yellow
there.
There
has
to
be
a
the
image
for
the
controller.
A
B
Yeah
the
way
we're
doing
it
in
chaos
is
we
have
two:
we
have
a
concept
called
channels
and
we
have
for
each
add-on
we're
going
to
have
two
versions,
one
of
which
is
the
version
of
the
operator
and
the
other,
one
of
which
is
the
version
of
the
of
the
thing
being
deployed.
B
So
the
version
of
cordialness
those
are
defaults.
Those
can
be
overridden
by
the
user,
but
the
idea
is
that
this
is
how
we
can
do
what
we
did
before.
We
basically
like
bind
a
version
to
a
particular
at
the
at
the
end
of
the
day.
Kubernetes
version,
that's
our
sort
of
primary
identifier,
but
like
and
auto
upgrade
users
and
and
keep
them
moving
on
so
that
if
they
want
to
keep
if
they
want
to
stay
on
the
recommended
path,
they
can
do
that.
A
Yes,
that
has
to
basically
you
have
to
be
able
to
ask
the
operator
what
is
it
supported,
secure.
It
has
to
support
like
a
dynamic
version,
matrix
outputs
of
sorts,
because
if
it's
it
depends
like,
maybe
the
operator
is
not
compatible,
I
mean
when
you
deploy
it,
you
have
a
manifest.
You
assume
it
works
for
this
version
of
kubernetes,
but
it
might
support
multiple
versions
of
the
actual
add-on.
So
maybe
there
has
to
be
a
way
to
ask
it.
The
current
set
of
versions.
B
Yeah,
the
there
is
support
in
in
the
operator
library
for
the
manifest
indicating
which
versions
of
the
operator
it
needs
which
is
sort
of
the
the
part
of
this
problem.
It's
not
a
full
solution,
but
at
least
at
least
it
makes
it
easy
for
an
operator
to
know
that
it
shouldn't
be
installing
a
newer
version
of
or
a
version
that
has
been
designated
as
not
working
with
it
anywhere.
A
It's
going
to
be
like
I'm
going
to
give
you
an
example.
What
happened
with
the
coordinates
adam
is
specifically
in
cuba.
Dm
we
change
the
path
of
coordinates
of
the
coordinates
image
now
lives
in
gcr.
A
Slash
accordions,
slash,
coordinates
something
the
addition
of
the
subpath
broke,
so
many
people
that,
because
they
they
they
had
scripts
to
people
assuming
there
is
no
support
which,
which
was
you
know,
it's
a
photon
parent
to
to
pin
against
the
repository
instead
of
assuming
they're,
not
assuming
that
there's
soup
parts
in
there
the
full
path
they
did
not
assume
it,
but
I'm
wondering
how
many
people
are
going
to
break
if
we
remove
the
reforgotten,
which
is
just
an
image
at
this
point.
A
B
It
would
be
good,
we've,
we've
tried,
I
don't
actually
know
the
state,
I
think
it's
sort
of
working,
but
I
haven't
tried
it
myself.
Recently,
we've
tried
to
support
the
ability
to
export
the
list
of
images
that
you
need
from
a
cops
cluster,
and
I
think
we
even
at
one
point
tried
to
like
implement
an
auto
mirroring
tool.
I
feel
like
doing
that
export
having
a
structured
format
for
outputting.
A
Somebody
looked
an
issue
recently
to
support,
pulling
an
image
and
tagging
it
differently
locally,
or
something
like
that.
We
also
have
machine,
readable
output
for
the
required
images
already,
but
this
particular
feature
that
they
requested
I
started
doing
some
research
on
it
and
crypto
has
missing
features.
Basically,
there's
no
way
to
do
some
tagging
and
basically,
I
don't
think
krakatoa
is
ready
for
because
we
use
cracon
for
all
the
container
stuff
on
the
host,
and
basically
the
tool
we
want
to
use
is
not
really
yet.
A
B
I've
used
the
g,
crane
library
and
I
like
it,
it's
a
google
library.
I
think
there
are
others,
but
it's
pretty
good
for
manipulating
images.
It
may
be
that
if
I
recall
it's
like
the
cri
itself
doesn't
actually
have
image,
support
right
or
doesn't
have
doesn't
have
as
much
image
support
going
on
it's
something,
there's
an
odd
distinction
in
there.
I
can't
remember
the
details,
but
yeah.
A
A
Yeah
yeah,
I'm
not
going
to
be
surprised
if
we
just
break
people
again.
If
we
just
include
change
the
add-on
deployment
method.
Basically,
I
think
we're
just
going
to
break
people
again,
and
maybe
we
have
to
in
cuba
at
least
utilize.
The
same
feature
gate
approach
we
had
that
I
mentioned
here.
A
All
right
any
questions
for
cops,
any
other
subproject
updates.