►
From YouTube: OCI Weekly Discussion - 2022-08-11
A
B
A
A
A
C
C
C
It's
got
an
artifact
type
field,
and
so
that
kind
of
that's
used
that
we're
looking
at
the
media
type
from
the
config
descriptor
on
the
existing
image
manifest,
and
we
also
have
an
artifact
media
type
or
artifact
field
on
the
artifact
manifest.
And
so
we
can
look
at
that.
And
then
we've
got
the
api.
So
that's
kind
of
the
long
term
where
you
want
to
get
to
and
we've
got
a
upgrade
path
that
we're
also
looking
at.
C
And
so
the
idea
is
that
for
registries
that
don't
have
this
api
a
day,
they
don't
have
the
new
media
type.
You
can
still
push
the
existing
image,
manifest.
The
way
that
the
artifact,
the
oci
artifact,
defines
it
with
a
custom
eotype
for
the
config,
and
you
would
need
to
also
push
up
the
resulting
response
that
you're
going
to
expect
from
the
api
and
so
I'll
show
how
that
works
in
a
bit
and
once
registries
do
upgrade.
C
C
This
was
just
kind
of
a
call
out
something
to
think
about
for
ci
in
general,
but
the
important
part
once
we
add
the
new
manifest,
is
kind
of
how
we
work
with
them
so
go
through
the
two
manifest
the
new
manifest
is
oci
artifact
manifest
and
with
that
we're
going
to
have
an
artifact
type,
that's
going
to
be
included
in
there
and
an
array
of
blobs,
and
so
it
looks
fairly
similar
to
an
image
manifest.
We've
changed
layers
to
blobs.
C
We
got
rid
of
the
config
and
we
pulled
up
that
media
type
from
the
config
up
to
the
top
level,
but
otherwise
it's
fairly
similar.
The
big
difference
is
because
it's
a
different
media
type
altogether,
one,
the
config,
is
no
longer
really
required,
so
that
eliminates
an
extra
bit
of
complication.
I
think
people
are
having
with
this
of
pushing
up
a
separate
blob
for
the
config
blob
and
we
don't
say
that
the
blob
order
matters
where,
when
you
look
at
the
layers
in
the
existing
spec,
they
all
say
that
the
order
is
very
important.
C
So
we
we
kind
of
eliminate
those
two
challenges
and
it's
also
an
optional
list.
If
you
have
zero
blobs,
you
can
push
that
up
where
I
think
we
say
that
you
need
to
have
at
least
some
layers
in
your
image,
so
that's
kind
of
the
difference
between
the
two.
The
other
thing
we're
doing
is
we
have
the
reverse.
C
So
this
says
I
am
referring
to
another
and
that's
kind
of
the
big
reason
the
working
group
was
great
was
to
be
able
to
say,
okay,
how
do
you
refer
to
another
manifest?
How
do
you
extend
another
image
and
any
annotations
should
go
in
there
once
you
do
that,
you
can
then
call
the
refers
api.
So
we
kind
of
said
refers
is
kind
of
the
field
you
put
inside
of
your
manifest
and
if
you
want
to
say,
okay
find
this
digest
out
there.
There's
a1
whatever
tell
me
everything
that
points
to
that
digest.
C
You
can
call
the
referrers
api
with
that
a1
digest
and
it'll
come
back
and
say:
oh
I've
got
this
manifesto
over
here,
that's
pointing
to
it.
Give
you
that
list
of
descriptors
and
the
way
we
return
our
list
of
descriptors
or
ci
likes
up
pretty
easily.
We
just
use
the
index
just
return
index
with
a
list
of
manifest
in
there.
C
C
So
if
you
have
any
annotations
down
there,
those
get
pulled
up,
and
then
let's
see
that
is,
if
you've
got
the
api.
So
it'll
just
give
you
that
response,
and
so
you
can
query
that
and
see.
Okay
for
my
given
image,
tell
me
all
the
s
bombs,
all
the
signatures,
everything
else
that
refer
to
this
one
so
that
I
can
go,
find
them
and
pull
them
as
needed
and
because
you've
got
all
the
annotations.
You
can
then
do
client-side
filtering
and
figure
out.
C
C
We've
also
got
some
ideas
in
here
for
pagination.
So
if
you
need
to
have
more
than
one
oci
index,
I
think
it's
going
to
be
an
extreme
case.
We're
kind
of
looking
at
the
numbers
we're
going
to
have
like
thousands
of
potential
descriptors
you
can
put
in
there
as
long
as
people
are
well
behaved,
not
throwing
a
whole
bunch
of
stuff
in
their
annotations.
C
But
if
the
worst
were
to
happen,
somebody
threw
a
whole
bunch
of
annotations
out
there
put
a
giant
descriptor
that
just
filled
everything
up.
We
do
have
the
ability
to
have
multiple
indexes
returned
from
the
api,
not
from
the
fallback
but
at
least
from
the
api,
and
then
we
defined
some
filtering
options
in
there
at
least
for
right.
C
Now
it's
just
the
one
filtering
option,
which
is
you
can
pass
an
artifact
type
and
if
you
say
I
want
this
one
specific
artifact
type,
the
registry
will
come
back
and
say
I've
got
the
responses
that
have
the
artifact
type
filter
applied
and
only
those
entries
with
that
artifact
type
are
returned
to
you
and
nothing
else
which
will
help
clients
that
want
to
say
I'm
a
client,
I'm
only.
I
only
care
about
my
one
artifact
type.
I
don't
care
about
all
these
other
artifact
types
that
are
out
there.
C
It
can
filter
on
just
as
things
that's
the
long
term
we
want
to
get
to
knowing
that
we're
not
going
to
get
there
on
day
one.
We
do
have
a
digest
tag
out
there,
that's
kind
of
a
fallback
and
so
clients
that
say:
hey.
I'm
trying
to
check
this
api
on
an
artifact.
That's
pushed
up.
The
api
is
giving
me
back
a
404.
So
clearly,
this
registry
is
a
1.0
registry
ahem
upgrade
in
the
newest
spec.
C
I
don't
need
to
fall
back
and
manage
this
tag,
and
this
tag
is
the
digest
of
the
thing
you're.
Referring
to
so
you
push
up
your
manifest.
You've
got
a
reverse
field
in
your
manifest.
You
now
need
to
go
and
look
for
this.
If
you
don't
have
the
api
and
update
it
or
create
it,
and
the
content
of
this
is
exactly
what
you
would
see
back
from
the
content
of
any
of
what
you're
looking
at
above
so
exact
same
image
manifest
it's
just
now
managed
from
the
client
instead
of
managing
the
server.
C
Because
of
that
we've
got
a
description
here
for
when
the
registry
server
needs
to
upgrade.
So
when
the
registry
server
itself
is
changing
from
with
versus
without
we
kind
of
go
through
and
describe
okay.
Well,
you
need
to
go
through
and
look
at
everybody.
That's
already
got
one
of
these
and
yeah
any
existing
image
or
other
thing
that's
referenced
by
one
of
those
digest
tags.
You
need
to
import
those
and
any
new
manifest
that
comes
up
afterwards.
C
C
I
think
I'll
be
a
little
bit
onerous
on
something
like
a
docker
hub
or
one
of
the
other
big
cloud
registries
out
there,
and
so
we're
saying
if
it's
got
one
of
these
digest
tags
that
the
client
would
have
pushed
down
here
then
scan
that
get
the
contents
from
that
in
there,
so
that
a
client,
that's
looking
for.
Does
the
api
exist
when
the
api
does
exist,
it
doesn't
have
to
fall
back
and
also
look
at
the
digest
tag.
What
exists?
The
client
just
says
it's
a
or
b,
you
know
the
api.
C
Is
this
or
it
doesn't
exist,
and
so
either
there's
managing
the
dodgers
tag
or
it's
not
and
do
that
the
server
needs
to
work
with
it
as
well
of
saying,
okay,
if
I'm
going
to
enable
that
api,
I
need
to
pull
in
everything
that
was
in
that
dodges
tag
previously
to
my
api
being
available
and
then
yeah
we've
got
a
whole
bunch
of
other
descriptions
in
here
portability,
thoughts,
garbage
collection,
thoughts
that
kind
of
stuff.
This
was
all
in
our
proposal.
C
The
end
result
for
people
like
pictures.
I
feel
like
a
lot
of
people
like
pictures.
Is
that
we're
gonna
have
you
might
have
a
multi-platform
image
out
there?
It's
got
a
tag
point
to
it.
It's
gonna
have
its
manifest
for
something
like
your
image.
It's
config,
it's
layers,
all
that
stuff
and
now
you're
gonna
have
maybe
an
s
ball.
Maybe
a
signature
point
back
to
that,
and
so
it's
got
a
refers
field
inside
of
this.
It's
pointing
back
to
that
manifest
and
if
the
api
exists
then
you'll
query
you'll,
get
this
oci
index.
It'll.
C
Give
you
back
these
things.
Whenever
you
say
I
pulled
this
image
here.
Tell
me
everything
points
to
it.
You
can
query
that
if
the
api
doesn't
exist,
you
can
fall
back
and
say
give
me
the
tag.
That'll
have
the
same
index
there.
That
gives
that
list,
and
the
question
is
whether
or
not
it's
going
to
be
managed
by
the
server
or
the
client
just
based
off
whether
or
not
it's
the
tag
or
the
api
response.
B
C
So
you,
you
can't
sign
the
api
result,
you
would
you
would
have
the
signature
inside
of
your
manifest
itself
for
the
same
draw
on
your
manifest.
So
this
is
a
dynamically
generated
list
that
you're
not
going
to
sign
this
itself,
but
the
thing
in
that
the
thing
that
that
points
to
either
maybe
this
thing
you're
signing.
So
this
is
an
s
bomb.
You
would
have
a
signature
on
that
itself.
B
C
B
C
It
absolutely
yeah
it
absolutely
can
it
could
also
laugh,
you
say,
give
me
v2
and
it
comes
back
with
a
different
index
and
what
the
v2
index
really
is,
and
so
the
signing
is
going
to
happen
on
this
index
here
this
over
here.
You
know
these
things,
you're
kind
of
assuming,
once
you
get
above,
that
that
you're
not
signing
the
tag
itself,
you're
signing
the
index
you're
not
signing
this
index
here,
you're
signing
this
manifest.
C
B
C
Yeah-
and
this
like
I
say
this
is
dynamic,
it's
changing
and
the
trust
in
there
keep
in
mind.
Clients
can
write
the
reason
we
really
want
to
get
to
the
registries
having
the
api
is
because
different
clients,
if
they
start
screwing
up
each
other,
this
kind
of
gets
clobbered,
and
so
we
really
hope
that
by
defining
this,
as
best
we
can
within
the
within
the
spec
that
clients
will
cooperate
and
be
nice
to
each.
C
C
C
We've
got
changes
the
readme,
because
we
changed
a
few
things
in
here.
So
this
is
going
to
be
the
distribution
spec.
We
got
one
for
distribution
spec,
one
for
image,
spec
in
distribution
spec.
We
actually
add
a
new
file.
There
called
client
implementation,
and
the
idea
of
this
is
for
clients
that
are
implementing
us
on
the
client
side.
C
They
need
to
know
how
to
work
with
the
registry,
whether
it
is
a
1.0
versus
I'm,
assuming
we're
going
to
be
like
a
1.1,
something
like
that
for
the
distribution
spec
once
you
get
to
1.1
you'll
have
the
new
api
calls
and
the
clients
can
use
those,
but
if
you
have
a
client
that
knows
how
to
use
this
stuff
that
talks
to
a
1.0
registry,
this
is
documenting
the
fallback.
This
document,
okay,
you've
got
that
tag
schema
sitting
out
there.
How
do
you
push
it?
When
do
you
push
it?
How
do
you
maintain
it?
C
So
that's
document
over
there
how
to
list
how
to
delete
how
to
delete
something
that
was
pointing
to
something
else,
a
bunch
of
different
scenarios
there,
the
spec
itself.
We
then
add
another
section
into
let's
see,
pulling
pulling
a
manifest
or
pushing
manifest.
We
had
to
document
that
hey
if
you've
got
a
reverse
field
in
there
go
check
out
the
client
implementation,
because
you
need
to
worry
about.
C
C
We
now
have
the
listing
referrer
section
and
this
documents
the
new
api
that
we
added,
including
you
know
you
call
it
you
say,
go
to
v2
within
the
name.
Slash
refers
and
the
digest
you
want
to
pull,
and
if
you
do
that,
you
get
back
this
thing
and
we
documented
here
what
it
must
look
like.
If
you
have
no
refers
at
all
that
you
are
going
to
return,
you
need
to
return
empty
lists,
not
a
404,
because
the
client
needs
to
be
able
to
differentiate
between
the
server.
C
Has
the
api
or
there's
no
results
in
the
api,
and
so
we
say:
don't
give
a
404.
If
you've
got
this
api
on
the
server
and
then
yeah
you
get
back
the
response
there.
We
document
the
link
that
goes
back
to
an
rfc.
We
didn't
want
to
reinvent
the
wheel.
We
said:
hey
just
use
the
rfc
to
document
that
link
header
and
use
the
next
field
in
there
and
let's
see
the
artifact
type
we
defined.
How
to
do
the
filtering
on
the
artifact
type
got
the
other
api
there.
C
Nope,
okay,
I
see
people
come
with
me
to
get
my
attention.
Let's
see
and
let's
see
sample
for
filtering,
we've
got
it
sitting
out
there
for
if
you've
got
the
example
s
bomb,
you
query
that
one.
This
is
the
above
example.
Here
we
talked
about,
you
can
query
the
signature
and
the
s
ball,
artifact
type,
and
if
you
ran
this
same
query
to
the
same
request
and
said
just
give
me
the
s
bomb,
it
will
come
back
and
say:
okay,
here's
your
response
with
just
the
s
bomb.
C
Other
than
that
we
add
a
new
api
down
there
and
since
we
had
to
go
a
b,
everything
got
indented,
and
so
we've
got
these
two
added
to
the
bottom,
and
then
we
have
the
upgrade
documentation
for
registry.
Saying
hey.
If
you're
a
registry,
you
must
include
any
pre-existing
images
that
have
that
digest
tag,
and
we
kind
of
point
over
to
what
the
digest
tag
is.
We
said:
hey
go
over
look
at
the
client
implementation
for
how
that
looks.
C
If
anybody
pushed
that-
and
you
add
this
new
api,
you
must
include
those
you
may
if
you
want
to
include
everything.
So
if
you're
small
registry-
and
you
just
want
to
scan
everything,
go
for
it
more
power
to
you
and
from
that
point
forward,
any
new
manifestos
push
needs
to
be
included
so
that
covers
distribution
spec.
C
C
We've
got
the
description
of
the
new
artifact
we're
pushing
up
there,
and
so
it's
got
a
media
type.
It's
got
the
artifact
type.
It's
got
blobs
in
this.
It's
a
must
that
you
include
the
media
type.
We
wanted
to
avoid
the
cv
that
we
experienced
a
while
back,
and
so
we
start
off
day.
One
media
type
is
a
must,
artifact
type
is
a
should.
We
think
you
probably
should
include
one
of
those,
but
if
someone
doesn't
we
didn't
want
to
call
that
a
spec.
C
C
C
C
C
D
C
D
D
C
E
B
A
Well,
I
I
mean,
if
it's,
I
guess
you
know,
that's
like
jumping
into
the
reviews,
like
the
next
step,
if,
if
the
folks
who,
if
merging
this
today,
doesn't
break
current
implementations
and
like
you
know,
I
heard
from
what
brandon
just
said
of
that,
there's
like
effectively
a
sniff
test
that
you
can
see
that
the
there's
an
up
you
know
api
upgrade
path
available
like
oh
this.
The
registry
does
support
it
and
you
can
like
do
that
then,
like
there
have
been
you
know
in
the
past.
A
The
registries
that
see
value
in
you
know
implementing
this,
because
it
enables
them
to
do
stuff,
like
a
number
of
us
have
talked
about
or
because
their
customers
are
asking
for
it.
You
know.
In
the
meantime,
they
could
have
a
registry
that
implementation
that
just
languishes
then
that's
kind
of
on
them.
D
Yeah,
the
other
thing
I'll
add
to
is
that
there
is
a
fork
that
I
think
started
with
auras
stuff,
that
is
implementing
this
of
distribution
and
I'm
not
so
I'm
not
so
sure
about
aura's
client,
jason
who's,
not
here
starting
to
work
on
ggcr
support
so
and
then
brandon
has
the
red
client
project.
So
there
are
a
few
things
already
starting
to
do
this.
I
think
zot,
I'm
not
sure
if
saat
has
yet
but.
C
The
comment
we
got
back,
we
we
proposed
to
them
and
said
hey,
give
us
feedback,
and
they
understood
that
we
were
looking
for
rapid
feedback,
didn't
didn't,
hear
and
know
what
they're
looking
at
right
now
is.
They
are
going
to
add
support
for
artifacts
proper
in
terms
of
not
filtering
on
that
config
media
type
anymore,
so
they
may
not
support
the
full
api
on
day
one
but
they'll
at
least
stop
blocking
those
custom
media
types
on
the
config.
C
Their
suggestion
was
to
only
have
one
index
for
the
image
itself
and
then
modify
it
from
their
image
originator
and
then
have
a
secondary
one
to
fall
back
with
that
digest.
Descriptor
we
kind
of
lean
toward.
We
still
want
that
api
at
some
point
and
we
want
that
digest
descriptor
to
be
pointing
to
every
manifest,
not
just
the
top
level
index.
C
C
So
from
that,
I
think
we're
going
to
make
them
happy
that
they
support
that
and
what
we've
said
is
hey
if
the
media
type
that
you're
using
on
your
artifact
says
that
this
media
type
requires
that,
let's
be
ordered,
that's
up
to
you,
you're
the
media
type
definer
there
for
your
artifact
type.
You
can
pick
and
choose
how
that
blog
list
is
supposed
to
look.
C
We've
got
that
the
manifest
itself
is
supposed
to
stay
less
than
four
megabytes,
and
so,
if
we
start
getting
a
whole
lot
of
these
artifacts,
that
would
be
hitting
up
to
that
limit.
But
I
think
we're
talking
about
thousands
of
artifacts
on
any
single
image.
So
that's
going
to
be
a
pretty
extreme
case
unless
somebody's
doing
something
crazy.
C
A
D
C
E
I
think
the
you
know
the
value
of
having
the
walkthrough,
I'm
not
sure,
on
the
distribution
and
image
spec
maintainers,
it
might
be
worth
just
putting
a
call
out.
I
don't
know
if
we
want
to
do
another
recording,
but
actually
the
context
that
brandon,
if
I
was
reviewing
this
having
no
prior
context
that
30
minutes
that
brandon
just
walked
through
that
would
probably
yield
a
much
faster
pr
review.
E
That's
just
the
way
my
brain
thinks,
but
if
I'm
just
looking
at
this
out
of
like
I
have
no
context
and
now
I'm
just
looking
at
a
wall
of
stuff,
it
might
take
a
little
longer.
So
I
don't
know
if
you
know
the
folks
that
are
maintainers
that
are
here
now
could
put
that
call
out
and
say:
hey.
We
can
do
an
ad
hoc.
B
E
E
Talk
now
was
that
actually
useful,
I'm
sure
if
you
just
reviewed
that
with
no
context,
it
would
have
taken
you
hours
to
get
your
head
around
it
and
that's
not
not
on
you.
It
would
take
me
hours,
but
just
that
30
minutes
of
the
structured
walkthrough.
I
can
contextualize
what
the
heck
I'm
looking
at.
E
Yeah
and
one
of
the
goals
of
the
working
group
is
to
bring
you
like
a
high
fidelity.
You
know
response
back,
that's
united
across
the
folks
they're,
a
part
of
the
working
group
is
this
recorded.
I
see
tienen,
we
we
could
just
wrap
it
up.
Did
we
end
up
getting
the
recording
going
vincent?
I
can't
remember.
A
A
E
E
But
I
I
know
when
it
happened
to
me.
I
was
like
what
you
know.
I
didn't
set
up
a
token
like
if
I
lost
my,
but
if
you
can
get
the
recording,
I
can
just
update
the
mailing
list
and
just
mention
to
maintainers.
We
could
just
say
hey
we're
trying
to
get
a
approval
within
two
weeks.
Here
is
the
recording
of
the
meeting
that
actually
walks
through
the
output
of
the
working
group.
C
Yep
and
if
it
for
some
reason
one
record,
I
was
always
happy
to
talk
about
again
anybody
that
wanted
to
hear
about
it.
The
the
other
part
to
me
is
that
there
is
a
value
for
somebody.
That's
looking
at
this
wall
of
text
and
saying
I
just
don't
get
it.
Why
is
this
point
over
there
they're
not
gonna,
be
the
only
person
have
that
question,
and
so
that
might
be
a
sign
that
there's
going
to
be
more
detail
needed
to
add
to
certain
places.