►
From YouTube: OCI Weekly Discussion - 2023-04-13
A
C
A
B
Yeah,
it
seems
like
it
seems,
like
the
removal
of
talking
about
artifact
manifest
from
that
is,
basically
all
we
need
to
cut
a
release,
and
so
I'm
wondering,
should
we
do
that.
A
So
linked
into
there,
the
Milestone
we've
gotta.
Let's
see
nine
open
issues
on
the
Milestone
right
now.
A
A
B
Okay,
let
me
open
a
different
can
of
worms,
because
I
see
ROM
here
too
so
in
the
Milestone
is
conformance
testing
for
references
which
he
actually
put
together
a
while
ago.
B
So
I
have
a
PR
up,
it's
a
number
four
zero
one
and
when
we're
adding
conformance
tests,
we
don't
really
know
if
the
tests
are
going
to
break
Registries
and
I
guess
we
can't
really
ever
know
unless
we're
all
we're
testing
all
the
registries,
but
zot
has
basically,
since
it's
been
around,
been
trying
to
track
the
changes
on
Main
as
far
as
I,
understand
and
also
Aura
stuff
and
so
I'm
I'm
thinking
that
what
we
should
do
is
when
we
open
a
PR
to
change,
conformance,
spin
up,
zot
latest
release
and
see,
if
conformance
passes
against
it.
B
As
we
were
doing
this,
we
found
that
our
conformance
tests
and
the
spec
in
general
break
one
of
the
ietf.
B
See
the
form
yeah,
the
formats
of
these
headers
and
I
was
talking
to
John
Johnson
about
this
a
little
bit.
Basically,
the
range
and
content
range
headers
have
always
been
broken,
but
it's
how
everything's
doing
it,
and
so
we
have
to
decide
whether
we
want
to
stick
with
the
broken
way
for
legacy
reasons
or
allow
both
and
conformance.
B
Even
though
that
means
that
if
the
registry
is
doing
it,
it
might
break
a
client.
It's.
A
Not
a
preference
thinking
about
that
one,
because
I
saw
a
little
bit
of
discussion.
My
preference
would
be
registry
should
be
strict
in
what
they
output,
and
so
we
should,
in
our
conformance
tests,
be
very
specific
of
saying
without
the
byte
equals.
Even
though
it's
not
going
to
follow
everything
else,
and
if
a
client
wants
to
be
more
permissive
and
allow
that
on
the
client
side
and
that's
great
for
the
client.
But
we
should
expect
the
registry
should
be
strict
in
what
they
output.
B
A
Well,
I
would
say
at
least
for
the
1.1.
If
we
want
to
start
changing
this
stuff,
I
think
that's
a
bigger
version.
Bumped.
D
I,
don't
want
to
be
in
the
world
where
to
be
conformant,
you
have
to
be
non-conformant
with
a
different
spec.
I
I
understand
why
you
have
this
opinion,
though,
like
it's
bad
if
we
break
clients
right
but
like
it
practically
a
registry
could
know
like.
Oh,
this
client
sent
me
broken
header
on
the
request.
I
can
send
them
back
a
broken
header
on
the
response,
but
yeah
like
My
worry
is
that
there's
software
that
expects
redness
servers
to
do
things
that
are
conformant
to
http
rfcs
and
because
of
how
HTTP
composes
with
proxies.
D
If
we
are
not
good
netizens
of
the
protocol,
then
it
can
be
bad
for
other
reasons,
but
like
I
also
don't
want
to
break
a
bunch
of
clients.
So
I'm,
not
really
I,
don't
have
a
great
suggestion.
D
I
I
think
they're.
You
know
it's
a
two-phase
thing
where,
like
we
need
Registries
to
support
both
before
clients
can
start
using
the
correct
thing
which
may
never
happen,
I,
just
don't
want
to
like
force
Registries
to
do
something
wrong.
I,
don't
know
this.
This
hurts
me
deeply.
A
At
least
right
now,
I'm
comfortable,
saying
that
both
Registries
and
clients
should
accept
both,
but
they
should
produce
what
we
put
in
the
spec.
D
A
A
D
I
mean
Registries
are
ready
so
like
on
on
the
download
path
for
range
requests,
I
assume
they're,
doing
the
RFC
compliant
thing,
because
most
Registries
just
redirect
to
a
blob
store
which
doesn't
know
about
oci,
but,
unlike
this
particular
chunked
upload
path,
we
have
this.
You
idiosyncratic
behavior,
I
I,
think
it's
not
breaking
for
Registries
to
accept
both
on
the
request.
It
is
potentially
breaking
for
Registries
to
respond
with
the
correct
thing
right.
D
So
if,
if
the
performance
text
requires
Registries
to
support
both
on
the
request
for
now,
then
we
can
like
get
Registries
happy.
Maybe.
C
D
D
B
A
All
right:
well,
we've
got
Dean
on
John
and
Sanjay
all
here,
so
we
can
talk.
Image,
spec
stuff
got
three
different
or
two
different
PR
sitting
out
there.
One
of
the
Marvel's
herpes
could
be
easy
and
quick,
which
was
10,
42.
A
A
I'll
chat
back
up
and
everything
so
I
can
follow
along
with
the
peanut
gallery.
In
the
background,
1042
I
think
the
biggest
challenge
we
had
last
time
was.
We
wanted
to
change
this
line
and
so
I've
got
that
changed
so
I'm,
hoping
with
that
that
this
is
good
enough
to
merge.
A
It
was
easier
for
me
to
talk
through
it
of
what
changed
in
here.
The
big
thing
we
got
rid
of
the
scratch
descriptor
before
already
so
this
just
changed.
The
text
saying
here
are
the
two
variables
we
Define
later
on
same
change
down
here.
These
are
two
variables
you
can
find
later
on
and
if
you
look
at
manifest
go
we
had
the
variables
found
already.
A
I
did
rename
one
of
them
took
out
the
digest
out
of
the
data,
because
this
isn't
a
digest.
It's
the
data
itself,
so
called
it
scratch
data
scratch
digest,
shot.
250,
256
I
can
never
say
that
fast
enough
and
put
some
docs
on
those.
So
put
a
comment
field
in
each
of
those.
So
that's
half
the
change.
D
At
the
risk
of
wasting
everyone's
time,
what
is
why
did
we
change
I
kind
of
liked
it
before?
What
is
this
about.
A
The
challenge
of
the
descriptor
was,
it
might
be
useful
for
for
producing,
but
if
you're
consuming
there's
it
was
mixing
the
output
and
the
input
was
my
biggest
challenge
where
the
input
was
going
to
be
hey.
I've
got
this
digest.
The
output
was
going
to
be
okay,
here's
the
data
that
you
would
get
back
if
you
query
that
Digest
and
then
that
descriptor
field
was
never
really
comparable
with
anything
else.
Now
we
changed
some
rewarding
since
then
and
started
doing
the
scratch
descriptor
with
the
media
type
field.
That's
got
the
scratch
menu
type.
A
A
A
Yeah
my
opinion
was
a
lot
firmer
when
this
was
the
config
manifest.
Well,
it
is
Big
manifest
when
the
configure
type
was
different
for
every
one
of
these.
Now
that
we're
going
to
say
the
config
meat
type
is
just
a
single
value,
I'm,
not
as
picky
on
that.
If
we
want
to
go
back,
we
already
made
the
change
once
though
so
I
don't
know.
If
we
want
to
keep
flip-flopping
back
and
forth.
D
Well,
I
I
personally,
would
prefer
this
as
a
scrap
scratch.
Descriptor
I.
Think
the
only
like
point
of
contention,
I
remember,
is
that
media
like
mutating
the
media
type
could
be
bad
or
whatever,
but
since
that's
now,
static,
I
think
it's
totally
fine
to
have
one
scratch
descriptor,
but
that's
my
opinion.
I
am
interested
if
someone
else
cares.
E
A
D
A
D
D
Don't
I
don't
think
it's
a
huge
deal.
You
could
also
like,
if
you
really
wanted
to
it,
might
be
nice
to
modify
scratch
descriptor
globally
for
your
terrible
program,
but,
like
I,
don't
know
you
know,
go
doesn't
have
like
cons
correctness
as
part
of
its
core
being
so
I'm,
not
sure
that
we
need
to
really
care
about
that
that
much,
but
maybe
someone
who
disagrees
with
that.
A
D
C
A
D
You
know
for
most
implementations,
I
feel
like
no
one.
They
don't
care
about
this
at
all.
They're,
mostly
going
to
be
like
querying
the
registry
for
an
artifact
type,
and
what
they
get
back
is
what
they
want
like
Registries
have
to
carry
this
complexity,
but
it's
not
that
bad
right.
It's
like
a
fallback
of
one
field
right
and.
H
A
That's
a
third
PR
around
the
distribution
spec
side,
but
yes,
we
initially
take
whatever
the
artifact
type
is.
If
this
is
blank,
we
fall
back
to
the
config
need
type.
D
D
H
A
D
A
Yeah
Aaron
was
asking:
should
we
give
it
that
direction
you're
asking
for
there
Mike?
Curiously,
the
other
Mike
Brown,
already
mentioned
that
and
my
comment
was
I'm
open
to
it,
but
maybe
a
separate
PR
to
say
this
is
the
direction
we're
steering
people
toward
okay,
and
this
PR
was
just
saying
both
are
valid.
Everything's
valid
in
this
case.
C
A
So
from
the
producer
side,
they
can
do
either
if,
if
they
have
a
scratch
here
as
the
media
type,
they
must
provide
an
artifact
hype,
but
otherwise
the
artifact
type
is
optional.
If
artifact
type
is
there
and
you're
building
the
refers
API
response,
then
you
use
artifact
type.
If
it's
not
there,
you
fall
back
to
the
config,
need
type.
A
Am
I
open
to
merging
was
that
the
question
yeah
I
get
all
the
approvals
in
this
time
sweet
and
how
about?
Because
we
did
say
it
was
kind
of
Quasi
related
to
this
one.
Just.
E
Specifically,
that's
fine.
We
can.
We
can
debate
on
another
PR
for
that.
That's
what
I
was
thinking.
Let's
get
in
this
March,
because
to
micron's
point
is:
if
we
have
this
Reno
artifact
type,
is
we
make
the
distribution
spec
PR,
depending
on
this?
That's
why.
G
C
I
H
F
A
C
A
E
The
the
reason
I
was
recommending
the
margin
is
right
now,
the
subject:
that's
one
field
and
then
there's
the
artifact
I'd
feel.
So
if
you
get
that
consistent,
at
least
the
consumer
of
distribution
can
get
unblocked,
even
even
if
the
other
PRS
don't
get
merged.
A
F
A
A
A
Come
on
okay,
so
now,
on
the
other
side,
let's
see
I
think
I
have
that
sitting
right
here,
somewhere
use
the
artifact
type.
So
this
is
the
flip
side
of
that
equation,
so
395
over
a
distribution,
spec
answers
the
question
of
when
that
is,
there
still
had
the
commission,
so
this
is
easier
to
read
when
artifact
type
is
set,
then
you
use
that
for
your
value
and
so
the
artifact
type
from
the
image
manifest
is
your
effect
type
if
it
is
not
set.
A
If
there's
different
phrasing,
I
should
use
for
this
happy
to
change
it,
but
the
idea
was
that
there
would
be
some
kind
of
take
it
from
the
first
one
in
the
first
place
and
then
fall
back.
G
Yeah,
it
sounds
like
you're
already
addressing
the
inconsistency
issue
over
in
the
image,
but
that
was
the
thing
I
was
concerned
about.
A
A
So
I
think
those
are
the
ones
that
I've
got
to
worry
about
stuff
that
other
people
want
to
talk
about
today.
A
E
F
F
A
A
A
A
D
E
H
F
A
F
G
G
E
A
few
a
future
LTT,
okay.
D
It's
ambiguous:
it's
more
ambiguous
if
as
to
what
the
if
present
applies,
if
it's
at
the
beginning
of
the
sentence,
because
it's
followed
by
two
things.
Whereas
if
it's
at
the
end
of
the
sentence.
C
G
D
A
C
A
E
A
F
We
are
yeah,
it's
proposed
by
a
maintainer
and
approved
by
two
other
maintainers.
Oh
so
before
I
hit
approve
on
it
and
bury
you
further
Brandon
I
wanted
to
give
you
some
space
to
talk
about
it.
A
E
F
E
D
It
doesn't
have
to
be
a
multi-platform
right,
it
can
just
be
a
list
of
manifests,
and
so,
if
you
have
an
aggregate
thing
like
that,
where
you
want
multiple
manifests
that
this
doesn't
need
to
exist,
but
it
has
to
because
we've
like
split,
manifests
and
blobs
into
separate
handlers,
and
so
it
sucks,
but
like
it's
also
a
nice
way
to
like
aggregate
say
multiple
attachments
into
one
thing.
They
want
to
say,
like
hey
copy.
This
bundle
you
know
refers
API
kind
of.
Does
that
for
you,
but
I
like
this.
F
F
A
C
E
H
F
A
F
C
H
D
So
one
place
I
think
this
would
be
nice
is
if
I'm
dealing
with
an
index
and
I
want
to
grab
some.
You
know
the
s-bomb
of
an
index
that
might
be
an
index
itself
right
and
like
that
might
I
might
have
platform
specific
s-bombs,
and
so
it
would
be
nice
to
just
ask
the
registry:
hey.
Does
anything
reference
this
index
and.
H
A
An
s-bomb
for
each
of
the
individual
images
and
then
you
would
have
index
of
all
the
s-bombs
yeah.
D
H
H
D
E
I
E
I
really,
like
your
suggestion
of
multi-platform,
refers
because
for
signatures,
we
have
the
same
problem
where
we
cannot
attach
it
on
the
index,
because
you
don't
know
what
you're
traversing
to
so,
we
always
say
attach
it
to
the
the
last
belief
right,
the
leaf
manifest.
But
if
you
have
this,
we
can
create
a
unified
hey.
These
are
all
my
signatures
for
each
individual
platform
and
whoever
resolving
it
to
that
platform
can
go,
walk
down
that
also.
D
E
D
Also
like,
if
you
can
do
this,
then
you
can
save
a
bunch
of
your
quota
with
Docker
Hub
right,
because
I
can
just
like
head
the
index
and
then
refers
that
digest
rather
than
having
to
block
it.
D
A
E
D
A
A
H
D
Yeah
I
think
my
my
I
mean
the
second
thing
I'm
upset
about
that
happened.
They
just
solved
my
first
one,
but
the
second
thing
is
that
it
refers,
is
scoped
too
narrowly
like
I
wish.
There
wasn't
I
wish
I
could
query
for
this
index.
Without
the
subject
field
like
we,
we
don't.
We
wouldn't
have
to
sign
everything
individually.
If
we
signed
at
the
index
and
I
could
ask
the
registry
hey
what
points
to
this
manifest
I
could
walk
back
up
to
the
index
and
get
those
signatures,
but
that's
not
possible
right
now.
D
A
And
untagged
manifest
that
refers
to
something
that
still
exists
should
remain.
We
don't
have
that
Define,
the
spec,
but
that's
kind
of
like
the
general
Assumption
of
a
way
registry
should
implement
the
GC.
C
D
Know
we're
not
being
ambitious
enough
if
we're
just
saying
oh
GC
won't
work
because
it
can
work.
It's
just
going
to
be
slightly
more
complicated.
G
Right
until
next
time,
irrespective
of
the
garbage
collection
issue,
I
do
have
a
question
on
what
does
it
mean
to
have
an
index
that
has
an
artifact
type
that
in
a
subject
reference
when
the
indexes
themselves
are
really
supposed
to
be
to
a
list
of
platforms,
right
images
and
wouldn't
those
artifact
subject,
references
be
different
per
platform.