►
From YouTube: 20180312 sig cluster lifecycle
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
today
is
Tuesday
March,
12
2019.
This
is
the
standard
state,
clustered
lifecycle
meeting.
We
don't
have
a
very
long
agenda,
but
I
thought
we'd
walk
through.
What's
there,
if
you
can't
add
details
to
the
meeting
minutes,
that
would
also
be
helpful
if
I
can
find
the
agenda
which
I
had
open
first
thing
up
on
the
list
was
to
discuss
sig
leadership
for
those
who
are
not
aware.
A
Robbie
has
found
a
new
gig
he's
going
to
be
designing
sort
of
the
game
engines
that
work
a
top
of
kubernetes
working
for
Google
in
a
different
bu
of
some
sorts.
So
he
said,
he'd
be
stepping
down
from
sig
leadership
role.
I
had
talked
with,
probably
informally
it,
but
I
didn't
see
it.
Him
sent
an
email
to
the
list
and
he
had
proposed
to
me
and
talked
informally
about
the
idea
of
possibly
having
Justin
step
up
into
a
single
inertia
position.
B
Yeah
I
mean
obviously
everyone's
very
sad
to
see.
Robert
move
on
I
think
I
would
be
happy
to
step
up
and
try
to
fill
his
shoes.
It
is
not
a
I
think.
We've
always
said
the
sig
leadership
is
not
a
company
role,
so
it
is
not
a
like
Google
gets
to
nominate
a
replacement,
but
I
think
I
would
bring
I
guess
coverage
of
some
of
the
projects
that
would
otherwise
be
underrepresented,
I
think
I
got
more
involved
in
things
at
the
other
that
the
two
remaining
saccades
are
not
involved
in.
So
I'm
lesson
well.
B
A
So
I
think
for
proceeding
further
I
think
we
should
probably
do
is
maybe
I'll
write
up.
If
there
are
other
people
who
are
also
interested
in
leadership,
we
should
make
sure
that
we
at
least
entertain
it
and
not
just
try
to
you
know,
make
it
a
rubber
stamp.
So
if
you're
interested,
please
let
me
know
you
can
feel
free
to
DMV,
and
just
for
just
as
a
PSA
sig
leadership
is
is,
is
servant
leadership.
It
is
not
you,
you
don't
rule
on
hi.
You
basically
have
to
listen
to
all
the
problems.
It
helps
solve
them.
A
So
that
is
the
goal
of
the
Sigma
T's.
It
is
not.
It
is
not
a
a
Thorat
Aryan
position.
It's
a
it's
a
servant,
leadership
position.
So
if
you
are
interested,
please
let
me
know
and
I'll
try
to
write
something
up
and
perhaps
next
meeting
we
can
just
have
a
vote
and
and
we'll
call
it
dun
dun.
Does
that
seem
like
a
fair
way
to
approach
this.
C
Yes,
do
we
have
to
this
points,
have
any
nominees
Justin
for
I.
A
Was
gonna
give
it
time
so
I
was
gonna,
say
Justin
had
talked
with
Robbie
and
is
one
of
the
nominees,
but
I
wanted
to
make
sure
we
at
least
do
the
due
diligence
and
talk
about
it
in
the
open.
So
that
way,
if
other
people
are
interested,
we
can
you
can
entertain
that
and
then
by
next
week
we
can
have
a
quick
or
the
next
meeting.
We
can
have
a
quick
round
table
vote
possessing
her
I.
B
A
There
are
a
couple
of
stuff
couple
of
topics
we
can
discuss
from
my
aside
that
I'm
gonna
put
them
down
at
the
bottom,
because
they're
kind
of
thorny
and
could
sprawl
so
I
do
believe
that
the
j-hook,
what's
the
actual
name,
was
going
to
talk
about
cluster
bundles.
He
had
pinged
me
informally,
so
if
he
is
here,
I
wanted
to
talk
about
it.
I
think
that
would
be
a
good
time
to
discuss
it.
B
B
About
it
sure,
yes,
I,
don't
management,
we
have
a
cap
which
is
linked.
The
number
is
seven
four,
six
and
I
think
we've
had
a
fair
amount
of
discussion.
It
is
a
fairly
abstract
cap.
At
this
point
saying,
we
should
essentially
investigate
the
use
of
operators
for
add-on
management,
and
we
it
would
it's
not
clear
whether
it
should
be
a
subject
or
a
working
group.
B
B
Yes
and
I
think
I,
absolutely
I
I
think
that
we
can
address
that.
I
also
am
mindful
of
not
like
I,
don't
want
to
I.
Don't
really
know
where,
where
we
draw
the
line
between
like
is
the
cap
supposed
to
be
like
a
complete
implementation,
or
are
we
supposed
to
get
the
ball
rolling
and
develop
more
in
the
open,
but
we
do
have.
We
do
have
answers
that
we
think
will
work
for
aircraft
scenarios
in
terms
of
josh's
bundle
and
register
mirrors,
I.
Think.
A
Cluster
API
was
the
de-facto
mechanism,
where
we
kind
of
we
talked
about
things
very
abstractly
about
the
states
of
problems
and
the
types
of
areas
that
we
wanted
to
address.
Things
in
that
kept
was
very
abstract
and
didn't
actually
go
into
specifics
about
technology
or
decisions,
a
versus
B,
for
why
don't
I
take
a
reread
of
that
and
see
if
I
can
potentially
try
to
push
the
the
add-on
management
one
into
that
direction
and
then
from
there
we
can.
We
can
go
ahead
and
do
a
bit
merge.
B
That'd
be
great
and
I
think
it
seems
likely
that
we
will
probably
want
a
repo
for
creation
of
the
initial
add-ons.
The
long-term
goal
is
the
add-on
operators.
The
long-term
goal
is
that
those
would
be
owned
by
that
cordeen.
That's
what
on
the
core
genus
operator,
but
that
feels
like
something
we're
not
going
to
achieve
on
day.
Zero
and
I.
Don't
know
whether
a
potentially
time-limited
repo
falls
under
a
work
group
or
a
sub
project.
A
B
C
C
For
this
thing
to
work
and
like
what
are
the
development
patterns
of
using
this
and
that
and
I
don't
know
so,
I
think
this
sounds
way
more,
like
a
sub
project
that
I'm
working
group,
because,
as
Tim
said
also
pointed
out,
working
groups
are
ephemeral,
and
this
is
something
that's
be
like
over
time.
That's
gonna
own
code
for
one,
and
we
already
have
the
cig
in
place
to
own
this.
D
C
Great
yeah,
it's
always
always
we're
needed
with
with
those
kinds
of
of
efforts,
and
this
is
a
purely
kind
of
or
like
to
a
large
extent,
coordination
like
between
coordinates
and
sig
Network
and
all
the
other
people
in
the
ecosystem
and
then,
like
architecture,
should
know
what
we're
thinking
and
doing
it's
at
rest.
It
right
cetera
and
providing
and
why
this
hasn't
really
executed
a
lot
since
late,
January
or
whatever,
when
the
cap
was
was
created,
is
because
we
don't
have
the
breakouts.
C
A
So
we
know
we
need
to
do
it.
I
just
think
the
language
of
vernacular
like
what
what
is
scope
boned
to
you
know
and
how
we
state
what
we're
gonna
be
doing,
may
need
a
little
refinement,
so
I'm
totally
fine.
If
somebody
wants
to
PR
community-
and
we
can
actually
get
this
ball
rolling,
we
could
do
the
informal
vote
right
now,
which
I
think
is
a
reasonable
thing
to
do.
Yeah.
E
C
A
A
H
A
A
All
right,
I'll
do
the
three-count
any
last
words
go
ahead
once
twice
three
times
all
right,
it's
so
official
official
plus
ones
grounds
the
board
feel
free
to
PR.
Community
I
will
try
to
get
your
meeting
set
up
for
you
as
quickly
as
I
can
and
just
DM
me
on
slack
I
know
I'll
trade,
it
the
bronies
thanks
to
me,
did
you
did
you
want
to
send
out
a
possible
doodle
or
something
to
solicit
times?
Were
there
might
work
for
folks?
That
is
a
great
idea.
I.
A
A
We
are
wildly
inconsistent
with
how
we
manage
artifacts
across
not
only
the
whole
project,
but
also
state
clustered
lifecycle,
seeing
how
we
kind
of
lead
the
pack
in
many
respects,
with
how
we
do
and
manage
and
run
sub
projects.
I
wanted
to
talk
about
it
with
the
group
to
determine
whether
or
not
we
want
to
possibly
have
some
unified
frontier
with
respect
to
n
on
management
and
discoverability
in
etc,
etc,
etc.
A
I
B
A
Is
a
piece
of
it,
but
actually
generation
in
having
uniform,
like
baseline
images,
uniform
testing
automation
for
release
infrastructure,
because,
right
now
you
know
the
way
a
cluster
API
releases
is
we
have
a
GCS
bucket
that
you
know
we've
been
granted
it
and
we
have
to
like
sync
through
a
couple
of
people
to
make
that
magic
happen,
and
this
should
really
be
an
automated
system
that
we
kind
of
we
can
push
test
infer
to
maintain
and
Ellen,
but
having
some
unified
way
of
building
some
unified
way
of
discovering
this
stuff
is
pretty
important.
I.
B
Guess
another
way
to
phrase
my
question
would
be
when
we
have
the
GCR
buckets
and
we
have
the
GCS
buckets
that
are
available
for
every
sub
project
and
proud
can
sort
of
you
can
great
a
proud
job
and
push
to
them,
and
you
can
we
have
some
form
of
promotion
process.
Are
we
through
the
registry
image
promoter
or
something
similar,
I?
A
Think
the
biggest
problem
we
have
outside
of
the
just
the
machinery
is
discoverability
right.
There
are
many
sub
projects
across
the
way
and
no
one
really
knows
all
the
versions
of
things
that
are
released,
and
sometimes
the
versions
are
different
numbers
than
the
versions
that
are
actually
released
with
the
main
artifacts
for
kubernetes.
So
just
having
an
awareness
of
where
all
this
stuff
lives.
If
we
maintain
maybe
just
an
adjunct,
point
and
the
main
Docs
that
might
be
a
reasonable
thing
to
do,
or
it
can
maintain
a
community
and
not
quite
certain
there.
H
H
I
actually
kind
of
think
of
it.
I
didn't
think
of
that.
If
you,
if
you
don't,
have
a
GCE
account,
then
I
actually
don't
know
of
an
easy
way
to
browse
a
GCR
repo.
If
there's
some
kind
of
user
interface,
that
I'm
not
aware
of
I
would
love
somebody
appointing
that,
but
when
comparing
the
usage
of
GCR
to
things
like
clay
and
docker
hub,
there's,
certainly
a
lot
to
be
desired
in
terms
of
usability
and
documentation
of
those
artifacts.
H
J
J
Possible
to
browse
GCR
without
being
logged
in
to
a
GCP
account.
It's
not
the
easiest
thing
in
the
world
like
it's,
not
super
discoverable,
but
I
can
share
a
link
in
chat,
for
example,
to
see
everything
that's
in
the
Google
containers
bucket,
but
there
are
more
user
friendly
registries
out
there
for
sure.
B
I
thought
before
we
had
the
80s,
you
could
just
visit
the
name
of
like
you,
just
literally
type
in
G
cRIO
slash
the
name
of
the
image,
but
there
is
also
another
Avenue
of
Hope,
which
is,
though
we
are
using
GCRs
our
infrastructure,
the
source
of
truth,
at
least
for
the
prod
buckets,
is
going
to
be
the
manifest
that
drives
a
registry
promoter,
and
it
isn't
necessary
to
the
case
that
GC
r
will
be
the
only
target,
and
so
we
could
easily
have
that
will
be
I.
Don't
look
older,
see
a
molar
or
what?
B
But
there
is
going
to
be
a
yellow
file.
That
will
say
these
are
the
images
that
are
in
the
prog
buckets
or
are
expected
to
be
in
the
crud
buckets.
So
from
that,
we
now
have
a
place
where
we
can
build,
or
we
shall
have
a
place.
We
will
in
future
have
a
place
where
we
can
build
tooling.
That
may
be
more
user-friendly
and
may
be
more
discoverable.
B
A
I
think
I
think
a
part
of
there's
there's
two
parts
here.
What
is
clearly
on
the
onus
of
the
Kay?
It's
for
a
working
group.
It's
clearly
not
our
domain
or
Dominion-
to
manage
that,
but
interfacing
with
that
and
making
sure
that
we
are
doing
the
same
thing
across
our
sub
projects
going
on.
But
what
is
definitely
in
our
Dominion
is
some
documentation.
J
A
H
J
J
I
don't
have
any
problems
with
a
set
of
pages
where
one's
for
cops
one's
for
mini
cute,
but
the
sig
has
a
broad
set
of
repositories
with
different
responsibilities
and
I,
don't
really
think
putting
them
all
together
on
a
single
page,
especially
since
it's
probably
gonna
have
to
be
manually,
curated
and
we'll
get
out
of
date
in
a
minute.
I,
just
I
don't
see
the
need
for
it.
J
A
J
I
A
H
A
A
For
set
up
in
the
right
documentation
and
I
think
that
that
is
a
natural
landing
home
and
it's
been
mismanaged
and
I
have
a
thing
on
my
whiteboard
right
next
to
me,
that
says:
do
the
document
destruction
which
has
been
on
the
list
to
do
so
to
do
that
anyways.
So,
if
I'm
going
to
do
that,
underneath
the
main
setup
pages
basically
have
a
listed
set
of
sponsored
sub
projects
and
eliminate
the
things
or
at
least
link
out
two
separate
projects
that
are
external
and
explicitly
specify
that
these
are
not
supported
by
the
community.
A
J
A
Up
on
the
list
was
CRD
management.
We
talked
about
it
last
time.
We
said
we're
gonna
talk
this
time
for
those
who
do
not
earn
familiar
with
the
problem,
it
would
apply
to
all
of
cluster
lifecycle.
The
proposed
solution
that
we
hate,
the
least
not
that
we
like,
is
that
we
would
treat
CRD
management
like
an
add-on
and
then
we
would
actually
have
an
add-on
manager,
which
is
still
you
know,
to
be
discussed,
possibly
the
later
be
the
manager
of
that
lifecycle
of
an
atom.
A
B
I
guess
I
would
share
some
experience
with
cops
where
we
had
a
similar
thing
with
CNI
providers,
and
we
chose
to
bake
in
C&I
providers
in
two
cups,
and
it
has
proved
to
be
a
lot
of
maintenance
work.
So
I
can
absolutely
see
why
it
is
a
nicer
choice
to
hunt
creation
of
a
cluster
that
includes
key
functionality
like
networking
into
a
post
installation
steps,
in
other
words
that
can
the
tooling
just
bring
out
enough
that
you
can
then
proceed
which
doesn't
block
you
from
doing
nice.
B
G
So
CNI
is
a
good
example.
Indeed,
I
think
the
problem
with
CNI
that
we
get
so
many
random
issue
reports
like
people.
You
know
there
was
a
difference
yet
I
ain't,
nobody
in
like
from
the
Kapadia
maintenance.
Nobody
has
even
tried
this
here
and
I
program,
and
now
we
have
exposed
the
way
for
the
user
to
apply
as
he
and
I.
But
if
we
bake
this
inside
cube
ADM,
we
control
what
the
users
do
and
kind
has
baked
the
weave
CNI
inside
and
if
the
users
suddenly
start
to
use
whatever
CNI
they
want.
G
A
Think
there
are
clear
demarcation
lines,
though,
with
Si
and
I
CRI
and
si
si
write.
Those
lines
are
very
clear:
there's
a
contract
that
has
been
specified
via
a
well-defined
I'll,
say
API,
and
it's
not
really
an
API.
It's
like
some
some
standard
set
of
interface
right,
but
there's
a
contract
there
and
there's
a
play
for
how
to
manage
that
as
part
of
a
bootstrap
cycle.
With
respect
to
some
of
the
CRD
migrations
that
is
very
unclear
to
me.
Different
CR
DS.
A
We
required
at
different
stages
of
the
pipeline
in
order
for
to
actually
each
traffic
control
plan
properly.
So
the
the
notion
of
you'd
have
like
almost
stages
of
launch
right,
where
it's
a
multi
staged
approach.
Where
you
need
to
know
exactly
what
time
you
would
need
a
specific,
C
or
D
to
be
enabled
before
you
could
actually
run,
give
any
certain
type
of
behavior
like
storage.
The
one
in
particular
that
I'm
talking
about
is
storage
right.
A
That's
entirely
possible,
but
I
think
it's
up
to
them
to
do
the
version
management
along
with
it
we'd
have
to
have
ski
you
tests
for
sure.
As
part
of
the
you
know
it.
That's
that
adds
to
the
complexity
of
the
test
matrix
right
inside
of
the
test
matrix
for,
like
prowl
periodic
sui,
don't
even
test
the
extension
points
for
the
main
cluster
and
if
we're
trying
to
do
version,
skew
tests
for
different
CR
DS
that
could
be
potentially
explosive.
G
So,
on
the
deep
water
side,
I
think
that
if
we
take
a
bunch
of
CFDs
inside
the
deployment
the
same
way,
we
do
Q
proxy
core
DNS
and
cube
ADM.
It
is
gonna.
This
is
going
to
basically
save
us
a
lot
of
work,
because
if
we
have
to
support
every
possible
scenario
out
there
for
people
installing
customs
here
this
on
both
rap
I,
don't
know
how
we
should
even
have
the
time
to
respond
to
the
users
that
are
going
to
report.
H
So
the
sum
of
this
phasing
and
dependency
model
is
solved
by
adjustments
proposal
to
use
operators
that,
because
that
does
create
like
a
very
fine
gag,
because
the
operator
can
you
know,
control
on.
You
know,
existence
of
a
CR
D
and
then
migrate,
CR
DS,
you
know
between
things
and
between
versions
and
so
the
there
something
that
has
like
a
technical
solution
and
then,
if
I
understand
correctly,
the
operators
are
supposed
to
be
owned
by
the
people
in
maintaining
the
components.
H
A
G
We
both
know
everything
and
basically
provide
the
users
with
a
scenario
that
is
supported
and
upgradeable,
and
we
test
this
and
we
support
it.
If
we
start
the
emerging
with
many
different
possible
scenarios,
we
have
to
support
the
impossibly
complicated
test
matrix.
If,
if
everything
the
couples
from
the
core
you
know
is.
L
E
J
J
How
do
we
get
endpoints
and
services
and
all
the
other
things,
and
then
how
do
we
get
the
controllers
running
at
the
right
time
after
the
CRTs
have
been
created
and
this
problem
whatever
those
solution
is,
would
have
already
been
there,
and
you
know
we
we'd
be
adding
more
CRTs,
potentially
the
core
today
and
they'd,
follow
the
same
sort
of
dependency,
management
and
you'd
use,
something
like
cuba,
diem
or
some
other
installer.
That
has
an
order
to
install
all
these
things.
J
B
Was
going
to
I
think
one
of
the
things
that
does
scare
me
is
the
idea
that
a
CRD
might
have
a
hook
which
might
require
another
CRD
to
be
operational
and
like
how
do
we?
How
do
we
sequence
that
but
allow
these
to
be
written
before
the
hooks
are
necessarily
up,
I,
guess
and
that
that
scares
me?
A
lot
I
think
I.
Think
in
terms
of
managing
the
set
of
these
CR
days.
I
do
agree.
B
A
Like
for
me
personally,
I
think
it
simplifies
the
problem
to
do
CR
DS
for
developments
and
then,
when
you
promote,
promote
the
standard,
API
yeah,
that's
my
personal
opinion,
but
it's
not
shared
amongst
a
lot
of
licor
api
machinery.
Folks,
they
would
like
to
see
it
managed
as
a
thunk,
a
separate
thunk
of
basically
like
schemas
as
an
add-on
which
has
its
you
know
it's
its
versions
in
lockstep
as
a
thunk
with
the
main
revisions
of
kubernetes
right.
C
Mean
I
think
that
is
way
more
of
an
architecture
question
because
it's
like,
if
we
start
breaking
things
up,
we
can
go
like
if
Isis
and
they
said
like
unreasonably
far
so
like.
Okay
for
this
company
is
115.
You
need
to
install
the
pod
CID,
because
otherwise
you
can't
run
pods.
But
if
you
don't
want
pods,
you
don't
need
to
install
that
CID
and
etc,
etc.
So,
like
I.
C
Don't
know
I
I'm,
just
I
agree
that
we
should
find
a
solution
to
the
problem
of
CID
is
general,
but
in
the
case
of
CSI
or
something
else
that
is
clearly
like
coursing
as
its
required
for
conformance.
We
should.
We
should
build
it
in
and
I
don't
care
if
it's
built
using
the
legacy,
API
machinery
semantics
or
if
it's
using
e
colonel
of
the
aps
of
the
newer
CRD
semantics
over
just
actually
registering
that
yeah.
So
that's
the
rant
about
that.
C
A
A
I,
don't
necessarily
want
its
kind
of
been
thrust
upon,
see
a
cluster
lifecycle,
not
necessarily
something
that
we
jumped
up
and
wanted
so
I
think
we
should
start
a
discussion
on
the
mailing
list
and
look
back
in
cig
art
architecture,
with
some
of
the
thoughts
and
opinions
that
I
can
try
to
distill
from
this
conversation
and
and
see
how
to
progress
in
the
future.
But.
C
C
A
J
K
All
right
so
I'm
sure
some
work
that
Justin
and
I
and
others
have
been
doing
40k
and
GK
on
pram.
So
we've
got
this
cluster
bundle
repository
that
we've
been
working
on
and
it's
really
the
goal
of
the
cluster
bundle
is
just
a
simple:
does
everybody
see
this?
What
I'm
working
on
it's
a
really
a
simple
way
to
package
up
kubernetes
material,
so
I've
got
this
bundle,
control
command,
CLI!
That
comes
with
the
repository
I'm
just
going
to
generate
my
okay.
G
K
A
version
and
a
bunch
of
object
files,
it's
really
key
ideas,
there's
this
build
step,
control,
IO
there
and
then
in
lines
everything
into
kind
of
one
hermetic.
That's
super
useful,
because
that
means
that
we
have
this
like
unit
of
kubernetes
material.
That's
version
that
we
can
ship
around
yeah
I
mean
the
bundle.
Control
comes
with
a
couple
of
other
things.
That's
kind
of
the
punchline
of
the
cluster
bundle
is
really
this
version
set
of
minis
material.
It
also
has
some
customized,
like
caching
support
built
in.
K
Builder,
so
you
can
see
there's
this
well.
I
should
I
should
take
a
look
at
this
batch
first,
so
we
got,
we
got
a
patch
and
it
has
this
format.
Oops
and
I
can
one
key
one
one
and
has
some
schema.
That's
like
a
CR
schema,
and
so,
if
we
rebuild
up
my
app,
then
the
back
is
on
the
control
and
say
catch.
This.
K
K
And
it
should
yet
has
it
has
the
food
namespace
now
and
then,
if
we
want
to
get
our
objects
out
again,
we
can
take
under
control
export
and
we
just
have
a
separated
list
of
projects
that
we
can
apply
to
órdenes.
So
that's
that's
kind
of
the
whole
idea
and
that's
like
super
useful,
because
now
we
have
like,
like
a
really
simple
unit,
that's
versions
and
names
that
we
can
say
apply,
give
to
an
operator
or
it's
a.
We
can
have
a
set
of
these
things
and
that's
like
a
cluster
song.
K
K
H
H
K
K
G
K
Just
great
you
can,
since
it
shows
kubernetes
material
like
I,
want
to
split
this
into
a
different
logical
unit.
They
split
apart
into
two
components,
from
my
perspective,
like
as
we're
working
on
G,
K,
n,
gga
and
Prem
like
this
is
mostly
religious
like
applications,
so
you
will
have
like
the
SVD
component.
The
cube
API
server
component,
maybe
like
maybe
like
a
CRC
Rd
component
that
has
all
the
C
argues
that
we
need
to
install
first.
C
K
C
H
K
An
option
the
component,
you
know
builder
component
library,
doesn't
come
with
any
served,
Osho
secrets.
You
know,
we've
played
around
with
several
different
options
for
secrets.
You
can
imagine
actually
like
a
custom
resource
that
says
like
in
the
cluster.
Make
me
this
secret,
like
a
secret
builder
or
something
or
or
you
could
provide
the
secrets
inside
the
component
itself.
C
A
And
it's
being
used
in
many
different
ways.
The
question
I
have
is
understanding
what
tool
is
would
be
used
where,
when
part
of
like
a
given
life
cycle
and
how
it
applies
like
you
could
use
this,
you
can
use
bundle.
A
very
generic
fashion,
isn't
even
germane
to
sequester
lifecycle
right
it
basically
like
manifests
patching
for
dynamic
environment
variables
or
your
cluster
very
similar
to
this
on.
It
is
so
the
how
that
interfaces
with
management
of
core
add-ons
or
something
would
be
a
super
or
useful
thing
to
understand.
B
Yeah
I
have
been
I,
have
been
playing
with
the
bundle
as
backing
some
of
these
operators,
and
it
is
super
useful
for
the
air-gap
types
in
our
where
you
don't
necessarily
want
to
pull
from
it
up
right,
because
you're
worried
about
get
up
going
down
or
whatever
it
is.
The
I
personally
have
been
putting
more
logic,
into
keeping
the
bundle
very
as
plain
objects
and
putting
more
logic
into
code
in
the
operators,
but
I
think
it's
very
powerful
to
have
the
option,
but
I
I
think
it's
also
important
to
realize
that
they
are
they.
K
So
I
think
from
from
our
perspective,
like
the
the
templating,
we
actually
have
like
a
just
a
raw
go
template.
Those
are
kind
of
I
would
say
like
experiments
like
how
can
you
use
the
bundle
in
real
real
life?
There's
even
a
like
imagine,
using
the
buckle
to
represent
OS
images,
there's
like
a
node
object
in
the
in
the
repository
which
you
might
get
rid
of,
but
the
whole
idea
is
like
you
know:
let's,
let's
represent
represent,
everything
is
custom
resources
like
like
secrets
or
secret
builders
or
whatever
yeah.
H
H
Yeah
I
did,
would
you?
Could
you
see
like
a
you
know,
I
have
a
question
is:
is
there
an
ordering
component
to
this
at
all,
or
could
we
build
in
like
some
dag
semantics
cuz,
you
could
actually
bundle
a
bunch
of
CR
DS
here
right
and
then
just
like
annotate
the
objects
or
wrap
them
in,
like
a
you,
know,
dependent
dependent
patch
or
something
like
that
right.
We're,
like
one
patch,
depends
on
another
by
patch
Rev
yeah.
K
That's
possible
I
haven't
really
thought
about
I
kind
of
separate
like
two
ideas.
One
is
like
a
runtime
dependency
versus
like
packaging
time
dependency
and
right
now,
how
representing
packaging
time
dependencies,
which
is
is
mostly
just
in
the
design
phase,
is
another
CR.
That's
like
a
requirements.
Custom
resource,
I
haven't
really
thought
about
representing
runtime
dependencies.
I.
Think
that's
your
problem,
so
you
have
to
worry
about
health
and
and
so
on.
H
That
seems
possible
definitely
like
where
a
lot
of
money
like
hesitation
comes
from
as
far
as
like
being
like
so
enthusiastic
about
another
implementation
from
the
add
ons
sub
project,
because,
like
we,
we
have
a
lot
of
youth
Durland
tools
that
solve
a
large
collection
of
these
problems
are
ready
and
for
us
to
ship
something
in
core
right
and
then
just
give
operators
another
bit
of
UX
that
they
need
to
be
concerned
with.
In
order
to
manage
their
collections
of
things.
Is
you
know
we?
E
H
K
Love
it
if
some
cig
owned
this
personally
I
mean
I,
think
I
have
to
like
Google
sign
off
for
that,
but
yeah
I
mean
I'm
like
Michael,
isn't
right
now
to
say,
like
I
think
some
sheiks
did
on
this,
but
I
would
personally
like
that
to
happen.
My
boss
would
be
like
hey.
What
do
you
guys
think
and
are
you
interested
sort
of
tree
pre
that
step
we're
not
quite
there
yet?
No.
A
We
go
Tim.
This
is
weird
weirdly
overlaps
with
a
bunch
of
easier
space,
applications
and
stuff,
and
even
absolutely
right.
So
the
application
of
the
inside
of
add-ons
is
very
germane
to
this
group
right,
but
outside
of
that
scope,
you
know
I
don't
want
to
tread
on
other
people's
turf
and
don't
want
us
to
get
another
holy
war
with
regards
to
application,
templating
and
overwriting.
Because
they're
you
know,
that's
I,
don't
want
to
get
near
that
that
black
hole
right.
K
C
And
I
agree
with
him,
so
as
long
as
we
keep
the
scope
down
like
really
minimal,
so
in
the
same
way
as
we
did
for
Cupid
I'm
like
okay,
we're
not
even
gonna
install
CNI
providers,
we
keep
the
scope
down
like
up
to
the
point
we
get
conformant
and
that's
all
if
we
find
a
certain
similar
way
of
saying
up
to
this
point,
we're
gonna
do
stuff
with
the
cluster
bundle
and
atoms
as
operators
thing
together,
but
not
anymore.
All
of
all
of
it
beyond
this
level
is
your
space.
A
This
is
yet
another
reason
for
me
to
go
over.
You
view
the
Allens
cap
right
now.
Well,
it's
it's
very
particular
to
this.
It
applies
to
this
conversation,
so
I
think.
If
you
have
a
chance
we
should.
We
should
review
that,
make
sure
that
we
don't
get
into
too
much
detail,
but
it
allows
space
but
I
think
the
key
to
what
Lucas
is
saying.
Is
that
explicitly
specify
the
non
goals?
B
It's
a
good
point:
Thanks
I
think
this
does
solve
real
problems.
Orthe
can
this
can
be
a
solution
to
the
real
problems
we
have
around
err
gapping
of
operators
and
I
are
added
operators
and
I'm
really
excited
to
try
it
more
and
but
we
should
always
explore
other
options,
but
this,
like
in
my
turn
so
far,
has
worked
pretty
well.
Sorry,
nice.