►
From YouTube: OCI Weekly Discussion - 2021-07-07
Description
Recording of the OCI weekly developer's discussion from 7 Jul 2021; notes/agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#July-7-2021
B
A
It
had
a
time
zone
on
it
when
I
was
first
creating
it
and
it
kept
changing
like
I'd,
set
it
to
east
coast,
and
then
it
would
change
it
to
zurich
and
it
just
kept
changing
it
back
to
zurich
and
so
and
it
had
like
an
option
that
was
like
just
remove
the
time
zone
because,
like
every
time,
I
open
a
doodle.
It
just
guesses.
The
time
zone
that
I'm
in
already
and.
C
C
B
A
I
have
not
no,
no
none
of
our
crew
have
been
at
all
like
not
even
a
little
sniffle,
and
so
as
it
had
gotten
on
like
past
a
year.
I
was
saying
that
very
likely.
The
next
time
I
get
like
a
common,
cold
or
gosh,
heaven
forbid,
like
a
stomach
bug
or
something
like
that.
It's
just
gonna
be
like
pitiful,
like.
E
In
one
of
the
e
m
banks
books
there's
it's
a
future
where
there
aren't
common
things
like
common
colds
and
as
a
trend
on
a
particular
spaceship.
They
go
through
and
decide
that
everybody's
going
to
try
out
having
a
cold,
and
so
they
walk
around
sniffling
and
everything
and
they're
like
yeah.
I
don't
understand
just
an
entertaining
anecdote.
A
Yeah,
even
with
this,
you
know,
like
the
first
person
in
the
in
the
house
that
started
feeling
a
little
funky
you
know
was
that
it
was
obviously
like
achy
and
had
headaches,
and
it
was
like
pack
up
everybody
we're
gonna
get
gonna
go,
get
coveted,
even
though,
like
most
of
us
are
already
vaccinated.
It.
F
B
The
first
issue
there
for
the
invalid
manifest
so
I've
been
pushing
them
that
you
know
maybe
a
better
option,
for
this
is
to
get
some
drive
behind
artifact
spec,
and
so
I
don't
know
how
much
that
rolls
back
into
this
on
the
oci
side.
But
there
are
people
trying
to
store
things
in
registries
in
ways
that
are
upsetting
the
registry.
Maintainers.
B
B
D
C
I
haven't
caught
up
in
the
latest
minutes.
I
mean
this
is
just
one
of
the
many
examples
where
you
know.
There's
general
like
like
this.
That
registries
can
store
various
artifacts
in
a
registry,
so
they
don't
have
to
be
hidden
as
a
container
image,
but
the
lack
of
it
being
a
spec.
The
lack
of
any
speci
you
know,
specificity
on
it,
has
called
caused
confusion
and
inconsistencies,
which
kind
of
lead
you
to
a
spec
is
the
way
to
resolve
consistencies.
C
So
basically,
this
this
part
of
this
threat,
at
least
the
part
that
I
read
was
how
do
we
handle
the
ambiguity
today?
Because
there
is
no
real
answer.
The
answer
could
be
like.
I
have
to
look
at
it
because
I
think
build
x
uses
a
collection
of
things,
so
I
have
to
go
back
and
look
at
how
it's
doing
it,
but
the
fact
that
they're
stuffing
blobs
in
the
index,
which
is
a
collec
a
manifest
collection,
is
broken.
A
C
A
Well,
this
is
what
I
say:
this
is
the
sentence.
I
was
thinking
of
an
encountered
media
type
that
is
unknown
regardless
of
whether
it's
a
manifest
in
the
manifest
list
or
not
that
in
an
example
like
this,
it's
got
it
enumerates.
You
know
some
descriptor
with
a
media
type
that
is
unexpected
effectively
unknown
for
that
area,
and
it,
you
know,
must
be
ignored.
If
you
don't
know
what
it
is,
so
the
the
how
you
garbage
collected
or
you
know,
throwing
500s
or
sage.
However,
you
said
it
was
causing
issues.
I
wonder
if
there's.
G
More
to
yeah,
I
can
kind
of
describe
that.
So
what
brandon
was
talking
about?
You
have
two
options:
either
we
reject
it
or
we
ignore
it.
We
ignored
it
and
when
that
was
ignored,
what
would
happen
is
our
gc
would
kick
in.
We
have
a
seven
day,
internal
gc
and
the
blobs
just
went
away,
and
then
the
cash
started
failing
and
then
suddenly
bill
times
were
going
up
like
10
times,
because
the
cash
was
all
suddenly
started.
So
that
was
the
experience,
and
then
we
got
a
bunch
of
cases
from
customers.
G
C
I
think
part
of
it
is
that
either
one
is
kind
of
a
bad
answer
like
if,
if
we
rejected
it,
then
at
least
they
would
have
known
up
front.
There
was
a
problem.
The
problem
was,
we
ignored
it
and
because
it's
ignored
it's
a
passive
cache.
You
know
you
don't
really
pay
attention
to
it,
because
it
seems
like
it's
working
and
only
after
time
do
you
sign
it
after
like
debugging
like.
Why?
Is
this
not
like?
The
whole
point?
Is
this
thing's
supposed
to
be
fast
and
it's
not
so
you
really
had
to
dig
in.
C
If
this
was
more
descriptive,
exact
or
followed
a
consistent
pattern
of
what
was
defined,
then
we
could
all
implement
it
consistently,
because,
basically,
what
we're
seeing
is
like
we
dealt
with
ours
as
sanji.
What
was
it
like
a
year
or
two
ago,
and
I
think
it
was?
It
was
a
digital
ocean.
I
forgot
who
it
was
that
opened
this
one
over
the
weekend
that
they
started
seeing
it.
So
it's
just
it's
working
its
way
across
the
registries,
with
a
lack
of
consistency.
H
C
A
At
least
since
the
fact
that
they're
using
this
image
index
json
thing
is
that
either
this
may
be
ignored
but
effectively
what
it's
saying
this
this
highlighted
sentence
is
saying
that
it
anything
that's
unknown,
may
be
ignored
or
effectively
define.
The
word
ignore
more
as
what
I'm
trying
to
think
either
may
be
ignored
or
ignored,
doesn't
necessarily
mean
dropping
the
blob,
maybe
ignored
projected,
or
you
know,
just
basically
not
aired
on.
A
You
know
because
it
because,
if
somebody
wanted
to
end
up
making
like
a
you,
know,
service
enhancement
that
you
like,
we
only
allow
from
your
authentication,
that's
pushing
a
blob,
these
media
types
and
if
you
want
to
show
any
other
random
media
type
at
us,
that's
a
service
add-on
or
something.
So
it
would
reject
up
to
the
point
that
your
account
allows
it
or
something.
I
don't
know.
A
C
If
you
go
to
the
up
a
little
bit,
though,
like
the
line
above
that,
like
you're,
looking
at
the
media
type
on
that
property,
if
you
go
all
the
way
up
to
the
root
where
it
says,
manifests
this
required
property
contains
a
list
of
manifests
that
sorry,
let's
keep
going
down
down
and
a
little
bit
more
sorry.
If
you
go
to
the
manifest
property
there
you
go.
C
A
C
A
H
A
It's
funny
so
slight
backstory.
That
really
doesn't
matter
at
all
at
this
point
is
that
I
wanted
this
to
in
the
past
to
just
say:
blobs,
either,
either
here
and
or
also
in
the
image
index,
just
to
say,
blobs
and
went
round
and
round
with
steven
day.
You
know
it
wanted
this
to
only
be
a
list
of
manifests
and.
A
A
B
H
C
Object
types
that
we
store,
a
manifest
that
defines
things
and
the
blobs
that
make
up
the
thing.
Like
that's
the
fundamental
thing
of
a
registry,
and
we
do,
I
mean
calling
it
life
cycle
management,
because
it's
gc
is
just
a
piece
of
it.
If
a
customer
intends
to
delete
something,
there's
expectation
there
if
something
is
an
income
and
then
because
of
the
deduping
and
things
you
wind
up
with
ref,
counting
in
gc
or
you're
uploading
or
synchronizing
content
across
different
registry,
there
needs
to
be
a
way
to
reconcile
if
things
are
in
an
incomplete
state.
C
So
gc
is
just
part
of
that.
But
the
fundamental
thing
here
is:
there's
a
manifest
that
defines
things
things
that
I've
been
trying
to
generalize
is
what
I
call
artifacts
and
then
the
blobs
that
make
up
that
thing.
When
we
started
mixing
those
it
starts
getting
very
confusing
on
how
to
do
any
consistency
across
registries
for
customers.
A
Which,
by
the
time
you
generalize
that
out
to
where
you
could
address
various
things-
and
you
know
address
something
for
its
media
type,
that
could
be.
You
know
a
zip
file
of
things
that
point
at
other
things
or
xml
or
one
of
our
json
documents
all
can
be
manifest.
Some
other
way
to
denote.
This
is
a
thing
that
points
to
things
versus
the
actual
like
root
effects
or
chunk
or
whatever
it
is
by
the
time
you
make
those
two
things:
generic
and
iterate
on
them.
A
If,
by
the
time
you,
but
if
by
the
time
you
call
this
like
blobs
and
then
just
add
another
like
annotation
or
field,
that
said,
is
this
a
type
of
manifest?
Yes,
you
know
it's
here's
a
media
type
and
this
is
a
type
of
manifest
versus
a
type
of
a
rude
effect
or
whatever
this
thing
is
and
and
then
once
we
iterate
over
kind
of
on
the
oci,
you
know
like
alexa's,
v2
efforts.
You
know
like
decomposing
things
where
now
these
are
no
longer
tar
objects
and
they
could
be
chunks
or
whatever
you
know.
A
C
C
C
So
now
you
don't
have
to
have
separate
those
as
separate
properties,
it's
layers
as
a
image,
spec
concept,
whether
ordinal
others
might
have
blobs
that
are
different
portions
of
disk,
that
they
don't
actually
overlay
with
each
other.
The
point
is
it's
up
to
the
individual
artifact
types
to
define
how
they
want
to
represent
those
justin's
original
larger
generalization
of
it
was
you
know,
yeah,
there's
it's
a
collection
of
things
that
you
can
specify
what
the
type
of
thing
is,
but
it's
it
just
got
more
complex
than
we
have
had
time
to
iterate
on.
A
To
have
a
field
called
manifest
is
required.
The
fact
that
it
says
it
should
be,
you
know,
contain
a
list
of
manifests,
I
think,
is
probably
ambiguous
and
should
be
just
pointed
out
as
an
example
of
types
of
things
that
are
manifest
examples
of
things
that
are
manifest
or
that
it's
like
this.
This
and
the
rest
of
the
sentence
right
here
could
be
clarified
of
like
effectively
manifest
is
something
that
defines
or
points
to
other
things.
C
But
I
I
think
we're
getting
to
the
root
of
the
debate
that
we've
been
having
for
the
last
several
weeks.
It's
this
is
the
very
root
concept
of
what
we're
trying
to
figure
out
is
if
a
manifest
represents
a
thing
and
then
the
layer,
the
layers
or
blobs,
make
up
that
thing,
and
we
can
detube
layers
awesome
as
soon
as
we
start
intermixing
them.
The
way
that
I
don't
even
know
how
to
think
about
how
to
start
doing
life
cycle
management
and
the
way
registries
have
been
implemented
today.
C
As
far
as
everybody
I
know
has
been
doing,
it
is
a
collection
of
manifest
it's
a
collection
of
blobs.
Yes,
we've
generalized
the
way
we
reference
things
as
descriptors,
which
is
awesome,
but
there's
definitely
a
difference
between
a
manifest
descriptor
and
a
blog
descriptor
and
the
type
of
content
that
it
is.
C
We
cache
manifest,
so
we
can
do
cache,
hits
and
and
serve
the
figure
out
whether
we
have
to
serve
different
content
blobs
we
like
to
do
cdns,
but
to
change
that
is
a
pretty
fundamental,
like
yeah
great
version,
think
about
what
we
want
to
do
differently
in
the
future.
But
this
is
a
pretty
core
concept
to
the
way
we
run
registries
today.
A
Well,
even
even
on
the
cache
versus
cdn
impossible,
just
to
see
what
the
media
type
is
and
make
a
decision
of
like
we
know
what
to
do
with
it.
I
know
that's
that's
some
amount
of
processing
on
receiving
it,
but
if,
if
I
guess
you're
saying
that
the
current
assumption
is
anything
that's
in
that
list,
you
cash
but
you're,
already
having
to
parse
and
process
that
list.
B
B
C
E
C
Has
hit
various
different
issues,
because
there's
not
enough
clarity
here
and
it's
great
that
we've
gotten
to
this
point
right.
This
is
this
is
a
great
problem
to
have.
We've
got
so
much
success
with
it.
People
want
to
do
more
with
it,
but
I
think
this
is
this.
Is
the
root
of
the
question
is
how
do
we
clarify
what
what
and
how
to
move
forward
on
this,
which
goes
to
the
discussion
we've
been
having
about
this.
H
Work,
I
think
this
could
certainly
be
clarified,
especially
in
the
context
of
distribution.
I
don't
know
that
we
really
need
to
change
anything,
but
I'd
be
open
to
being
wrong.
It's
like,
I
think
many
people
writing.
Clients
and
registries
have
have
different
models
of
how
this
like
data,
like
type
system,
works
in
oci
and
kind
of
getting
on
the
same
page.
For
what
what
goes
where
and
how
things
work
is
would
be
nice.
H
I
don't
want
to
legislate
garbage
collection
models,
but
I'm
happy
to
you
know,
make
sure
everyone
agrees
on
some
semantics
around
like
if
I
upload
it
through
this
path.
Can
I
access
it
through
this
path
or
if
it
has
this
media
type,
can
I
expect
to
pull
it
through
a
blob
or
whatever?
I
don't
know.
I
don't
want
to
be
too
prescriptive
about
that,
but,
like
it
definitely
tripped
me
up
a
lot,
but
I've
kind
of
either
accepted
the
complexity
and
justified
it
to
myself,
or
maybe
it
is
reasonable.
I'm
not
sure.
C
A
A
B
A
What
is
it
that
makes
it
a
manifest
and
point
to
the
fact
that
these
these
things,
the
things
in
this
list
are
handled
differently?
You
know,
like
here's,
the
distribution
api
for
manifest
and
be
like
effectively.
I
know
that
these
things
are
different,
but
like
point
to
that
doc
and
be
like
this
is
why
the
things
in
this
list
are
handled
differently.
C
I
mean
we
don't
treat
these
as
just
arbitrary
stories
like
they're
the
fact
that
it's
a
manifest
and
then
registries
choose
what
manifest
they
support.
Like
not
all
registries,
even
support
index,
only
there's
a
couple
that
only
added
it
even
recently
the
and
then
what
we're
proposing
is
yet
another
manifest
they
can
parse
for
various
reasons
as
well.
But
the
point
is
that
we
look
at
those
in
those
manifest
to
figure
out.
Is
this
a
windows
image?
Is
it
a
linux
image?
C
What
architecture
is
it
there's
data
in
there,
and
this
has
actually
been
one
of
the
limitations?
Why
dockerhub
hasn't
adopted
the
generalized
artifacts
approach
yet
is
because
they
are
parsing
that
index
for
information
and
the
manifest
they're
parsing
both
of
them
so
to
start
to
say
that
this
could
be
anything
would
affect.
Just,
I
think,
just
about
everybody.
C
It's
not
that
we
don't
want
more
things
in
there
right
that
this
is
the
root
of
the
hey
we'd
like
to
have
another,
manifest
that
we
can
start
describing
things,
including
a
graph.
But
the
idea
is
the
manifest
represents.
What
is
the
thing,
and
then
I
have
a
way
to
dedupe,
or
you
know,
represent
a
thing
over
multiple
blobs,
so
that
I
can
do
concurrent
downloads
and
all
the
magic
of
the
way
registries.
F
H
Oh,
this
must
be
a
blob,
but
this
seems
like
a
kind
of
tractable
problem
to
just
analyze.
What
you're
looking
at
and
say.
Oh,
that
you
know
this
must
be
something
that
is
not
a
manifest,
which
is
why
we
were
tossing
it
because
it
said
it
was
a
collection
of
manifest
right,
but
it
doesn't
really
define
that
in
a
normative
way.
It
just
links
to
a
manifest,
which
is
like
the
image
manifest.
If
you
were
to
take
that
link
as
a
gospel,
then,
like
you
would
never
support
a
nested
index
either.
C
But
well,
a
nested
index
is
another
manifest
type.
It's
just
and
registries
are
chosen
to
support
the
end,
the
manifest
or
the
index
manifest
types.
Those
are
two
different,
manifest
types
that
can
be
uploaded,
the
not
all
registries
until
I'm
sure
all
of
them
do
today.
But
index
was
one
that
few
registries
implemented
and
they
started
adding
right,
so
they
they
basically
would
throw
you
couldn't
just
submit
something
up
to
it.
They
would
throw
because
I
don't
know
what
you
know
they
would
say.
C
C
I
mean
to
your
previous
mod
just
to
separate
lifecycle
in
gc.
I
think
gc
is
an
internal
implementation,
detail
that
every
registry
should
choose,
because
it
implements
a
lot
of
details
that
is
optimized
about
their
registry
and
I
don't
think
customers
care
about
the
gc.
They
do
care
about.
What
how
do
they
treat
the
storage
that
they're
paying
for
the
amount
of
storage?
How
do
they
delete?
How
do
they
know?
What's
in
there
we
have
customers,
because
most
registries
didn't
implement,
delete
upfront.
Then
we
started
having
registry
customers.
C
H
C
G
A
C
A
A
That
would
be
something,
but
it's
otherwise
very
cyclical
for
it
to
say
it
should
be
a
list
of
manifest
and
it
points
to
a
very
specific
media
type
like
it
should
be
one
of
these
media
types
and
it
points
to
a
specific
one
and
then
right
here
it
almost
invalidates
it
right
here.
It
almost
invalidates
that
because
then
it
says-
and
it
should
also
have
this
one.
C
This
is
the
root
of
how
we
came
up
with
the
artifact.
Manifest
was
the
interpretation
of
this,
so
I
think
if
you
had
mike
brown
mike
brown
from
ibm,
as
opposed
to
michael
brown,
mike
brown,
derek
justin,
probably
some
of
the
other
registry
operators,
like
you,
know,
haley
and
so
forth.
We've
this
has
been
interpreted
as
a
registry
should
support
at
least
the
index
and
manifest
as
manifest
image
index
and
image
manifest
just
and
they
treat
them
as
manifest
and
here's
the
media
types
for
those
two.
A
C
G
So
right
now
there's
inconsistency
either
way
because
the
index
call
so
the
problem
is
the
index
says
it
needs
to
point
to
a
manifest,
but
an
index
can
point
to
another
index.
The
spec
is
already
polluted
and
the
examples
don't
align
with
the
specification
also.
So
I
think
we
need
to
call
that
out
that
the
example
is
inconsistent
with
the
specification
classification
needs
to
happen.
I
think
that's
that's
a
separate
thing,
you're
saying
this
example
yeah,
because
it
is
not
a
manifest
and
it
shouldn't
be
in
that
list.
Ideally
speaking,
I
went
to
and.
A
At
the
time
when
we
we
created
this-
and
this
one
particularly,
is
because
the
way
that
even
flat
packs
you
know
the
containerized
desktop
applications
yep,
they
they
push.
They
push
flat
packs
to
ocr
to
registries
that
support
oci
and
they
they
include
additional
metadata,
a
manifest
of
metadata
and
that
manifest
is
xml
and
it
has
a
manifest
and
they
shove
it
at
different
registries.
G
G
A
A
G
H
If,
if
that
did
not
link
to
the
manifests
page,
it
links
to
only
the
image
manifesto
right.
If,
if
it
didn't,
I
think
the
interpretation
of
this
document
would
be
very
different.
We'd
have
to
define
what
is
a
manifest
yeah
and
that's
kind
of
the
conversation
I
want
to
be
having
eventually,
I
wish
that
did
not
link
to
the
image
manifest.
I
agree.
A
C
A
B
A
And
this
was
the
same
way
that,
like
s,
bombs
and
other
stuff
like
this,
we
investigated
this
red
hat
towards
the
end.
We
never
got
around
to
implementing
it,
but
having
having
like
a
you,
know
some
other
json
type
that
we
created
completely.
It
has
all
the
different.
You
know,
source
pointers
and
you
know
build
root
information,
but
it
was
like
a
manifest
of
the
build
of
that
of
those
images
and
it
would
be
a
type
of
a
manifest,
but
it's
not
anything
that
had
nested,
blobs
or
otherwise
it'd
be
a
self-contained
document.
A
A
That's
where
you
could
have
a
a
that's
where
you
could
have
differentiation
of
registries
or
like
say,
if
you
know
in
that
use
case.
If
red
hat
wanted
to
push
a
manifest
that
had
a
lot
of
build
root
information,
then
they
could
at
least
make
their
own
access
that
red
hat
registry
support
that
so
that
their
own
tools
would
know
how
to
push
and
fetch
from
something
that's
relevant
to
their
story.
A
D
A
A
The
flat
back
to
the
flat
pack
example
just
to
close
that
loop,
that
was
like
the
flat
pack
developers,
were
working
directly
with
the
fedora.
You
know:
infrastructure,
people
and
so
the
registry
that
they
were
working
with.
They
had
a
client
that
was
pushing
things
and
the
registry
side
that
knew
they
expect
those
things.
But
it
was
like
a
valid
oci
registry,
but
it
had
additional
things,
and
it
was
using
this
right
here.
Okay,.
C
I
don't
know
if
this
is
about
what
individual
registry
operators
could
do
right.
There's
lots
of
things
we
need
to.
We
all
have
various
apis.
We
we
bolt
onto
the
registry
for
the
for
the
gaps
that
are
there
and
sure
we
can
stuff
lots
of
different
things
in
because
the
spec
is
fairly
thin.
On
some
of
these
things,
the
question
is:
we're
seeing
you
know
with
the
explosion
of
registries,
because
everybody's
kind
of
recognized
they
should
have
a
private
registry
for
their
own
content.
C
C
Of
copying
a
file
from
one
thing
to
another,
but
a
usb
doesn't
have
an
operating
system,
but
the
point
is:
is
that
there
needs
to
be
some
consistency
to
copy
content
across,
which
is
what
we're
looking
for
the
specs
to
provide.
You
know
that
standard
so
that
tooling
can
build
things.
Services
can
build
things.
G
But
I
don't
think
that
precludes
if
the
customers
choose
to
go
down
on
a
product
path,
it
doesn't
mean
that
all
the
specification
needs
to
handhold
them
right,
there's
a
choice
that
they
make
that
this
is
not
something
that
is
there
on
the
spec
and
they're
choosing
to
do
that
being
able
to
move
all
content.
That
is
not
within
the
specification.
Doesn't
it's
probably
not
going
to
be
possible,
for
example,
there's
no
way
that
they're
going
to
be
able
to
access
the
xml
manifest
from
a
registry
that
doesn't
understand,
xml
or
cannot
push
to.
G
C
Yeah,
I
was
trying
to
say
that
the
approach
we've
been
trying
to
take
with
the
artifact
stuff
is:
let's
have
a
generic
thing
that
can
define
things
a
file
system.
Api
has
a
set
of
apis,
it
doesn't
know
or
care
whether
it's
a
word
document
an
excel
document.
You
know
a
golang
file
or
whatever
it
just
says.
I
know
how
to
persist,
content
in
this
store
and
then
it's
up
to
the
clients
to
decide.
I
know
what
to
do
with
that
content.
C
So
how
do
we
create
a
very
generalized
way
to
persist
things
in
a
registry
both
from
what
the
the
apis
for
what
I've
been
thinking
as
a
manifest?
It
says
just
defines
the
thing,
then
here's
what
makes
up
the
thing,
but
the
registry
is
pretty
stupid
about
it,
doesn't
care
whether
it's
a
home
chart
singularity
build
x,
whatever
it
carries,
a
property
that
allows
it
to
inform
by
the
way
this
is,
you
know,
a
helm.
This
is
a
cnav.
C
This
is
a
you
know,
singularity
a
scan
result
whatever,
but
the
registries
don't
need
to
know
about
that.
The
only
thing
the
registries
would
need
to
know
is:
how
do
I
persist
and
pull
push
and
pull
generic
things,
and
then
the
clients
can
decide
what
they
want
to
do
with
it.
Then
we
have
full
life
cycle
management
because
we
know
how
to
manage
it
and
so
forth,
and
then
the
idea
is
the
image
spec,
the
home,
spec,
the
singularity
spec
the
scan
result
specs.
They
all
say
hey
of
that
generic
manifest.
C
I
say
you
must
have
an
or
like.
Let's
take
the
image
stack,
the
image
spec
would
say:
I
must
have
a
collection
of
blobs.
There
must
be
at
least
one
and
the
blobs
are
ordinal
and
by
the
way
one
of
the
blobs
has
to
have
a
config
media
type.
That
would
be
the
image
spec
because
it
would
say
this
is
how
I
use
this
generic
manifest
the
helm,
spec
would
say:
hey.
C
D
D
A
D
A
A
A
Use
cases
where
other
people
are
shoving
other
stuff
that
are
types
of
manifest
they
just
should
be
ignored
because
they're
not
if
you're
a
container
runtime,
you
should
be
able
to
safely
ignore
them
and
that's
fine
and
if
you've
added
additional
functionality
in
it.
That's
fine
so,
rather
than
linking
to
that
specific
oci
image
manifest.
A
A
You
know
one
of
the
known
media
types
that
we
already
have.
Then
what
happens
if
you
like
saju,
said
that
they
had
done
at
some
point
where
they
ignored
it,
and
it
meant
that
they
later
garbage
collected
and
dropped
any
any
of
these
ignore,
ignored
or
unknown
media
types,
and
it
caused
issues
anyhow.
So,
rather
than
pointing
to
a
specific
implement
a
single
implementation
of
what
a
manifest
is
describe
the
nature
of
things
that
would
be
listed
there.
That's
all.
B
Yeah
and
I
think
the
ignored
phrase
there
probably
should
mean
different
things
to
different
people.
If
you're
the
runtime.
That's
trying
to
execute
this
thing,
which
you
mean
you
don't
try
to
execute
it,
but
if
you're
a
garbage
collector,
maybe
it
means
that
you
at
least
see
it.
There's
a
descriptor
out
there
and
do
your
best
effort,
but.
C
Yeah,
I
think
the
ignored
makes
sense
from
the
client.
It
doesn't
make
sense
from
a
registry,
so
I
think
that's
the
client
in
the
service
side
of
processing
of
that
is
what
became
a
little
ambiguity
but-
and
I'd
also
say
you
know,
based
on
the
word
we're
just
saying
I
love
I
like
the
idea
that
you're
saying
it
it's
a
list
of
manifests,
but
let's
define
what
a
manifest
is.
The
thing
I
was
objecting
to
is
saying
it's
a
restricted
list.
C
Today
there
is,
there
is
a
concept
of
what
a
manifest
is,
there's
a
couple
of
them
out
there
we're
trying
to
propose
some
new
ones,
but
we
never
actually
defined,
there's
no
hard
definition
to
what
describes
what
a
manifest
is
and
the
fact
that
buildex
is
trying
to
stuff
blobs,
which
clearly
aren't
manifest
in
the
manifest
collection.
That's
what's
triggering
this
conversation.
I
It
is
a
little
bit,
I
mean
when
I
say
restricted
events
I
mean
clearly
it
says
in
there
that
you
know
it's
a
restricted,
descriptor
type
right
where
the
media
type
has
to
be
one
of
these,
or
at
least
one
of
these,
I
guess
was
the
point,
and
I
and
I
guess
the
part
where
it
says
at
least
is
a
little
confusing.
I
could
see
word
yeah.
B
C
I
think
at
least
my
interpretation
of
this
and
granted
I
wasn't
in
the
original
group
that
created
these
docs,
so
I'm
just
one
of
the
many
that
came
in
is
trying
to
interpret
this
is
for
registry
to
be
a
container
registry.
It
has
to
at
least
support
the
image
manifest
if
you
want
to
support
the
index.
If
you
want
to
support
the
artifact,
if
you
want
to
support
joe
bob's
random
manifest,
then
you
can
it's
completely
consistent.
The
registry
has
to
implement
it
it.