►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20191112
A
Hello
welcome
everyone
to
the
cluster
announce
meeting.
It
is
the
12th
of
November
and
we
have
a
couple
of
things
on
the
agenda
actions
from
last
time.
So
we
had
a
couple
of
things
for
the
cook
on
face
to
face
meeting.
Did
we
decide
on
anything
there?
I
noticed
there
was
also
a
question
on
slack
from
somebody,
so
we
still
going
to
announce
it
during
the
contributors
image
like
where
everyone
is
going
to
meet
or
which
I.
B
C
Would
be
excellent,
especially
you
know
getting
early
on
in
the
conference
in
front
of
each
other
and
then
even
before
that
on
Monday
right
we
have
the
contribs
Amit.
So
we
have
our
sig
update
on
I
haven't
talked
with
Timothy.
He
hasn't
asked
anybody
for
slides,
but
I
think
eventually
we're
probably
gonna
need
something.
So
I
will
mention.
F
G
C
You
and
then
yeah
we
kinda
have
to
full
disclosure
for
anyone
watching
the
recording
is
we're
kind
of
repeating
things
that
we
accidentally
started.
Talking
about
before
the
recording
and
then
Justin.
You
mentioned
one
thing,
which
is
not
a
particular
action
item,
but
you
said
you
were
working
on
the
Multi.
B
F
B
Still
trying
to
figure
out
how
to
get
it,
but
it
is
pretty
straightforward,
but
I'm
still
trying
to
figure
to
get
that
into
cops
I'm.
What
the
right
way
to
do
that
is,
but,
like
maybe
by
cube
club,
we
will
have
some
PRS
that
show
a
at
least
a
flow
into
into
cops,
which
hopefully
then
we
can
talk
about
like
how
that
compares
with
like
the
Covidien
plus
and
that.
B
C
B
C
B
C
It's
that's
a
fine
default
to
start
out.
It's
also
stuff
right,
I'm,
doing
the
exact
same
thing
for
qu
proxy,
actually,
I
know
Jeff
you're
on
the
call.
If
you
wanted,
if
we
can
talk
about
qu
proxy
operator
in
a
moment,
maybe
discuss
through
some
stuff
there,
but
yeah
as
far
as
I'll
just
mention
here
that
the
node
local
DNS
stuff
has
minimal
need
for
user
supplied
fields
and
then
I'll
mention
yeah,
DNS
IP
can
be
inferred.
B
Yes,
yeah,
there
is
actually
there's
a
relatively
interesting
there's,
a
more
interesting
thing
in
the
notable
DNS.
The
original
configuration
of
it
used
a
would
replace
the
DNS
server
IP
pass
to
the
cubelet
to
point
to
the
node
local.
That
is
super
hard
to
do.
I,
don't
think
we
actually
need
to
do
that
anymore,
because
I
think
we
can
get.
B
We
can
do
with
IP
tables
rules
which
is
I,
think
is
actually
current,
encourage
configuration,
but
yes,
if
so
for
v-0
I
am
just
trying
to
like
get
away
without
those
changes,
but
there's
another
one
of
these,
like
you
know,
calico
needs
to,
or
we've
needs
to
open
certain
ports.
In
this
case,
this
operator
needs
to
configure
something
on
cubelet,
a
sort
of
action
and
distance
type
thing.
So.
C
Yeah,
there's
probably
like
a
lot
of
different
ways
to
configure
the
routing
and
fallback
and
all
that
I
remember
reading
through
the
dock,
with
all
the
proposals
for
the
local
DNS,
particularly
when
it
comes
to
H
a
and
evicting
those
pods.
It's
like
really
weird
what
the
failure
mode
should
be
so,
but
that
that's
potentially
something
that
could
have
like
some
same
configuration
paths
for
a
user
or
maybe
something
will
magically
emerge.
B
C
E
C
If
you
have
anything
on
that,
you
wanted
to
discuss.
Jeff
I
wanted
to
give
you
a
chance,
because
I've
been
looking
at
crude
proxy
now
that
the
COO
vidiian
work
is
starting
to
be
more
mature
from
a
like
an
instrumentation
side.
I,
don't
know
if
you've
kept
playing
with
this,
because
it
is
a
little
bit
of
learning
problem
that
you
were
pretty
emphatic
about
it
like
one
or
two
meetings
ago.
Yes,.
D
I
have
locally
I,
have
a
Q
proxy
that
I
can
spin
up
like
a
kinder
cluster,
which
was
really
fun
thanks
for
that
tip.
It's
really
great
for
this
kind
of
development.
We
can
spin
up
a
kinder
cluster,
run
the
cube
proxy
operator
locally,
like
on
my
machine
and
then
deploy
keep
proxy
that
way
and
the
only
big
work
there
and
when
I
say
big
I
think
it's
just
a
couple.
Little
tweaks
to
the
operator
manifest
is
just
to
get
it
to
schedule
on
the
cluster
when
the
cost
doesn't
want
a
scheduled
staff.
Basically,.
C
D
C
Localhost
to
get
to
the
API
server
is
the
server
usually
listening
on
that
interface
and
does
it
validate
HTTP
on
localhost
thanks
Wikipedia
I'm,
install
I,
know,
there's
been
like
weirdness
in
this
area
for
several
Covidien
releases,
where
the
the
UX
for
localhost
stuff
it
even
was
broken
in
115.
Oh
god,.
C
Yeah
it
was
like
if
you
wanted
the
API
server
to
only
listen
on
the
local
host
address.
Kuba
Tim
was
doing
things
to
IP
addresses
where
that
was
a
non-functional
branch.
Basically
it
would
it
would
exit
calling
you
your
requests
like,
but
maybe
maybe,
when
it's
just
using
the
default
behavior
it
listens
on
all
interfaces
and
localhost
is
part
of
the
sands
for
the
HTTP
stuff,
okay,
cool
I'll,
just
add
here
or
local
O's
I
will.
D
C
So
this
kind
of
coup
proxy
operator
will
only
function
when
you
can
schedule
to
the
same
infrastructure
and
network
main
space
of
the
control
plane
nodes
right.
So
it
is
there
something
you
want.
The
operator
pod
to
land.
C
C
Say
anything
I
will
be
wrong,
so
I
don't
have
to
change.
Okay.
The
only
other
thing
I
can
think
of
this.
Coop
proxy
is
kind
of
similar
to
the
couplet
right.
In
that
it's
it's
a
component
that
needs
to
talk
directly
to
the
API
server
right,
since
it's
neither
the
couplet,
Northey
or
nor
coop
proxy
can
depend
on
the
assistance
of
cluster
ip's
being
routable.
C
D
C
D
C
I
would
imagine
that
your
coop
can
fake
from
the
service.
Account
is
going
to
look
the
same
as
any
other
pod,
because
it,
if
you're
hosting
it
on
some
worker,
then
like
you,
don't
have
any
kind
of
local
access
to
an
API
server.
You're
gonna
want
to
go
through
the
East
service,
the
default
service,
so
that
mechanism
is
dependent
that
something
has
made
that
service
routable,
probably
coop
proxy.
On
that
same
node,
the
coop
proxy
is,
is
a
node
topology
add-on
right.
C
C
F
D
C
Yeah
then,
you
would
still
just
use
the
operator
to
create
the
daemon
set,
because
I
mean,
if
you're
asking
the
user
to
supply
the
IP.
You
could
just
create
the
daemon
set
directly
from
the
add-on,
yeah
yeah,
okay,
cool
kind
of
just
thinking
through
things
here,
I've
been
trying
to
decipher
what,
like
the
simplest
and
most
user-friendly
way
for
a
user
to
supply
an
argument
to
an
add-on.
Is
it's
something
like
helm
or
Jason?
Net
like
this
is
super
easy
but
customized.
It's
like
not
really
meant
to
do
that,
like
everything
is
patches.
C
There's
no
like
way
to
say,
like
hey,
here's,
a
structured
list
of
five
things
with
names
now
put
them
into
my
manifests,
so
I
can
think
of
something
happy
with
like
config,
Maps
and
variables,
but
but
we'll
see
where
that
ends
up.
I
might
write
a
coup
proxy
add-on
that
doesn't
depend
on
an
operator
and
we'll
see
if
it
works.
C
C
Okay,
well,
we
talked
a
little
bit
about
the
coup
proxy
problem
statement
and
all
that,
so
we
can
probably
move
on
if
Jeff
doesn't
come
back
thanks
to
Jeff.
A
C
This
yeah,
it's
so
our
code,
freeze
for
being
the
core
kubernetes
repo
is
gonna,
be
two
days
from
now,
I
believe
firm.
Remember
correctly,
it's
either
two
or
six
days
from
now,
yeah
I
think
it's
the
14th
yeah
and
so
two
days
from
now,
and
so
we
don't,
we
don't
have
like
really
any
restrictions
like
what
we
can
hard
repository.
But
if
we
want
to
do
things
in
cubed
am
before
then,
which
may
or
may
not
be
feasible
depending
on
people's
review
bandwidth,
then
it's
we
may
not
make
117.
C
C
Yeah
but
the
the
add-on,
installer
library
I
pushed
some
patches
to
it
last
week
and
this
morning
that
basically
fixed
the
coop
config
stuff,
implement
the
change
that
Jessica
and
pointed
out
that
Jeff
also
pointed
out,
which
is
the
extensions
kate's
IO
namespace
for
the
config,
and
then
that
example,
that
Daniel
was
showing
you
just
had
a
list
of
strings,
but
the
config
in
the
newer
version
of
the
library
is
now
structured
a
little
more.
So
the
add-ons
have
names
and
different
kinds
of
references
that
you
can
cast.
C
One
is
just
the
plain
manifest,
so
it
now
supports
like
manifests
that
aren't
customized
and
as
well
as
directories
that
are
not
customized.
Just
like
directories
of
manifests
both
of
those
are
very
common,
so
scripting
to
be
able
to
support
for
users
and
then
I,
just
added
a
delete
function
and
added
like
support
for
recursive
stuff.
C
I.
Have
this
now
plumbing
into
kuba,
DM
and
I.
Just
need
to
open
up
a
patch
and
things
are
things
are
working
so
I
wanna
its
pull
25
on
the
admin
operators
repository
which
I
believe
Daniels
linked
and
I
want
to
merge
this
so
that
we
can
actually
use
the
library
without
having
to
reference
my
fork,
but
I
definitely
wasn't
gonna.
Do
that
without
at
least
letting
somebody
say
something
I've
done
my
best
to
implement
the
feedback.
So
let
me
know
if
anyone's
got
any
reservations
or
comments.
B
C
It's
yeah,
so
it
doesn't
happen,
a
strict
opinion
about
like
whether
or
not
to
use
an
operator
or
not.
It's
should
support
basically
people
extending
the
add-on
in
whatever
way
they
see
fit.
So
if
they
want
to
copy
a
manifest
and
post
it
on
an
HTTP
server
or
in
a
bucket,
they
can
do
that
if
they
want
to
use
a
git
repository,
that's
probably
a
common
method,
but
we
need
some
place
like
if
you
want
to
install
anything
into
a
cluster.
We
need
some
place
to
have
those
definitions.
C
We
need
a
place
that
has
a
pluggable
like
user
editable
list
of
things,
so
they
add-on
installer
configuration
and
the
library
are
intended
to
be
imported.
All
ven,
durable
implementation
of
the
configuration
and
the
mechanism
for
applying
those
things
to
the
cluster
for
simplicity,
it
shells
out
to
coop
Cpl,
and
because
now
we
have
the
ability
to
use
existing
manifests.
We
have
support
for
add-ons
in
that
fashion.
People
are
distributing
them
already
and
then
there's
the
customized
thing
which
has
upstream
supporting
groups
ETL.
That's
really
the
only
reason
we
chose
and
then
so.
C
How
does
it
bridge
to
core
DNS
operator
right?
We
could
have
add-on
operators,
we
already
have
to
a
git
repository
right,
so
we
can
tag
in
our
git
repository.
We
can
reference
the
subdirectory.
We
can
put
a
customized
Durer
there
and
then
that
folder,
fork
or
DNS
operator
would
have
our
back
split
out
into
its
own
thing.
You
could
have
different
patched
directories
for
different
use
cases,
and
then
it
would
have
the
manifests
and
the
are
back
necessary
for
the
operator
to
run
and
then
and
manage
it.
C
Something
one
of
our
patch
directories
could
be
like
the
defaults
custom
resource
right
patched
into
the
operator
right.
So
the
operator
itself,
when
you
deploy
it,
is
not
going
to
do
anything
right.
You
need
to
put
a
custom
resource
into
the
cluster.
We
can
do
their
deploy
that
as
a
patch
or
as
a
separate
add-on.
B
Thank
you,
I
mean
to
me.
This
feels
useful
and
additive
to
or
like
separate
from
what
we're
doing
like
it
is.
It
is
a
very
important
mechanism
for
installing
arbitary
manifests
and
we
should
have
it
for,
like
it'll,
be
great
for
installing
out
like
end
user
applications,
and
it
will
be
great
for
installing
the
operators,
as
you
say,
I
do
think
we
still
want
and
like
and
cops
has
a
similar
but
more
limited
field
where
you
can
like
specify
a
list
of
URLs
right
so,
like
that
does
add
URLs.
B
That
should
be
done
applied
to
the
question
when
it
comes
up,
so
this
does
feel
like
a
like
a
something
that
should
exist
right.
Having
a
standard
for
this
is
great,
I
feel
like
we
also
want.
We
still
want
it.
We
still
want
operators,
and
we
still
want
CID-
is
to
be
like
a
a
smoother
smoother
affair.
But
you
know
like
a
first-class
operation,
where
you
know
you
have
to
patch
them.
In
my
opinion,.
C
B
B
Change
the
operator
great
right,
like
I,
should
we
should
be
able
to
do
that,
but
I
shouldn't
have
to
like
get
like
really
stuck
into
things.
If
that's,
what
I
want
to
do?
I
should
just
be
like
yep
I
want
to
turn
on
their
local
DNS,
so
we'll
see
discussions
to
be
had
when
a
direct,
but
in
some
way
I
drop
in
a
llamar
which
just
has
that
or
it
was
had
a
yams
block.
Uh-Huh.
C
That
is
a
that
is
a
really
good
point
on
usability.
I.
Don't
think.
We've
ever
said
that
out
loud
before.
So
thank
you
for
saying
that
not
locked,
yeah.
G
C
C
C
B
The
upper
yes
I
agree
with
that
and
I
think
it's
super
important
for
other
reasons
as
well
to
be
able
to
overwrite
that,
like
it,
we
we
don't
want
to
do
all
this
work
only
to
then
become
the
bottleneck
on
the
operator
but
yeah
site,
but
I.
Don't
think
that
should
preclude
being
able
to
have
defaults.
I
would
like
to
make
that
as
pluggable
and
replaceable
as
we
can
possibly
imagine,
but
yeah
I
mean
I,
don't
know.
C
Yeah
one
thing
that
is
not
supported
right
now
in
the
add-on
library
is
the
inline
patching
which
I
think
for
what
you're
talking
about
is
one
of
the
more
important
use
cases,
because
then
it
allows
you
to
just
in
your
add-on
install
configuration
just
paste
the
custom
resource
directly
into
whatever
you're
doing
so.
That
is.
C
C
Because
that
would
that
could
be
a
place
right
where
it's
like
I
have
my
two
line.
Definition
that
says
please
install
core
DNS
operator
right
and
then
I
have
the
next
add-on
is
a
string
that
I
pasted
in
for
the
custom
resource,
and
that's
not
that
much
more
than
just
pasting
in
the
custom
resource.
It's
just
a
few
lines
and
a
little
bit
of
key
value
pairs
which,
if
it's
in
a
readme,
should
be
pretty
usable
for
people
I.
B
Think
I
guess
when
it
comes
to
PS,
25
I
will
take
another
another
look:
I
am
in
favor
of
merging
it
as
long
as
like
I
think
it's
a
valuable
feature
and
I
think
we
should
standardize.
This
I
think
we.
We
also
want
a
flow
for
like
a
more
direct
flow
or
a
flow
where
I
can
put
my
easier
D's
in
there,
but
we
can
start
with
25
and
I.
Think
it's
a
valuable
feature
that
we
should
get
out
there
I
heard.
F
D
C
One
thing
that
I've
kept
in
mind
is
that,
like,
if
you've
got
a
bundle
of
stuff,
Coop's
ETL
will
apply
the
CR
DS
first,
so
that
that
means
that
you
don't
have
to
like
worry
about
any
adding
any
kind
of
special
handling
right.
That
is
gonna.
Make
sure
that
that
CR
de
that
the
API
is
registered
before
you
can
apply
the
custom
resource.
C
So
that's
a
that's.
Definitely
something
I
kept
in
mind
right
like
okay.
Well,
if
we
build
this
generic
thing,
is
it
gonna,
like
through
a
fairly
minimal
declaration,
actually
get
everything
the
operator
needs
into?
The
cluster
has
been
a
big
concern
of
mine.
I
would
like
to
see
if
with
like,
maybe
a
follow
up
PR
for
the
inline
patching.
C
If
we
can
use
the
the
library
and
provide
some
examples
of
like
hey,
this
is
a
minimum
flow
for
like
how
we
can
get
a
user
to
specify
their
the
custom
resources
they
want
into
the
cluster
and
actually
have
them
be
backed
by
an
operator
that
was
previously
not
going
to
be
installed.
Cuz.
That's
ultimately,
I
think
what
Justin
what
you're
describing
right
is.
C
B
Like
yes,
I
would
say,
the
observation
would
be
an
instance
of
the
CRD
is
sufficient
to
know
that
we
want
an
operator
for
it,
but
there
there's
an
intent
to
student,
so
the
operator
and
we
could
like
in
we
could
choose
to
infer
that
and
it
brings
challenges
around
like.
Are
we
creating
a
like
first
class
and
second
class
er
these
and
all
this
sort
of
stuff,
but
like
that's,
that's
the
sort
of
Upton
for
user
experience
that
I
would
like
to
see
yeah.
C
I
mean
if
there
was
like
a
network
accessible
place
it
just
it
gets
tricky,
because
some
of
these
tools
are
supposed
to
work
offline
right.
So
it's
in
in
the
offline
you
know
category
you
either
requesting
the
user
to
like
pull
a
map
from
somewhere
or
the
map
needs
to
be
built
into
the
binary.
E
F
B
C
I
mean
if
the
map
is
extensible
and
well
documented
and
everywhere
that
you,
you
know,
find
an
operator
there's
a
good
chance
that
the
readme
says
add
this
to
your
map.
Then
I
could
see
that
being
kind
of
helpful
I.
Don't
know
how
much
more
helpful
that
is
of
like
having
the
kind
to
operator
mapping
than
it
is
to
just
supply
in
the
list
of
add-ons
hey.
Give
me
this
thing.
That's
fair
I
do
so.
C
I
will
say
that,
like
kuba,
TM
already
has
like
first-class
support
for
the
coop
proxy
configuration,
which
is
technically
like
a
that's
more
first-class
right.
Then
something
else
and
that
like
if
you
pass
in
a
coop
proxy
config
with
like
your
multi
doc,
Koopa
Dame
config,
like
that'll,
plum
through.
So
that's
that
like
if
you
wanted
to
support
node
local
DNS
through
its
CRD
and
then
have
that
be
like
imported
inside
of
cops
and
then
just
like.
C
C
Cluster
without
a
core
DNS
and
coup
proxy
is
not
what
most
people
want.
Most
people
want,
those
two
things
at
least,
and
then
probably
some
CNI
on
top
of
it,
but
so
the
default
behavior
in
Cuba
team
has
traditionally
been
to
install
those
two
add-ons
from
the
hard-coded
manifests
and
if
you
enable
the
feature
gate,
the
intention
is
that
those
two
add-ons
will
still
get
installed,
but
instead
of
using
the
hard-coded
code
paths,
they
will
actually
default
to
an
add-on,
installer
configuration
that
is
useful,
so
I
could
see
the
logic
being
like
okay.
C
B
C
To
share
what
the
kuben
mu-x
would
be
with
the
existing
things
that
are
already
in
coup
DM.
The
cap
specifies
that
we
have
us.
We
already
have
a
sub
command
called
cubed
and
config,
and
it
allows
you
to
print
defaults
for
various
configuration
types,
so
you
could
pass
it
your
intended
cluster
configuration
and
ask
it
to
print
your
add-on,
installer
defaults
right
so
that
that
allows
the
user
to
then
say:
okay.
C
Well,
what
would
cops
do
right
if
I
was
doing
nothing
but
I
wanted
it
to
do
these
things,
and
then
you
can
get
out
a
very
specific
add-on
installed
configuration
that
has
all
of
the
cops
defaults
for
your
specific
use
case,
and
then
now
you
can
take
that
dynamic
defaults.
They've
been
serialized
for
you,
you
can
ad-lib
onto
it
when
you
pass
that
back
to
cops
in
your
next
run.
Cops
is
like.
Oh
the
users
asking
me
to
do
something
very
special
I'm
not
going
interfere.
C
C
My
thoughts
are
maybe,
if
I
can
convince
like
glue,
gloomier
or
Fabricio
to
to
help
with
a
review
and
I'm
looking
to
get
a
patch
up
this
afternoon
and
we'll
post
in
both
channels
when
that's
up.
If
anyone
is
curious
about
what
the
integration
code
looks
like
for
all
of
that,
UX.
A
Super
dude,
like
I,
think
the
last
time
we
talked
you
had
a
clothings.
He
still
wanted
to
do
or
you
would
like
to
land
later.
Maybe
if
we
had
like
a
short
shopping
list
of
this,
we
could
say
like
okay
for
vision,
one
want
to
land
this
and
because
the
feature
is
going
to
be
hidden
behind
a
feature
gate
anyway.
A
C
I
can
agree
with
that.
I
think
that
what
is
ready
to
be
patched
into
Covidien
is
already
useful.
It's
missing
some
meat
from
a
usability
perspective
like
for
the
config
stuff,
so
it
needs
to
be
able
to
like
prune
stuff
from
an
old
config.
A
You
can
see
how,
like
we
can
all
see
the
individual
things
that
are
still
missing
and
would
be
great
to
have.
You
know
like
I,
come
from
the
other
side
of
the
spectrum,
where
just
you
know
build
this
small
demo
and
I'm
super
excited
and
feel
like.
Would
you
be
looking
at
this
and
I
think
it
would
be
nice
to
at
some
stage,
get
a
blog
post
out
and
say
like
okay?
This
is
the
stuff
that
is
already
yeah.
A
C
You
know
those
those
add-on
definitions
and
get
no
local
DNS
without
any
user
intervention
or
operator
intervention.
So
yeah
folks
have
wanted
support
for
that
for
a
really
long
time
so
being
able
to
even
just
have
an
experimental
feature
where
people
can
get
to
a
cluster
with
that
installed
in
a
simple
manner
is
something
worth
talking
about
for
sure.
Blog
post,
mailing
list,
yeah
side
conversations
at
coop
con.
C
Justin,
if
you,
if
you
have
a
repo
for
that
somewhere,
it
would
be
great
to
add
it
to
the
meeting
notes.
I
will
definitely
take
a
look
at
it.
I'm.
C
Cool
yeah
I
mean
it
I
guess
if
that
PR
shows
up
sometime
this
week,
I
rolled
I'll
probably
look
at
doing
an
add-on,
installer
demo,
and
then
maybe
we
can
talk
about
the
UX
a
little
bit
more
messy.
F
C
C
B
C
F
E
C
C
B
C
No,
it
wasn't
Red
Hat
that
did
that
it's
called
shell
operator
and
if
I
remember
correctly,
it
might
have
been
the
kin
Volk
folks,
okay
yeah
shell
operator,
it
was
pretty.
C
C
Well,
I
I
would
just
say
like
thanks
to
everyone,
who's
been
joining.
These
calls
consistently
like
staying
up
to
date,
with
the
work
that
we've
been
putting
in
here.
I
think
that
the
way
we've
governed
this
kind
of
sub
project
has
been
very
open.
There's
a
lot
of
cross
collaboration
from
folks
different
organizations,
good
participation
and
I'm
just
really
really
proud
and
grateful
to
be
jumping
on
these
calls
and
working
with
all
of
you.
So
thanks
so
much
yeah.