►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20190405
Description
Cluster Addons meeting 2019-04-05. https://docs.google.com/document/d/10_tl_SXcFGb-2109QpcFVrdrfnVEuQ05MBrXtasB0vk/edit#
A
All
right,
I
think
we're
live.
Yeah.
Welcome
everyone
to
the
first
cluster
add-ons
meeting,
I'm
very
happy.
We
got
this
set
up
if
you
haven't
joined
slack,
yet
it's
the
cluster
I,
don't
slack
on
on
kubernetes,
and
then
we
have
links
to
the
kept
document
to
the
repo
and
to
everything
else.
So
have
we
got
this
all
started
and
I
see
that
a
bunch
of
you
already
joined
the
meeting
notes
talks,
which
is
great,
and
so,
let's
all
help
to
you
to
keep
this
up
to
date
for
everyone.
So
far
we
have
on
the
agenda.
A
First
of
all,
a
quick
recap:
I
think
it
would
be
good
just
an
if
you
could
say
just
a
few
words
on
the
cap
itself
and
then
I
thought
it
would
be
good
to
do
a
round
of
introductions.
So
we
know
who's
interested
in
this
effort
like
what
you
want
to
get
out
of
it
and
maybe
also
where
you
would
be
willing
to
help
or
where
there's
some
prior
art
already
I.
A
Think
that
would
be
great
Justin
wanted
to
talk
about
the
first
milestone,
but
we
want
to
see
there
and
then
I
had
another
point
about
the
meeting
time,
because
there
was
a
bit
of
a
confusion
there.
So
it's
how
we
can
get
to
get
this
figured
out.
If
you
have
any
other
agenda
items,
please
add
them
now
and
maybe
just
new.
You.
B
Want
to
start
yeah
I
will
I
will
kick
us
off
with
a
thank
you
off,
because
I
was
like
a
quick
summary
of
I
guess
what
we're
trying
to
solve.
There
is
a
cap,
it's
important
to
a
sub-project
of
seat,
coaster
lifecycle.
There
is
a
cap
which
describes
our
sort
of
goals
for
the
project,
which
is
the
PR
and
I'll
put
the
link
in
the
PR
later
when
I
have
a
moment,
but
essentially
the
the
problem
of
a
Dom
management
has
been
one
that
has
been
an
issue
for
cluster
tooling
for
a
long
time.
B
Attempt
to
solve
every
application
to
one
problem,
and
so
we
have
I
believe
scoped
it
to
be
things
that
are
a
cluster
atom
is
something
that
is
managed
alongside
the
lifecycle
or
along
with
the
lifecycle
of
the
cluster.
So
it
typically
has
to
be
upgraded
or
downgraded
like
when
you
change
kubernetes
versions,
and
by
doing
that
we
hopefully
get
a
lot
of
things
out
of
scope
and
we
make
it
a
slightly
easier
problem
to
solve,
and
then
the
particular
approach
or
meta
approach.
B
I
should
say
that
we
are
hoping
to
follow
or
thinking
that
we
will
follow
is
the
idea
of
using
operators
so
that
there
will
be
a
CR
D
that
describes
each
add-on.
I
think
that's
a
topic
of
discussion
and
then
some
some
code
that
actually
will
go
and
install
whatever
the
add-on
actually
is
based
on
little
or
enthralled
by
the
CR
D.
B
The
this
is
a
community
project.
So
that's
our
starting
point,
but
we
we
want
to
figure
it
out
together.
I
know:
there's
lots
of
people
that
have
built
a
lot
of
things
in
the
past,
and
you
know
some
of
those
motivated.
This
group,
like
I,
think
the
bash
add-on
manager,
which
is
technically
the
one
that
Cuba
and
currently
uses,
is
one
that
we
would
like
to
get
away
from.
That's
our
main
motivator,
but
then
I
think
everyone
has
got
it
gotten
away
from
the
batch
one
in
different
ways
and
I.
B
It
seems
unlikely
that
it
would
be
part
of
conformance,
for
example,
but
the
hope
is
that
it
will
be
good
enough
that
all
the
tooling
will
want
to
use
it
and
I
consider
it
sort
of
a
success
if
the
I
don't
know
like
don't
say,
the
the
most
common
open-source
tooling,
and
that
by
that
I
mean
coop
up
or
cluster
API,
you
were
pending
wherever,
wherever
that
lands
starts
to
use,
these
operators
cops,
coop,
ADM,
ideally
coop
spray
and
the
other
projects.
But
none
of
those
projects
are
going
to
be
required
to
use
it.
B
B
If
there's
a
that's
a
there
are
more
details
on
a
proposed
approach
in
the
kept
and
Jeff
Johnson
I,
don't
know
if
Jeff
is
here,
Jeff
Johnson
may
have
done
some
work
on
sort
of
making.
It
really
easy.
All
the
other
secession
work
making.
It
really
easy
to
create
these
operators,
because
the
the
goal
is
not
that
this
sub
project
becomes
the
maintainer
of
all
operators
and
the
installation
of
all
add-ons
in
or
cluster
add-ons.
B
B
So
the
hope
is
that
Cortinas
will
maintain
its
operator,
because
the
core
DNS
team
knows
best
how
to
install
core
DNS,
and
we
in
this
group
have
to
make
it
so
that
the
operator
that
they
that
they
create
by
default
will
be
one
that
we
like
and
that
works
well
and
then
follows
the
same
patterns
as
other
operators,
so
that
a
user
of
kubernetes
doesn't
have
a
dramatically
different
experience
when
they're
using
core
DNS
or
coop
DNS,
or
the
operative
record.
Enos
feels
consistent
with
the
operator
for
coop
proxy,
for
example.
B
D
B
A
great
question
we
might,
we
might
not
need
operators
for
everything.
The
the
there
are.
A
bunch
of
things
that
are
currently
installed
by
the
bash
add-on
manager
to
proxy
is
not
one
of
them.
Interestingly,
but
I
think
we
would
like.
We
would
like
it
to
be
installed
as
a
daemon
set
I,
don't
necessarily
I,
don't
think
we
should
dictate
which
add-ons
are
done
by
operator
and
which
are
not
and
I,
think
different
configurations
may
choose
to
have
operators
for
certain
things.
B
Think
you
raise
a
good
point
and
so
I
think
first
queue
proxy,
specifically,
if
we're
thinking
about,
if
we
agree
that
we
want
to
head
in
a
particular
direction
and
build
an
operator
first
to
see
what
comes
out
right
like
what
is
our
example
operator
that
we
want
to
want
to
see
for
this
to
try
it
out.
I
agree
that
probably
queue
proxy
is
not
the
one
that
we
should
start
with.
D
Just
to
go
east
to
a
key
native
examples
for
from
the
from
the
queue
con
talk,
talk,
there's
one
talk
to
talks,
I,
don't
know
some
reason.
I
thought
you
had
to
talk,
say
yeah,
so
the
the
moment
that
you
mentioned
in
the
video
that
there's
yak
a
native
and
I
missed
you
and
those
are
those
I
think-
are
good
examples,
because
there's
a
complicated
bits
of
software
and
and
you
kind
of
need
to
handle
dependencies,
please
give
a
nice
version
either.
D
Not
potentially
Network
provide
a
version
for
even
the
cloud
provider
thing
or
whatever
so
yeah
that
that
make
sense
to
me
right
so
I
think
those
are
maybe
a
better
examples
for
before
the
operators
case.
I
mean
more
like
for
for
the
reason
why
why
you
need
an
operator,
and
maybe
there's
like
a
sort
of
a
Suisse
knife,
Suisse
Army
knife
type
operator
that
can
handle
a
few
standard,
simple
cases
like
in
the
case
of
Kate
proxy,
where
you
know
the
image
has
to
be
updated
to
to
an
image
based
on.
D
You
know
like
based
on
the
kubernetes
version
like
it
cooperate
socialist
states
their
theme.
It
should
be
that
for
some
something
else
right,
some
like
the
some
of
those
simple
things
and
maybe
like
some
of
the
network
implementations
need
an
operator
of
their
own.
So
the
ethernet
has
slightly
known,
kubernetes
native
configuration
at
present.
It's
you
know
we
we
can
pass
in
basically
some
environment
variables.
D
D
We
kind
of
like
to
have
add-ons
which
who
can
choose
some
AWS
things?
Let's
say
we
want
to
provision
a
let's
say:
leave
cortex.
Actually,
it's
not
leave
cortex,
it's
just
products
right.
So
if
we
went
to
to
deploy
cortex,
we
need
to
create
some
DynamoDB
tables,
so
we'd
like
to
be
able
to
do
that
as
part
of
the
add-ons
information
and
I
don't
know,
I,
don't
know
how
that
could
be
expressed,
but
perhaps
it's
an
operator
yeah
I
mean
that
that
may
make
sense.
Perhaps
there
is
a
cortex
operator
that
is
fairly
simple.
D
Maybe
doesn't
do
a
lot
throughout
the
day.
I
mean
just
initially
it
kind
of
just
sets
up
some
that
would
be
tables
and
then
it
installs
called
x-ray.
Maybe
maybe
that
is
reasonable
tasks
for
an
operator,
although
I
kind
of
feel
like
some
of
those
things
may
may
I
mean
I
wonder
whether
within
this
context,
we
could
consider
the
path
end
where
we
have
a
CR
D.
A
D
Yeah
I
mean
yeah,
people
could
put
down
some
examples
for
sure,
yeah,
yeah
and
I'm
happy
to
are
the
examples
that
that
I
know
of
cool
movie
too
many
so
yeah.
My
problem
with
this
is
that
I'll
sit
down
for
days
and
days
and
be
writing
examples
anyway.
So
but
the
yeah
there
are
a
few
things
there
and
you
know.
Maybe
you
shouldn't
limit
ourselves
to
a
definition
of
an
operator
to
worry.
It
is
a
piece
of
software
that
runs
inside
a
cluster
and
may
have
you
know
there
is
a
spec
today.
D
A
Imagine
that
quite
a
few
people
here
already
have
like
concrete
use
cases
and,
if
they're
simple
for
us
to
to
support,
we
should
do
it.
Okay,
maybe
we'll
just
do
a
quick
round
of
introductions
where
you
just
there's
know
who
you
are
and
what
you
would
like
to
get
out
of
this.
What
your
use
case
would
be
anyone
who
would
sit
the
first.
G
E
And
our
interest,
in
particular
class
trade-ins
comes
from
a
perspective,
is
what
we
have
several
components
which
we
would
like
to
brain
stole
in
the
cluster.
So
it's
related
to
what's
a
device
plug-ins
for
different
accelerators,
like
FPGA,
GPU
and
so
on.
We
have
several
CSI
providers,
which
we
also
want
to
manage
to
get
all
this
plaster
life
cycle
like
all
kind
of
upgrades
installations
mechanism.
So
we
interested
in
word
project
interesting
to
contribute
for
operators
for
our
stuff.
H
I'm
going
to
go
next,
my
name's
Andrew
Roy
I'm
from
New
Relic.
Our
interest
in
this
particular
project
is
the
description
of
this
cap
is
something
that
we
were
about
to
try
and
do
anyway,
and
they
came
out
at
about
the
same
time
that
we
were
planning
to
think
about
starting
to
do
it
so
yeah,
that's
basically
it
we
have
some
add-on
add-ons
management
concerns
that
we'd
like
to
knock
out,
and
if
we
can
do
that
as
part
of
a
larger
community,
that
would
be
great
I.
B
B
J
Ii
do
want
to
go
next
sure,
thanks
Justin,
so
I
can
probably
speak
for
several
of
us
at
VMware.
We
are
interested
in
tracking
this
from
the
cluster
API
perspective
in
terms
of
add-on
management.
So,
while
we
were
working
on
provisioning
clusters
in
various
infrastructure
providers,
we'd
like
to
have
a
consistent
experience
for
things
like
core
DNS
and
anything
else,
that
makes
sense
as
sort
of
core
cluster
governance.
C
Hey
guys
Jessica
I'm
with
a
group
here-
and
this
is
Arlene
here
with
me-
and
we
have
some
friends
in
New
York
as
well.
So
this
is
we're
from
the
operator
framework
group
at
Red
Hat
and
we've
been
working
on
tools
in
this
space
for
a
while
now
so
things
like
lifecycle,
managing
of
operators
and
building
toolkits
around
how
those
can
create
operators
and
things
in
that
space
and
then
generally
on
the
open
shift
side.
You
know
we
working
on
operationalizing
things
at
the
cluster
type
level
as
well.
St
ends,
the
API
servers,
controller
managers.
G
K
K
By
a
tariff
immense,
soaring,
ordinary
proxy,
its
rapid
currently
wire
ends
no
tables,
and
we
want
to
make
it
more
flexible
one
yeah,
so
we
can
update
it
faster,
so
currently
only
have
bigger
reasons
every
few
months
and
then
updating
stuff
like
coordinates.
This
would
be
nice
if
you
can
just
do
it
on
a
weekly
basis
or
something
like
this
fear.
Operators
across
the
whole
field.
K
L
So
hi
I'm
marki
mice,
from
we've
works
working
on
a
cluster
API
implementation
and
getting
to
the
point
where
okay,
we
got
the
cluster.
Now
we
need
to
add
on
actual
workloads
into
the
cluster
and
having
a
consistent
way
to
do
that
for
applications
and
tooling
is
a
useful,
useful
thing
for
us
and
so
working
on
it
with
with
my
colleagues
here
on
this.
So
just
wanted
to
be
involved
in
how
we
push
this
work.
D
So
we
go
through
all
the
V
works.
People
say:
yeah
I'm,
Bianca
I'm
based
in
London
UK,
and
it's
kind
of
late
time
for
me.
So
I
hope
that
we
inclusive
discussion
in
this
meeting
about
the
time
of
the
meeting
under
yeah.
So
I
was
gonna
say
that
add-ons
been
a
thing
on
my
agenda
for
quite
a
while.
However,
I
could
see
that
you
know
it's
not
something
that
I
could
solve
on
my
own.
Really
I
spend
a
lot
of
time.
Thinking
about
it.
D
We
have
a
few
ideas:
we've
not
in
APR
or
any
key
s
fit
all,
but
then,
but
then
the
they
kept
by
Justin
came
up,
and
you
know
that
kind
of
definitely
attracted
my
attention
and
the
really
interesting
things
there
and
I
think
we
should
just
put
my
solution
for
this
problem.
Yeah
and
I
mean
I
can
talk
a
lot
about
these
cases,
as
you
could
see
already
earlier
on,
anyway,
who's
next
I
guess.
A
Daniel,
do
you
wanna
introduce
yourself,
you
haven't
yet
sure
I'm
Daniel
I'm
in
Berlin,
also
work
for
weave
works.
I'm
a
community
manager
and
I
was
looking
for
initiative
in
communities
to
contribute
to
for
a
long
time,
and
several
of
my
colleagues
pushed
me
forward
and
said,
look
at
this
camp.
This
is
something
that
needs
doing
so
I'm
happy
to
help
from
a
logistic,
specific
perspective.
M
O
I'll
introduce
myself
I'm
new
to
this
I'm
Rodolfo
Pacheco
work
for
AT&T.
We
developed
something
called
airship,
which
is
a
provisioning
mechanism,
and
we
have
our
own
way
of
deploying
the
clusters
in
our
way
interested
in
integrating
the
cluster
API
into
what
we
do
into
airship
specific,
especially
interested
in
involving
the
paramedic
provisioning
aspect
of
this
and
Red
Hat
is
started
with
metal,
cube
and,
of
course,
the
add-ons
because
we
do
deal
with
CNI,
provisioning
and
CSI
and
so
forth.
I
Can
do
next.
This
is
Siddarth
Rana.
Also
working
be
aware.
I've
been
involved
with
the
cluster
API
for
some
time
now,
I,
primarily
work
on
the
cluster
API
vSphere
provider,
implementation
side
and
again,
a
topic
of
add-ons
have
been
interesting,
one
which
I
think
we
have
all
discussed
for
quite
some
times.
I'm,
actually
pretty
happy
with
that,
starting.
Our
dedicated
group
and
effort
here
happy
to
help.
Q
I
can
go
next,
I'm
Jason
to
tippers
I,
also
work
at
VMware.
My
main
focus
is
around
cluster
API.
Like
Andy
said
you
know,
as
we
build
out
closer
API
I.
Don't
want
us
to
have
to
build
our
own
kind
of
spoke
at
on
management
or
kind
of
cluster
recliners
add-ons,
so
anything
that
we
can
help
out
with
to
have
a
more
broad
effort
and
shared
effort
around
managing
those
is
great
to
me,
and
also
in
particular,
for
cube
ATM
in
the
past.
Q
R
Ok,
next
I'm
Nydia,
also
at
VMware,
it's
working
on
that's
like
many
date.
The
best
implementation,
so
I'm
kind
of
interested
in
there
see
sort
of
where
Adams
also
required
changes
to
infrastructure
and
how
we
could
even
make
that
work
and
open
do
any
vehicle
along
those
lines.
I.
F
T
Michael
rythmic,
also
at
Red
Hat,
also
bases
same
interests
since
their
metal
came
up
a
minute
ago,
I'll
plug
that
I
worked
on
the
operators,
decay
and
does
old
work
on
controller
one
time
before,
but
now
I
work
on
more
a
consumer
of
those
things
and
a
consumer
of
operator
lifecycle
manager
by
working
on
adding
native
bare-metal
provisioning
through
the
bare
metal
operator
and
the
bare
metal
machine.
Actuator
simply
is
interested
in
that
to
clean
it.
You
have
to
discuss
that.
U
U
So
you
know
I,
guess
one
thing
that
I'm
that
I'm
hoping
to
to
get
out
of
this
meeting
working
group
etcetera,
is
just
sort
of
coming
up
with
you
know:
they're
the
common
mental
models
for
you
know
for
for
upgrading.
You
know
various
you
know
not,
maybe
not
like
core
control
playing
components,
but
but
things
like
cube
proxy
could
be
an
escort
DNS
things
like
that.
You
know,
as
those.
C
D
N
Well,
it
would
do
this
myself.
My
name
is
Pablo
I
work,
persistence,
I'm
here,
because
we
were
still
working
in
the
architecture
of
the
neo,
the
next
release
of
our
cast
platform.
We
start
working
on
on
the
d-pad
phones
and
then
realized
that,
as
you
start
out
onto
your
connector,
that
you
introduce
anything
problem,
what
we're
trying
to
look
for
some
solution
already
existing
that
we
found
many
of
them.
N
So
one
of
the
ideas
are
coming
here
years,
trying
to
see
if
we
can
arrive
to
our
common
denominator
of
different
approaches
because
seems
to
be
Eric
that
many
people
have
tried
to
solve,
including
ourselves
and
main
objective
here
is-
is
to
see
if
there
is
really
a
with
income
to
a
common
approach
to
this
necessarily
a
common
implementation
that
the
least
common
set
of
rules
how
advanced
can
be
stored
in
a
closure
in
a
way
they
can
work
together.
T
there
are
developer
different
providers
to
their
own.
R
G
My
name
is
Jeff
Johnson
I
work
at
Google
and
I've
been
working
with
Justin
on
these
on
add-ons
for
gke
and
GK
on
pram,
and
my
sort
of
not-so-secret
goal
with
this
is
to
sort
of
redefine
a
relationship
between
cluster
bring
up
and
management
and
the
actual
add-on
installation.
So
what
I
really
want
to
do
is
sort
of
push
out
those
complex
complexities
to
the
edge
sort
of
and
simplify
that
sort
of
relationship.
So
that's
what
we've
been
doing
so
far
with
Jiki
Jiki
on-prem,
so
I'm
excited
to
work
with
the
community
on
it.
B
Based
on
our
discussion
of
my
tea
perimeter,
we
come
through
at
the
end,
but
I
like
having
a
Northstar
we
can
head
towards.
I
would
love
to
have
something
like
that.
I
think
the
example
I
had,
in
my
mind,
was
a
was
a
an
operator
or
whenever
we
decide
for
installing
core
DNS,
and
then
we
try
and
get
that
into
the
cube
up
as
an
option.
B
The
cube
up
the
cluster
bring
up
as
an
option,
because,
although
it
is
it's
deprecated,
so
it's
less
of
a
problem
in
terms
of
like
breaking
everyone,
but
it's
also
the
one
where
a
lot
of
ete
test
runs
feel
like
it.
We
could
actually
get
some
mileage
on
that
in
terms
of
testing
if
we
cared
about
that,
but
that
that
is
a
triple
man,
but
it's
more
just
like.
B
Do
we
like
the
idea
of
of
aiming
towards
something
concrete,
because
I
think
one
of
the
big
problems
in
this
face
is
that
we
we
risk
like
just
having
an
analysis
processor
we
just
have
like.
There
are
a
million
things
that
we
could
build.
Operators
for-
and
hopefully
we
can
get
most
of
them
is
out
of
scope,
but
then
there
are
million
different
ways
to
do
things
and
I
feel
like.
G
A
few
things
at
this
phase,
I
think
is
just
it
was
a
really
good
way
to
sort
of
Explorer
and
see
what
see
what
concepts
work
out
and
what
concepts
don't
work
out.
You
know
and
maybe
start
to
help
to
inform
us
to
figure
out
where
that
dividing
line
should
be
of
ones
we
actually
want
or
don't
want
to
do
or
types
of
things
we
do
or
you
don't
want
to
do
that.
I
do
like
the
idea
of
just
like
picking
one
or
two
and
building
does.
A
B
Like
what
Jeff
said
a
lot
there,
where
he
said
that
it's
like
one
when
they
were
trying
out
and
then
we
can
discuss
I,
think,
like
you
know,
like
I,
know,
Red
Hat
certainly
have
a
lot
of
work
in
the
area
and
I
don't
want
to
be
like
you
can
just
build.
Something
could
be
different
and
ignore
at
all,
but
I
I
also
think
that
having
something
that's
concretely,
application
of
what
we're
talking
about
is
is
handy
and
I'd
like
to
see.
G
I
was
gonna
suggest
is
that,
since
we
do
have
a
lot
of
experience
with
this
already
it
would
we
have
tried
a
bunch
of
different
things
out
over
the
past
two
years,
and
so
we
do
have
some
experience,
both
some
things
that
work
and
some
things
that
don't
and
we
we
know
that
we're
not
like.
We
haven't
hit
operator
nirvana
already
so
we're
we
can
definitely
just
like
share
sort
of
one
we've
tried
out
and
where
we
think
we
need
to
go
see.
If
do
this
lines
up,
I.
G
Imagine
that
the
solution
for
add-ons
is
not
going
to
be
like
wholesale
buy
into
the
operator
framework,
but
one
thing
that
we
can
think
about
is
like
dividing
out
pieces
that
we
know
are
modular
and
potentially
could
help
bootstraps
this.
If
that
sounds
like
a
good
idea
after
we've
discussed
at
some
point,
so
is
it?
Is
there
interest
in
learning,
like
learning
more
about
what
we've
tried
out
already
and
what
or
or
using.
B
B
We
do
actually
have
a
repo,
so
we
can
like
create
example
like
if
we
stroll
man
Cordia
Ness,
that
we
pick
one
and
we
build
like
couple
of
things
and
see
what
we
think
and
put
them
in
PRS
and
discuss
them,
have
some
code
to
look
at
and
then
we
can
like
circle
back
on
them
in
the
meeting
and
dig
back
into
like
the
sort
of
philosophy,
type
questions,
I
guess
which
are
harder
to
doing
in
code.
Yes,
I.
B
G
Of
the
things
that's
interesting
to
me
is
the
distinction
between
like
different
stages
of
bringing
a
cluster
up
and
retinas
fit
in.
So
there's
not
going
to
be
a
strong
distinction
between
stuff
that
needs
to
be
available
before
any
real
work.
Let's
start
and
things
that
need
to
be
available
after,
but
even
if
we
decide
there's
a
strong
distinction
there,
it
might
be
valuable
to
like
a
line
on
the
packaging
of
those
things
or
something
like
that.
I.
B
Think
I'll
be
great,
I,
don't
think
it's
required.
Alright
I
think
we
definitely
you
don't
want
to.
We
we
don't
want
to
try
to
set.
This
is
the
the
system
that
everything
should
use
a
toast
they
just
from
here
on
out.
But
if
we
achieve
that,
that's
wonderful,
but
that's
not
that
it's
not
a
goal
right.
G
C
Justin
I
think
you
pointed
out
the
scope.
You
guys
were
interested
we're
add-ons
that
had
to
lifecycle
with
the
cube
API
server
that
the
cube
version
basically
right.
So
is
that
not
necessarily
things
that
have
to
be,
as
Evan
said
before,
workloads
come
on?
Are
there
things
that
still
need
a
life
cycle
with
the
cube
version,
but
there
might
be
at
that
next
level.
C
B
I
think
it's
a
things
are
managed
like
alongside
the
cluster,
so
it
will
be.
There
are
things
that
are
required
to
be
liked.
Even
if
they're,
not
even
a
thing,
you
think
could
be
added
afterwards
if
you're
still
gonna,
if
the
the
tooling
I
guess
that
manages
them
as
part
of
his
injuries.
If
there's
a
dependency
on
the
coop
on
the
kubernetes
version,
we
would
expect
this
that
the
management
of
that
piece
would
be
done
by
the
tooling
that
manages
your
cluster
right.
G
Is
there
a
goal
around
discoverability
of
these
things
like
right?
Now,
it's
not
super
easy
to
determine
what
makes
up
your
cluster
when
you
bring
it
up,
for
example,
which
which
feature
gates
you
have
enabled
like
this
I
I.
Think
you
need
a
lot
of
privilege
to
discover.
So
is
one
of
the
goals
of
sort
of
managing
add-ons
in
a
more
defined
but
may
to
exploit
some
of
that
to
consumers.
We
need
to
know
who
may
not
have
the
privilege
to
lead
the
future
flights.
B
It's
it's
a
side
effect
I,
think
it's
a
great
side
effects
and
I
I.
Imagine
we
will
rapidly.
We
should
we
should.
We
should
embrace
that,
because
I
imagine
it
will
become
very
important
like
once.
We
start
having
it.
Even
if
it
started
as
a
side
effect.
I
think
tooling
will
come
to
rely
on
it
and
like
assume
that
yeah
use
it.
H
B
Agree
and
I
think
I
I
for
your
monitoring
thing.
I
think
we
I
think
we
have
a
definition
that
excuse
it
and
I
think
that
is
the
correct
thing
to
do
and
I
think,
because,
because
it
wouldn't
necessarily
manage
you,
wouldn't
upgrade
it
if
you're
a
Georgia,
brandies,
cluster
and
I
think
nothing
stops
you
using
an
operator
to
do
that.
Nothing
stops
using
whatever
operative
framework.
You
want
to
or
not
using
an
operator
and
I.
B
Think
that's
great
and
I
think
we
I
think
the
relevant
pieces
of
tooling
should
come
up
with
a
hook
to
allow
you
to
do
that
in
a
clean
way,
but
I
hope
if
we
do
that
that
that
would
be
sufficient
to
enable
you
to
say
like
I.
For
us
a
cluster
includes
these
additional
components
and
we
install
them
using
this
manifest
or
this
whatever
it
is,
and
that
I
I
would
hope.
If
we
have
that
that,
if
we
have
that
hooking
point,
then
we
can,
we
don't
have
to
bring
it
all
in
to
skip.
E
B
E
B
Guess
maybe,
if
we
created,
if
we
I
guess
what
I
would
help
is,
if
we
create
a
good
operator
that
those
third
parties
could
use
the
same
approach,
it
doesn't
mean
that,
just
because
this
just
an
operator
is
produced
or
originates
from
the
work
of
this
group,
that
doesn't
mean
that
it
will
ship
in
every
kubernetes
cluster
or
that
the
human
race
project
will
ship
it.
So
the
those
third
parties
would
be
able
to
use
the
same
framework
for
these
more
system
level
components
even.
B
Of
the
kubernetes
release
they
might
be
closed
source,
whatever
it
is,
and
the
the
management
experience
would
be
similar
and
I
guess.
As
long
as
there
is
again
a
hook
of
some
port,
some
sort,
there
shouldn't
be
a
huge
distinction
for
people
whose
clusters
do
include
those
pieces,
and
their
tooling
would
include
those
or
hook
out
to
those
additional
pieces.
B
I
guess,
but
I
I
would
hope
the
despite
the
fact
it
would
be
a
different
party
producing
the
operator
that
it
would
be
seamless,
and
we
want
that,
even
even
for
even
the
open
source
we
don't
want
to.
We
want
to
gather
operators
from
the
various
teams.
We
don't
want
to
be
too
fine
operators,
and
that
makes
sense,
Alexander
well.
E
What's
true,
we
don't
want
to
gather
everything
in
one
place,
but
we
want
to
have
what
scenario
would
where
was
kind
of
clustered
on
operators
can
be
developed
by
different
teams,
but
when,
for
an
customer
who
are
getting
co-creating
about
kubernetes
cluster,
you
should
be
able
to
discover
and
use
those
operators,
regardless
for
source,
for
that
comes
from
as
a
twin
dorito.
It
will
be
from
scrimmage
I.
B
Guess
I'll
be
the
role
of
the
installation
to
nothing
basically
to
gather
these
in
a
okay
here
in
fashion,
and
we
should
certainly
I
agree.
I
really
said
we
should
provide
guidance
and
we
can,
you
know
I'm
sure
we're
building
cops
ability
of
ABM
in
the
living,
trust
or
API
I.
Don't
think
we
necessarily
have
to
dictate
any
approach.
I
guess
we
can
make
it
we
should
make
it.
We
should
make
it
easy
such
that
everyone
does
the
right
thing,
which
is
hopefully
so
like
falling
into
the
pit
of
success
or
just
Pulliam
success
rate.
M
Off
that
point,
so
I
haven't
read
into
the
cap
too
deeply,
but
it
seems
like
we
want
to
define
interdependencies
between
add-ons
and
be
able
to
support
any
installation
of
different
add-ons
based
on
what
they
require
on
the
cluster
and
I.
Think
there's
a
lot
of
parallels
with
like
package
managers
that
already
exist
for,
like
OS
level
packages.
B
B
Speak
I
think
I
think
this
is
where
building
and
practice
and
learning
from
what
I've
learned
and
our
experience
in
the
gk
in
the
work
didn't
gke,
I
think,
is
valuable.
I
think
we,
you
know
it's.
If
you
try
to
design
a
dependency
aversion
dependency
framework
in
general,
you
could
never
make
any
progress
at
all
and
I
think
it
will
be
interesting
to
see
what
dependencies
we
actually
need.
B
I
think
we've
found
that
we
can
impose
limited
sequencing
by
encoding
inning
by
through
code,
and
I
guess
the
question
is:
to
what
extent
is
that
sufficient
and
what
extent
do
we
need?
What
extent
do
we
need
more
complex,
declarative
definitions
of
dependencies
and
some
sort
of
meta
sulfur,
which
is
what
most
package
management
system
seem
to
have
I
would
I
would
hope
we
can
not
I
would
hope
we
get
away
with
it
without
it,
but
we
will.
I
would.
A
So
I
heard
that
you
have
meetings
coming
up
just
after
this
one.
We
have
eight
minutes
left
so
I
think
there
were
too
many
like
strong
objections
against
going
with
Cortinas,
as
it's
justin
suggested.
Is
that
put
them
anyone
be
interested
in
helping
out
with
this
or
get
together
with
just
in
talk
about
this.
M
A
B
A
All
right,
yeah,
the
last
point
was
the
meeting
point
at
the
meeting
time.
You
brought
it
up
earlier,
so
there
was
some
confusion
because
the
US
had
already
changed.
D'este
and
Europe
was
just
about
what
the
doodle
happened
and
some
people
weren't
sure
that
this
was
PST,
so
I
guess
I'll
just
set
up,
and
you
do
know
and
just
make
sure
that
it
doesn't
clash
with
the
you
know
with
any
of
the
other
sig
meetings
said
so
more.
Everyone
cool.