►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20200204
A
Looks
like
right
now
we
don't
have
any
new
faces
and
no
introductions
and
actions
from
last
time.
Yes,
so
we
were
able
to
rename
or
repository
from
add-on
operators
to
just
the
add-ons
that
is
done.
I
was
actually
quite
surprised
how
often
it
was
referenced
in
various
places
across
github.
That
was
a
nice
surprise
and
yes,
read
the
this
I.
Don't
discovery
draft
PR,
just
nothing
to
remember
you
we're
going
to
take
a
look
I'll
give.
B
Some
feedback
I
managed
to
take
a
look
in
the
last
hour,
so
I
have
not
put
any
food
back
on
there.
I
guess,
hey
I,
think
the
reason
I
wanted
to
take
a
look
was
because
I
know
that
there
were
lots
of
other
efforts
that
I'm
just
trying
to
figure
out
how
it
all
fits
into
it
like
it
sounds
like
oh
I,
don't
Nick,
it's
not
here
right!
B
B
We've
also
had
our
own
debates
about
like
whether
we
want,
through
surface
components,
status
on
an
aggregate
CRD
or
whether
we
consider
that
a
security
issue,
potentially
so
just
like
going
through
sort
of
the
assumptions
in
here
and
instead
of
trying
to
figure
out
why
we
aren't
doing
that.
And
but
I
will,
I
will
post
a
comment
on
there
as
nick
it's
not
here
unless
he
shows
up.
I
think.
C
He
was
planning
to
come,
but
I'm
just
in
case
he
doesn't.
We
were
also
very
surprised
that
the
sig
ups
didn't
think
this
is
very
similar
to
what
they're
trying
to
do
so.
Maybe
we
presented
it
in
the
wrong
way,
but
yeah.
It's
definitely
it's
along
those
lines.
I
think
the
main
difference
is
that
this
is
really
just
trying
to
be
an
inspection
tool
right
now,
at
least
just
giving
you
like
an
aggregate
view
of
what
the
thing
is
in
your
cluster
and
what
it
can
do.
B
A
C
Just
wanted
to
mention
that
this
is
now
a
draft
kept
in
the
enhancements
repo
instead
of
a
Google
Doc.
Okay
is
because
there
wasn't
any
didn't
seem
like
there
is
any
feedback
so
figured.
We
could
discuss
it
there
and
then
I
know
I,
see
Sean
John
joined
the
call
and
I
know
that
this
was
discussed
at
the
cou
builder
face-to-face
last
week.
So
Sean
do
you
have
any
updates
from
that
side
that
you'd
like
to
share
yeah.
D
Basically,
like
the
people,
the
folks
are
gonna,
fill
with
the
captain
and
also
comments
on
that.
They
had
some
some
initial
feedback
around
like
we
should
be.
We
should
actually
add
a
name
for
the
things
instead
of
a
saying
name
like
in
things.
We
should
actually
start
naming
stuff,
but
that
was
a
minor
feedback
other
than
that
there
was
going
to
be
more
discussion,
hopefully
on
that
PR,
okay,.
A
A
B
I'm
certainly
happy
to
be
like
a
mentor
type
or
like
whatever
the
correct
term
is
but
I
don't
know
what
project
we
would
do
and
I
guess
one
project
we
could
do
would
be.
You
know,
go
and
build
cluster
add-ons
for
a
whole
bunch
of
things
and
as
things
arise,
then
you
know
that
wouldn't
fix
those
things
in
the
right
way
right
so
like,
but
probably
I,
guess
if
it
was
just
going
in
like
packaging,
a
bunch
of
manifest
that
would
be
sort
of
a
boring
Summer
of
Code.
B
So
hopefully
some
challenges
would
arise
that
were
more
challenging
and
that
could
be.
That
could
be
a
really
great
outcome
for
someone's
like
CV
or
resume
right
that
they
like
a
package.
Half
the
thickness
that
the
world
excusing
so
I
can
totally
propose
that
and
if
anyone
else
has
any
ideas
on
things,
we
could
do
or
knows
of
any
problems
that
WOM
tackling
that
aren't
too
challenging.
E
Mean
to
me
that
sounds
like
a
road
fraught
with
challenges
and
though
it
was
really
just
more
but
I
was
thinking.
Yeah
attacking
some
of
the
add-ons
work
would
be
an
appropriate
project.
What
was
really
more
concerned
about
the
time,
commitment
that
it
would
be
you
know
on,
like
all
of
our
behalf,
to
just
go
and
make
sure
that
the
people
have
the
proper
support
so
or
more
likely
that
person
right
probably.
B
Just
that
right
is
there
a
guideline
for
how
much
time
what
sort
of
tank
we're
talking
about
I.
A
B
B
Yes,
I
assume
again
it's
not
a
30
hour
week.
Commitment
I
would
be
happy
to
mentor
someone
if
that
we
want
to
put
in
that
that,
as
a
project
obviously
like
having
other
people
also
will
help
would
be
great,
particularly
yeah,
particularly
when
it
comes
to
you
like.
If
we
decide
to
do
that,
like
some
of
the
other
add-ons
like
that,
I
might
not
be
as
familiar
with.
E
B
The
description
is
very
short
I'm
just
reading
the
existing
ones
sleeo
so
I
mean
I
can
certainly
put
together
a
paragraph
fill
out,
but
it
says
like
create
a
whole
bunch
of
new
add-ons
for
them
most
interesting
or
widely
used
communities
add-ons
and
like
we
expect
there
will
be
lots
of
challenges
that
arise
and
so
basically
work
with
existing
community
to
address
some
of
those
or
surface
and
ideally
address
some
others.
I
would.
E
So,
if
we
throw
that
in
there
right
that
it's
like
you're
you're
making
a
platform
contribution
like
there
are
artifacts
that
come
out
of
there
are
going
to
be
add-ons
but
like
right
now,
that's
not
something
that
we
would
expect.
Even
somebody
senior
in
the
kubernetes
community
to
be
able
to
pick
up
and
just
go,
do
because
there's
no
right
like
helping
create
that
path
to
add
on
creation
and
then
like
in
the
process,
will
produce
some
important
add-ons.
B
B
E
I
think
it
would
just
be
like
us
as
a
community.
You
know
like
supporting
the
project.
Okay,
good
idea,
yeah.
A
B
A
What
we
get
I'm,
just
thinking,
trying
to
think
big
here,
will
we
get
two
projects
out
of
this
part
of
from
packaging,
a
bunch
of
add-ons
just
think
of
some
of
the
I?
Don't
know
you
baby
I'm
integration,
or
you
know
other
bids
in
general
that
we
would
generally
like
to
see-
or
you
know,
testing
a
bigger
story
or
I.
Don't
know
what,
like.
E
Also
familiar
with,
like
students,
who've
gone
through
this
project
before
and
kind
of
blown
way
past
the
scope
of
their
project,
which
I
don't
think
anyone
is
going
to
you
know,
complain
about
and
like
if
some
of
these
hungry
to
go
solve
a
bunch
of
problems
and
they
have
the
skill
set
to
do
so,
along
with
some
support
and
mentorship.
And
that's
like
the
ideal
scenario,
I
think
for
everyone.
Well,
I
won't
call.
B
I
think
one
of
the
advantages
of
the
the
tasks
that
we
have
proposed
right
now
is
it's
very
elastic
right.
Someone
can
come
and
package
an
add-on
and
have
some
success
metric
or
someone
can
go
and
like
package,
every
I
don't
know
in
the
community
and
like
integrate
docker
or
ci
packaging
and
all
the
other
things
for
dreaming
of
and
to
be
built.
You
know
yeah,
so
it's.
E
B
B
B
This
one
and
see
if
I
guessed
right,
can
you
see
me
typing?
Yes,
perfect,
alright,
so
I
just
want
to
quickly
sort
of
show
how
we're
thinking
about
add-ons
in
cops-
probably
it's
all
hidden
by
the
feature
flag.
Npr's,
like
you
know,
not
not
baked
I.
Don't
people
can
see
us.
I
may
get
one
bigger,
because
I
think
that's
pretty
good
compromise.
So
we
have
a
there.
B
Are
normal
cops,
create
cluster
command,
basically
establishes
a
bunch
of
llamó
files
or
llamó
objects
or-
and
you
basically
name
your
cluster
and
you
give
it
a
zone
and
that's
all
you
need
to
do
to
incent
she
ate
or
to
template
a
cop's
cluster.
What's
new
is
we
are
adding
the
ability
to
add
additional
llamó
files
which
can
contain
essentially
arbitrary
bits
of
or
arbitrary
criminales
objects?
And
I've
previously
run
this,
and
if
I
get
it,
you
can
see
that,
like
so
a
normal
cops
cluster.
B
Is
these
two
objects
there's
a
cluster
up
to,
and
there
are
instance
group
objects
which
are
like
somebody.
Nope
goes
on
gke
or
auto-scaling
groups
on
Amazon
or
machine
deployments
in
cluster
api
and
what's
new,
is
we
have
these
this
new
add-on
section
where
we
essentially
have
arbitrary
kubernetes
objects?
And
so
you
can
see
here
that
I
have
a
node
local
DNS
or
an
instance
of
the
node
local
DNS,
CRD
and
I.
Also
for
now
have
the
CRD
for
the
node
local
DNS.
That
is
instantiated
like
there.
B
The
add-ons
is
an
add-on
object
and
the
CRD,
and
now,
basically
all
that
happens
is
when
we
do
the
normal
cups
update
just
how
we
create
the
actual
cluster
cups
will
create
the
cluster
as
normal
and
then
it
will
go
and
coop
kuddle
apply
the
additional
objects,
and
so,
in
this
case
the
CRD
gets
applied
and
then
the
local
dns
instance
of
that
city
gets
applied
and
right
now
in
a
sort
of
concept
or
group
concepts.
We
have
the
controller
for
node
local
dns,
built
into
a
hot
controller.
B
B
We
think
that
is
a
nice,
reasonable,
UX
and
definitely
creates
some
problems,
but
like
enables
us
to
avoid
putting
more
and
more
stuff
into
the
cluster
yeah
Mel.
So
I
don't
know
if
people
have
ever
seen
this,
but
I
will
quickly
show
I,
don't
know
if
any
of
them
by
default
were
there,
but
basically
in
there
in
the
cluster
object,
we
have
a
bunch
of
fields
that
are
effectively
like
descriptions
for
the
add-ons.
B
So
at
CV
clusters
is
a
good
example
where
we
have
like
the
configuration
of
Etsy
d,
and
ideally
that
would
be
for
that
so
I
better
example
is
networking
cube
net
cube
meta
is
not
very
complicated,
but
other
CNI
providers
are
much
more
complicated
and
so
like
weave
is
in
here
with
a
bunch
of
options
and
we'd
love
to
be
able
to
split
that
up
into
its
own
CR
the
instance.
So
it
would
appear
just
in
the
add-on
section
and
not
be
sort
of
lumped
in
with
the
cluster
object.
E
Thanks
Justin
I
I
liked
this
helix
as
far
as
feedback
and
heckling
goes,
I
have
feedback,
so
the
I
think.
For
me
it
makes
sense
for
the
CRD
the
operator
and
then
optionally,
like
whatever
number
of
custom
resource
instances
to
be
supplied
in
a
place.
That's
next
to
each
other
from
the
UX
standpoint,
with
the
constraint
that
you
would
want
to
be
able
to
support
a
third
party
of
add-ons
that
you
do
not
manage
so
I
think
that
that
UX
doesn't
make
sense.
E
I
also
think
that
it's
okay
to
have
some
in
controllers,
like
embedded
or
automatically
installed
by
the
project,
if
you
or
to
do
like
some
just-in-time
controller
installation
of
some
Blessed
daughter
add-ons.
That
pattern
is
similar
to
the
add-on
installer
behavior.
That
I
expect
will
behave
like
how
it
will
behave
in
coop
idiom
where
it's
like.
If
you
don't
supply
anything
Koopa
dam,
will
you
know
figure?
Oh
well,
you
should
you're.
E
That
is
a
place
that
where
we
could
look
at
how
the
add-on
installer
might
help
from
an
API
standpoint,
since
it's
basically
just
a
little
shim
of
code
that
turns
component
config
into
a
bunch
of
bundled
add-ons
being
installed,
you
know
customizer
yeah,
that's
that
looks
really
cool.
It
looks
like
a
nice
UX
and
breaking
that
out
from
the
cluster.
B
Thanks
yeah
I,
think
I,
think
you're
I
think
you're,
probably
right
in
that
it
would
be
good
to
have
it
be
very
explicit,
with
a
controller
for
in
this
case
node
local
DNS
right
there,
but
I
yeah.
As
you
point
out
today,
we
have
those
objects
individually
split
out,
so
it's
okay
for
the
CR
D,
which
is
only
one
object,
but
for
a
controller
which
is
a
set
of
I've,
maybe
objects
like
it
could
be
a
little
hard
to
keep
track
of.
So
we
would
like
some
way
to
undo
this
and
I
y'all.
E
I
think
there's
power
here
in
the
idea
of
like
actually
bundling
a
package
of
multiple
artifacts
or
having
a
single
artifact
with
multiple
manifests
in
it.
That
is
called
something
and
that's
what
the
add-on
installers
goal
is
like.
What's
the
minimal
way
that
we
can
share
some
packages
right
and
then
with
Bevins
KPG
work
like
that,
could
be
a
container
image,
it
could
be
to
get
repo.
C
Yeah,
that's
exactly
what's
gonna
bring
up
this
this
problem
of
like
calling
a
set
of
manifests
by
a
name.
That's
what
that
manifest
bundle
kept
is
about
if
we
could
figure
out
so
like
if
we
could
figure
out
a
good
way
to
say,
like
here's,
how
you
do
play
manifests
or
here's
how
you
do
customized
manifests
or
here's
how
you
do
add
on
manifests
like
if
it's,
if
it's
unique
enough,
that
it
needs
to
be
its
own
sort
of
kind
within
that
framework.
E
Hi
heartfully
agree:
there
I
think
we
we
have
a
lot
of
amorphous
ways
of
like
shipping
around
our
blobs
outside
of
the
cluster,
and
a
little
bit
of
standardization
would
not
hurt
the
ecosystem,
and
this
provides
a
useful
purpose
vehicle
to
actually
share
clusters
of
these
things
or
bundles.
Of
these
things,.
C
Maybe
it's
worth
walking
through
the
both
Cube
ATM
and
cops
as
like
potential
applications
to
just
say
like
if
we
use
them
for
these
two
applications.
What
would
it
look
like
and
how
does
it
simplify
just
as
like
a
strawman
for
going
forward
with
it
in
some
way,
I
did
have
a
question.
Justin
I
mean
to
complete
derail.
C
B
Yes,
it's
calling
add-ons
anything
else
like
so
basically
like.
Today
we
have
clusters,
and
instance,
groups
are
like
built-in
kinds,
and
now
we
basically
had
it
on
unstructured
bucket
and
anything
else
is
called
an
add-on.
But
yes,
we
could
certainly
like
when
you
were
talking
I
was
saying:
oh
maybe
we
should
spit
out
like
an
eye
whether
you
like
a
manifests
and
objects
or
something
might
be
a
better
term.
Let
me
have
like
four
types
but
or
we
could
just
yes
like
somehow,
but
that
is
that
is
what
they
are
like.
C
Interesting,
it's
definitely
in
the
same
vein
of
like
problems
that
we
were
thinking
about
with
that
add
on
discovery
operator
where
it
is
kind
of
like
okay,
now,
you've
applied
manifests
if
I
have
a
cluster
already
and
I
want
to
find
out
what
the
add-on
is.
What
was
installed,
how
do
I
tell
because
I've
just
got
like
a
jumble
of
ceará
to
use
here?
Yes,.
B
These
are
effectively
a
set
of
files.
Today
they
are
living
on
s3
right
in
this
case
they're
living
on.
Actually,
it's
either
ask
your
GCS
camera
and
then,
but
like
a
lot
of
people
put
those
in
get,
and
then
there
is
a
separate
state
that
is
the
kubernetes
state
and
the
state
which
cops
chose.
Is
the
file
state,
whether
it's
an
s3
or
GCS,
I
gotcha.
C
B
Much
so
yes,
I'd,
like
the
particularly
for
the
case
of
add-ons
and
in
future
for
the
case
of
cluster
an
instance
groups.
We
will
be
applying
those
directly
to
the
cluster,
so
there
will
be.
There
will
in
future,
be
a
one-to-one
mapping,
but
today
particular
clusters
and
this
groups
there's
not
other
miscellaneous
bucket.
There
will
be
I,
see.
C
B
And
we
are
moving
like
what
I
was
sort
of
describing
is
like,
as
we
adopt
cluster
API,
we
will
increasingly
have
a
one-to-one
mapping,
and
so
it's
not
entirely
clear
happens
to
the
cops
CLI
told
at
that
point
like.
Should
it
should
it
go
and
ask
the
cluster
or
should
it
go
and
ask
us
three
and
what
if
it's
gonna,
go
ask
the
cluster?
What's
the
point
of
the
gulps
he
like
tokus,
why
isn't
it
just
coop
cuddle
type
thing
so.
E
This
is
a
really
interesting
problem
space
that
I
think
I'm
like
starting
to
understand
more
completely,
which
is
like
how
does
the
bootstrap
you
know
or
outside
cluster
configuration
like
ultimately
become
introspected
like
inside
the
cluster?
Is
that
appropriate
is
that
secure
and
how
does
that
help
people?
And
then
what
is
the
appropriate
mechanic
to
do
that,
because
yeah
I
mean
we're
doing
effectively
the
same
thing
in
the
coop
idiom
proof
of
concept
where,
like
you
have
the
component,
the
add-on
installer
component
config
and
that's
provided
to
Kupa
DM.
E
E
B
E
I'm
thinking,
if
we
can
append
to
each
other's
api's,
we
can
end
up
with
the
same
API
right
right.
That
then
just
has
like
optional
things
in
there
I
I
wouldn't
be
against.
You
know,
like
Covidien,
adding
a
CRD
to
the
cluster
like
to
have
a
formal
like
mutable
ependymal
portion
of
the
add-ons
installation
API
right.
E
B
C
Yeah
this
is
I
mean
we
have
a
similar
distinction
within
operate,
your
framework
stuff,
where
we
have
these
bundles
of
things
that
we
talked
about
before
they
applied
to
the
cluster.
But
then
once
they're
on
the
cluster,
there's
a
specific
API
type
that
we
use
for
all
of
our
status
aggregation
and
that
sort
of
thing
and
it's
much
much
less
generic
than
the
stuff
we've
been
talking
about
here.
But
we
have
the
same
split
and
it
seems
pretty
important
to
make
the
distinction
and.
E
C
E
Well,
sweet
sweet
demos,
good
progress,
great
conversation,
just
like
adding
some
meta
filter
filler
in
here
until
we
decide
to
move
on
with
the
final
agenda
topic
that
CR
DS
and
brake
controllers.
So
there
was
a
list
of
open
questions,
and
then
we
talked
about
a
bunch
of
stuff
didn't
like
that.
The
last
thing,
I
guess
is
I
had
to
think
to
share
em
the
agenda
when
we
were
on
this
call.