►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20210302
B
Had
on
that
yeah,
I
just
started
the
recording
welcome
everyone.
This
is
the
cluster
add-ons
meeting
today
is
tuesday,
the
2nd
of
march.
B
A
Updates
yeah,
I
mean,
I
think
the
I
don't
have
any
updates,
but
it
just
seems
like
the
primary
effort
that
we
would
be
working
on
would
be
just
efforts
around
manifest
bundle
and
centralizing
or
providing
like
a
community
like
resource
in
place
for
those
bundles
to
be
indexed.
A
So
I
definitely
see
that
work,
that's
something
that
could
be
quite
important.
A
As
a
building
block
for
sharing
sources
objects
and
configuration
in
a
cloud-native
way,
it
could
be
pretty
compelling
to
work
towards
getting
a
gsoc
proposal
for
manifest
bundles,
but
this
is
really
just
about
what
the
group
thinks.
As
far
as
supporting
that
effort,
is
this,
just
like
a
temperature
check,
like
we've,
been
at
the
cluster
add-ons
effort
and
produced
some
meaningful
things
over
the
past?
What
year
and
a
half?
A
A
A
Explicitly
enough
yeah,
I
mean
sure
justin.
If
you
have
comments
on
my
posited
inquiry.
C
I
can
go
otherwise
I
mean
I
think
I
for
me.
I
think
that
the
thing
I
really
want
to
see
happen
is
like
for
us
to
get
it
into
from
my
perspective,
chaos,
but
like
other
tooling
generally,
and
I
feel
like
that,
will
be
when
a
lot
of
our
hard
work
sort
of
pays
off
and
we
sort
of
start
to
see
it
used
in
in
reality.
So
that's
where
I'm
very
much
focused,
and
I
don't
know
to
what
extent
that's
something
that
a
a
gsoc
person
can
necessarily
address.
C
B
Work
prakash,
you
raised
your
hand.
D
Yeah,
I
did
I
just
wanted
to
know:
are
there
any
interns
who
are
going
to
participate
from
our
side
in
this
cluster
addon
areas
for
gsoc.
B
So
it
looks
like
next
week
only
the
organizations
will
be
announced
and
after
that
it
will
be
our
turn
to
put
in
a
proposal
for
project
or
many
proposals
if
we
have
enough
mentors
but
right
now,
it's
not
even
clear
that
I
mean
it's
very
likely,
but
it's
not
announced
yet
that
the
cncf
will
participate
as
a
as
a
project.
So
we're
we're
well
ahead
of
of
schedule
right
now,.
B
For
that
yeah
I
can
share
the
link
to
the
the
timeline.
So
it's
going
to
be
a
a
couple
of
weeks.
Still,
what
does
it
say?
It
says
the
students
would
only
be
announced
in
may
may
17th,
so
quite
a
while.
Until
then.
A
I
certainly
see
like
a
lot
of
opportunities
as
well
prakash,
if
you
have
ideas
about
things
that
you
would
like
to
be
like
to
see
happen
with
like
something
that
is
approachable
for
an
intern
type.
Individual
likes
touchy
was
last
year
to
you,
know,
be
successful
in
a
mutual
kind
of
partnership.
With
this
group
come
up
with
those
ideas
you
know,
let's,
let's
get
them
documented,
so
we
can
propose
them
and
if
you're,
if
you'd
like
to
be
involved,
you
know
in
reviewing
or
mentoring
just
yeah.
D
Sure
I
I
am
looking
at
cluster
api
in
relation
to
openstack
provider.
So
there
is
anything
that
comes
up
there
like.
I
am
thinking
like
what
happens.
Example,
okay,
I'll
just
give
you.
If
you
give
me
a
minute,
so
you
have
a
design,
let's
say
for
data
centers
and
you
have
openstack
being
used
and
your
kubernetes
being
used.
So
whether
we
are
doing
open
stack
over
kubernetes
or
we
are
doing
kubernetes
over
openstack.
The
two
are
two
cams:
are
there
and
you
deal
with
kubernetes
at
the
cluster
level?
D
Okay,
but
you
deal
with
the
multiple
cluster
at
cluster
api
level.
So
the
issue
is:
should
a
design
of
cluster
api
be
single
cluster,
to
connect
hundreds
of
data
centers
like
a
campus
data
centers,
or
should
it
be
focused
on
multiple
clusters?
And
if
you
do
multiple
cluster,
what
is
the
definition
of
a
cell?
D
D
Whereas
so
I
have
assigned
to
two
of
the
students
in
one
of
the
universities
in
india
to
investigate
into
it
and,
if
possible,
we'll
see
how
we
can
connect
that
so
goal
is.
Can
I
have
a
proper
definition
of
what
is
the
control
of
clusters?
D
Should
it
be
based
on
both
being
loosely
coupled
in
the
sense
that
kubernetes
clusters
keep
themselves
themselves,
openstack
keep
themselves
only
vm
based.
So
what
is
the
advantage,
and
what
should
we
focus
on?
That's
what
I
am
trying
to
arrive
at?
I
don't
know
the
answer,
but
if
I
am
able
to
articulate
it
correctly,
then
only
I
should
get
in,
but
I
will
try
my
best
what
I
can
do.
A
Yeah
a
little
bit
of
that
overview,
I
have
not
thought
about
openstack
in
quite
a
long
time,
and
certainly
you
know
there
are
many
large
environments-
you're,
probably
working
in
one
of
those
yeah.
So
I
took
some
notes
just
on
a
little
bit
of
what
you're
thinking
about
so.
D
As
the
baseline,
where
you
have
kubernetes
being
used
inside
the
vms,
and
we
want
to
go
the
other
way
around,
like
you,
use
kubernetes
as
the
control,
plane
and
management
plane
and
then
focus
on
openstack
containerized
version
and
then
go
with
that
concept,
how
will
it
turn
out,
or
should
it
not
be
either
way?
Should
it
be
okay
or
ko
or
neither
of
them,
that's
the
dilemma
I
have,
and
I
want
to
get
that
cleaned
out.
If
I
can
and
if
I.
A
Know
that
there
are,
there
was
an
old
project.
A
friend
of
mine,
brandon,
jose
his
handle
is
vicodin
with,
like
alternating
lead
speak
in
it.
A
He
used
to
work
on
a
project
called
openstack
helm,
which
is
a
fairly
mature
helm,
chart
that
packages
almost
openstack
to
be
able
to
run
on
top
of
kubernetes,
and
I
think
they
demo
actually
a
live
migration
on
on
top
of
an
openstack
installation,
kubernetes
cluster.
A
But
this
raises,
like
kind
of
the
question
of
packaging
needs,
that's
a
little
bit
of
where
the
crosstalk
happens
here.
The
design
of
this.
So
you
mentioned
that
you're
already
working
with
some
interns
to
kind
of
help
them
contribute
in
the
area
of
the
kind
of
topology
infrastructure,
design,
considerations
right.
D
A
A
I'm
not
sure
if
the
project
is
still
maintained,
but
it
was
two
years
ago
so
and
it's
yeah
very
non-trivial
set
of
package
charts
if
you
yeah.
If
your
students
need
support
with
regard
to
packaging,
they
certainly
could
bring
up
those
topics
here,
join
the
call
you
know
we
can
talk
through
that.
A
Yeah,
from
my
perspective,
for
sure,
is
what
I
would
like
to
see
is
I
I
really
should
be
contributing
more
to
the
specification
for
the
manifest
bundles
inspiration
being
that
in
flux,
v2,
we
have
source
controller
source
controller
is
responsible
for
fetching
all
of
the
things
into
a
format
that
the
other
reconciling
type
controllers,
like
customize,
controller
and
home
controller
inside
of
flux.
A
You
know
they
basically
talk
to
source
controller
storage
and
are
able
to
use
the
artifacts
there
right
and
the
so.
This
allows
us
to
have
a
nice
separation
and
yeah
support
for
the
oci,
bundles
right
or
the
you
know.
The
docker
manifest
images
you
know
inside
of
flux
would
be,
I
think,
quite
powerful,
particularly
for
better
metal
installations,
but
that's
not
the
only
use
case.
You
know
anyone
definitely
interested
in
that's
a
new
area
of
work
that
could
develop.
A
This
is
something
that
you
know.
If
we
had
the
spec
by
summer,
we
could
potentially
work
with
the
right
google
summer
of
code
candidate.
D
Yeah,
it's
a
possibility,
so
is
prakash,
sorry
for
the
interrupt
yeah.
A
So
flux
doesn't
really
interact
with
contain
with
cri
the
container
runtime
interface,
but
it
does
operate
on
with
some
oci
registry
interfaces.
Like
the
docker
distribution,
you
know
style
api
for
container
images
right
now.
A
There's
currently
no
support
for
the
helm,
oci
charts,
because
those
packages
inside
of
helm,
3
are
still
internal,
but
once
the
helm
team
does
make
those
ga,
we
will
likely
add
oci,
helm,
repository
support
to
source
controller,
and
this
is
the
same
place
where,
for
the
manifest
bundles
that
primarily
nick
has
been
driving.
As
of
lately,
which
is
storing
things
like
yaml
files
or
customize
directories.
Inside
of
a
container
image.
A
Kind
of
support
for
that
inside
of
source
controller
from
flux
would
be
powerful
because
you
would
no
longer
it
just.
It
gives
you
another
option.
You
know
that's
not
a
bucket
or
an
http
server
or
git
repository
or
helm
or
repo.
You
can
package
artifacts
in
a
lot
of
different
formats.
A
Sign
them
validate
those
signatures.
That
kind
of
thing
so
that
that's
kind
of
what's
certainly
a
motivating
thing
for
me
to
continue
staying
involved
with
cluster
add-ons.
E
Like
so,
I
have
some
like
straw
man
stuff
around
manifest
bundles
and
ocis
pertains
to
the
stuff
we
were
talking
about
before.
I'm
not
really
ready
to
share
that.
Yet
I
got
a
little
bit
more
busy
than
I
thought
it
was
gonna,
be
with
work
work
stuff,
but
I'm
I'm
targeting
the
next
add-ons
meeting
to
have
stuff
publishable,
I'm
going
to
try
to
share
with
you
earlier
on
or
share
it
with
the
channel.
A
Yeah,
I
think
that
that's
been
a
successful
strategy
for
collab,
like
async
collab
in
the
past,
when
we
did
the
very
original,
like
operators
and
packaging
document.
So
if
when
when
you're
ready,
you
know
for
any
feedback,
I
think
we're
all
reachable
from
that
channel.
E
Okay,
yeah
again,
I
apologize
for
taking
so
long.
E
A
No
apologies
necessary,
I
think
you've
gone
above
and
beyond,
to
actually
take
any
ownership
of
the
work.
So
thank
you
no
rush,
if,
if
you
yeah,
if
you're
still
on
target
to
share
in
two
weeks
awesome
if
it
takes
a
month,
that's
cool.
So
thank.
B
A
Yeah
and
sorry,
if
I
cut
you
off
at
all
but
yeah,
if
you
have
any
more
comments,
please
feel
free
to
speak
up.
So
I
think,
as
far
as
g-shock
goes
you
know,
cops
is
not
a
not
a
good
target,
but
we
want
to
keep
working
in
that
direction.
A
Prakash
is
already
working
with
interns
if
they
need
support
with
packaging
or
add-on
related
concerns.
They
can
come
here
for
some
help
and
as
far
as
manifest
bundles.
This
is
certainly,
in
my
view,
one
of
the
most
important
things
that
we
could
get
out
of
this
sub
project.
A
A
So
potentially
we
could
have
some
derivative
work
there,
not
the
main
core
stuff,
but
things
that
are
related
to
bundle
ecosystem
by
summer
seems
possible
and.
A
Yeah
cool
well,
there's
nothing
urgent
that
needs
to
happen
towards
summer
of
code,
but
it's
really
good
that
we've
got
a
heartbeat
on
that
really
terrific
to
see
everyone
nick
I
I
was
actually
curious
about
revisiting
this
question.
I
missed
last
week's
meeting
and
was
just
curious
what
the
outcome
of
this
question
of
putting
multiple
versions
of
packages
into
a
single
container
could
look
like,
or
why
why
you
brought.
E
E
Well,
I
brought
it
up
because
the
current
format
that
I
can't
remember
the
name
of
the
repo
right
now,
but
the
declarative
config
pattern,
I
believe-
or
the
operator
pattern
has-
is
a
essentially
a
package
with
a
bunch
of
versions
in
it
of
different
manifests
and
the
manifest
bundle
describes
a
single
instance
of
that
thing.
E
So
the
current
operators
are
geared
to
consume
that
and
I
think
the
outcome
of
the
the
meeting
was
that
the
straw
man
would
include
like
both
options
for
one
for
a
single
version
per
manifest
bundle
and
another
one,
for
you
know
making
that
a
composite
pattern
with
like
multiple
bundles
in
a
single
single
manifest
bundle,
so
that
we
could
like
compare
contrast.
A
All
right,
yeah,
thanks
for
satisfying
my
curiosity
there.
It
does
make
sense
to
me
that,
depending
on
the
use
case,
you
might
be
interested
in
one
or
the
other
and
if
there's
space
in
the
way
that
these
bundles
are
consumed
to
specify
which
version
of
the
package
you
intend
to
use
beyond
the
tag
of
the
image
that
you're
actually
consuming,
then
that
seems
sensible
to
me.
A
To
a
registry
under
multiple
tags,
that
kind
of
be
syncing
the
metadata
of
what's
inside
the
image
with
the
metadata,
that's
actually
consumable
in
the
registry,
so
that
what
you
would
download
would
kind
of
be
this
like
larger
image
containing
multiple
versions
but
addressable
in
that
kind
of
specific
way,
and
that
would
allow
you
to
like
also
tag
something
as
a
release
channel.
Potentially
so
there's
a
lot
of
options
here
and
see
that
working
pretty
well
with
the
source
controller,
custom
resources.
A
The
clients
would
you
know
if
you
wanted
to
use
that
kind
of
if
you
wanted
to
take
advantage
of
the
hashing
and,
like
that
happens
inside
of
an
image
registry,
the
client
would
likely
benefit
from
some
sort
of
image,
store,
cache
or
layer
cache
so
which
I
feel
like.
That
is
probably
inherently
how
an
oci
client
works
for
layer,
pulse,
cool.
E
I
think
with
oci
you
get
some
more
options
than
you
do
with
the
docker
container,
as
well
like,
for
instance,
custom
media
types
right
so
like
I
could.
I
can
store,
manifests
in
a
manifest
list,
with
a
different
media
type
than,
for
instance,
with
docker
images.
We
we
have
to
use
a
file
system
to
do
that
right.
We
would
have
to
have
them
all
be
media
types
that
docker
understands
and
we're
restricted
by
a
file
system.
So
like
there
are
a
lot
of
things.
A
Yeah
that
that
is
certainly.
A
Yeah,
you
would
end
up,
you
know,
having
libraries
that
would
have
like
an
in-memory
file
system
as
a
fallback
and
then
that
yeah
restricts
where
you
can
run
or
as
a
fallback.
You
know
for
when
you're,
in
an
environment
where
you
can't
run
with
the
file
system
and
that's
yeah,
maybe
undesirable,
and
when
you
could
have
that
more
elegant
design,
like
you
mentioned
with
the
media
types,
yeah
yeah,
and
even
just
having
a
tarball
in
general,
like
not
needing
that
to
store
a
couple
of
objects.
A
This
registry
support
you
know
for
hosting
these
types
of
alternative
things
is
improving
and
the
helm
folks
have
kind
of
started
off
on
a
path.
That's
blazing
a
trail,
for
maybe
people
like
this
group
to
follow
along
and
also
adopt
the
oci
spec,
the
parts
of
it
that
aren't
normally
used.
E
A
That's
a
really
good
question.
I
imagine
that
the
projects
that
we
would
want
to
target
poc
would
be
using
the
the
upstream
opens
like
the
distribution
project
that
docker
originally
created
that
most
other
registries
are
based
off
of
or
if
we
wanted
something
like
more
concrete.
A
We
could
look
at
like
using
harbor
to
prototype
off
of,
and
harbor
is
kind
of
a
more
an
interesting
opportunity
like
beyond
just
the
core
bits
of
the
registry
api
and
how
to
interact
with
it
properly.
C
What
do
you
mean
by
an
oci
image
like
what
are
the?
What
are
the
gaps
that
are
that
are
needed
beyond
what
say,
gcr
gives
you,
I
can
forgive
my
ignorance
here.
A
So
just
like,
as
some
context
for
people
who
would
very
reasonably
not
be
aware,
is
that
the
a
docker
image
is
like
roughly
compatible
with
the
oci
spec
for
container
images
and
each
the
image
is
marked
with
several
layers
of
media
types
and
in
a
container
image.
A
You
have
these
layers
that
are
marked
as
these
tarballs
and
then
the
actual
contents
of
those
layers
then
get
unpacked
onto
the
file
system.
A
A
A
Yeah
so
right
here
in
the
oci
format,
section
this
docker
image,
manifest
version,
2
schema,
2
format.
Supporting
you
know.
Docker
images
with
this
format
is
something
that
almost
all
cloud
registries
have
adopted.
A
But
what
gets
a
little
bit
challenging
is
and
then
there's
also
this
image
indexes
thing
which
is
useful
for
like
the
multi-arch
support
so
like.
Sometimes
that
takes
a
while
for
a
new
image
registry
when
they
provide
a
service
to
have
these
image
indexes,
and
so
these
kinds
of
extensions
beyond
just
using
tarballs
as
a
media
type.
A
A
A
I
I
don't
know
if
that's
helpful
at
all
nick
but
yeah.
E
I
mean
at
the
at
the
very
least
we
can,
if
there
is
a
way
to
push
to
a
gcr
registry,
we
can
test
it
like.
We
can
construct
an
image
with
a
random
media
type
or
a
custom
media
type
and
then
try
to
push
it
and
pull
it
make
sure
it
works.
C
Yeah
and
nick,
if
you
I
don't
know
whether
you
have
the
the
the
structure
of
it-
is
that
there
is
a
every
kubernetes
project
gets
a
staging
gcr
repo,
which
is
not
considered
particularly
secure
and
they
get
a
production
pcr
zone,
there's
a
sort
of
fairly
involved
or
auditable
promotion
process
involving
prs.
Our
cloud
build
job
should
be
able
to
push
to
that
staging
gcr
repo,
and
we
can
probably
also
give
you
access
to
push
to
it
directly,
although
that's
a
little
bit
less
good.
C
E
Sorry,
this
is
all
very
new
to
me
in
terms
of
like
these,
the
cloud
build
the
staging
and
production
dc
repos
is
there?
Are
there
any
ducks
describing
them?
So
I
can
like
better
understand.
What's
going
on,
there.
C
There
definitely
are,
this
is
all
the
the
production
or
the
provisioning
of
these
repos
is
done
under
the
auspices
of
the
working
group,
kate's
infra,
wg,
kate's
infra,
and
they
have
a
git
repo,
which
is
very
confusingly
named
as
this,
which
I
will
paste
and
then
read
out,
github.com
kubernetes
case.io
and
in
there
you
should
be
able
to
see
well,
at
least
how
those
happen.
I
don't
know
if
we
have
docs
on
on
how
to
use
those
things
yeah.
C
This
is
the
this
directory
is
reasonable
to
read
me
here,
sort
of
reasonable
it's
it's
very
focused
on
the
working
group
kicks
in
from
perspective
instead
of
the
consumer
perspective,
but
it
it
if
you
sort
of
read
it
with
the
other
mindset.
You
can
sort
of
figure
out.
What's
going
on,
I
think
the,
but
yes
the.
C
C
If
you
have
access
to
a
gcr
repo,
you
can
try.
I
would
personally
just
try
it.
If
you
don't,
you
can
probably
send
up
a
pr,
and
I
can
try
pushing
it
for
you.
If
you
want.
E
Yeah,
the
only
thing
that's
going
to
be
interesting
is
that,
like
I
I'm
not
sure
so,
if
this
depends
on
like
using
a
docker
file
or
some
other
format
to
build
an
image
from
a
file
system,
we
may
not
be
able
to
build
images
using
that
job
in
the
way
that
I'm
thinking
that
we
want
to
that's
interesting.
Yes,.
A
A
Yeah,
you
should
be
able
to
do
whatever
you
want:
okay
and
yeah.
It's
it's
basically
a
ci
runner,
so
you
you
can
put
whatever
tools
you
want
in
a
container
image
and
use
it,
but
as
far
as
yeah,
just
publishing
to
gcr
like
whether
or
not
gcr
will
accept
a
container
image
that
has
these
alternative
media
type
sections
is
a
question
as
to
I
don't
know
the
answer
to
that.
C
And
it's
also
not
if
we
are
the
first
people
ever
to
promote
one
of
these
little
bit
different
images.
It's
not
clear
that
the
promoter,
which
is
our
own
code,
kubernetes
code,
we'll
be
able
to
cope
with
it,
but
obviously
we
can
extend
it
or
fix
any
bugs
that
we
encounter.
E
Okay,
cool
that
sounds
like
a
an
action
item
on
the
path
to
defining
oci
manifest
bundles,
because
I
mean
at
the
end
of
the
day,
we
don't
need
to
use
those
special
things.
We
could
do
it
just
like
a
doctor.
We
could.
We
could
have
it
essentially
just
be
oci
version
of
the
docker
image
here
v22,
but
it
would
be
nice
to
actually
use
the
features
of
oci
to
make
an
image
that
doesn't
need
all
this
extra
stuff
like
a
layered
file
system
and
target
balls.
And
what
have
you.
A
Yeah
and
there
may
be
room
for
both
implementations
depending
on
the
amount
of
flexibility
of
what
you
want
to
actually
store
inside
the
you
know,
manifest
bundle
like
if
it's
literally
just
manifests.
A
You
know
you
can
see
why
that
would
be
super
attractive,
but
even
just
with
the
next
step,
which
is
like
packaging,
something
like
a
customized
directory.
This
is
just
not
really
like
a.
A
A
But
if
you
want
a
bundle
to
be
able
to
hold
a
package
of
something
non-trivial
where
the
file
system
is
actually
important,
then
the
docker
v22
compliant
images
may
be
a
good
fit
for
that.
So
it's
yeah,
it
might
be
space
for
both.
E
Basically,
you're
hinting
at
the
fact
that
the
content
of
the
bundle
has
an
implication
for
how
it
is
used
and
applied
and
has
a
coupling
with
the
type
of
bundle
that
we
use
right
so
like
there
would
be
a
bundle
for,
let's
say,
helm
or
a
what
like.
If
helm,
didn't,
have
its
own
format
already
or
you
know,
customize
or
queue
or
etc,
because
they
depend
on
different
things.
Some
depend
on
file
systems,
others
do
not.
A
Yeah
this
is
yeah.
The
helm
point
is
a
great
example.
There's,
no
real
blocking
reason
why
you
could
not
already
use
a
docker
v22
image
to
store
a
helm
chart.
A
So
it's
a
very
generic
like
blunt
hammer,
but
then
the
helm
team
chose
because
they
saw
a
benefit
in
packaging,
using
these
media
types
for
helm
charts,
and
we
could
have
one
of
those
you
know
specifically
for
like
in
a
bunch
of
kubernetes
objects
right
and
that
could
be
more
minimal.
It
would
use
less
space.
It
wouldn't
have
as
complex
with
a
code
path
for
unpacking
that
artifact
did
have
less
dependencies
so
that
that
there's
definitely
an
attractive
thing
there
it's
like
do.
We
also
build
one
of
those
for
customize.
A
A
C
If
I
may,
I
want
to
mention
one
thing
which
is,
I
think,
is
what
you
said:
it's
it's
there's
a
difficult
trade-off,
like
suppose
like
when
we,
when
we
talk
about
image
registries
as
the
preferred
format
or
as
a
good
format,
I
think
implicit.
There
is
the
idea
that
everyone's
already
running
an
image
registry
and
therefore
we
should
leverage
it.
I
think
if
we
start
saying,
but
you
have
to
run
an
image
industry
that
supports
this
potential
feature
that
maybe
not
everyone
supports
newer
feature.
How
about
that?
C
It
may
reduce
the
argument
in
favor
of
image
registries.
So
that's
one
thing,
but
on
the
other
hand
like
we
need,
if
no
one
ever
adopts
like
some
of
these
more
advanced.
If
no
one
ever
adopts
oci
image
format
in
its
general
form,
then
none
of
the
image
industries
will
ever
support
it.
C
So
there's
a
trade-off
between
sort
of
leading
the
we're
getting
getting
reach
and
then
leading
the
industry
towards
this
new
use
case,
and
I
like
I,
like
the
idea
of
I
don't
know
whether
there
are
any
other
users
today
of
oci,
that
the
go
beyond
the
docker
spec.
But
it's
a
it's
an
interesting
trade
off
and
I
I
like
the
idea
of
of
of
going
for
it.
C
A
Yeah
so
go
ahead
aside
aside
from
helm,
I'm
not
aware
of
other
folks
who
are
using
oci
in
this
way
as
a
large
community
effort.
What
about
you
nick.
E
We've
always
been
trying
to
go
there.
I
think
I
don't
know
if
you
guys
are
aware,
but
like
quay
is
red
hat
product
under
the
hood
and
I
think
oci,
custom,
media
types
and
oci
have
been
like
on
the
agenda
for
like
two
years
now,
or
as
long
as
I
can
remember.
E
So
you
know
it's,
I
don't
know
how
many
actual
services
have
that
implemented
yet
or
would
the
point
that
justin
brings
up
about
like
compatibility
with
existing
docker
images
is
something
I
think
we've
talked
about
before
and
was
like
the
spirit
of
the
original
kept,
and
it
almost
makes
me
think
like
we
want
a
meta
we
just
want
to
use
like
whatever
the
current
ubiquitous
thing
is
as
like
the
abstract
container,
and
we
define
our
our
format
to
capture
everything
like.
E
Let's
just
say,
we
zip
up
whatever
you
have
in
a
tarball,
and
that
goes
inside
the
image,
and
so
now
that
the
tarball
is
the
thing
that's
the
or
whatever,
like
custom
format.
We
design
that
can
wrap
the
things
that
we
want
to
apply
can
be
either
stored
in
the
file
system
or
it
can
be
stored
in
a
manifest
list
or
it
can
be
stored.
You
know
in
a
file
server
like,
maybe
maybe
that
going
that
direction
is
the.
E
One
way
we
could
save
ourselves
pain
in
the
future,
with
oci
docker
supremacy.
A
Yeah,
I
think
that
that's
probably
the
biggest
or
one
of
the
most
motivating
things
is
like
it's.
It's
compatibility
from
two
different
perspectives
when
you're
talking
about
just
using
docker
v22
the
tarball
style
image
right
is
you
have
compatibility
with
the
ecosystem
of
tools
if
people
want
to
store
some
sort
of
structured
data,
that's
used
by
some
tool
later
on,
and
then
you
have
compatibility
with
all
of
the
registry
infrastructure
that
happens
to
be
out
there,
and
then
it's
like
you're
asking
yourself
a
little
bit
of
like
okay.
A
Well,
what
are
the
benefits
of
not
going
that
direction
and
I
think
the
benefits
are
largely
like
mechanical
there's.
Also,
probably
some
indexing
benefits
from
using
a
proper
media
type.
A
But
definitely
mechanical
benefits
from
the
client
side
in
terms
of
simpler
code
path,
less.
A
Dependencies
but
yeah,
I
think
that's
one
of
the
reas
or
pretty
good
picture.
Why
that's
a
good
option
to
support,
regardless
of
whether
we
do
move
you
know
beyond,
and
do
something
that
takes
advantage
of
these
other
oci
specification
properties.
A
It
might
be
interesting
to
hear
what
some
of
the
oci
spec
contributors
think
about
this
approach.
I'm
sure
that
the
helm
folks
probably
spoke
to
them
or
some
of
those
team
members
were
part
of
writing
that
spec,
so
probably
an
opportunity
for
some
opinions.
There.
A
But
yeah,
ultimately,
there
are
definitely
benefits
of
going
beyond
the
docker.
A
So
touchy
had
to
drive
off
good
to
see
her
anyway,
we
have.
We
have
had
quite
a
long
meeting
today
of
a
good
discussion
thanks
so
much
does
anyone
have
other
things
that
they
wanted
to
bring
up
before
we
convene-
and
you
know,
get
go
into
async
feedback
mode
on
this.
A
Feel
free
to
append
the
agenda
for
the
next
time
with
me
and
yeah,
we're
always
available
in
the
cluster
out
on
this
channel.
So
let's
keep
the
discussion.