►
From YouTube: OCI Weekly Discussion - 2023-02-23
A
B
D
F
D
D
F
D
The
thing
I
liked
about
1025
is
that
I
feel
like
we
had
all
these
different
options
up
here
of
what
we
can
do
and
it
gave
a
nice
visibility
of
what
we
want
to
pick
from
this
whole
list
of
everything
is
happening
and
my
thought
process.
If
we
can
look
through
this
and
say,
okay,
one
optional
expire
in
the
other.
Let's
pick
it
and
let's
go
with
it
that
might
help
us
decide
which
of
these
other
PRS,
what
direction
we're
going
to
go
with
some
of
these
things?
D
We've
got
a
lot
of
PR
sitting
out
there
during
directions
to
go
so
from
this.
Is
there?
Has
anybody
had
how
to
look
at
this
and
object
to
anything?
That's
in
here
I
know
we're
still
waiting
on
a
couple
of
answers
from
like
GCR
and
AR,
but
my
suspicion
is
that
the
zero
layer
is
probably
a
no
over
here.
D
Yeah,
the
the
zero
layer
I'll
go
down
to
these.
The
zero
layer
looks
like
this.
It
was
my
original
comment
of
add
her.
The
GCR
has
issues
with
this.
When
you
push
a
manifest
with
size,
zero,
that's
only
second
hand,
knowledge
the
other
option
that
I
liked
better
was
thrown
out
there
of
saying
well
what
if
we
just
Define
it
like
this,
where
you've
got
this
shot
here,
which
is
the
double
brackets
same
as
this
shot
here?
D
So
what
you
put
in
the
config
is
pretty
much
empty,
it's
nothing,
but
that
one
will
blob.
You
do
push
a
layer,
but
it's
the
same
as
what's
in
the
config.
Mini
type
might
be
different,
but
it's
for
all
purposes.
It's
an
empty
there's,
nothing
there,
but
those
two
bytes
and
I
think
any
clients
seeing
that
would
treat
that
as
basically
empty
at
that
point,
and
they
would
know
the
tree
is
empty,
is
because
they're
looking
at
this
media
type,
they
know
what
they're
supposed
to
do
with
this
media
type
here,
and
so
they
know.
D
D
We
don't
have
to
modify
what's
in
the
spec
today
we
just
document
when
you
see
this
it
it's
valid
according
to
the
spec
other
than
a
media
type,
not
really
representing
what
it
what's
really
under
the
covers,
but
you
can
do
it
today.
We
don't
have
to
change
the
spec
to
do
it.
It
works
with
all
the
Registries.
They
just
kind
of
felt
like
a
really
good
option
to
me.
G
B
D
D
My
goal
right
now
is
to
say
if
we
needed
to
find
the
fallback,
let's
get
that
defined,
let's
get
a
1.1
out
and
then
let's
Circle
back
and
try
to
figure
out
how
we
did
the
artifact
manifest,
because
I
I
think
it's
still
something
we
want
to
do.
At
least
some
of
us
want
to
do,
and
so,
let's,
let's
do
the
easy
problems
first
and
then
work
on
the
hard
problems
later.
H
I
think
I
think
my
only
concern
about
this
is
it
feels
like
the
specification
is
going
down
the
road
to
look
like
x509's
use
of
asn.1,
where
we've
got
sort
of
a
a
fractal
degree
of
complexity
in
the
image
manifest
where
parsing
one
is
highly
context,
dependent
things
like
descriptors,
don't
actually
waiting
to
update
descriptor,
for
example,
and
I
commented
this
on
999
is
the
media
type
of
a
descriptor
is
no
longer
the
media
type
of
The
Blob
associated
with
it.
We're.
H
H
The
specification
says
the
media
type
must
be
the
content
of
The.
Blob
must
describe
the
content
of
the
plot,
so
I'm
just
saying,
like
we're,
adding
a
lot
of
sort
of
caveats
to
the
existing
specification
here
when
we
accept
something
like
this.
This
that's
my
concern
is
that
this
pushes
a
lot
of
complexity
down
into
implementations
in
the
future.
D
D
That
looks
a
little
bit
weird
coming
back
over
into
the
images
package,
just
because
we're
trying
to
take
this.
This
knowledge,
that's
out
there
already,
where
we
say
hey
when
you
see
something
that
has
this
other
media
type
curve
there
handle
it
differently
and
that's
that's
how
we
document
before
another
repo
and
so
we're
just
giving
this
into
one
place.
D
H
Yeah,
so
we
have
a
number
of
places
in
the
specification
where,
in
some
places
we
have
used,
must
ignore
errors
and
other
places.
There's
this
word
ignored,
and
it's
been
kind
of
unclear
to
me
what
ignoring
means
in
some
places
so
I've
changed.
The
use
of
ignore
in
those
places
too,
must
not
generate
errors.
D
D
I
think
that's
where
I
was
going
with.
My
PR
was
that
I
was
calling
out
specifically
client
versus
registry,
ignore
and
a
registry
ignore
means
that
you've
got
content.
Addressable
content,
the
digest,
doesn't
change.
The
content.
Doesn't
change.
You
just
return
back,
exactly
what
you
received
or
a
client
ignore
means.
Hey
I
received
a
bunch
of
Json
I
know
how
to
do
something
with
five
nights
of
it.
Then
you
only
work
on
the
five
mindset.
You
know
how
to
work
with.
H
D
I
I
I
J
F
I
H
I,
don't
think,
there's
anything
in
specification
that
requires
a
registry
to
understand
future
versions
of
oci
and
be
able
to
parse.
For
example,
if
we
added
a
subjects
field
that
allowed
a
an
image
or
artifact
to
refer
to,
multiple
manifests
like
that
would
just
not
an
oci
1.1
registry
would
just
not
understand
that
and
yeah.
It
would
potentially
not
understand
the
children
properly,
but
does
that
answer
your
question
Tiana.
D
I'll
say
kind
of
relate
to
that
when
we
added
the
subject
field
to
the
image,
spec
I
think
the
Assumption
was
that
Registries
that
knew
how
to
work
with
oci,
1.0
stuff
would
see
this.
They
wouldn't
parse
the
subject
View
at
all
and
they
wouldn't
do
any
GC
or
anything
else,
any
any
kind
of
graph
basis
of
that
subject:
field,
and
that
was
okay
with
our
design,
because
the
way
we
laid
it
out
so
maybe
it
needs
to
come
along
that
hey
in
the
first
iteration
of
any
media
type
that
we
introduced
to
a
registry.
D
D
G
Yeah,
so
this
kind
of
gets
down
to,
like
my
objections,
to
artifact,
manifest
as
it
is
currently
defined
today
as
a
static
set
of
fields
that
all
implementations
need
to
learn
about,
because
it
doesn't
solve
this
problem,
we're
talking
about
of
oh.
If
we
evolve
the
spec
further,
then
we
need
to
update
everything
again.
G
Obviously,
you
need
to
update
clients
that
care
about
additions
to
the
document,
but
there
are
a
lot
of
implementations
like
things
that
copy
stuff
or
things
that
store
stuff
without
running
or
modifying
them.
That
would
operate
just
fine
without
actually
knowing
the
semantics
of
new
Fields,
if,
if
artifact
manifests,
were
defined
in
such
a
way
that
I
could
write
a
correct
registry
that
would
work,
even
if
you
added
the
subjects
field
with
you
know,
a
list
of
descriptors
I
wouldn't
really
have
any
objections
to
it.
G
G
If
we
do
it
once
and
not
every
time,
we're
going
to
change
these
things
going
forward
so
like
I'm
interested
in
solving
that
problem
today
and
not
again
later
when
we
add
another
field,
otherwise
I
think
it's
not
worth
adding
the
artifact
manifest
yeah
I,
don't
know
where
I
was
going
so,
but
like
this,
this
is
the
point
of
999
it's
like.
Can
we
solve
this.
C
G
There
also
exists
the
artifact
manifest
that
I'm
trying
to
remove
and
pull
request
999..
They
are
functionally
the
same
from
my
perspective,
I
think
some
people
disagree
with
that,
but
they
adding
this
artifact
manifest
has,
in
my
opinion,
no
benefits
but
has
the
drawbacks
that
existing
clients
and
registries
won't
work
with
it,
and
it
causes
a
lot
of
churn
in
the
ecosystem
to
get
to
the
point
where
those
would
work
with
it
and
it
doesn't
solve
the
problem
that
it
introduces
of.
G
D
I'll
make
an
attempt
to
summarize
the
other
side
quickly,
hopefully,
I'll
be
able
to
do
it,
which
is
that
we
would
be
able
to
differentiate
between
image,
content
and
artifact
non-image
content,
so
abstract
art
content
just
by
the
media
type,
not
looking
at
the
embedded,
config
descriptor
and
the
config
descriptor
itself
needs
to
point
to
some
kind
of
blob.
We
don't
necessarily
always
want
to
have
a
blob
in
there.
If
we
just
want
to
note
that
hey
this
is
an
artifact
of
this
type.
D
C
G
D
I
I
D
A
lot
of
there's
a
lot
of
confusion
out
there,
that's
inflating
the
artifact,
manifest
with
pushing
artifact
within
an
image
manifest
and
where?
What
we're
saying
is
you
can
push
an
artifact
in
the
image
manifest
because
we
already
have
the
image
manifest.
You
don't
need
the
new
manifest
to
do
this
stuff.
Yeah.
I
C
D
They
see
today,
the
config
media
type
is
different.
So
when
they
pull
down
that
image
manifest,
they
see
the
configure
you
type
and
say
I,
don't
know
what
that
convey.
Media
type
is
I'm
looking
for
either
a
Docker
config
or
an
oci
config,
and
this
is
a
Helm
chart.
I,
don't
know
what
to
do
with
that
and
they
failed
that
part.
C
D
That
also
gets
in
if
you're
talking
about
the
media
type
of
the
config,
you
can
do
that
in
the
descriptor.
If
you're
talking
about
the
blob
content
of
the
config,
that's
where
we've
got
some
disagreement
here
of
saying
we're
going
to
set
a
config
media
type
that
says
I
am
X,
even
though
the
blob
that's.
There
is
just
a
couple
of
curly
brackets,
it's
not
actually
X,
and
so
we
might
need
to.
As
a
spec
authors
here
say:
here's
how
we're
gonna
handle
that
kind
of
confusion.
D
Yeah
we
tried
as
best
we
can
not
put
that
into
the
spec
just
because
we
don't
know
what
someone's
going
to
create
later
on
the
next
day,
and
we
don't
want
the
spec
to
be
the
maintainers
of
that
list.
So
the
general
recommendation
is
that
it.
Ideally
it's
an
in
a
registered
media
type,
if
not
is
at
least
in
the
format
of
an
Ina
media
type,
and
so
follows
their
spec
on
how
it
should
be
formatted
with
the
something
slash
something
else.
I
D
So
I
think
got
the
handful
of
issues
there.
We've
got
to
find
what
the
middle
manifest
is.
I
think,
there's
somewhat
agreement,
I
hope,
there's
agreement
we'll
find
out
when
I
submit
the
pr
to
start
documenting
some
of
this
stuff
to
go
with
that
last
column
to
say
we're
just
going
to
use
the
double
bracket.
D
D
D
This
thing
doesn't
have
a
config
so
ignore
these
things,
they're
just
stub
values
there
to
make
the
image
manifest
happy,
and
so
we
need
to
put
some
documentation
there.
That
says
that,
even
though
we
say
that
every
time
you
have
a
descriptor,
the
media
type
descriptor
must
be
the
media
type
of
the
content.
In
this
case,
we're
going
to
draw
an
exception.
There.
I
What
aggression,
it's
all
good,
I,
think
the
the
primary
thing
that
people
need
to
know
is
the
use
cases
are
going
to
still
be
there.
Okay,
they
architecturally.
You
know
one
might
think
it's
a
little
bit
ugly,
this
this
this
version,
but
it's
the
it's
the
ugly
baby
that
we've
been
working
with
for
the
last
four
years
and
it
and
it
does
work.
I
E
D
G
G
G
That
is
how
I
have
solved
this
problem.
There
are
other
ways
to
solve
this
problem
like
defining
one
field,
say
descriptors
or
something
or
maybe
two
Fields
like
descriptors
and
subjects,
and
then
the
rest
of
the
Manifest
is
just
whatever
you
want,
and
so
you
have
you
know:
Registries
can
parse
two
three
well-known
Fields
out
of
the
thing
that
would
cover
all
of
the
relationships
that
that
manifest
has
within
it.
And
so
let's
say,
config
is
one
of
those
relationships.
G
A
G
Man
yeah,
what
I
imagine
it
would
be
would
be
like
media
type,
descriptors
and
then
I
guess,
that's
it
yeah
like
that
is
enough
and
then
any
other
fields
you
can
completely
ignore
or
do
something
with
them
so
subject
would
be
like
a
new
optional
field.
If
the
registry
knows
about
subject,
then
it
can
have
the
refers
API
that
that
is
one
way
I
would
solve
this,
but.
G
Into
your
field
description,
so
if
you
want
the
registry
to
like
maintain
invariance
around
relationships,
then
you
could
put
the
subject
descriptor
inside
the
descriptors
list
as
well.
This
is
a
way
to
like
hide
relationships
from
the
registry
too,
by
not
including
them
in
the
descriptors
field,
something.
F
G
D
Yeah,
hey
give
some
thought,
because
one
of
my
thoughts
is
from
listening
to
that,
the
one
that
caught
my
attention,
the
most,
which
one
you
said,
having
a
map
of
a
string
to
a
list
of
descriptors
and
I
was
like
I
can
see
some
value
there.
I
could
see
some
people
writing
artifacts.
That
would
like
be
able
to
say
here
is
all
this
type
of
content,
all
this
type
of
content,
each
one's
a
list.
G
Yeah,
the
other
issue
is
like
the
registry
is
bad
by
the
fact
that,
like
we
have
manifests
and
blobs
stored
slightly
differently
and
so
like
having
one
field
isn't
great,
but
you
know
we
could
have
two
right
manifest.
You
could
have
blobs
and
those
could
be
two
well-known
fields
for
artifact
manifest.
G
Then
you
have
the
other
media
type,
let's
say
artifact
manifest
and
when
you
put
that
done
or
you
know,
media
type
could
say,
Helm
chart
or
whatever
and
registry
doesn't
care
it.
Just
parses
manifests
and
blobs
and
media
type.
It
uses
that
to
store
it
and
maintain
relationships,
and
then
you
have
other
fields
like
hell
thing:
I,
don't
actually
know
anything
about
home.
So
it's
nice
right.
You
remove
certain
things.
You
can
promote
fields
to
the
top
level.
You
don't
have
to
have
annotations.
D
Yeah
once
you
once
you
add
the
Manifest
in
there,
then
we
definitely
can't
treat
the
subject
field
as
a
as
basically
creating
that
reverse
Link.
At
that
point,
I
know
you
and
I
have
gone
back
and
forth
on
that
a
whole
bunch
of
saying,
hey,
you
can't
reverse
the
links,
don't
cross
the
streams,
kind
of
stuff
and
yeah.
D
G
G
G
D
D
This
is
a
index
and
I've
got
a
bunch
of
children
from
that
index.
One
is
the
Manifest
for
386
and
others
manifest
for
64.
arm
V6
arm
64,
all
these
different
things.
Each
one
of
these
are
image
manifest
and
then
each
one
of
those
has
some
kind
of
thing
laying
off
of
it.
This
first
thing
is
not
great
to
look
at
because
they're
misusing
media
types
so
we'll
ignore
them
for
a
second,
but
I've
got
stuff
like
Cyclone
DX,
spdx
I
could
have
other
things
in
there.
D
They
are
all
things
that
kind
of
extend
this
image,
and
so,
if
I'm
looking
for
what
are
all
the
s-bombs
for
these
images,
this
is
kind
of
walking
that
tree
in
that
way,
and
so
it's
The
Logical
way.
I've
looked
at
this
so
far,
and
the
challenge
is,
if
we
say
this
all
of
these
s-bombs
they're,
not
children
of
this
image.
They
have
a
subject
that
points
to
that
image,
but
they're,
not
children
of
that
image.
G
D
F
G
D
G
F
D
G
G
C
So
we
did,
we
did
bring
that
bit
up
in
proposal
C
and
we
didn't
use
it
because
we
didn't
want
to
enforce
garbage
collection
but
yeah.
If,
if
that's
the
case-
and
this
seems
to
be
like
a
a
problem
trying
to
fit
a
a
regular
dependency
tree
into
something
that
is
meant
for
a
bag,
then
maybe
this
is
more
difficult
than
we
thought.
G
D
G
G
G
G
D
I
I
completely
understand
the
logic
of
what
you're
saying
I'm,
trying
to
understand
how
to
take
that
logic
and
apply
it
to
the
user
request
which
is
I
just
want
to
know
that
all
my
images
have
s-bombs
on
them
and
that
they
have
signatures
that
kind
of
stuff.
And
so
how
do
I
give
them
a
view
of
saying
here's
all
the
metadata
on
your
image,
and
so.
G
Well,
so
you've
done
that
already
right,
that's
the
one
level
of
reverse,
but
if,
if
you
like,
so
you
could
in
your
referrals,
subtree
right,
you
could
show
all
of
the
referrers
relationships,
because
that
that
you're
going
backwards
only
backwards
there.
But
you
could
not
show
the
children
relationships
under
the
refer
section.
G
J
J
G
G
D
G
D
G
But
they
are
relevant
to
your
route.
Okay,
that's
like
why
it
refers.
Api
exists
like
I
want
to
know
about
my
route.
If
you
wanted
to
know
about
things
in
your
route,
you
go,
you
can
go
down.
You
know
down
the
graph,
find
everything
that
is
referenced
by
my
root
and
then
go
back
up
from
there
and
as
long
as
you're,
only
going
up
you're
never
going
to
have
a
cycle
but
like
if,
if
there's
stuff,
not
something
that's
reachable
from
my
root,
I,
don't
care
about
it.
D
I
I
D
D
Well,
that's
where
I
was
trying
to
get
at
if
we
make
an
artifact
manifest
that
has
arbitrary,
manifest
as
its
children.
Things
get
really
complicated
here
really
quickly.
When
we
started
off
and
said,
artifacts
can
only
have
blobs
that
that
collapsed,
a
layer
of
the
complexity
here
and
we
didn't
have
to
worry
about
things
but.
D
Yeah
I
mean
a
lot
of
our
apis
right
now.
Everything
we
do
this.
This
was
kind
of
taking
that
and
extending
it
a
whole
lot
because
all
the
commands
we
have
now
says
I've
got
this
digest
off
the
top.
Give
me
all
the
refers
to
it
and
from
the
sample
there
are
none,
there's
ear
be
first,
but
there
are
all
these
s-bombs
on
each
of
the
individual
manifests
that's
kind
of
something
that
users
might
want
to
see.
F
A
D
G
F
A
A
List
right
and
the
reference
are
separate,
Roots,
actually
speaking,
so
you
would
have
children
to
each
one
of
those
which
is
the
Cyclone.
Dx
could
have
other
blobs
or
things
like
that,
but
it
could
also
have
other
refers,
which
would
be
again
more
rude,
so
it
gets
really
complicated
to
render
this.
G
B
And
that
sounds
like
something
that
could
be
useful
for
something
like
build
packs
as
well.
Right,
like
you,
have
things
for
the
container
image
separated
into
very
distinct
things.
The
other
thing
I
was
thinking
about,
is
you
know,
leveraging
some
some
aspect
of
composition.
Right,
like
you,
have
a
s-bomb,
that's
split
out
for
every
layer,
and
then
you
can
compose
the
aggregate,
s-bomb
I.
Don't
think
any
of
that
works
today
with
the
specs
on
either
side.
But
but
like
is
it
interesting
and
I
idea?
D
But
I
was
me
putting
away
the
command
line.
There
was
not
me
trying
to
show
too
much
liquid
line
to
Tina's
point
there.
It's
more
just
showing
the
concept
of
why
someone
want
to
look
at
this
as
a
tree
and
I
was
gonna
show
and
I
failed.
There
is
another
Aurora's
command
that
does
pretty
much
the
same
thing.
I
was
just
replicating
some
functionality
from
over
there.
So
it's
not
simply
one
project
doing
that
I
think
there's
a
value
for
a
lot
of
projects.
They're
looking
doing
this.
D
Even
not
even
thinking
about
clis
thinking
about
garbage
collection,
thinking
about
all
these
other
if
I
want
to
copy
this
route
to
another
registry,
I
want
to
recursive
copy
of
all
the
content
you're
going
to
follow
that
tree,
and
so
all
the
20
gets
written
on
this
going
forward.
That
used
to
be
able
to
assume
that
everything
I
was
touching
was
a
dag
is
now
going
to
be
updated
to
assume
that
it's
going
to
be
on
a
multi-rooted
tag.
At
that
point,
and
potentially
a
circular
one.
D
Boy
that
answer
as
best
I
can
here
yeah
the
the
one
comedy
did
make,
though,
was
that
did
get
my
attention
earlier
was
how
we
can
extend
the
artifact
to
make
it
more
complex
and
so
I
think
that
shows
that
maybe
there
is
a
point
here
coming
up.
Well,
that's
why
everybody's
dropping
off
we're
at
the
top
of
the
hour
thinking
of
how
we
can
extend
this
in
the
future.