►
From YouTube: OCI Weekly Discussion - 2023-02-16
C
D
A
Okay,
I
think
other
folks
yeah.
Thank
you,
Sergey
for
adding
stuff
to
the
agenda.
A
Sorry
I
got
kind
of
feisty
over
the
weekend
and
opened
a
bunch
of
PRS,
so
go
ahead
and
apologize
ahead
of
time,
but
the
I
guess
seeing
the
conversations
go
round
and
round
of
like
when,
when
and
how
best
and
by
what
threshold
to
introduce
new
manifests,
doesn't
mean
that
the
spec
is
Frozen
I.
Think
General
consensus
is
the
spec
is
not
and
has
has
not
been
frozen,
but
to
achieve
certain
functionality.
A
What's
the
bare
minimum
requirements
so
that
if
we
did
introduce
a
new
spec,
because
it's
a
new
manifest
it's
substantially
different
so
then
like.
If
we
follow
that
train
of
thought,
then
I
was
thinking
like
what
are
some
of
the
topics
that
particularly
have
bubbled
up
to
the
top
of
like
effectively
doing
the
card.
A
A
A
You
know
somebody
in
the
community,
somebody
on
issues
have
been
opening
issues
on
GitHub
to
clarify
and
like
even
just
make
a
table,
so
it
can
kind
of
clarify
what
Registries
do
and
don't
support
like
an
empty
array
of
layers
versus
no
layers
at
all
and
all
that
kind
of
stuff.
So
first
on
that
has
have
people
looked
at
1016
and
feel
strongly
against
it.
A
G
A
E
I'll
say
I
don't
feel
strongly
for
it,
but
I'm
not
going
to
raise
too
much
of
a
stink
against
it.
It's
one
of
the
scenarios
where
I
just
worry
that
we're
taking
something
away
that
is
for
for
all
intense
purposes,
expected
in
early
versions
of
the
spec.
It's
all
the
documentation
like
the
Json
schema
whatnot
says
this
field
will
exist.
The
ghost
schema
said
this:
this
isn't
an
optional
thing.
This
is
going
to
be
created
so
taking
away
I.
B
A
A
Only
koi
I
think
is
currently
broken
by
it,
GCR
and
Docker,
Hub
and
Azure,
and
it
was
like
we
started
going
down
the
list
and
that's
what
I
was
saying
that
racking
person
opened
an
issue
and
they
even
have
started
venturing
into
like
artifactory
and
some
other
ones
and
everybody's
like
it's
actually
pretty
unanimously
supports
an
empty
array
and
just
not
even
having
the
field.
B
Yeah,
do
we
want
to
be
explicit
about
the
difference
or
lack
of
difference
between
the
field
is
not
present
and
the
field
is
present,
but
it's
an
empty
list.
I,
don't
I
think
we
should
accept
both
I
think.
We
should
be
explicit
that
we
accept
sorry
that
that
not
that
we
accept
anything
that
it
should
be
expected
that
those
are
allowed
to
buy
Registries
by
clients,
yeah.
A
A
The
the
layer
at
the
zeroth
index
must
be
the
base
layer,
but
it
can
be
empty
and
the
only
other
wording
or
the
only
other
thing
that
that
said
anything
about
the
link
to
the
list
was
and
the
Json
schema
which
clearly
nobody
uses,
because
it
was
you
know
whatever.
But
we've
updated.
The
Json
schema
well
as
well,
so
yeah.
B
I'd
say
my
my
only
possible
concern
would
be
that
Registries
effectively
have
supported
this
forever,
but
if
you're
saying
that
even
the
top
three
five
six
Registries
you've
tested
supported,
then
I'm
fine
with
it
I
think
I.
Think
it's
a
good
step
toward
that's
one
of
the
things
we
wanted
to
do
when
documenting
artifacts
or
images
as
artifacts.
Is
that
one
way
to
describe
an
artifact?
B
The
case
that
always
comes
up
is
like
what,
if
I
just
want
to
annotate
a
thing
just
for
annotations,
no
config,
no
layers,
no
anything,
and
that
was
one
of
the
sticking
points-
was
that
you
have
to
push
a
layer
and
it
can
be
empty.
Well
if
it
doesn't
have
to
be
there,
then
great
I'm,
I'm
super
for
this.
A
So
that
that
that
is
exactly
one
of
those
sticking
points
and
the
other
is
the
next
topic
on
this
list
is
like
you
have
to
have
us,
you
have
to
have
a
config,
you
know,
what's
the
bare
minimum
config
that
makes
it
portable
and
is
Sanjay
is
pointed
out,
you
can't
you
have
to
have
a
config
but
you're,
it's
not
very
portable
to
have
a
zero
length
object.
That's
pushed
with
that.
A
E
On
issue
10
25,
where
all
this
discovery
happened,
GCR
is
one
of
those
that
did
not
work
with
empty
layers.
E
Of
those,
but
we
actually
did
work
as
long
as
you
actually
did
not
specify
layers.
But
if
you
had
a
empty
layers
under
layers,
they
worked
with
empty
layers,
which
is
the
scenario
where
the
layers
array
was
empty,
but
they
didn't
work.
If
you
didn't
have
a
layer
skilled
at
all
and.
G
H
D
H
A
This
is
almost
like
that
the
thing
about
even
something
like
this-
that
it
there's
a
lot
of
crane
here
green
here-
and
it's
almost
like
if
these
were
if
this
was
a
change
of
like
objects
that
were
floating
around
the
world,
that
we'd
have
to
update
all
the
objects
like
every
image
in
the
world
is
Now
Inc
compatible,
that's
not
the
way
it
is.
This
is
almost
like.
This
could
be
fixed
in
like
two
spots.
A
You
know
ACR
GCR
and
perhaps
some
people's
bindings
or
whatnot
almost
anyhow
I
feel
like
this
kind
of
change
is
not
as
as
catastrophic
as.
E
E
E
A
Okay,
anyhow,
so
that's
that's
pretty
much
that
I
think
specifying
you
know
clearing
up
foreign.
What
was
the
exact
clearing
up
that
you
wanted
to
see
Jason
on
on
the
the
layers.
E
E
E
E
These
kind
of
examples
down
there,
so
you
go
down
to
the
last
example,
and
it's
just
the
two
braces
is
that
that's
the
two
bytes.
A
B
A
B
You
say
it's
a
layer
gzip,
you
know
layer,
targy,
zip
and
you
send
an
empty
Json
document
like
things
might
practically
handle
it.
But
the
open,
brace,
closed
brace
is
not
a
valid
right.
E
Correct
I've
had
the
same
concern
other
places
where
we
change
the
artifact
type
to
be
what
we're
pushing
and
it
makes
sense
if
I'm
pushing
a
Json
thing
to
say.
Here's
an
empty
config
for
an
spdx
Json
format,
but
if
I
push
an
spdx,
XML
format
and
I
specify
my
artifact
type.
Is
that
empty
couple
brackets?
That's
not
valid
XML.
B
I
think
we
would
say
the
the
scratch
document
for
the
config
media
type.
The
config
Json
media
type
is
open,
Grace
closed,
brace.
If
you
define
your
own
config
media
type
of
s-bomb
s,
you
know
spdx
XML,
you
define
what
you
accept
and
what
you
don't
accept
and
what
scratch
means,
but
like
we
want
to
have
a
a
special
config.
When
you
specify
Media,
Tech,
config
media
type
of
oci
config,
it
must
be
at
least
this
scratch
document.
I.
B
I
think
I
think
the
I
think
there
is
a
lot
of
common
practice
out
in
the
world
and
part
of
our
job
is
to
constrain
responsibly
that
common
practice.
The
genie
is
out
of
the
bottle.
So
at
some
point
we
can't
we
can't
really
stop
them
from
doing
whatever
they
want.
We
can
say
these
are.
B
This
is
the
place
in
the
spec
chapter
and
verse
where
what
you're
doing
is
not
spec
expected
like
if
you
are
ignoring
the
config
media
type
and
parsing
it
as
Json,
even
though
the
config
media
type
told
you
it
was
XML.
That's
on
you
buddy,
not
that
that's
you
know,
that's
cold
comfort
to
them
when
they're
breaking
and
like
whatever,
but
we
can
at
least
say
the
spec
says
you
shouldn't.
Do
that
I.
B
E
B
E
B
Yeah,
but
people
are
going
to
ignore
the
layer.
Media
type
not
see
that
it
says
it's
going
to
be
empty,
try
to
parse
it
as
a
tar,
gz
explode
and
be
mad
I
think.
If
we
were
worried
about
that,
we
can
make
the
scratch
layer
when
the
layer
media
type
is
layer
scratch
what
this
I
agree.
That
word
is
weird,
but
empty
is
equally
bad.
B
When
the
media,
when
the
layer
media
type,
is
layer
targyz,
it
is
an
empty
tarjisi
which
is
like
38
bytes
of
the
headers
and
the
whatever,
and
we
can
Define
if
the
media
type
is
empty.
Then
it's
zero
bytes.
E
E
E
B
B
I
I
do
agree
that,
like
an
oci
1.1,
you
know
under
the
new
rules
empty
is
a
special
media
type
that
we're
allowed
to
push
around,
but
under
the
old
rules
it
will
be
ignored
and
written
and
blow
up
so
yeah
I
think
I.
Think
you're,
probably
right.
We're
still
going
to
have
this
problem,
though,
where
if
the
scratch
layer
is
open,
brace
closed,
brace
anything
that
expects
to
be
able
to
parse
it
as
a
tar
will
not
be
happy.
A
I
If
we
standardize
an
empty
media
type
of
special
behavior,
it
needs
to
be
generic.
I
The
issue
is
with
an
artifact
I
I
care
about
in
the
refers
API
or
care
about
with
artifacts
the
artifact
type
being
projected
into
the
refers
API
or
into
descriptors
on
indexes
and
a
config
type
of
a
media
type
of
empty
is
no
information.
The
artifact
is
empty,
but
that's
not
actually
true,
because
the
artifact
could
have
blobs
on
it
so
like,
if
I,
attach,
if
I
put
an
image
manifest
out
there
with
an
s-bomb
layer
attached
to
it,
but
I
don't
want
to
push
a
config
type.
E
Yeah
my
my
way
of
phrasing
is
that
takes
a
second
to
spit
out
is
if
I'm
going
to
push
my
electron
Bill
materials
I,
keep
picking
on
that
one
or
whatever
I'm
going
to
do.
I'll
have
my
electron
build
materials,
media
type,
and
it's
just
known
within
my
application
that
I
don't
care
about
the
content
and
So
within
my
application.
Whenever
I
see
the
electron
build
materials,
media
type,
there
might
be
a
couple
empty
brackets
in
there,
and
that
might
be
it.
I
Yeah
I
would
say
we
should
either
designate
a
a
special
case.
Shaw
I
think
there's
been
a
couple
suggestions
there
or
a
special
case
behavior
that
you
are
allowed
to
Simply
reference,
anything
in
a
descriptor
in
the
config
type.
If
the
length
is
zero,
that
the
media
type,
that
is
just
clients,
are
just
not
expected
to
pull
it
because
it
has
length
zero.
All
of
the
information
is
already
in
the
descriptor.
E
It
has
to
be
a
shot
that
you
can
push
for
backward
compatibility,
because
the
registry
is
going
to
validate
that
you've
already
pushed
all
the
blobs
within
the
Manifest
ahead
of
time,
and
so
it
has
to
at
least
on
assisting
Registries,
be
something
we've
already
pushed,
and
so
you
end
up
with
like
the
double
brackets.
The
only
challenge
I
have
a
summer
case
is
saying:
hey
you
can
skip
the
checks
and
whatnot
is
there
is
a
different
workflow
for
push
than
pull
push?
E
You
still
have
to
push
the
blob
and
get
up
there
or
you
can
skip
that.
But
for
me,
when
I
push
I
do
a
initial
head
request
and
so
I
now
need
two
head
requests:
one
when
I'm
doing
a
push
and
I
want
to
verify
it's
really
there
and
another
one
I'm,
just
saying:
I,
don't
care
if
it's
really
there
just
tell
me
what
this
had
request
would
have
done.
If
it
was,
there
gets
a
little
complicated.
A
A
At
least
for
10
23
is
it
does?
Does
people
have
any
knee-jerk
reaction
to
edit
that,
or
can
we
possibly
just
leave
that
as
it
is
and
then
figure
out
the
scratch
layers?
Discussion
as
it
relates
to
it.
I
The
only
thing
I
would
suggest
is
that
we
change
the
or
add
an
exhibitional
example
with
a
different
media
type
to
indicate
that
you
do
not
have
to
specify
a
CI
image.
Config
plus
Json.
A
Like
like
what
hold
on
so
you're
like
say
that
we
don't
have
is,
as
far
as
the
example
in
the
scratch,
config
doesn't
need
to
be
the
oci
image
config,
yes,
because
it
might
not
even
be
a
technically
good.
That's
not
a
valid
configuration.
It's
not
a
valid
FCI
image.
Config.
A
Just
application,
slash
Json,
is
a
is
like
the
mime
type
would
be
just
application,
slash,
Json
or
whatever
plane
like
basically
and
him,
then,
in
that
one
little
section
of
restrictions
on
the.
A
A
A
Does
would
would
that
suggestion
also
to
say
like
okay,
this
thing's,
not
technically,
you
know
currently
open
close
curly
brackets,
not
technically
valid
image
fig.
So
should
it
I'm
not
showing
the
right
window
yeah?
A
Should
it
then,
should
this
wording
in
the
spec
say
that
it
should
at
least
support
this
and
application
Json
or
some
other
media
type?
That's
just
like
empty
Json
document.
It's.
I
The
the
confusing
thing
here
is
the
blob
that
this
descriptor
points
to
will
not
in
fact
be
for
most
artifacts,
the
media
type
described
in
the
descriptor,
which
is
actually
incompatible
with
oci
image
layout.
If
I,
if
I
have
read
the
spec
correctly
is
oci
image
layout
requires
that
there
be
alignment
between
descriptors
and
with
the
contents
of
the
blah
bar.
So
if
I
say
application,
s-bomb
and
the
blob
is
not
an
asked,
the
application
s-bomb,
then
it's
it's
in
violation
of
the
spec.
I
E
I
Because
that's
what's
projected
into
the
refers
API
as
the
artifact
type
and
you
know
potentially
other
apis
in
the
future.
E
Okay,
if
we're,
if
we're
going
to
document
a
change,
we
can
document.
This
is
an
exception
to
that
rule.
For
this
one
scenario
not
thrilled
about
it,
but
I
love,
it.
I
The
the
risk
to
implementations
there
and
I
don't
know
not
having
looked
too
deeply
into
registry
implementations
is
that
you
could
end
up
with
a
single
blob
for
which
responses
to
get
that
Blob
should
return
different
media
types
depending
on
the
context
of
how
you
looked
at
it
right.
Is
that
how
do
you
store
this
blob
in
S3
or
with
a
database
backing?
It
is
if
I
either
request
this
blob,
and
one
manifest
says
that
this
is
a
s-bomb
and
one
that
manifest
says
that
this
is
a
in
total
annotation.
I
E
B
Yeah,
that's
that's
pretty
easy
because
we
allow
so
many
things
allow
unknown
Fields.
This
was
the
nature
of
the
last,
only
cve
that
oci
has
ever
had
where
you
could
make
a
manifest
that
looked
like
an
image.
If
you
looked
at
it
like
an
image
and
an
index,
if
you
looked
at
it
like
an
index,
and
so
they
had
all
the
same
Digest.
B
A
E
D
A
A
B
Of
that
I
think
I
think
I've
turned
into
not
wanting
to
change
the
config
media
type,
because
it's
hoisted
up
into
artifact
type
I
think
we
can
for
config.
We
can
say
there
is
a
special
config.
It
is
open,
brace,
close
brace.
It
is
only
applied
when
the
media
type
is
config
the
if
you're,
storing,
Helm,
charts
or
s-bombs
or
any
other
thing.
Those
are
in
the
layers
of
your
image
and
you
can
Define
whatever,
and
you
define
your
media
type
of
those
layers.
You
define
what's
what
an
empty
one.
B
Is
you
define
what
a
real
one
is?
That's
wholly
up
to
you,
but
configures,
open,
brace,
close
brace
the
issue
of
what
a
empty
layer
is
is
we
could
also
do
that
for
image
layer,
tar,
gz,
whatever
that
media
type
is
I,
think
we
just
need
to
say
that
it
is
a
valid
Target,
easy
or
something?
Maybe
we
don't
I
don't
know.
Maybe
nobody
cares
about
that,
but
we
can
only
say
that's.
That
applies
for
these
media
types,
for
your
media
type.
An
empty
Helm
chart
may
have
to
have
these
fields.
E
E
E
I
just
know
that
when
I
read
that
manifest,
when
I
read
that
media
type
for
the
config
I,
don't
even
care.
What's
in
the
blob,
because
I
know
there
are
no
layers
there,
so
I
don't
even
process
that
part
of
it.
If
I'm
copying
from
one
registry
to
another
it
just
copies,
because
the
blob
is
there,
The
Blob
is
the
same,
digest
all
right
got
copied
or
not
copy.
The
config.
B
A
That
was
part
of
the
logic
of,
or
you
know,
part
of
the
thought
behind
any
of
this
is
that
any
tools
that
are
fetching
or
receiving
or
whatever,
and
even
like
some
of
the
logic
of
like
not
letting
somebody
not
push
a
layer
to
challenge
that
they
do
or
don't
have,
that
object
is
like
here's,
a
canonical
hash.
If
you
see
that
hash
I
don't
need
to
make
the
round
trip,
you
don't
you
know
just
agreed
to
not
push
this
player.
I
A
I
It's
I
think
it's
acceptable
to
have
the
a
canonical
hash
here.
I
think
it's
it's
slightly
frustrating
as
a
client
implementation
to
have
to
always
on
every
push
push
two
things,
because
I'm
going
to
have
to
check
I
I
either
have
to
get
the
blob
to
see.
If
the
registry
already
has
it
or
I
have
to
push
it.
G
A
Almost
well
I
mean
because
that's
why
we
use
the
the
phrase
scratch
when
talking
about
this
is
because
at
some
point
there
was
an
official
image
ID
that
was
the
scratch
layer
and
or
scratch
base
layer
image
in
Docker
world,
and
then
it
just
it
got
to
be
so
silly
that
it
just
we
just
made
it
the
magic
of
like
whenever
you
see
this
image
or
this
phrase
just
assume
these
certain
steps,
so
I
don't
have
to
push
it.
I
don't
have
to
fetch
it.
A
We
can
just
eliminate
the
whole
step
so
effectively
to
do
the
same
thing
like
you.
Don't
have
to
do
a
head
request,
it's
built
into
the
library
of
like
if
you
import
from
the
specs.gov
or
whatever
oci
library,
that
this
this
hash
is
there.
You
do
the
check,
don't
even
worry,
about
pushing
or
fetching
it
or
head
or
whatever
request.
A
E
So
10
23
I
think
we
need
to
loosen
whatever
the
media
type.
There
is
in
fact
it
probably
will
not
be
image
config
in
any
scenarios
there,
because
if
it
is,
you
should
have
content
and
then
for
10
16
I
think
we
can
close
it
and
say
we're
just
going
to
go
with
the
back
finding.
It
said
scratch
was
probably
the
most
portable
and
so
it's
closed
1016
document.
What
the
method
is
for
that
scratch
method.
D
A
F
Yeah
I
mean
it
would
be
nice
to
make
this
optional,
but
I
am
sympathetic
to
the
random
Registries
that
assume
it's
not
optional,
including
jcr
about.
D
E
I
think
my
take
is
the
whole
reason
we
pulled
scratch
or
pulled
the
artifact
manifest
out,
at
least
temporarily
is
that
we
can
do
this
portably
existing
a
day
without
making
changes
without
having
to
force
Registries
to
anything
on
their
side
without
breaking
clients,
and
so
to
me
it
feels
like,
let's
pick
the
most
portable
most
compatible
for
how
we
deal
with
the
image.
I
still
want
to
keep
artifact
manifest
on
the
table
for
future
I.
Don't
think
we
know
how
we
want
to
roll
that
out.
E
Just
yet,
and
so
there's
gonna
be
some
work
to
do
later
on,
but
the
long
term
I
think
still
makes
sense
to
have
an
artifact
manifest
at
some
point,
and
we
just
need
to
work
out
how
we
can
roll
that
out
and
then
we
can
get
that
into
a
future
version
of
the
spec.
So
yeah
we're
pushing
a
couple
extra
blobs.
It's
not
pretty
it's
ugly.
It's
a
lot
of
this
portability
stuff
that
you
just
have
to
do
with
the
vision
that
in
the
future,
will
have
a
better
answer.
D
A
I
Yeah
in
responding
to
some
of
the
questions
on
on
999
I've
gone
ahead
and
made
a
PR
to
change
language
from
ignored,
to
accept
in
a
number
of
places
and
my
interpretation,
it
seemed
like
there
was
some
confusion
around
what
ignore
meant
and
as
I
read
through
the
spec,
it
seemed
like
there
were
already
places
where
an
oci
1.0
registry
must
accept
artifact
manifest
because
they
were
set
to
be
ignored,
but
I
think.
Maybe
there
was
some
confusion
around
what
does
ignored
need.
I
E
The
methodology
for
the
madness
was
that
I
think
a
lot
of
places
where
it
says
ignored
was
referring
to
clients
and
run
times,
and
so
on
that
side
it
does
make
sense
to
ignored
if
you're
a
runtime
you
don't
you
see
something
you
don't
know
what
to
do
with.
Then
you
probably
shouldn't
do
anything
different.
You
know
just
ignore
it.
E
F
Yeah
I
think,
depending
on
your
perspective,
some
language
makes
sense
or
not,
and
I
just
linked
to
the
extensibility
section
of
considerations.md
and
the
language
that
uses
is
implementations
that
are
reading,
slash,
processing,
manifests
or
image
indexes
must
not
generate
an
error
if
they.
E
F
Like
it
doesn't,
I
don't
know,
clients
don't
have
to
accept
something,
they
don't
know
how
to
process,
but
for
a
registry
like
if
you're,
not
processing,
something
right,
if
you're
just
accepting
it
and
storing
it
and
then
returning
it
later,
it
makes
sense,
but
for
a
client
like
it,
the
accept
word
is
like
what.
I
I
I
I
feel
like
there's
a
pretty
big,
disconnect
and
I.
Think
it
goes
to
999
is
I
I
really
want
the
specification
and
I
think
it's
been
I've
reiterated
this
a
number
of
times.
I
really
want
the
specification
to
guarantee
some
degree
of
reliability
for
implementations
that
want
to
Target
oci
as
a
baseline,
that
they
can.
They
can
rely
on
oci,
1.1
or
or
what
whatever
as
a
signal
for
compatibility,
and
it
seems
like
I
I'm
a
little
frustrated
because
it
seems
like
there's
no
interest.
F
I
wasn't
linking
that
to
say:
oh
I
disagree.
We
already
say
this
I'm
saying
like
if
we're
looking
for
specific
verbiage
that
is
applicable
equally
to
clients
and
Registries
I
think
something
along
the
lines
of
must
not
generate
an
error
is
maybe
less
ambiguous
than
except
but
I
I
think
the
change
is
fine,
as
is.
D
I
Than
what
we
have
today
like,
instead
replace,
except
with,
must
not
generating
error
cool.
B
F
Yeah
I
think
you
know
ignored,
is
applicable
to
like
a
client
that
is
unpacking
an
image
with
layers
and
I.
I.
Think
some
of
that.
Some
of
the
reasons
behind
that
language
was
that
for
Z
standard
layers.
One
of
the
ideas
was
to
just
have
an
image
reference,
both
the
like,
say
normal
layers
and
Z
standard
compressed
layers
and
older
clients,
and
you
should
ignore
the
Z
standard
compressed
layers,
but
I.
Don't
think
that
that
was
a
good
rollout
strategy
or
something
that
people
are
actually
doing
so.
E
The
biggest
risk
I
see
is
that
Registries
do
want
to
be
able
to
filter
and
reject
things
and
give
them
a
sample.
Docker
schema
one
which
manifests
for
those
game.
One
Registries
want
to
say:
hey.
We
don't
want
to
support
this
anymore.
It's
it's
always
step
K.
We
want
to
cut
it
off,
and
so,
if
you
put
everywhere
in
here
that
you
can
never
reject.
If
you
see
one
of
these
media
types,
that
puts
them
in
a
situation
where
there
are
different,
Registries
doing
different
things
and
there's
kind
of
like
a
common.
F
E
I
I
Block
lists
are
okay
right,
like
I,
we
have
moved
off
of
Docker
manifest
types,
but
if
oci
conformance
permits
allow
lists,
then
implementations
products
cannot
build
on
oci
1.1,
because
you're
I
can't
use
them
for
cat
gifts.
I
can't
use
them
for
electron
s-bombs.
You
know
the
conformance
doesn't
mean
anything
in
terms
of
artifacts.
B
D
C
We
have
about
10
minutes.
There
was
a
discussion
about
the
the
scratch
subject,
having
a
media
type
that
is
not
equal
to
the
content
John,
do
you
have
any
issues
with
that?
I
just
want
to
kind
of
get
your
thoughts
on
it.
F
Practically
I
suspect
Registries
that
are
trying
to
parse
the
config
as
Json.
Don't
care
about
the
media
type
that
it's
set
as
but
like
from
a
purity
perspective?
F
I,
don't
love,
say
if
if
your
artifact
type
was
not
a
Json
thing,
then
it's
unfortunate
that
the
media
type
doesn't
match
I.
D
F
We
sidestep
entirely,
but
that
I
don't
know
we
spent
enough
time
arguing
about.
It
feels
a
shame
to
suggest
anything
else.
I.
A
C
Specification
clearly
says
that
the
content
needs
to
match
so
either
we
loosen
that
up
or
we
pay
that
for
artifacts.
The
config
media
type
descriptor
doesn't
follow
this
portion
of
this.
There
needs
to
be
an
exception
somewhere
again.
We
don't
have
to
codify
it,
but
at
least
it
guarantees
that
this
is
how
artifacts
can
be
used.
And
yes,
if
you
were
to
get
artifact
type
in
the
image
manifest
as
a
first
class
then,
but
the
config
is
still
required.
So
you
still
need
a
scratch
config
as
to
Define.
F
Yeah
I
mean
if
let's
say
we
make
artifact
type
top
level
field
and
image
manifest.
Then
you
know
the
scratch.
Config
can
be
hard-coded
and
we'd
have
to
have
some
language
around
like
okay,
artifact
type.
Is
this
topical
field?
But
if
that
doesn't
exist,
check
the
config
media
type
because,
like
home
charts
use
that
and
so
there's
some
precedence
for
parsing.
That
I.
E
E
F
I
agree
with
you:
if
by
artifact
manifest
you
mean
something
abstract
and
not
the
current
thing,
we
can
do
better
right,
I,
I'm,
also
I'm
fine,
with
like
you.
F
Perfect
but
it
works
and
let's
do
it-
let's
come
up
with
something
better
to
merge
later,
but.
E
I
was
going
to
say,
part
two
of
the
big
values
with
artifact
manifest
one.
You
don't
have
to
actually
push
that
blob
for
the
config,
and
so
that's
one
less
thing
in
there
and
then
empty
layers
is
implicit.
That
point
you
know
you
can
push
no
pause.
If
you
wanted
to
the
the
other
big
Advantage.
Is
that
you're
explicitly
saying
this
isn't
a
container
image?
This
isn't
something
any
runtime
should
ever
be
looking
at
from
the
media
type
at
the
top
level
right
there,
and
so
there's
there's
no
confusion.
I
There's
another
benefit
which
is
I,
think
we
would
need
a
substantial
rewrite
of
layer.md
and
the
the
language
on
image,
manifest
layers
field
talks
about
things
like
file
systems
and
how
they
have
to
compose
into
a
valid
file
system
according
to
layers.nd,
which
is
absolutely
not
going
to
be
the
case
right.
So
there's
needs
to
be
substantial
changes
there
I.
B
C
C
Yeah
I
didn't
want
to
slow
down
the
layers
optional
PR,
but
if
we
were
to
standardize
that
layers
can
be
anything
that
is
not.
That
is
not
odd
enough
from
like
0
to
n.
We
need
to
call
out
that
it
can
be
a
blob
that
is
not
following
this,
this
portion
of
specification.
So
this
is
how
VMS
manifest
kind
of
morphs
itself
to
a
non-image
in
some
way.
So
there
are
many
gray
areas,
that's
still
there
what
I
wanted
to
kind
of.
C
So
if
we
have
to
push
an
empty
config
and
we
have
to
do
a
layer
as
well.
That
kind
of
an
example
manifest
for
what
an
artifact
looks
like
would
be
super
ugly
and
to
John's
point
of
us
being
able
to
make
it
better
it's.
This
is
kind
of
like
a
bloated,
manifest
of
how
it
would
be
in
some
way
so
I
think
an
optional
layer
is
something
that
I
would
like
to
see
as
let's
get
at
least
layers
optional
and
then
the
config
media
type.
C
B
C
B
I
won't
speak
for
John
or
Jesse
who's
gone,
but
I
think
there's
a
path
to
get
ECR
and
GCR
to
to
allow
an
empty
layers
or
missing
layers
and
then,
like
that's
pretty
great.
Let's
do
that
I,
don't
think
we'll
be
able
to
get
all
clients
and
Registries
to
ignore
the
config
meeting
like
to
accept
an
empty
or
missing
config,
but
that's
a
much
smaller
hurdle
to
me
or
much
smaller
grossness.
B
Layers
feels
like
a
bigger
hurdle:
I
don't
know
they're,
but
they're.
Both
the
same
size
they're,
both
very
small.
B
I
think
if
I
could
only
choose
fixing
one
I
would
rather
a
layers
to
become
optional,
and
that
seems
easier
to
manifest
LOL
easier
to
make
happen
because
GCR
and
ECR
seem
interested,
at
least
in
the
abstract.
In
doing
that.
B
A
B
Which
thing
do
we
not
agree
on?
I
said
a
few
things.
E
B
E
D
D
C
C
I
don't
know
I
mean
in
the
sense
that
we
have
okay.
Let's,
let's
be
honest
here,
we
haven't
got
a
prettier
manifest.
You
got
a
bloody
ugly,
manifest
right
like
it's
got.
Config
it's
got
layers
legally
agree.
I
think
we
agree.
The
the
point
is
this
is
where
we
will
stand
today
and
that's
maybe
that's
what
it
is.
I
I
don't
see
us
making
progress
if
we
don't
agree
on
qualifying
the
artifact
in
some
way,
I.
I
I
E
A
A
That's
part
of
the
value
well
exhausting,
but
that's
even
part
of
making
the
argument
of
like
what
is
what
is
the
middle
ground
here
of,
like
is,
is
there
Middle
Ground
is
between
the
breaking
changes
that
would
come
from
introducing
the
Manifest,
and
you
know
manifest
type
versus
the
value
of
like
clearly
trying
to
work
around
these
issues,
because
even
to
John's
point
of
like
there's
no
technical
value
in
the
in
the
artifact
manifest
and
now,
if
the
technical
value
is
in
seeing
these
conversations
of
like
all
the
warts
that
it
would
take
to
work
around,
and
it's
like,
okay
moving
to
an
artifact
manifest
removes
the
warts.
A
D
A
A
So
if
you
have
a
part
of
either
fixing
those
or
moving
any
part
of
that
conversation
forward
of
what's
working
everywhere
and
we
could
bike
I
think
I'd
be
really
awesome.
If
somebody
stepped
up
and
said
they
would
wanted
to
carry
that
into
the
conformance
tests
that
Josh
had
gotten
started.