►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20210105
A
B
Very
nice,
it's
dinner
time
for
daniel.
I
think
we
have
all
familiar
faces
here.
We
still
might
have
quite
a
few
people,
trickling
in
since
folks,
are
settling
back
into
the
routine
from
the
holidays.
It's
good
to
see
everybody
and
yeah
did.
Does
anyone
want
to
take
a
chance
to
add
something
to
the
agenda?
I
know
some
of
us
were
hacking
on
fun
projects
over
the
break,
or
you
know
getting
into
some
of
the
open
issues
that
we
have
currently
cool
thanks.
B
Nick
I'll
give
you
a
moment
to
add
to
the
agenda
and
does
any
anybody
have
anything
in
particular
that
they
wanted
to
just
share
about
their
personal
life?
B
Well,
I
see
nick's
adding
to
the
agenda.
We
had
quite
a
quite
a
cool
2020
lots
of
active
work,
even
just
recently
as
a
refresher
for
folks,
so
we
did
get
that
manifest
bundle
kept
merged
in
justin
was
moving
forward
with
a
lot
of
work
in
cops
to
align
with
what
we
have
with
add-ons.
B
B
If
people
are
looking
at
projects
that
they're
taking
on
let's
go
ahead-
and
you
know
take
some
time
to
talk
through
things
yeah,
so
everyone
here
mostly
knows
each
other
if
you're
joining
us
from
youtube
feel
free
to
try
and
ping
us
in
our
slack
channel
and
we're
or
make
it
to
this
time
block
this.
This
meeting
is
totally
open
for
everyone
to
come
with
their
ideas.
B
I
wanted
to
share
something
pretty
cool
that
I
mentioned
last
year
that
sunny
the
co-maintainer
of
ignite.
Our
micro,
vm
manager
has
been
working
on
a
lot
of
operator
things
and,
while
sunny
hasn't
been
coming
to
the
cluster
add-ons,
meaning
he's
been
looking
at
our
code
and
getting
more
familiar
with
kind
of
the
problem
set
that
faces.
People
who
are
building
operators
and
we've
talked
a
lot
about
these
kinds
of
issues
before
I
am
not
up
to
date
with
anything.
B
That's
been
happening
inside
of
operator
sdk
to
maybe
make
the
programming
model
more
safe,
but
I
think
many
of
us
are
familiar
with
just
how
treacherous
like
building
proper
life
cycle
and
reconciliation
inside
of
a
kubernetes
controller
can
be
since
it's
you
know,
these
things
are
designed
to
build
platforms
that
take
responsibilities,
take
ownership
of
responsibilities
that
are
normally
watched
over
very
carefully
by
human
beings.
B
So,
with
operator
toolkit
sonny's
been
messing
around
with
kind
of
adding
a
little
bit
more
structure,
and
so
I
am
sharing
my
screen.
I
think
it's
not
highlighting
it
like
it
usually
is.
Can
you
see
my
browser.
B
B
We've
seen
these
patterns
and
other
kind
of
framework
approaches
with
different
design
decisions
like
meta
controller
and
things
like
that
and
composite
just
has
a
reconcile
that
you
can
wrap
you
know,
so
you
can
implement
a
composite
reconciler
and
then
take
advantage
of
this
method,
and
so
this
reconcile
has
things
that
are
built
in
for
you.
It's
got
pre.
It's
got
hooks
that
you
can
kind
of
take
advantage
of,
so
you
can
implement
a
validation
you
can
implement
the
defaulting
you
can
just.
B
You
can
enable
this
kind
of
initialization
phase
for
your
object
if
things
need
to
be
set
up,
and
so
that
ties
into
this
status,
patching
logic
which
gets
deferred
and
then
there's
a
deep
copy,
so
it
allows
you
to
kind
of
it
saves
this
clone.
This
is
going
to
be
just
renamed,
but
it's
basically
the
older
version
of
what
was
fired
in
the
reconcile
loop
before
we
start
changing
the
instance,
and
so
then
the
because
of
the
way
that
the
reconciles
put
together
you're.
B
B
I'm
kind
of
forgetting
how
to
navigate
this
code,
even
though
I
was
just
talking
about
it
yesterday.
Sorry,
I'm
blanking,
but
yeah
there's
an
interface
where
you
can.
You
know,
have
the
validation
and
defaulting
hook.
You
can,
you
know,
have
the
update
status
method
and.
B
Wow,
I
have
not
woken
up
today.
Yet
and
again
you
can
like
implant
on
this
controller
object
right
here
you
can
set
if
the
the
cleanup
strategy,
so
you
can
enable
you
know
if
you
want
finalizers
on
your
object
and
that
kind
of
thing,
and
then
it
does
like
the
time
stamp
comparison
and
all
of
that
stuff
that
you
need
to
kind
of
know
about
kubernetes
machinery
in
order
to
implement
finalizers
properly.
So
now
you
can
just
have
the
cleanup
hook.
B
You
just
implement
your
own
cleanup
in
this
handler
and
then
you
don't
have
to
actually
know
like
how
to
get
all
this
life
cycle
correct
and
that's
really
cool,
because
the
controller
is
tested
thoroughly.
So
all
of
these
life
cycle
methods
are
usually
something
that
you
would
need
to
test.
You're
like
okay.
Well,
does
the
object
initialize
properly?
Does
it
you
know
finalize
yeah
when
I
delete
it
does
it,
you
know,
are
the
things
that
are
owned
by
it
also
delete
it.
B
You
would
have
to
write
these
tests
if
you
were
writing
your
own
controller
project,
but
now
that
there's
this
kind
of
different
programming
model
being
introduced,
you
can
kind
of
inherit
the
tested,
behavior
and
stop
worrying
about
whether
or
not
you've
implemented
your
life
cycle
properly.
One
yeah,
I'm
remembering
what
I
was
trying
to
say
now.
There
is
a
operator
class
that
actually
implements
a
dag,
and
so
you
can
create
operands.
B
You
implement
this
operand
interface
and
you
can
like
just
make
one
of
these.
You
know
put
in
all
the
things
that
you
need
to
actually
interact
with
kubernetes
to
create
child
objects,
and
things
like
that.
If
you
want
to
have
a
copy
of
the
instance,
you
can
update
it
and
change
the
status
and
things
like
that,
and
then
the
status
update
gets
deferred
and
these
operands
can
be
formed
inside
of
a
dag.
You
know
so,
then
you
can
put
a
dag
together
when
you
make
your
actual
controller.
B
This
was
yeah
just
when
the
controller
is
operated.
It
just
ensures
that
we,
it
just
runs
the
insurer
method
and
then
the
insurer
method
creates
a
config
map.
That's
owned.
You
know
by
the
thing
so
like
it's,
it's
cool,
go
check
it
out.
The
reason
that
this
is
pertinent
is
because,
if
we're
going
to
be
encouraging
people
to
be
building
add-ons,
I
think
that
sonny's
really
identified
a
lack
of
something
like
an
express.
B
You
know
that
makes
common
things
that
need
to
be
done
for
all
http
server
type
projects
when
you're
building
an
application,
things
like
authentication
and,
like
request
form
injection
detection
and
safety
tokens
and
all
that
kind
of
stuff.
B
You
know
there's
this
whole
other
class
of
problems
that
you
get
regarding
life
cycle
and
machinery
inside
of
kubernetes
that
are
just
beyond
generating
types
and
setting
up
watches,
and
so
I
think
that
there's
space
and
if
we
know
of
other
projects
that
are
trying
to
make
it
safer
and
easier
to
build
an
operator
or
a
controller
that
functions
properly,
then
certainly
you
know
we
should
talk
about
those,
but
I'm
not
aware
of
other
work
that
is
trying
to
make
this
safer
at
this
abstraction
level,
with
using
coup
builder
and
controller
runtime
and
the
kinds
of
things
there
are
additional
packages
in
here
that
have
some
overlap,
and
also
some
shared
code
with
cool
builder
declarative
pattern
as
well
wow.
B
So
in
the
there's,
this
declarative
directory
that
has
like
a
customized
loader,
these
two
are
kind
of
overlapping
independent
from
what
we
did
with
our
string
maps
inside
of
ku
builder
declare
pattern.
It's
just
a
different
approach:
that's
using
the
in-memory
file
system
and
kml
libraries.
B
This
transform
thing
is
kind
of
related
to
that,
but
these
things
are
actually
used
inside
of
the
example
controller
and
then
the
applier
is
from
who
builder
declarative
pattern.
Libraries
so
take
a
look
around
some
of
this
code.
I
think
there's
some
useful
bits.
B
I
haven't
read
much
of
rancher's
wrangler,
but
I
don't
know
if
there's
any
of
this
kind
of
structure
yeah
actually
having
a
pre-computed
reconcile
that
lets.
You,
opt-in
to
things
like
an
initialization
phase
like.
B
Deferred
status
updates
that
are
done
properly
and
having
a
gag
that
can
do
re-cues
and
things
like
that
is
not
something
that
I've
seen
somewhere
else
and
this
stuff
is
very
formational,
but
we
could
probably
get
sunny
to
come
and
do
a
walkthrough
or
something
if
people
are
more
interested
and
yeah.
That
was
that's.
Basically,
all
that
did
people
have
like
questions
or
comments.
I
know
I
just
kind
of
rant
at
them
about
this.
C
B
Yeah,
I
I
kept
getting
more
and
more
excited,
as
sonny
talked
about
getting
serious
about
doing
this
and
then
like,
as
I've
seen
it
materialize
like
I'm
a
little
bit
in
disbelief,
because
I've
spent
so
much
of
development
time.
Just
suffering,
writing
controllers
and
not
understanding.
When
I've
introduced
a
bug-
and
I
think
like.
I
could
definitely
see
myself
using
this
and
forgetting
about
common
things
that
I've
had
to
previously
be
concerned
with.
B
Cool
well,
I
know.
C
Before
before
we
move
move
topics,
I
know
this.
This
is
sort
of
the
thing
that
I
know
the
operator
sdk
team
has
been
thinking
about
and
is
eventually
planning
to
work
on
it.
It's
also
something
that
they
had
considered
working
on
a
while
ago,
but
ended
up
way
more,
focusing
on
sort
of
the
scaffolding
aspects
of
writing
operators
and
conventions
there.
So
I
mean
I
don't
know
if
that's
something
that
you
know
sonny
would
be
interested
in,
but
I
know
there's
interest
in
this
type
of
thing
from
the
operator
framework.
B
B
As
well
in
operator
framework
with
things
that
are
much
higher
level
than
than
this
right
like
this,
is
we
kind
of
have
a
few
patterns
and
then
like
a
safe,
dag
and
a
couple
of
life
cycle
hooks,
but
in
operator
framework
I
know
that
they
have
maybe
something
similar,
but
it
like
ties
in
with
antsy.
B
You
know
where
you
can
kind
of
plug
in
your
own
ansible
stuff
and
it
gets
run
by
me
by
the
operator.
So
that's
not
go
it's
not
just
trying
to
make.
You
know
the
the
most
basic
thing
you
could
do
simpler,
but
it
is
similar
in
concept,
and
I
know
that
you
know
they
have
like
the
ability
to
kind
of
decorate
a
helm
chart
with
extra
logic.
So
that's
pretty
cool
yeah.
B
I
should
mention
that
who,
who
do
you
think
would
be
what's
the
best
avenue
you
know
for
sonny
to
get
in
touch
with
the
right
folks?
I
I
have
never
been
to
an
operator
framework
meeting
per
se.
C
So
sdk
has
weekly
meetings
that
they
do
on
the
cncf
calendar
and
there's
the
kubernetes
operator
sdk
slack
channel
as
well,
which
is
a
good
place.
But
if
all
all
failing,
if
you
switch
out
to
me,
I
can
make
sure
we
get
in
touch
with
the
right
people.
If
none
of
those
things
work
out.
D
This
might
be
getting
too
into
the
weeds,
with
the
specific
like
implementation
of
things,
but
was
the
dag
there.
That
was
specifically
for
sort
of
triggering
re-cues
of
different
objects.
That
need
to
be
aware
of
changes
to
other
objects.
Is
that
correct.
B
The
the
dag
is
so
that
you
can
implement
your
reconcile
so
typically,
when
you're
doing
a
reconcile
you're
like
hey,
I
want
to
make
sure
that
this
thing
is
done
before
this
dependent
thing
next
needs
to
get
finished
and
the
cool
thing
about
doing
that
in
a
dag
is
there
is
a
class
of
bug
in
reconcile
logic
where,
if
your
reconcile
runs
without
error,
it's
awesome.
B
So
if
you
change
the
programming
model
of
how
you
do
a
reconcile,
then
you
can
pick
an
execution
strategy
and
you
can
write
tests
to
make
sure
that
those
execution
strategies
pass
so
like.
If
you
there's
a
common
or
it's
pretty
early
known
pattern,
they
use
it
inside
of
scd
operator
where
any
time
they
actually
make
an
update
to
the
object
and
the
related
things
that
you're
keeping
in
sync,
which
for
etcd
there's
a
lot,
then
what
they
do
is
they
re-queue?
B
Because
they
are
trying
to
run
through
their
dag
from
the
top
every
single
time
they
modify
the
system
and
it's
just
a
programming
convention
that
they
have
within
the
functions
that
make
up
the
reconcile.
B
But
if
you
actually
kind
of
allow
people
to
do
that
without
having
to
think
about
it,
because
that's
just
the
way
that
it
works,
then
enabling
that
behavior
like.
If
you
want
to
quick
reconcile,
you
can
turn
on
a
flag
for
it.
You
know,
but
then,
when
you're
developing,
you
can
ensure
that
everything
is
functioning
properly
and
inject
failure
and
all
kinds
of
stuff
in
between
dependencies.
B
So
it
really
like
cool
potential
to
make
sure
that
your
reconcile
is
very
robust
and
is
not
going
to
like
fail
on
you.
D
Okay,
I'll
have
to
give
this
a
deeper
read.
I
must
have
misinterpreted
what
you
were
saying
earlier.
B
The
the
cross
object
thing
was
just
about
it.
It
relates
to
how
to
use
the
dag
and
the
framework
to
do
that.
Composite
pattern
where
you
have
a
child
object
or
multiple
child
objects,
and
that
the
dag
is
useful
for
that
right.
But
that's
that's
part
of
the
reconcile.
B
B
Yeah
sweet
well
nick,
I
feel
free
to
to
take
the
floor.
I
think
we've
talked
enough
about
experimental
programming
improvements,
so
yeah
yeah.
D
I'm
excited
to
hear
what
you
want
to
talk
about
here.
Yeah,
I
mean
it's
funny.
You
guys
are
mentioning
this
because
I
remember
evan
and
I,
where
went
through
this
whole
thing,
where
we
were
talking
about
like
hierarchical
state
machines
and
stuff
way
back
yeah,
and
it
didn't
turn
out
too
great,
but
but
this
seems
pretty
promising.
D
So
I
digress.
Basically,
at
the
beginning
of
december
I
had
signed
on
here
to
kind
of
implement
the
bundle
spec
in
that
cap
for
manifest.
For
those
who
don't
remember,
it's
just
a
basically
a
way
to
store,
manifested
metadata
about
an
add-on
in
a
container
image.
D
And
one
of
the
primary
questions
that
I
had
as
I
was
going
through,
this
is
where
to
document
the
usage
and
the
generation
of
these
things,
because
I've
seen
that
there
are
quite
a
few
other
remote
sources
like
git
and
I
think
http
that
aren't
documented
today
within
the
cluster
add-ons
repository.
B
I
think
that
you
would
certainly
be
doing
the
most
formal
work
for
what
these
sources
should
look
like,
so
where
those
docs
should
live.
Yeah,
let's
justin,
do
you
have
a
strong
opinion
about
this
at
all.
B
Yeah
I
mean
I
would
totally
be
cool
to
just
start
putting
the
docs
into
the
repo,
and
then
I
mean
do
we
I'm
not
sure
about
hosting.
If
we
would
like
those
to
be
like
web
accessible
outside
of.
B
Github,
certainly
this
something
like
a
spec,
you
know,
is
very
appropriate
inside
of
a
markdown
file
inside
the
repo.
D
Oh
yeah
yeah.
I
I
totally
agree
it's
just
like
the
organization
of
where,
to
put
it,
there
wasn't
a
lot
to
go
with
based
on
what
exists
today.
So
I
just
wanted
to
see
if
people
had
a.
B
Preference,
I
think
that
this
is
one
of
the.
This
is
one
of
the
first
things
that
we've
done
that's
more
of
a
spec
and
less
of
like
an
experimental
project.
I
I
think
we've
talked
with
plenty
of
folks
and
gone
through
the
cap
process
as
well,
and
this
is
like
something
that
everyone
agrees
like.
We
want
to
kind
of
get
a
good
standard
on
so
yeah.
Getting
getting
some
central
documentation
and
an
official
place
inside
of
under
the
cluster
add-ons
control
would
be
appropriate.
B
When
I
did
that
other
add-ons
custom
resource,
you
know,
like
we
kind
of
we
made
a
library,
and
there
was
like
you
know
that
the
api
documentation
was
kind
of
the
thing
and
then
kubler
declarative
pattern
has
some
like
api.
B
You
know
conventions
and
the
code
is
kind
of
that
documentation,
so
pretty
minimal
in
terms
of
specification
right,
that's
just
where
those
things
live
and
how
the
git
and
the
http
stuff
was
supposed
to
work.
You
know
was
really
quite
experimental,
but
the
the
bundle
stuff
can
go
into.
I
don't
know,
should
we
just
have
a
docs
folder?
Should
we
have
a
bundle
folder
inside
of
cluster
add-on.
D
The
critical
thing
here
for
me
is
that,
like
the
thing
that
actually
implements
the
ability
to
use
both
the
local
file
system,
git
http,
all
that
lives
in
the
cubillar
declarative
pattern
of
which
has
its
own,
you
know
I
think
it
was
like
the
the
initial
readme.
It
looks
like
kind
of
walks
through
how
to
use
it.
So
should
it
live
there
or
should
it
live
in
the
cluster
add-ons
repository?
B
E
Yeah,
as
I
said,
I
feel
like
the
there
is
an
implementation
incubator
declarative
pattern,
but
there
is
no
spec
document
for
it.
E
Currently,
it
sounds
like
there
should
be
one,
but
for
what
we've
implemented
in
a
cable
declarative
pattern
and
then
that
same
spec
could
be
implemented
in
other
tooling,
and
so
I
think
that
that
like
you're
going
backwards
as
it
were-
or
I
mean
you're
going
the
right
way
around
but
like
so
from
that
sense,
like
put
it
into
put
the
spec
docs
into
cluster
add-ons
and
then,
if
you
want
to
do
an
implementation,
people
declare
the
pattern.
That'd
be
great,
but
there
can
also
be
other
implementations.
So.
B
Yeah
I
mean
I'm
almost
positive
that
if
there
is
a
bundle
spec,
you
know
that
is
related
to
a
cap
about
how
to
get
manifest
out
of
an
image
at
some
point,
we're
going
to
implement
that
in
the
new
flux
controllers,
so
yeah.
That
would
be
definitely
good
and
then
other
projects
like
tekton,
you
know,
would
probably
be
very
interested
in
you
know
being
able
to
interface
with
that
from
a
ci
perspective,
you
that's
not
even
a
cncf
project,
so
they
probably
want
some
place
for
central
spec.
D
Okay,
so
that
sounds
super
reasonable.
I
can
sort
of
play
with
it
and
throw
stuff
at
the
wall
and
see
what
sticks
maybe
have
something
out,
at
least
before
the
next
one
of
these
meetings.
So
that's
that's
all
I
have
to
say
about
this
particular
topic.
I
think
I
have
two
more
here.
B
Yeah,
I
think
maybe
some
my
other
reaction
would
be
like
we've
been
mentioning
that
there
are
some
things
inside
of
to
build
a
declarative
pattern,
so
I'm
sure,
like,
as
you
want
to
work
on
the
bundle
stuff
in
particular
for
oci,
manifests
like
maybe
you
need
to
build
tooling
outside
of
google
declarative
pattern,
then
we
can
vendor
that
in
or
or
imported
and
then,
if
we
need
to
fix
stuff
so
that
the
spec
makes
more
sense,
you
know
we
could
probably
change
the
way
that
crew
builder
declare
pattern
works,
so
should
not
use
that
as
a
sole
authority.
D
So
you're
you're
already
I'm
just
you're
already
talking
about
the
second
point
that
I
put
down
here.
Oh
just
so,
okay.
B
D
Yeah,
okay
cool,
so
I
think
our
heads
are
at
the
same
place,
so
the
the
actual,
like
simplest
way
to
do
this,
based
on
the
way
the
spec
exists.
Where
the
I
guess,
the
declarative
pattern.
Channel
spec
exists,
is
to
store
the
like
directory
structure
in
the
root
and
the
spec
for
storing
things
in
docker
v22
manifest,
which
is
the
bundle
kept
as
it
exists
today.
Not
oci.
D
Keep
in
mind
is
slightly
different
and
is
a
set
of
sort
of
flat
directories
with
some
other
icing
on
top
now
the
simplest
and
most
straightforward
thing
to
do
obviously
is
to
just
put
the
just
put
the
original
file
system
layout
in
the
root
of
an
image
and
then
unpack
that
as
a
remote
source
with
cubicle
or
clarifact
add-on.
D
B
I'm
I'm
all,
for
you
know
doing
the
simple
thing
with
like
if
you
would
like
to
get
the
most
minimal
amount
of
changes
like
if
you
want
to
work
directly
on
the
docker
specific
kind
of
image,
with
the
workarounds
and
trade-offs
that
were
made
inside
of
the
kep
design
to
make
that
work
with,
like
the
normal
file
system.
A
B
Like
I
think,
that's
a
totally
acceptable
approach,
we
don't
have
to
have
like
one
spec
necessarily.
B
I
think
there's
still
evolving
registry
support
for
those
oci
like
meta
different,
like
meta
tags,.
B
That
sounds
reasonable.
Thank
you
yeah.
I
I
there
was
kind
of
like
multiple
things
going
on.
I
think.
The
other
part
that
I
heard
you
asking
about
there
was
how
should
the
crew
builder
declarative
pattern
stuff
behave
with
regard
to
unpacking
the.
B
Sorry
I
had
to
decline,
call
with
regard
to
unpacking
the
bundle
and
yeah.
I
would
say
you
know
that
that
behavior
doesn't
exist
right
now,
so
we
might
as
well
just
make
it
behave
in
whatever
the
first
spec
looks
like
and
if
we
need
a
separate
spec
that,
like
says
hey.
This
is
how
we
imagine
you
know
this
could
work
in.
You
know
a
perfect
world
where
support
for
oci
is
mature.
B
That's
something
that
we
could
work
on
for
like
a
v2
kind
of
thing,
but
I
imagine
that
I
would
be
down
the
road
some
unless
other
people
have
a
different
view
of
container
registries.
I
haven't
like
kept
up
with
the
harvard
project
and
where
quay
is
at
with
their
public
offerings
and
github
container
registries
support
for
oci
blogs.
B
B
D
B
B
What
do
I
implement?
Okay,
yeah?
So
that's.
That's.
Definitely
a
concern
for
sure
all
right,
yeah,
the
other
people
feel
free
to
chime
in.
If
you
have
opinions
on
how
this
stuff
should
work,
because
it's
definitely
I
mean
you
kind
of
have
to
build
the
world
here.
B
It's
great
because
you
know
with
with
kind
of
the
olm
like
ecosystem.
At
least
there
is
some
prior
art
and
how
how
this
stuff
can
function.
So
that's
cool.
B
Sweet
well
nick
props
to
you
for
for
taking
this
on.
It's
definitely
a
significant
task
and
whatever
we
can
do
to
actually
get
in
there
and
help
like
I'm
sure,
the
some
of
the
initial
stuff
will
just
be
like
ripping
this
back
apart,
right
and
and
actually
trying
to
come
up
with
something
that
makes
sense
yeah.
But
I
feel
like
that.
A
lot
of
that
has
been
done
with
the
cap.
You
know
so
any
other
technical
bits
and
stuff.
B
Like
you
know,
we
we
have
people
here
to
help
with
any
technical
implementation
bits
as
well.
You
wanted
to
talk
on
this
next
bit
about
like
what
it
means
to
like
parameterize
the
manifests.
D
Yeah
so
as
I
was
like
taking
a
closer
look
at
a
lot
of
what
cube
builder
declared
pattern
was
doing.
It
kind
of
strikes
me
that,
like
the
thing
that
you
get
with
the
file
system,
is
that
a
method
of
keeping
track
of
things
next
to
the
the
binary
of
the
add-on
operator
itself?
D
Is
that
you're
basically
tying
a
set
of
versions
of
an
operator
to
sorry
a
set
of
versions
of
an
add-on
to
an
operator
which
seems
like
a
completely
necessary
thing
to
do,
and
when
you
allow
that,
when
you
parameterize
that
and
make
it,
so
you
can
swap
it
out
at
runtime
the
add-ons
that
an
operator
is
managing
it's
sort
of
removes
the
meaning
or
like.
I
can't
really
reason
about
sorry.
D
An
alarm
can't
really
reason
about
how
an
operator
is
supposed
to
know
whether
this
add-on
image
that
it's
pulling
down
and
unpacking
actually
meets
the
criteria
that
it
expects
or
that
it
knows
about
so,
like
you
know,
I
could,
for
example,
I
can
have
an
ncd
operator
and
I
could
give
it
prometheus
add-on.
D
Let's
say
if
that
was
a
cluster
extension.
Prometheus
add-on
bundle,
images
right.
So
the
meaning
is
kind
of
lost
there
like
it
seems
to
me
that
there's
you
know
a
reason
for
tight
coupling
between
an
operator
and
a
set
of
add-ons
versions
and
being
able
to
swap
that
out
doesn't
seem
to
make
a
lot
of
sense.
B
I
think
that
there
is
potential
for
people
to
extend
the
the
fact
that
these
things
are
modular.
A
B
B
Their
add-on
operator
uses
a
bundle.
I
can
push
their
bundle
to
my
internal
registry.
I
know
that
it's
signed
by
them
and
I
can
see
what's
inside
it,
I
can
inspect.
You
know
in
general
what
they
intend
to
install
to
my
cluster
and
then
you
know
like
I
can
decide
to
use
their
operators
and
the
operator
doesn't
have
to
bundle
all
of
that
in,
but
you
could
potentially
continue
using
it
with
the
newer
bundle
right,
so
that
helps
with
maintenance.
B
You
know
if
you're
just
trying
to
ship
manifest
changes
as
the
vendor,
you
know
or
the
you
know
the
maintainer,
then
you
can
tell
them
hey.
Can
you
just
update
the
channel?
You
know
the
operator
can
still
work
with
it
and
if
I,
you
know,
find
a
bug
and
need
to
hotfix
something
I
don't
have
to
build
their
operator,
I
don't
have
to
modify
their
code.
I
can
you
know,
change
the
node
selector.
B
B
So
it's
that
there's
already
this
use
case
of
like
here.
You
see
the
benefit
from
the
maintainer.
You
see
the
benefit
of
like
the
visibility.
Now
I
can
see
the
manifest
inside.
You
see
the
benefit
of
hosting
right,
so
there
isn't
a
mystery.
Unlike
how
do
I
get
this
source?
It's
like.
I
have
a
registry.
In
my
you
know,
air
adapt
environment
that
I
can
use
and
then
there's
the
ability
for
the
user
to
potentially
extend
it
because
the
abstraction's
not
leaked.
You
know
the.
B
I
don't
have
to
modify
the
bin
data
of
some.
You
know
binary
in
some
go
binary.
So
does
that
now
the
question
of
like
how
does
the
operator
know
that
you're
not
giving
it?
The
wrong
package
that
probably
has
to
do
with
the
metadata
portion
of
the
spec,
because
yeah
like
and
a
bundle
you
know,
could
be
in
any
number
of
registries
of
any
number
of
tags.
B
Like
maybe
the
name
of
the
image
is
not
super
related
to
what
the
name
of
the
package
that's
actually
inside,
bundled
inside
is,
or
maybe
it
is
that
has
to
be
specified,
but
the
tag
you
know
is
probably
something
that
needs
to
be
within
a
certain
number
of
constraints
related
to
the
actual
version
of
the
thing
and
but
the
registry
that
it's
hosted
at
you
know
that
could
probably
be
anywhere.
I
don't
know
I'm
just
guessing.
B
You
know
that
the
metadata
of
how
does
that
thing
know
that
it's
actually
useful
or
that
it's
what
it's
intended
is
part
of
the
spec.
D
D
Content
and
providing
ways
to
sort
of
overlay
new
content
on
a
bundle
while
keeping
the
you
know
different
layers
of
it
signed
and
secured.
I
think
it's
going
to
be
really
hard
to
ensure
that
an
operator
is
always
sorry.
An
operator
will
be
working
with
the
bundles
that
you
give
it.
D
E
On,
if
I
meant
we
do
have
one,
we
do
have
one
mechanism
which
we
know
about
that
actually
satoshi,
I
think
added,
which
is.
We
know
that
there
will
come
a
time
when
you
want
to
add
a
new
like
variable
or
exp
or
like
a
placeholder,
and
you
need
a
newer
version
of
the
operator
to
support
that
package.
E
That
is
not
a
problem
if
it's
all
on
the
local
image
right
because,
like
you
they're
distributed
together,
but
it
is
a
problem
with
git
or
https
distribution
and
presumably
with
docker
distribution.
I
believe
the
mechanism
that
was
added
by
samtoshi
is
that
a
manifest
can
declare
a
minimum
version
of
the
operator.
E
It
is
only
like
it's
fairly
restricted,
like
it's
only
a
december
version,
so
it
doesn't
protect
against
like
cross
packages,
but
it
does.
It
does
at
least
address
that
issue.
We
could
certainly
extend
extend
it
to
prevent,
like
mistakenly,
like
accidentally,
crossing
the
streams
right,
so
you
could
say
like
expected
operator
key
or
explicit
operator
id
must
be
like
ncd
manager
and
not
prometheus
manager.
E
It
wouldn't
be
secure.
It
would
just
stop
mistakes
that
might
be
useful.
B
E
B
Could
go
beyond
that?
I
mean
if
we
agree
that
bundles
it.
You
know
it's
like
every
kind
of
additional
metadata
that
we
like
push
on
to
folks
who
are
authoring
bundles
like
the
further
we
stray
away
from
the
current
ecosystem,
which
is
like
where
people
have
a
bunch
of
manifests.
You
know
being
served
from
a
git
repositories
archive
or
something
you
know
or
like
server
on
some.
B
You
know
hosted
kit
service
right
so,
like
a
lot
of
people
are
just
doing,
coop
cuddle
apply,
f,
you
know
some
manifest
over
there
and
maybe
they
download
it
and
modify
it.
B
So,
like
the
operator
goes
beyond
that
and
we're
talking
about
packages,
if
we
you
know
enforce
that
like
packages,
you
know
say
what
operator
they
should
be
used
with
right,
it's
still
usable
in
the
apply
f,
but
now
there's
this
one
extra
step
in
authoring
that
thing
to
be
used
with
an
operator
and
the
operator
could
say
you
know
fire
warnings
or
you
know
it
could
have
a
pre-flight
check.
You
know
that
says
I
must
have
this
annotation
or
I'm
not
going
to
use
your
bundle.
B
You
know
and
then
that
pre-flight
check
could
be
ignored.
You
know
that
kind
of
thing,
but
the
the
good
thing
right
is
maintainers.
You
know
should
as
long
as
that's
not
too
much
of
a
pain
for
them
to
maintain.
You
know
that
annotation
that
expects
the
operator
from
the
package
that
matches
it.
B
Then
that's
good
and
then
users,
you
know,
always
have
control
over
what
bundle
you
know
they
want
to
be
using
in
the
operator
use
case
right.
So
that
could
you
know,
be
an
example
where
you
know:
whoever
has
permission
to
control.
The
bundle
can
fork
it.
You
know
if
they
want
to
make
it
not
fire
a
warning,
but
that
would
prevent
mistakes.
B
The
way
it's
a
little
funky
to
say
like
use
the
operator
image
as
a
bundle
right
for
what
you
mentioned.
I
don't
think
that
this
is
good
because
go
binaries
are
massive
in
comparison
to
kubernetes
yemen,
so
you're
going
to
have
to
pull
that
bundle
image
once
you
know
to
actually
run
the
execute
the
operator
on
the
node,
with
whatever
cri
you're
using
and
then
twice
with
the
you
know
in
memory
library,
that's
just
really
silly.
B
If
you
look
at
the
way
that
code
builder
declarative
pattern
works
right
now,
this
is
basically
already
an
implementation
that
does
package
the
add-on
inside
of
the
image
that
executes.
B
So,
if
maintainers
are
looking
for
that
kind
of
one
image
solution,
you
know
the
the
operator
is
coupled
with
the
add-on.
D
I
truly
get
it.
I
don't
know
that,
like
there's
enough
space
on
the
internet
to
store
as
many
images
as
you
want
right
so
like
I
could
see
a
world
where,
like.
If
you
want
to
have
just
apply
your
add-ons,
you
have
an
image
that
just
has
the
add-on
and
you
apply
directory
directly
and
there's
no
operator.
But
if
you
had,
you
know
an
operator
that
consumes
add-ons,
you
could
bundle
it
as
you
do
today,
with
the
file
system,
format.
B
Yeah
yeah:
let's
move
some
of
the
discussion
about
operators
using
bundles
and
packaging
and
safety
on
the
benefits
and
caveats
into
the
cluster
add-on.
Slack
channel.
B
Overall,
I
don't.
I
don't
really
feel
like
there's
too
many
gotchas,
so
feeling
confident
and
super
happy
that
you're
you're
driving
this
thanks
nick
great
evan.
You
had
one
more
thing
that
you
wanted
to
share
if
you're
still
still
hanging
out
with
us.
C
Yeah
I'm
here,
I
thought
this
would
just
be
for
fun,
but
I
think
it's
actually
surprisingly
relevant
to
the
discussion
today.
So
let
me
share
my
screen.
Really
quick.
Oh,
I
can't
share
my
screen.
Well,
if
you
click
on
the
link,
this
is.
B
C
This
is
just
a
little
side
project
I
was
playing
with
a
couple
months
ago,
but
I
don't
know
if
you've
seen
q
the
configure
unify
execute
language,
but
I
think
it
has
a
lot
of
promise
and
it's
making
some
interesting
strides
in
the
configuration
space
and
one
of
the
things
that
is
kind
of
a
personal
pet
peeve
of
mine.
About
writing.
Kubernetes
manifests.
C
Is
that
there's
a
huge
set
of
problems
where
you
can't
just
declare
stuff
you
have
to
wait
and
do
things
in
some
imperative
order,
because
you
have
to
first
apply
a
manifest
wait
for
some
controller
to
do
some
work
on
it,
get
out
some
value.
You
need
for
another
manifest
and
apply
it
somewhere
else,
so
this
is
just
a
little
project
that
tries
to
solve
some
of
that
with
by
using
q.
C
C
That's
like
four
or
five
steps
right,
because
you
create
the
role
edit,
the
role
binding
reference,
the
role
apply
it,
but
then,
if
you're
using
q-
and
I
won't
go
into
too
many
details
about
q-
because
it's
kind
of
a
big
topic-
I
can
create
the
role
and
the
role
binding
and
have
the
role
binding
reference,
the
name
of
the
role
and
what
cubecuddle
does.
Is
it
continuously
reconciles
these
resources
that
you've
defined
in
queue
with
the
state
of
the
cluster?
C
So
what
it'll
do
first
is
create
the
role
because
that's
sort
of
like
a
complete
definition.
It
doesn't
need
it.
It's
not
missing
any
data
and
then
once
it's
created,
it'll
sync,
the
state
from
the
cluster
back
and
unify
the
values
with.
What's
here
using
just
normal
queue
machinery
and
then
the
role
binding.
C
So
you
see
that
when
you
just
apply
the
toy
example,
you
get
the
role
binding
can't
be
applied,
then
the
role
is
created
and
the
role
binding
was
created,
and
I
sort
of
been
playing
with
these
ideas
and
found
them
to
be
pretty
useful
just
for,
like
local
testing
provisioning
things
locally
against
like
a
kind
cluster,
and
things
like
that
where
I
want
to
be
able
to
spin
things
up
quickly
in
parallel
and
not
have
them
conflict,
or
I
think
another
use
case
I
found-
was
wanting
to
be
able
to
direct
internal
traffic
out
through
an
ingress
and
back
into
the
cluster,
and
so
the
only
way
that
the
simplest
way
to
do
that
was
just
to
have
some
q
cube,
colorful
stuff
that
referenced
whatever
the
final
cluster
ip
that
was
assigned
to
the
ingress
was
so
I
could
direct
traffic
just
to
the
ip
and
then
it'll
come
through
the
address
controller
for
some
testing.
C
I
was
doing
so.
I
don't
know
it's.
I
think
it's
relative.
It's
pretty
relevant
to
a
lot
of
the
stuff
we
talk
about
here.
It's
kind
of
like
maybe
an
extension
of
the
builder
declarative
pattern
and
to
a
degree-
and
this
is
written
to
eventually
be
a
thing
you
can
run
as
a
controller.
I
mean
you
could
run
it
as
a
controller
right
now.
I
I
just
kind
of
pitched
it
as
a
steel
eye
tool
or
a
cube
cuddle
plugin,
but
it's
all.
C
You
could
just
spin
it
up
in
a
pot
and
it
would
do
everything
there.
My
big
reservations
are.
The
queue
itself
is
still
in
flux.
So
I
don't
think
this
is
anything.
Anyone
should
really
use,
there's
still
weird
edge
cases
where
you
you'll
hit
a
panic
and
q
or
something
like
that,
and
so
you
don't
really
want
to
be
using
it
in
a
cluster
where
you
can't
always
control
all
the
inputs,
but
I
think
once
q
is
stable.
C
B
Looks
super
fun
yeah
you,
you
built
an
apply,
dag
that
reflects
off
of
the
state
of
the
api
server
and
yes,
yeah.
That's
that's
kind
of
the
thing
is
just
like.
If
that
ip
were
ever
to
change
right,
then
you
would
need
to
run
the
apply
again
right,
and
so
that's
when
it
turns
into
a
controller
so
yeah
very.
C
B
C
Of
it's
kind
of
weird,
but
that's.
B
C
B
C
B
C
Yeah
long
term,
one
of
the
interesting
things
about
queue
is
that
you
would
have
the
ability
to
write,
manifests
and
then
ensure
that
their
configuration
is
backwards
compatible.
That's
one
of
the
benefits
of
using
queues
that
you
can
take
two
disparate
configurations
and
then
answer
the
question:
is
this
new
spec
a
new
schema
backwards
compatible
with
this
old
schema,
which
is
sort
of
like
an
update
problem?
C
We
have
for
configuration
of
of
operators
or
controllers
in
general,
yeah
like
how
do
we
know
that
an
operator
author,
providing
an
api
or
controller
providing
an
api,
has
actually
followed
the
conventions
so
that
the
existing
config
continues
to
work
with
the
next
version
during
the
some
transition
period?.
B
So
that's
like
yeah,
that's
huge
and
then,
if
you
can
provide
stability
to
that
same
indirection
kind
of
api
that
you
built
between
the
two
and
that's
really
cool,
then
that
gets
into
what
justin
and
nick
were
bringing
up
about.
Has.
How
does
the
operator
know
that
it
can
trust
you
know
to
that
inflating.
This
package
is
an
intended,
behavior,
interesting,
cool,
all
right.
Well,
we're
running
slightly
over
time.
B
I
guess
we
did
start
a
little
behind,
but
we
should
let
people
get
to
their
next
thing
or
make
their
english
breakfast
or
whatever
so
awesome
to
to
hang
out
with
all
of
you,
they're
all
brilliant
folks,
great
to
be
starting
a
new
year
thanks
so
much
for
everything
that
we
we
did
last
year
and
let's
have
another
good
one.
Yeah
see
you
in
two
weeks.