►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20210216
A
A
I
think
it's
all
old,
I
mean
young
but
still
old
faces
in
the
call.
So
no
no
introductions
today,
yeah.
A
We
had
a
conversation
about
the
google
summer
of
code.
Somebody
brought
this
up
on
the
just
close
this.
A
And
somebody
brought
it
up
on
on
slack
and
it
looks
like
currently
we're
in
the
stage
where
the
cncf
applied
to
google
or
is
still
applying
so
we're
still
very,
very
early.
So
first
google
needs
to
improve
the
cncf,
and
then
we
can
propose
projects.
But
if
we
have
anything,
we
would
like
students
to
work
on
the
earlier.
We
noted
down
somewhere
the
better
and
so
with
a
couple
of
ideas.
The
last
time
one
of
them
was
around
the
manifest
bundle
cap.
A
Unfortunately,
we
don't
have
lee
here
today,
like
I
think
he
came
up
with
a
couple
of
these.
We
also
were
talking
about.
C
Like
anything,
you
could
imagine
yeah
yeah
yeah.
I
had
a
suggestion,
for
I
guess,
evaluation
to
see
if
it's
something
we
are
interested
in,
it's
basically
just
a
project
that
I
kind
of
poked
at
last
summer
and
didn't
really
get
a
chance
to
push
it
all
the
way
through.
C
C
Maybe
it
uses
some
specific,
separate
tool
that
needs
to
be
on
the
node
that
you
install
when
you
install
the
volume
driver,
and
I
was
kind
of
interested
in
taking
that
driver
and
turn
it
into
something
that
pulls
images
for
mounting
its
volumes
but
via
cri
instead,
so
that
if
you
mount
an
image
as
a
volume
that
just
picks
up
all
the
rest
of
your
cluster
and
node
configuration,
if
you
have,
you
know
credentials
to
private
registries,
you
can
use
all
those
the
same
exact
way
for
pods,
and
I
I
prototyped
a
couple
things
I
reached
out
to
the
maintainer
and
we
talked
through
a
bunch
of
different
options.
C
I
have
like
a
work
in
progress.
Pr,
that's,
I
think.
Maybe
the
first
iteration
of
this
I'll
go
ahead
and
link
just
for
for
context.
C
C
So
I
thought
an
interesting
project
would
be
to
sort
of
define
those
requirements
and
lay
out
the
argument
and
go
to
some
of
the
node
teams
and
talk
about
what
changes
to
cri
would
be
needed
and
make
those
so
that
you
could
write
the
image
volume
driver
in
a
way
that
sort
of
made
sense
and
didn't
duplicate
data
and
had
a
workflow
that
seemed
reasonable.
C
The
reason
I
thought
it
was
interesting
for
this
context
is
because
it
seems
like
a
thing
that
would
be
useful
for
manifest
bundles.
It
will
let
you
operate
on
them
easily
in
a
cluster,
and
it
might
be
a
good
launching
point
to
start
looking
at
adding
like
oca
artifact
support
to
cri
in
the
future.
As.
C
B
Yeah
I
mean
I
can
to
me
that
sounds
like
a
good
good
project.
I
think
there
is
a
risk
that
you
know,
like
google
center
of
contributor
has
to
spend
their
time
trying
to
persuade
maintainers
of
the
various
cris
and,
and
it's
more
political
than
technical.
I
I
think
against
that.
Risk,
though,
is
the
fact
that
it's
not
the
end
of
the
world
if
the
various
installation
tools
have
to
configure
something
twice.
B
So
you
know,
like
maybe
there's
an
argument
that
you
you
should
opt
into
reusing
those
credentials
like
your
image,
bulk
credentials,
your
default
image
credentials.
So
I
think
it's
a
good
project
and
I
think
it
also
works
towards
the
direction
of
like
making
image
registries
more
generally
useful,
beyond
just
holding
just
container
images.
So
I
like
it.
C
Well,
I
mean
that
that's
the
only
one
that
came
to
mind,
I'm
sure,
there's
some
other
stuff.
I
wasn't,
should
we
should
we
just
go
back
and
watch
the
recording
from
last
time
to
get
an
overview
of
the
other.
A
No,
I
like
I
like
the
idea.
Does
anyone
else
have
any
comments
or
maybe
nick
do
you
have
an
opinion.
D
There's
I
only
have
like
thoughts
on
implementation
about
that,
but
but
other
than
that,
I
think
it
is
going
to
be
useful
in
general,
because
the
direction
of
most
at
least
the
I
guess
downstream
flavors
of
kubernetes
the
restrictions
that
I'm
familiar
with,
at
least
from
an
openshift
perspective,
is
that
everything
needs
to
flow
through
cri.
D
So,
like
it's
kind
of
restrictive,
when
you
can't
play
around
with
the
metadata
on
images,
let's
say
oc,
I
mean
cri.
D
So
like
to
get
there's
a
there's,
a
bunch
of
like
layering,
of
different
things
like
proxy
and
other
stuff
that
comes
with
pulling
image.
That
is
like
a
cluster
specific
configuration
that
you
don't
get
if
you're
pulling
it
directly
into
a
pod
and
not
through
cry.
A
So
cool
yeah,
I
guess
we
can
mull
it
over
and
just
review
it
the
next
time
again
and
then
start
flashing
out
like
proper
project
ideas.
A
Are
you
referring
to
g-suck
or
something
else,
sorry,
yeah,
g-shock
and
and
cody
nest?
Let
me
check
my
notes
like
because
I
know
sandeep
also
said
something
on
on
slack.
E
E
E
So,
apart
from
that,
I
do
not
have
any
other
ideas.
If
there
is
time
I
can
still
look
into
potential
ideas,
but
apart
from
codiness
there
is.
E
B
I
think
what
we
talked
a
little
about
last
time
about
like
what
is
a
good
gsoc
project
and
like
is
this:
is
this
going
to
be
more
technical
or
is
it
going
to
be
more
political,
and
I
would
say
this,
one
is
probably
more
on
the
political
side.
I
think
I
don't
know
if
that's
a
problem.
It
feels
like
it's
a
problem,
but
I
don't
know,
but
it's
certainly
a
riskier
project
for
a
gsoc
participant
who
might
not
have
the
like
depth
of
relationships
in
the
community
to
undertake.
B
I
mean
it's
a
riskier
project
for
anyone
to
undertake,
but,
like
they
said,
it's
a
like
a
fairly
short
time
period
with
people
that
are
probably
new
to
the
projects
and
that's
a
good
thing,
but
so,
in
other
words,
we
need
to
sort
of
pick
a
topic
that
is,
I
guess,
more,
set
up
for
execution
and
more
setup
for
success.
B
I
don't
know
how
setup
for
success
this
one
is,
but
you
know
I'm
in
favor
of
of
doing
something.
I
just
don't
know.
If
this
is
this,
this,
I
would
consider
this
one
a
higher
risk
project
for
someone
to.
A
A
All
right
did
any
of
you
want
to
get
anything
else
discussed
in
this
meeting.
D
I
had
a
few
things
yeah,
so
I
guess
I
should
preface
this
by
saying
that
I've
recently
been
able
to
find
some
more
time
to
regularly
work
on
stuff
in
closer
add-ons,
so
hopefully
I'll
be
able
to
turn
things
around
a
little
bit
more
quickly
from
now
on,
but
related
were
the
things
that
I
was
working
on
earlier,
which
were
basically
taking
the
bundle
manifest
kept,
that
evan
had
got
merged
and
sort
of
applying
it
to
what
we
have
today
in
terms
of
the
keybuilder
decorative
pattern,
and
so
there
were,
there
were
two
pieces
that
came
out
of
that,
both
of
which
I'm
not
very
far
along
with
but
are
going
to
try
to
be
soon.
D
One
is
the
docs
so
like
formally
structuring
the
docs
for
cluster
add-ons
and
adding
documents
for
how
we're
going
to
package
add-ons
and
distribute
them.
There's
some
stuff
in
declarative.
Cue
builder
pattern
now,
but
it
is
not
like
official
docs.
D
The
other
side
of
it
is
sort
of
trying
to
match
what
we
have
today
with
evans
kep
and
the
long
story
short
of
it.
Is
that
sorry,
I'm
fumbling
with
words
today
the
core
question?
I
have
is,
if
evans,
sorry,
what
we
have
today
is
more
of
a
set
of
operators.
D
C
D
Yeah
so
the
way
the
bundle
is
structured,
if
I
recall
correctly,
is
that
there's
a
manifest
directory
for
a
single
thing
that
we
want
to
install,
which
is
keep
cuddleable,
and
we
can
apply
that,
whereas,
like
the
current
packaging
format,
let's
say
in
terms
of
like
the
file
system
that
the
cute
builder
declarative
pattern
consumes,
which
is
the
thing
that
like
actually
applies.
The
manifest
is
a
set
of
versions
for
an
operator.
So
sorry,
the
set
of
versions
for
an
add-on
keep
completing
the
terms.
C
I
see
yeah,
I
guess
to
me
those
would
either
be
like
different
artifact
types
like
it
be
yeah
a
bundle
with
multiple
versions
in
it
versus
a
bundle
with
a
single
version
in
it
yeah,
depending
on
what
thing
is
consuming
it
but
yeah.
I
think
that's
a
good
it's
worth
like
writing
that
out.
I
think.
D
Yeah,
I
just
wanted
to
see
if
anybody
had
some
initial
like
ideas
on
this
like
we
could.
You
know
this
could
be
like
a
composite
pattern
and
like
a
bundle,
could
be
and
add-ons
that
an
operator
supports,
or
there
could
be
separate
artifacts
where
you
know
you,
you
reference
these
individual
add-ons
from
something
that
is
meant
to
be
the
the
container
type
the
aggregate
over
all
of
them,
or
so
I
can.
I
can
like
enumerate
the
options
and
then
kind
of
pass
them
enough
for
review
later.
B
Yeah,
I
think
that'd
be
super
helpful.
I
think
the
when
I
was
reading
it.
I
wasn't.
I
thought
it
looked
like
you
could
actually
put
more
than
one
package
into
a
single
image
if
you
wanted
to-
and
I
was
also
imagining
that
the
version
would
go
into
like
the
container
or
the
image
tag.
I
guess
so.
B
We
wouldn't
necessarily
put
multiple
versions
into
one
image
which
is
sort
of
more
of
a
just
like
distribution
thing,
but
I
don't
that
was
just
my,
but
if
there
are
other
options
and
or
if
I'm
wrong
about
like
the
way
we
can
put
multiple
containers
in
there
or
multiple
packages
in
there,
then
it'd
be
great
to
see
to
explore
this.
I'm
not
even
sure
how
important
it
is
to
put
multiple
packages
in
a
single
container
like
it
might
be
that
we
can
just
use
a
convention,
so
I
think
yeah.
B
I
think,
exploring
that
and
making
sure
that
we
are
in
a
good
good
can
support
the
use
cases
we
need
today.
I
think
that'd
be
good.
D
Yeah,
I
guess
I
guess
my
this
stems
from
the
current
format
being
only
the
container
so
that
so
the
stuff
that
like
cube
layer,
better
use
today,
is
the
set
of
versions
and
not
a
single
version,
and
it
can
be
a
single
version
so
making
the
sort
of
making
the
input
this
interface.
D
It
would
be
nice
if,
like
those
two
things
kind
of
matched
so
that,
like
we
didn't,
have
to
have
a
different
input
to
operators,
that's
like
well,
if
you're
going
to
take
a
bundle,
here's
a
list
of
bundles
you're
going
to
take,
whereas
if
you're
going
to
take
this
other
packaging
format
that
we
had
previously,
you
could
do
that
too,
which
is
a
single
water
effect.
B
We
have
some
of
this
today
with
the
git
support
and
I
haven't
looked
in
detail.
I
can't
remember
in
detail
about
how
that
maps,
but
it
doesn't
necessarily
you
know
like
for
git.
I
would
very
much
imagine
that
the
versions
would
probably
go
to
tags
or
branches.
I
could
be
wrong
there,
but.
A
D
Yeah
we
could
separate
it
that
way.
I
think
as
it
since
today
from
my
reading,
it
was
just
checking
out
a
git
repository
and
in
that
git
repository
was
the
package
with
the
set
of
versions
there.
So
it's
like
no
different
than
just
getting
it
from
a
different
source,
but
got
it
okay.
B
But
we
could
also
support
tags
there
as
well
like
I.
I
think
we
need
to
find
out
what
people
how
people
want
to
use
it,
but
I
don't
think
I
don't
think
it
should
be.
B
I
don't
think
we
should
make
people.
I
don't
think
we
should
hobble
the
like
image
distribution
format,
just
because
we
happen
to
have
started
with
a
in
in
in
pod
file
system
format
right,
we
should
do
whatever
makes
whatever
makes
sense
and
is
best
for
the
image
manifest
format.