►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20200414
A
B
Yeah
sure
so
we
just
got
off
of
the
component
standard
call
and
Chris
did
a
little
presentation
regarding
the
component
config
patch
for
controller
runtime
and
Chris
is
here.
So
if
you
have
any
comments
that
you
wanted
to
address
specifically
feel
free
to
speak
up.
But
just
my
big
takeaway
is
that
some
of
the
things
that
Mike
toughen
was
pointing
out
is
just
reducing
the
complexity.
That's
needed
for
somebody
to
offer.
One
of
these
configs
and
yeah
I
did
add.
B
C
And
if
anybody,
if
anybody
has
any
thoughts
feedback
open
for
any
any
any
of
that
you
neither
did
on
floor
request
or
sent
me
anything
the
idea
there
was
the
the
the
core
goal,
at
least
from
what
I
saw
was
Jeff
wanted.
Something
or
I
think
everybody
on.
This
call
wants
a
more
standard
way
to
can
any
any
cluster
add-on,
so
they
can
have
something
that
looks
similar
and
make
it
makes
the
add-on
installer
easier
and
so
on
so
forth,
cool.
B
B
So
the
first
note
that
I
just
thought
was
interesting
was
we
noticed
that
post
apply?
The
controller
is
using
server-side
apply,
which
is
a
beta
feature
now
in
the
newer
versions
of
coop
Nettie's,
but
that
does
not
work
on
older
clusters
for
people
who
are
trying
to
use
these
new
versions
and
new
features.
Experimental
features
of
cluster
api
on
older
stuff,
that's
not
going
to
function,
and
then
it's
also
a
major
difference.
B
B
Be
a
big
difference
from
like,
say
trying
to
add
coop,
CTL
or
customize
to
the
post,
apply
controller
and
then
exec
out.
So
we
could
have
a
server-side
apply
feature
gate
in
the
API
that
could
be
enabled
or
not,
and
maybe
not
in
the
API,
but
at
the
library
level,
for
the
application
portion,
but
then
you're,
probably
not
gonna,
get
away
from
either
vendor
in
customize
or
showing
out
to
it
as
a
binary.
So
those
are
some
differences.
Anyone
have
any
comments
on
that.
B
Ok,
so
the
idea
that
sadef
and
I
and
we're
talking
about
was
importing
the
add-on
installer
configuration
and
the
accompanying
library
into
the
controller
for
the
post
apply.
So
the
way
post
apply
works
is
it's
got
a
CRD
that
points
to
a
bunch
of
secrets
in
the
main
space
and
those
secrets
contain
manifests,
and
we
were
thinking
that
we
could
turn
the
add-on
install
config
on
generate
a
CR
key
for
it
and
then
basically
do
the
same
thing.
B
B
So
the
operator
will
need
the
in
cluster
network
to
be
functioning
from
service,
routing
and
pod
routing
perspective,
because
an
operator
needs
to
be
able
to
view
the
definitions
that
it's
been
given
from
the
kubernetes
api
and
be
able
to
store
state
inside
of
it.
You
could
bootstrap
the
operator
with
a
component
config.
That
would
be
a
thing,
but
then
it
couldn't
talk
to
the
kubernetes
API
to
actually
create
the
resources
that
it
needs
unless
it
were
running
external
to
the
cluster.
A
B
B
D
B
D
B
I
haven't
thought
about
this
well
enough,
and
obviously
you
have
so
I'm
gonna.
Definitely
take
a
note
on
this,
which
is
that
really,
as
long
as
qu
proxy
is
installed
on
the
node,
no.
B
B
So
I'm
going
to
make
a
note
that
we
could
run
a
low-level
operators
in
this
manner
as
long
as
the
user
or
config
tooling
can
patch
the
add-on
to
you
know
either
look
at
a
yeah.
You
couldn't
look
at
a
config
map
because
I'll
sure
you
could
I
guess,
because
the
couplet
can
talk
to
the
API
server
and
then
the
couplet
is
going
to
yeah.
Do
that
for
you.
B
Stowed
in
that
regard,
there's
really
no
motivation
like.
If
you
want
to
use
the
Calico
operator,
you
know
you
don't
have
to
bootstrap
the
manifest
in
order
to
stand
up
calico.
You
know
for
the
operator
to
be
able
to
do
its
job.
As
long
as
you
can,
you
know
reach
the
API
server
from
the
node,
which
is
basically
every
kubernetes
cluster
ever
so.
B
So
I
don't
see
that
big
of
a
dissonant
problem
with
what
post
supply
is
serving
with
its
one-time
apply,
because
the
idea
was
that
there
were
potentially
some
things.
I
could
only
be
done
when
you're
bringing
up
add-ons
for
the
first
time
in
a
declarative
way,
because
you
have
that
connection
to
the
API
server.
B
E
B
B
If
we
want
to
be
able
to
run
in
like
a
managed
environment
or
with
like
the
Ubuntu
solution
which
doesn't
have
couplets
on
the
control
plane
nodes,
then
it
starts
to
get
a
little
tough
to
do
that
kind
of
thing,
but
it
is
probably
a
good
default
is
just.
We
could
have
customize
directory
that
configures
the
operator
to
only
node,
select
on
control,
plane
nodes
using
like
the
default
annotations
and
then
talk
on
localhost
using
the
API
sir.
It
just
sets
the
API
server
and
points
to
look
lowest
and
then
a
user
can
patch.
A
A
My
idea
would
be
that
the
Dementors
that
would
be
lien
just
in
for
the
one
project
and
for
the
other
project
I
think
it
was
Jeff
and
Sandeep
I
think
get
together
and
then
just
review
the
the
applications
or
talk
about
it.
I'm
not
sure
how
much
feedback
you've
seen
in
the
past
couple
of
weeks
or
requests
from
from
students.
I
know
that
in
the
beginning
there
was
a
lot
of
interest
I'm,
just
not
sure
what
we
need
to
do
until
be
announced
in
two
and
a
half
weeks.
F
Yeah
I
just
want
I
actually
had
it
all
sorry,
I,
don't
know.
If
you
can
hear
me.
Yes,
I
had
a
look
at
the
at
the
Summer
of
Code
website
and
it
wasn't
clear
what
we
could
actually
do
at
this
stage.
I
think
I
starred
one
or
two
of
them,
but
it
wasn't.
It
wasn't
very
clear
whether
we
were
supposed
to
be
reviewing
them
at
this
point
or
or
what
we
were
actually
supposed
to
do.
A
F
Thank
you
yes,
I
mean
there
are
so
there
are.
There
are
very
large
number
of
proposals,
actually
not
all
of
which
are
for
our
sub
project.
Some
of
I
think
we
basically
can
see
all
the
CNCs
proposals
like
there
are
a
lot
of
proposals
for
like
TI
kv
technically
or
things
like
that,
which
I
assume
are
other
people's
projects,
and
but
there
are,
you
know
there
are
there
probably
dozen
for
ours
and
we
should
go
through
them,
but
it
wasn't
really
clear
what
we
were
supposed
to
do.
There
is
the
ability
drug
review.
F
B
So
I
remember
two
weeks
ago
that
basically
was
the
application
deadline,
and
so
everyone
polished
those
off
and
got
them
up,
but
yeah
I
haven't
read
any
applications
or
received
any
correspondence
that
I
need
to
do
that.
So
if
we
need
to
do
something,
then
I'm
happy
to
to
jump
on,
but
I
was
very
aloof.
A
F
F
How
are
we
going
to
install
the
thought
was
good
feedback
first,
how
are
we
going
to
manage
the
installation
of
the
operators
themselves
and
I
had
previously
done
it
with
a
sort
of
hard-coded
logic
that,
yes
and
I
think
the
feedback
was
that
we
wanted
some
I
guess
generic
way
of
installing
up,
for
we
want
some
way
of
installing
the
operators
which
should
be
less
magic.
So
it's
more
open
to
third
parties
and
doesn't
purpose,
and
then
that
sort
of
implies
placing
me
some
sort
of
generic.
F
B
B
F
B
So
just
the
idea
with
the
install
configuration
is
we
have
a
simple
API
that
could
point
to
places
where
you
could
source
manifests
and
those
manifests
you
know
may
have,
ideally
that
the
API
is
extensible
enough.
You
know
where
you
can
use
customize,
and
you
know
you
could
use
raw
stuff
from
an
HTTP
server
and
you
know,
maybe
eventually
we
could
support.
You
know
a
templated,
helm,
chart
or
tanka
or
something
else,
but
yeah.
Those
things
are
seem
like
easy
wins.
B
B
The
reason
I
made
it
a
component
config
was
because
it
was
supposed
to
work
in
an
environment
where
you
did
not
have
an
API
server
you
up
yet
right.
So
something
like
Covidien,
where,
like
it
needs
to
function
from
outside
of
the
cluster
before
the
cluster
is
ready.
Before
you
have.
You
know
the
basics,
but
we
could.
We
could
relook
at
that
and
change
the
way
that
it's
that
it
functions.
F
So
there
wouldn't
be
any
logic
like
that's
how
we
sort
of
break
the
we're,
not
gonna
like
continually
like
it's
not
going
Turtles
all
the
way
down
like
the
the
way
we
break
the
turtles.
The
way
down
is
we
have
one
generic
mechanism
that
can
apply
the
operators
and
the
operators
have
the
specific
logic.
But
yes,
it's
the
installation
of
those
operators.
Yeah.
B
G
So,
in
a
no
LM,
we're
actually
kind
of
doing
something
similar
to
this,
where
we
use
that
packaging
format
that
we
have
that
proposal
up
for
and
what
we
do
is
we
actually
pull
the
manifests
out
of
that
and
then
we'll
apply
them.
However,
we
want
to
apply
them
like.
So,
if
you,
you
would
have
an
apply
er
for
customize
or
helm
or
something,
and
you
could
write
that
a
player
and
the
manifest
will
get
shipped
in
that
packaging
format.
And
then
one
thing
would
just
know
how
to
like.
B
Yeah,
that
sounds
really
awesome.
Sean,
especially
the
the
pluggable
applier
thing,
I'd,
be
interested
in
how
you
get
a
mounting
space
to
do
that
and
that
kind
of
thing
or
you
know
what,
how
you
build
the
environment
to
have
those
pluggable
appliers
and
then
the
other
question
I
have
is
just.
Is
that
code
available
to
view
somewhere
yeah.
G
Where
we
are
actively
looking
at
new
API
to
kind
of
coalesce
around,
and
so
this
is
a
I
think
kind
of
a
really
interesting
time
for
this
to
come
up
since
we're
starting
to
look
at
this
anyway.
I
think
I
just
saw
Nick
joint
who's,
much
more
intimate
with
the
details
of
this
work,
but
so
I
think
Justin.
If
you
could
talk,
didn't
make,
maybe
just
to
get
like
a
lowdown
of
what
he's
thinking
and
maybe
some
of
the
design
Doc's.
If
that
would
help
you
in
any
way,
it
would
be.
E
G
E
B
No
it's
it's
related
to
that.
We
were
also
talking
about
cops
in
general,
so
Justin
built
a
way
of
having
cops,
have
a
controller
that
installs
other
operators
that
then
managed
their
add-ons,
and
he
presented
that
to
the
cops
group
whose
primary
feedback
was
love
it
can
we
make
it
generic
and
allow
a
configuration
that
sources,
those
add-ons
from
multiple
places,
and
then
my
comment
was
that's
exactly
the
the
type
of
problem
I
was
trying
to
solve
with
add-on,
installer
config,
so
just
whatever
we
end
up
with
I
would
like
all
the
things
to
have.
B
You
know
similar
API
types
and
that
kind
of
thing.
Ideally,
we
could
use
the
same
API.
You
know
in
koobideh,
I'm
in
cops
in
cluster
API
in
OLM,
I
think
that
that
would
be
ideal
for
users.
Yeah
there
would
be
really
nice
is
I
did
whoa.
What
we're
doing
you
know
has
only
a
couple
facets.
The
complexity
like
we're
really
just
trying
to
inflate,
manifests
from
package
sources.
The
package
sources
thing
is
really
flimsy
right
now,
because
we
don't
have
a
good
prior
art
for
a
lot
of
that.
B
Hence
the
proposals
right
and
things
like
customized
but
yeah
and
then
have
a
config
that
tells
you
how
to
do
it
and
apply
it
from
some
privileged
place,
and
if
we
could
have
shared
libraries
that
shared
API
for
that
problem
said
in
all
of
these
tools,
which
have
many
users,
then
those
tools
can
provide
the
defaults
configs.
You
know
that
ship
with
the
distro,
be
it
cops
or
OpenShift.
You
know,
and
that
kind
of
thing
is
that,
then
it
makes
it
very
clear
to
users
like
this
is
what's
happening.
B
E
I,
don't
have
the
right
in
front
of
me,
so
I
can't
tell
you
for
sure,
but
I
have
the
proposal
for
the
lake
first
pass
of
the
install
API.
That
I
can
share
with
folks
on
the
Google
Doc
here
and
that
basically
walks
through
exactly
what
we
were
thinking
and
what
the
Manifest
would
look
like
you
with
the
behavior
around.
It
would
look
like,
and
it
is
very
similar
to
the
installed
configuration.
B
E
B
E
E
A
A
E
Perfect,
so
just
real
quick
get
that
at
the
head
of
this
proposal,
section
you'll
see
there's
a
collaborative
resource.
This
is
very
similar
to
the
add-on
resource
that
we
had
pictured
while
ago,
and
the
wig
PR
has
been
sitting
up
for
a
while
I
apologize
for
not
getting
back
to
finishing
that
up
and
really
busy.
E
E
E
We
wanted
to
kind
of
drive
a
permission
model
that
was
similar
to
what
you
see
on
Android.
Wear
like
as
permissions
are
new
permissions
are
required.
They
are
requested
of
a
more
privileged
user
to
expand
the
permissions
up
to
exactly
what
it
means
in
order
to
apply
those
manifests
or
install
that
thing
so.
E
Yeah
I
can
remember
it's
a
proper
superset,
but
it
needs
to
have
at
least
at
least
this
set
attempting
to
be
approved
in
order
to
do
that,
and
then
in
in
the
future.
Now
that
they're
associated
with
the
service
account,
we
have
to
drive
updates.
So
there
may
be
cases
where
this
service
account
needs
to
ratchet
up
its
permissions
or
or
has
the
same
set
of
permissions
so
like
we
don't
want
to
have
to
approve
this
every
time,
you've
really
a
new
service
account
or
something
if
that
makes
sense,.
B
E
And
you
can
always
make
escape
hatches
and
stuff
since,
like
our
back
and
support
custom
verbs,
we
could
always
add
in
another
group
like
I'm,
trusting
you
as
an
installer,
so
I
buying
the
in
this
case
operator
installer
verb,
and
that
means
that
hey,
you
are
essentially
admin
for
creating
whatever
you
need
for
this
operator,
so
that
that
controller
can
look
in,
say,
hey!
Oh,
they
have
this
custom
bird
bound
to
them.
Then
they
can
just
create
whatever
and
I'll
use
my
privileges
to
ratchet
up
the
permissions.
B
B
So
say
you
were,
you
know,
managing
the
sealed
secret
operator
and
they
create
a
new
type
of
secret
thing.
You
could
you
could
change
the
are
back
without
having
access
to
the
secret
thing,
which
at
first
sounds
bad
until
you
think
about
the
management
of
the
cluster,
then
it
might
be
kind
of
interesting,
I.
Think.
E
B
B
B
B
E
B
E
G
Also
things
that
are
webhooks
/
plug-in
like
there
is
a
plug-in
where
you
could
use
an
external
provider
that
would
you
basically
have
to
do
SAR
checks
right
to
determine
if
somebody
can
do
a
thing
and
it
runs
through
all
the
different
authorizers.
So
just
getting
the
list
of
roles
and
determining.
If
that's
an
okay
thing,
it's
not
it's
not
necessarily
sufficient
to
cover
all
of
the
the
actual
authorization.
The
cluster
has.
G
B
Sense
to
me
to
still
be
fine,
though,
because,
for
instance
like
it
would
be
for
the
operator
installer
thing
or
if
you're,
oh,
okay,
well,
I,
see
yeah,
you
would
need
to
kind
of
make
a
claim
of
some
sort.
Saying
like
is
the
user
allowed
to
do
this
to
something?
That's,
not
our
back
yeah
and
that's
dimensional.
B
G
I
also
think
that
these
these
problems
start
to
like
our
tackles
after
we
get
kind
of
the
initial
stuff
that
we're
have
been
we're
talking
about
like
as
long
as
we've
like
are
not
boxing
ourselves
and
I.
Don't
I,
don't
think
that
any
of
these
problems
shouldn't
weigh
us
down
with
getting
started
on
building
something
for
cops
and
like
something
that's
more
generic
and
working
on
a
API
like,
in
my
opinion,
I
think
we
could.
We
can
tackle
these
problems
as
we
as
we
get
to
them,
rather
than
starting
out
with
the
entire
world.
G
F
This
looks
super
cool
I'm,
just
thinking
about
like
this
is
a
flow
for
someone
that
is
sort
of
I,
guess,
adding
it
to
an
existing
cluster,
whereas
I
sort
of
imagine
there's
a
there's
another
flow
for
like
the
administrator
setting
it
up
where
they
just
want
their
CNI
provider
to
work
and
don't
want
to
like
approve
the
permissions
or,
like
you
know
what
I'm
saying
where
they
like
want.
They
said
pre
approving
the
Commission's
by
like
having
their
nominee
choice.
B
B
E
I
wonder
if
we
could
do
something
where
we
like
allow
a
preset
service
account
rep
in
the
spec
of
this
and
then
so.
You
can
like
apply
everything
and
apply
your
set
of
permissions
upfront
and
then
now
that
now
that
that
service
account
is
already
bound,
and
it
knows
which
one
it's
going
to
use
and
it
has
the
permissions
to
install
the
things
that
you
assume
that
it
needs
to
install.
B
Because
the
difference
here
in
this
flow
is
because
you're
talking
to
the
privileged
operator
inside
of
the
cluster
through
ACR
and
the
reference
to
the
manifest,
like
is
just
a
string
that
points
to
a
bunch
of
things
from
somewhere
else.
It's
technically
a
form
of
privilege
escalations.
The
thing
that's
installing
the
manifests
is
potentially
more
privileged
than
the
person
editing
the
resource,
yeah
uh-huh.
E
Again,
this
doesn't
need
to
be
like
taking
sort
of
whole
hog,
like
the
I.
Think.
One
of
the
core
concepts
here
is
using
human
type
for
the
content
and
being
able
to
do
something
similar
to
what
me
install
configuration
is
doing
with
different
pipes
and
we
can
tech
on.
Like
that
permission,
approval
and
stuff
later,
like
you,
can
see
a
world
where,
like
the
bar
back
to
create
this
resource,
is
limited
to
certain
people,
and
so
like
it's
an
all-or-nothing.
B
That's
how
close
supply
works
from
the
management
cluster
inside
of
cluster
API?
Is
you
make
the
post
apply
resource?
If
you
have
the
permission
to
do
that,
then
the
privilege
operator
will
go
apply
whatever
you
know
anything
using
admin
credentials
to
the
child
cluster
and
then
it's
a
similar
but
simpler
pattern.
You
know
it's
something
like
coop
idiom,
where
the
thing
that
is
applying
the
resources
is
literally
the
user
running
a
tool
from
outside
of
the
cluster
using
their
own
are
back.
B
So
then
this
this
makes
it
very
op,
more
flexibly
operator
or
more
flexibly,
operable
yeah
from
a
permission
standpoint,
and
then
you
mentioned
that
the
content
basically
you're
having
a
pluggable
type,
and
then
how
is
the
type
in
directed
on
like
how
does
something
else
plug
into
a
different
type?
That's
specified
there.
E
So
there
is
a
light
field
here
that
X
is
the
discriminator.
There
was
a
touch
a
while
back
that
merged
and
also
I
think
the
code
for
it
merged
into
I
want
to
say
the
proper
cogent
libraries
to
do
union
types
on
TV
eyes.
I
haven't
hundred
percent
tested
if
that
works
well,
but
you
basically
specify
that
this
example
somewhere
of
doing
in
line.
E
B
So
this
is
where
the
most
overlap
is
with
the
add-on
installer
config,
because
that's
basically
the
only
type
of
or
that's
the
only
problem
that
that
is
solved
by
the
add-on
and
config
by
now
is
so.
The
library
has
code
inside
of
it
that
interacts
on
the
supported
types,
but
I
wouldn't
say
that
the
library
is
pluggable
right
now.