►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20191029
A
B
A
Welcome
everyone
to
big
cluster
errands
meeting
today
is
the
29th
of
October,
and
let
me
see
just
looking
at
the
action
items
from
last
time,
so
edit
them
already
to
the
to
the
agenda
doc.
So
I
had
an
action
to
share
the
user
stories,
which
I
did
didn't
put
much
more
additional
work
into
it.
Yeah.
Maybe
maybe
people
can
give
feedback
what
they
think
of
them.
A
Lee
had
an
action
to
don't
know
this
Lee
here,
not
yet
all
right,
Kingdom
I
talked
to
him
today,
already,
maybe
he's
going
to
turn
up
in
a
bit.
I
think
the
last
time
he
already
presented
his
cap
for
yellow
means
order
to
be
integrated
in
the
cube
ATM.
With
some
discussion
about
it.
I
had
mentioned
to
look
at
the
queue
builder
patch
and
try
it
out
and
see
what
the
difference
are
with
the
coding
as
operator
I
did
that
as
well?
A
Yes,
all
right,
so
when
slack,
there
was
the
request
to
set
up
a
class
add-ons
face
to
face
meeting,
and
you
can
sort
of
discuss
this,
but
I
don't
think
we
got
anywhere
in
terms
of
which
date
or
time
or
how
people
would
organize
themselves.
I'm
not
going
to
be
there.
Unfortunately,
so
I
can't
the
health
setting
things
up.
I.
B
A
A
C
B
B
A
B
B
A
A
D
D
D
D
D
So
I
think,
depending
on
how
you
use,
it
is
really
whether
or
not
you're
concerned
for
it
being
a
config
map.
Everything
that's
in
there
is
going
to
be
applied
to
the
cluster.
So
it's
just
a
question
of.
Do
you
want
that
visible
in
particular
game
space
as
a
config
map
outside
of
those
objects
or
not
yeah?
That's
certainly.
C
D
A
D
B
B
Think
I
probably
run
the
operators
on
the
cluster
and
they
would
for
those,
there
will
also
be
I.
Think
some
components
well
currently
have
some
components
that
are
sourced
from
the
CLI
and,
as
you
point
out,
that
would
then
require
a
docker
while
the
ability
to
read
a
docker
image,
it
is
not
terribly
difficult
to
read
a
docker
image,
so
we
might
be
able
to
make
that
work.
D
That's
exactly
like
what
I
was
getting
at
is
included,
am
I
think
it
makes
probably
more
sense
because
that's
run
from
the
from
a
control
point
node
at
some
point
for
an
it
like.
You
are
on
the
node,
and
the
coop
in
in
binary
is
operating
in
a
process
on
that
node
in
some
privileged
context,
but
for
cops
you're,
usually
on
an
operator
machine
or
on
on
a
person's
mission
right.
B
And
I
think
I'd
mean
towards
the
cluster
except
I.
Think
the
exception
would
be
if
we're
able
to
like
get
some
information
about
like
what
ports
a
CNI
provider
needs
open.
Right
like
we
have
already
figured
out
what
the
mechanism
is,
but
like
that's,
where
I
can
see
like
us
wanting
to
not
run
that
on
the
cluster
for
security
reasons,
but
to
run
it
in
some
sort
of
external,
like
in
cult
CLI,
for
example,
the.
D
D
Separately
or
did
I
misunderstand
what
actually
I
think
the
problem
comes
from
the
strength
of
referencing
the
images
base,
because
then
I
can
do
that
like
a
regular
file
on
my
local
machine
in
the
case
of
cops,
we're
not
on
the
same
hardware,
not
in
the
same
Linux
kernel
user
spaces
as
the
cluster
itself.
So
if
you
want
to
run
the
installation
in
a
pop
on
the
cluster,
you
need
to
ship
any
of
those
users
supplied
context
over
to
do
the
installation
there.
D
B
These
four
cops,
although
what
you
describe
is
great,
like
I,
don't
think
cops
actually
does
a
great
job
of
that.
Yet
so
it
doesn't
like
it's
actually
not
very
practical
to
like
patch
one
of
the
today
and
it's
not
very
practical
in
cups
to
like
easily
replace
one
bug
to
accord
manifests
or,
or
anything
like
that.
So
we
have
that
coming
for
us
that
we
are,
we
are
less
advanced
than
you
attributed
market.
B
Yeah
I
would
be
good
to
figure
out
a
nice
workflow
so
that
users
could
easily
like
bring
their
own
things,
but
it
sounds
like
you
know
like
creating
an
image
is
not
the
hardest
thing
in
the
world
for
most
users.
So
if
we
can,
I
crap
this
in
some
I
read
in
that
open
ship,
for
example,
already
has
some
nice
tooling.
That
makes
this
not
like
yeah
you're,
not
constructing
tar
files.
I
mentioned
there
were
tar
goals
and
doing
it
by
hand.
I
might
have
a
nice
tooling
somewhere
yeah.
D
And
then
the
same
thing
for
like
repository
off
right,
if
you
just
want
to
push
up
your
add-on
fork
to
your
github
enterprise,
internal
get
depository
or
something
like
that,
then
I.
Imagine
that's
gonna,
be
something
people
reach
for
so
the
network's
solutions
right
like
where
you're
actually
pushing
up
this
package
of
yours
to
an
O
CI
registry
or
a
git
repository
or
HTTP
file,
served
from
some
web
server.
D
All
of
those
things
sound
like
they
would
make
perfect
sense
and
whether
you
were
installing
from
your
laptop
or
from
a
operating
or
job
style
pod
for
the
cops
installation
inside
of
the
cluster
and
then
just
the
only
difference
between
those
two
things
is
that,
like
as
a
user?
If
I
want
to
provide
a
context
that
is
not
served
by
some
registry
repo
or
server,
then
you
need
to
distribute
those
files
to
the
cluster.
D
If
you
want
to
run
the
installation
workload
in
the
cluster
but
and
then
I
I
was
also
listening
carefully
for
the
fact
that
you
said
that,
like
that,
that's
not
a
use
case.
That
cops
is
even
capable
of
doing.
Right
now
is
patching
these
add-ons.
So
as
long
as
there
is
a
way
to
do
it,
then
that's
a
good
thing:
yeah.
B
D
I
am
curious
if
both
of
you
touched
on
this
a
little
bit
I'm
curious.
If
we
think
this
value
and
defining
these
images
such
that
they
don't
require
the
runtime
at
all.
So
there's
two
options:
right
like
we
could
say,
we
specify
a
folder
in
an
image
and
we
treat
the
images
of
normal
container
image
and
you
need
to
runtime
with
a
union
file
system
to
find
out
what
the
final
set
of
manifests
in
that
folder
will
be,
and
the
other
option
is
we're
just
using
the
image
format
as
a
turbo
metadata.
D
B
The
difference
would
be
basically
multi-layer
support
right,
like
great
great
yeah.
We
sure
we
had
indeed
only
have
a
single
layer,
but
I,
don't
imagine
from
a
user
point
of
view
like
I
can
imagine
like
it
would
be
nice
to
just
drop
a
patch
onto
an
existing
there.
So
would
be
nice
if
containing
flattens
it,
but
I.
Imagine
that
you
can
have
a
library
I
haven't
looked
at
like
okay,
like
Creighton
is
my
preferred
library.
B
D
The
main
difference
here
would
be
because
Evan
built
the
the
KPG
demo,
which
does
exactly
that,
which
is
it
uses
a
specific
metadata
layer
that
is
not
for
a
file
system.
It's
just
for
specifying
manifest
or
a
customized
file,
and
then
you
use
the
KPG
library
to
unpack
that
OCI
image
and
get
those
manifests
into
memory
inside
of
your
go
program
so
from
a
technical
standpoint
using
OC
I.
That
way,
which
isn't
supported
to
my
understanding
by
all
registries
right
now
that
is
technically
simple
and
elegant.
D
I,
also
don't
see
why
we
couldn't
support
both
if
that
was
a
reasonable
support
matrix,
but
the
the
main
reason
why
your
current
cap
on
the
open
shift,
earth
I,
don't
know
it.
Openshift
oaep
euro
SEP,
your
current
enhancement
on
that
side
is
using
the
docker
stuff
is
because
it's
easy
for
people
to
build
those
images
with
a
docker
file.
D
C
D
Than
I,
though,
simpler
implementation
or
a
more
accurate
OCI
model,
yeah
right
yeah
I
mean
at
some
point.
It
might
make
sense
to
do
that,
but
just
like
further
record-
and
this
is
kind
of
embarrassing,
but
I-
actually
implemented
add-on
installer
as
like
a
hundred
lion,
bash
script
and
I
I
didn't
check
it
in
anywhere
and
accidentally
deleted
it,
but
it
used
yamaki,
which
is
a
library
but
also
a
command-line
tool.
D
If
you've
never
used,
you
Maki
before
it's
capable
of
unpacking
with
no
container
runtime,
it
just
is
capable
of
operating
on
images,
and
so
you
can
get
like
the
result
of
the
in
file
system
with
like
a
single
CLI
exec
and
that's
the
first
thing,
I
built
I.
Didn't
even
do
the
OCI
label
thing
like
you
guys
had
done
in
the
docker
file,
but
I
just
like
had
a
canonical
directory
called
add-on,
and
if
you
just
yeah
like
if
you
just
put
stuff
in
the
add-on
directory,
then
it
was
part
of
the
manifest
list.
D
Still
have
the
dockerfile
actually
I,
just
don't
have
the
the
install
script
anymore,
but
the
dockerfile
takes
of
our
customized
examples
from
the
main
repository
and
packages
it
into
a
docker
container,
just
using
that
directory.
So
I
am
like
all
about
the
usability
and
I
think
it
makes
sense
to
use
the
docker
file.
D
So
that's
like,
basically,
the
only
real
important
part
about
the
spec
there's
a
little
bit
more
to
it,
for
for
what
we're
using
it
for
and
that
we
needed
a
distinction
between
manifests
that
can
actually
be
applied
to
the
cluster
and
metadata
that
might
changed
the
way
those
manifests
are
are
applied
or
process
I'm.
So
we
leave
this
for
each
of
those.
So
it's
nothing
surprising,
but
there
is.
D
D
D
Have
a
question
that
that
makes
me
think
of
which
is
that
in
the
in
the
install
API
declaration,
I
decided
in
the
kept
to
force
the
user
to
add
names
for
each
thing,
which
I
don't
think
is
unreasonable.
That's
that's
pretty
simple.
It's
maybe
a
little
bit
less
machine
oriented
because
then
you
can't
just
like
add
refs
to
a
list.
I
guess
you
could
generate
IDs
and
they
just
wouldn't
mean
much,
but
should
we
like
have
like
a
default
name
for
an
add-on,
or
is
that
just
kind
of
not
even
that
useful.
D
Because
we
could
shove
that
in
a
label,
but
then
it's
like
as
soon
as
you
start,
extending
the
OCI
images
that
way
you
have
to
have
the
way
to
also
represent
those
things
in
like
a
customized
file
or
like
some
API
object
inside
of
a
git
repo,
like
the
more
that
we
bolt
on
to
the
labels
portion
of
it
that
isn't
just
like
use,
customize
or
use
a
manifest
list,
then
the
more
stuff
we
potentially
need
to
add
to
whatever
is
inflating
the
contents
of
the
add-ons.
D
It
does,
and
that
is
why
we've
at
least
for
this
proposal,
we
try
to
have
the
label
data,
be
the
things
that
tell
you
we're
kind,
other
data
in
the
image
and
the
media.
So
the
way
the
proposal
is
right
now
is
that
there's
a
media
type
that
tells
you
what
the
type
of
this
content
is
and
then
the
value
is
the
location
of
the
image
where
that
concept
exists.
D
Any
any
of
the
metadata
we're
talking
about
could
just
be
a
label.
The
reason
the
like
implementation
reason
why
this
is
less
ideal
for
today's
world
is
that
when
we're
doing
the
on
poster
and
packing,
we
have
another
way
to
get
the
labels
for
an
image
in
communities.
We
have
to
only
pull
the
contents
after
the
fact.
D
So
right
now
we're
sort
of
keeping
those
things
in
sync,
but
it
also
have
the
advantage
of
the
doings
of
more
flexible
I,
certainly
could
see
the
value,
because
I
I
think
it's
been
pretty
loudly
requested
that
we
don't
only
support
customize,
but
that
we
support
the
richness
of
the
ecosystem.
That's
just
using
these
flat
manifests.
Some
of
those
are
just
like
a
single
file,
and
then
some
of
them
are
directories
and
git
repos.
D
C
C
C
D
D
Can
share
it
or
whatever
you
want
yeah,
sometimes
it
only
ever
makes
it
to
this
live
channel,
but
I
think
it
would
probably
be
more
polite.
Since
I've
noticed
when
we
create
issues,
there
are
people
from
different
time
zones
that
have
feedback.
Okay.
So
maybe,
let's
put
that
into
the
cusp
the
OCI
image
issue
that
we
already
have
open.
We
can
link
the
rule
lock.
There.
B
D
D
D
D
D
Doctor
copy
yeah
yeah
like
if
I
dude,
even
just
to
create
and
I,
don't
even
run
a
process
from
an
image
and
then
I
do
a
doctor
copy
of
the
root
filesystem
into
some
directory.
Then
you'll
have
like
an
Etsy
host
file
and
that
kind
of
thing
which
is
its
you
know
interesting,
but
it
might
be
in
the
best
interest
whatever
tooling,
we
have
that.
Maybe
it
encourages
people
to
always
use
folders.
D
Yeah,
if
we
could
get
the
existing
enhancement
contents
into
a
doc
and
then
update
that
on
the
issue
and
just
paying
this,
the
slack
channel
or
cluster
lifecycle
for
some
feedback
once
we
think
it's
starting
to
look
like
how
we
want
then
that'll
that'd
be
a
good
step
to
working
toward
customized
support.
I.
Imagine
that's
going
to
be
like
the
main
edition
and
then
maybe
just
like
label
schema
stuff,
since
most
of
what
we
need
is
probably
already
in
the
cap.
D
D
Future
packaging
approach,
which
is
OCI.
This
is
the
this
basic
idea.
Essentially,
let's
do
what
I
see
is
trying
to
do,
but
without
making
these
things
not
actually
docker
images,
we're
still
gonna
just
use,
actual
docker
images,
and
then
the
OCC
I
expect
is
all
about
changing
what
the
way
you
interpret
the
layers
that
are
listed
and
allowing
like
multiple
nesting
of
those
things.
D
D
Media
types
and
all
the
all
of
the
current
UCI
they
get
extra,
basically
the
same
as
the
documents,
so
they
don't,
they
don't
allow
for
different
interpretation
of
the
content,
but
I
think
that
that's
where
almost
going
things
I
believe
that
they're
trying
to
define
new
media
types
last,
a
change
yeah.
That's
that's!
My
understanding
is
that
if
you
package
a
chart
and
then
OCI
images,
not
using
the
file
system
layers.
D
D
D
D
Cluster
Anton's
janda
see
yeah,
so
we
talked
about
setting
up
a
time
to
meet
and
Justin
both
going
to
take
that
and
then
now
we're
talking
about
the
the
OCI
image
stuff
and
we're
gonna
get
the
Google
Doc
up.
But
we
didn't
talk
about
anything
else,
technical,
so
I,
maybe
just
a
helpful,
like
high-level
overview
where
everything
is
the.
D
D
Assuming
things
are
going
well,
there
will
have
a
way
to
get
stuff
into
a
cluster.
That's
using
customized
and
plain
manifests,
which
means
that
we
support
regular
files
that
people
have.
We
support
things
over
an
HTTP
server,
and
then
we
have
git
repos
and
sub
directories
of
git
repos.
So
it's
already
pretty
powerful.
D
D
We'll
need
some
way
to
consume
that
in
a
library
format,
we've
talked
about
some
ways
to
do
that,
either
using
the
runtime,
that's
on
a
person's
computer
or
in
a
cluster,
or
just
using
tools
like
the
yamaki
library,
OCI
and
then
now
that
we
have
a
way
to
package
things.
D
So
they've
been
working
on
a
coop
proxy
operator,
technical
details
of
which
will
be
more
involved,
as
well
as
the
core
DNS
operator,
based
off
of
the
coop
builder
updates
that
are
going
into
the
v2
branch.
So
the
coop
builder
v2
stuff
will
enable
us
to
do
things
in
a
better
way
and
we'll
create
the
core
DNS
operator,
as
well
as
the
what
is
it
the
node
local
DNS
operator,
and
these
are
examples
then,
of
packages
that
we
could
install.
D
That
would
result
in
non-trivial
behavior
inside
of
the
cluster,
so
the
user
would
modify
their
installer
configuration
API
pass
that
to
the
installer
tool.
It
invokes
the
library
it's
able
to
fetch
the
add-on,
either
as
a
manifest
or
customized
directory
from
the
four
different
packaging
formats,
a
folder
server,
OCI
and
git
repo,
and
then
that
gets
inflated
into
the
cluster
using
the
privileged
permissions
of
the
privileged
are
back
that
is
available
from
two
cluster
installer,
be
it
cop,
Scooby,
damn
ETS
cuddle
and
then
the
add-on
gets
into
the
cluster.
C
D
D
D
D
D
Cool,
so
that's
where
my
understanding
is
from
like
a
project
management
perspective
and
if
we
can,
as
long
as
I'll
make
sure
to
write
that
up
and
let's
we
can
get
some
asynchronous
feedback,
just
make
sure
that
no
one's
seeing
shortcomings
or
having
any
issues
with
the
way
that
things
are
moving.
And
then,
ideally,
we
can
take
kind
of
these
3
streams
to
work
that
are
happening
right
now
and
build
something
cohesive
for
users.
D
D
Well,
I
imagine
Justin's,
probably
often
library,
land,
reading
the
ìmake
code
now
and
I.
Don't
think
we
have
anything
else
on
the
agenda.
So
if
we
get
that
date
on
the
calendar,
get
the
kept
start,
collaborating
on
a
Google
Doc
for
it,
and
then
I
will
do
that
small
write-up
then
all
have
made
pretty
good
progress.
We
can
probably
close
this
meeting
out
unless
anybody
else
has
something
I
want
to
bring
up.