►
From YouTube: OCI Weekly Discussion - 2021-07-14
Description
Recording of the OCI weekly developer's discussion from 14 July 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#July-14-2021
A
A
C
A
A
B
A
E
Yeah
I
mean
working
for
everybody
is
an
unattainable
goal,
but
working
for
more
or
most
might
be
achievable.
This
is
just
a
plug
to
fill
out
the
doodle.
I
think
there's
like
six
or
seven
people
who
have
so
far.
If
we
get
a
few
more
and
there's
sort
of
an
overwhelming
or
even
moderately
overwhelming,
better
alternative,
I
will
propose
them,
I
guess
here
or
somewhere
and
see
if
we
could
find
a
better
time.
Yeah,
it's
not
binding.
A
Just
on
the
notes,
it's
come
up
quite
a
few
times
on
this
and
it's
it
is
struggling
to
find
different
time
zones.
I
I
put
a
little
suggestion
there
is,
is
the
morning
u.s
time
to
be
fair,
a
balance
across
the
various
okay.
Now,
I'm
really
distracted
by
vanessa's
very
creative
background
now,
she's
upped
it
to
a
whole.
C
Well,
yeah:
the
problem
is
that
every
everybody
knows
that
right
again,
not
nine
a.m,
eastern
or
eight
a.m.
Eastern
is
the
you
know
the
universal
time
for
everybody,
but
there's
only
one
hour
window
and
everybody
uses
it.
So
we
we
ended
up
getting
a
lot
of
people.
You
know
in
and
out
we've
tried
before
one.
E
One
alternative
that
I
have
had
experienced
some
moderate
success
with
is
having
every
other
week
sometime
every
other
week,
seven
a.m,
eastern
time
and
then
every
other
week.
You
know
4
p.m.
Eastern
time
or
you
know
whatever
to
to
meet,
I
mean
again
going
back
to
there's
absolutely
no
time
that
will
work
for
everybody.
There's
going,
there's
24
time
zones,
yeah.
E
Yeah
yeah
yeah,
but
I
think
I
mean
the
the
goal
is
also
so
that
there
is
a
diversity
of
people
coming
to
the
meetings,
a
diversity
of
people
being
able
to
lead
the
meetings,
the
diversity.
You
know
if
one
time
doesn't
work
for
you
like
that,
should
be
fine.
There
should
be
another
meeting,
you
can
catch
the
next
time
or
the
recording
or
whatever
so
just
a
plug
for
fill
out.
E
G
When
you
do
the
alternating
weeks
for
different
times
of
meetings,
does
that
mean
that,
like
each
time
zone
that
goes
to
some,
you
know
one
particular
meeting
catches
up
by
like
watching
the
video
of
the
last
one
like?
How
do
you?
How
do
you
make
sure
that
everyone's
synced
and
when
it's
likely
the
case
that
most
people
are
going
to
like
one
time
zone
meeting.
E
Don't
think
the
goal
of
the
alternating
meetings
is
for
anybody
to
feel
like
they
have
to
go
to
all
the
meetings
in
the
in
the
tecton
community,
where
we're
doing
this
there's
a
monday
at
6
p.m.
Meeting
for
people
in
australia
mainly
and
the
people
in
australia
mainly
work
on
some
like
one
area
of
stuff,
and
so
that
meeting
is
mainly
about
the
stuff
they
want
to
talk
about
and
anybody
you
know
in
compatible
time
zones
that
are
interested
in
it.
It
sometimes
works.
It
sometimes
doesn't
work.
E
I
don't
know
that
I'm
necessarily
advocating
for
alternating
meetings,
but
I
am
advocating
for
getting
more
data
about
what
times
people
could
do
it
so
that
we
can
use
that
to
figure
out
if
there's
a
good
time.
It's
it's
difficult,
also
to
bring
up
when
meetings
work
for
people
in
this
group,
because
this
is
naturally
a
survivorship
bias
problem
of
like
well.
This
time
works
for
everyone
who's
here,
so
yeah
so
go
spread.
The
word
also
and
see
you
know
if
anybody
is
interested
who
can't
make
this
meeting?
C
And,
and-
and
I
guess
that's,
my
sort
of
feedback
here
is
most
the
people
on
the
original
calls
were
california-based.
You
know
for
for
obvious
reasons
right.
A
lot
of
this
stuff
was
donated
from
docker
and
it
sort
of
happened
that
way
and-
and
that's
why
it
was
afternoon
not
morning,
which
is
the
time
that
california
is
usually
not
going
to
be
around
so
that,
while
that
that
window
works
for
some
people
yeah,
we
started
of
get
california
to
get
up
early
enough.
A
That
would
be
nice
was
a
floating
hand.
I
did
sean
or
jason
sorry
do
you
remember
if
doodle
has
a
way
to
ask
additional
questions
like
because
we
tried
we
tried
doing
the
alternating
before
and
it
has
been
struggling
and
because
no
answer
is
perfect,
would
would
it
be
better
to
do
weekly,
alternating
or
a
three-month
stint
in
one
and
a
three
months
to
the
next,
and
I
actually
don't
really
have
an
opinion
one
way
or
the
other?
I
just
I
remember
the
reluctance
to
doing
the
alternating.
E
B
Yeah,
so
this
is
continuing
last
week
where
the
questions
come
in
I'll
go
ahead
and
do
a
quick
screen
share
on
this
question
has
come
in
when
we
look
at
what
an
in
what
an
image
index
is
supposed
to
contain,
and
the
challenge
comes
in
that
when
we
have
the
manifest
array,
it
says
it's
required.
Property
contains
list
of
manifests,
so
that
creates
an
assumption
that
these
are
going
to
be
manifest.
B
But
then
the
contents
of
that
is
really
just
a
list
of
descriptors.
So
then,
potentially
we're
looking
at
descriptors
and
we've
got
the
requirements
that
the
media
type
must
on.
The
you
know
must
support
that.
It
can
have
a
image
manifest,
but
it
could
also
include
other
stuff,
so
it
could
have
different
media
types
and.
C
B
Yeah,
and
so
the
challenge
comes
up
when
we
get
over
to
distribution
distribution
had
an
issue
on
this,
where
the
docker
themselves,
as
part
of
buildkit
buildx,
has
gone
through
and
made
their
own
version
that
puts
in.
Let
me
see
if
I
can
find
the
example
here,
and
otherwise
I've
got
one
local
that
was
worked
on
frantically
where
they
make
their
index
and
sorry.
This
is
well
that's
an
index,
but
they've
got
a
media
type
with
some
different
manifest
in
there.
That
are
not
necessarily
a
manifest
for
its
point.
A
B
B
It
yeah
yeah
it's
putting
stuff
inside
of
an
index
that
is
not
necessarily
a
manifest,
and
so
that's
kind
of
the
challenge
distribution
distribution
had
so
it
got
brought
up
over
here
last
week
of
okay.
Do
we
need
to
redefine
some
of
this
stuff?
Do
we
need
to
define
what
is
a
manifest,
because
we
didn't
really
define
that
specifically
in
here,
so.
I
Actually,
the
the
description
this
requires
property
contains
a
list
of
manifests
and
manifests,
is
a
link
for
something
else,
and
that's
where
the
definition
of
manifest
is
so.
If
you
click
there,
you
go
directly
to
the
definition
of
the
manifest,
and
then
you
have
the
required
properties
for
that
so
yeah.
This
is.
This
was
a
bit
controversial.
I
It
needs
to
be
adjacent
payload
with
the
minimum
required
properties
that
this
document
describes,
and
I
think
that's
where
the
the
problem
lies-
and
this
is
not
actually
about
oci,
because
before
oci
build
kit
was
using
manifest
lists
from
docker
and
the
docker
stack
is
even
more
strict,
because
there
can
only
be
two
media
types
within
the
manifest
array
on
a
list
and
it's
either
a
manifest
schema,
2
or
a
schema.
1
and
buildkit
was
already
using
that
to
include
layers
and
config
so
yeah.
I
B
B
So
they
give
an
example
as
part
of
their
stuff,
so
when
they're
looking
at
what
does
an
index
example,
look
like
a
lot
of
us
have
taken
the
assumption
that
a
manifest
is
usually
json,
but
it
could
be
other
stuff,
and
so
this
was
some
of
the
stuff
that
we
were
looking
at
last
week.
Vincent
was
pointing
out
was
that
there
are
situations
that
they
were
putting
out
there,
where
there
could
be
something
other
than
a
json.
That's
that
is
a
manifest.
A
My
interpretation
of
that
was
that
I
mean
a
manifest,
is
still
a
manifest
describes.
The
thing
you
know
an
artifact
in
the
registry,
whether
it's
json
or
xml,
was
you
know
I
don't.
I
don't
know
who
put
that
in
there
it's
it's
the.
I
think
the
idea
is
that
there
can
be
different,
manifest
types
and
that's
kind
of
where
we
ran
from
this.
In
the
past.
B
I
think
what
I
saw
from
some
of
the
distribution
discussion
was
that
they
were
expecting
that
they
could
always
parse
the
json,
no
matter
what
and
always
get
a
config
object
and
a
layers
object
and
just
work
with
that
as
a
manifest,
no
matter
what
the
manifest
version
was.
I
don't
think
that
is
a
proper
proper
way
to
look
at
that,
because
there
could
always
be
a
future
manifest
format
that
changes
these
and
there's
no
guarantee
that
it's
always
going
to
have
those
two
fields.
B
C
G
G
J
A
I,
the
interpretation
was
a
little
like
the
example
is
perfect
actually,
but
I
think
the
idea
is
that
a
registry
on
ingestion
would
look
at
the
media
type
and
they're
unique
right.
The
the
idea-
that's
application
section
now,
obviously
is
a
pretty
generic
one,
but
maybe
it's
application.
Slash
vanessa.xml,
in
other
words,
there's
a
specific
format
that
happens
to
be
an
xml
versus
json.
A
A
G
A
A
I'm
asking
for
this
name
thing
right,
repo,
colon
tack
and
what
I
get
back
is
a
manifest
that
I
don't
know
what
is
you
know
or
the
the
food
client
and
the
food
client
says.
Well,
I
don't
know
what
that
is
so
I'll
just
say
ignore
it,
maybe
it
should
throw
whatever,
but
I
think
the
point
is
is
that
a
client
can't
ignore
it,
because
it
doesn't
know
what
to
do
with
it.
A
server
I
actually
think
should
provide
some
more
actually,
probably
even
a
client
should
provide
some
feedback.
A
B
People,
people
implementing
this
should
probably
know
that
if
they
talk
to
a
server
that
doesn't
implement
it,
that
what
does
it
look
like
on
the
server
you
know
if
the
server's
just
gonna
ignore
something
unknown,
then
that's
part
of
your
development
process
of
how
you
know
this
can
be
handled
on
the
server,
but
there
should
be
some
base
level
functionality.
The
challenge
is
that
garbage
collection
isn't
defined
even
in
distribution
spec.
Today,
that's
left
up
to
the
implementation.
I
believe.
H
There's
one
more
ambiguous
point
here
for
distribution:
when
you
push
an
index,
all
the
manifest
needs
to
exist
in
the
manifest
file
store.
Do
we
assume
that,
irrespective
of
it
being
xml
or
not,
that
does
exist
or
do
we
ignore
the
fact
that
the
descriptor
might
not
even
exist
in
the
in
the
implementation.
J
I
have
a
lot
of
opinions,
but
I'm
trying
to
not
just
scream
at
the
mic,
so
I
I
think
you
there
are
a
lot
of
assumptions
being
stated
that
are
often
true,
but
not
necessarily
true,
like
the
distribution.
Spec
does
not
require
that
all
of
the
manifest
that
an
index
references
actually
be
pushed
to
the
manifest
store.
It
also
doesn't
define
what
a
manifest
store
is
and-
and
I
think
that
I
think
my
point
earlier-
john.
C
J
I
think
there's
a
lot
of
ambiguity
and
I
tried
to
get
this
clarified
in
the
distribution
spec,
but
I
think
we
aired
on
the
side
of
more
generic
than
useful.
So
I
think
this
is
only
a
problem
if
you
have
split
your
content
store
into
two
different
namespaces
being
like
blobs
and
manifests
right,
if
they
all
target
the
same
kaz,
it
doesn't
matter
if
it's
a
blob
or
a
manifest,
you
can
check
to
see.
Does
this
thing
exist
so,
like
there's
a
whole
class
of
registry
implementations
that
aren't
affected
by
this
problem?
J
A
This
I
mean
it
does
say
manifest
collection,
so
yeah.
I
think
that
is
a
logical
thing
and
if
you
look
at
that
issue
that
I
passed
in
there
for
moby,
which
job
created
it's
actually
been,
what
we
found
is
the
majority
of
them,
don't
support
it.
The
fact
that
acr
did
was
actually
a
side
effect
that
I
explained
in
one
of
these.
You
know
things
is
that
with
tasks
we
support
build
decks.
It
came
in
as
a
support
issue
and
engineering
just
went
and
fixed
it
with.
A
Had
I
even
seen
it
well,
we
want
to
try
to
figure
out
how
to
fix
the
customer's
scenario.
We
would
have
kind
of
pushed
back
and
said:
hey.
Can
we
fix
this
in
a
more
generic
way?
What
I've
seen
the
distribution
spec
maintainers
talk
about?
Is
there
was
a
workaround
put
in
place
that
kind
of
made
this
work,
but
it
wasn't
really
even
intended.
A
I
J
D
Yeah,
I'm
not
there's
a
long
history
here,
though,
like
when
this
was.
This
was
the
recommendation
actually
back
years
ago
when
it
was
introduced,
because
there
was
this
period
of
time
where
these
new
types
were
coming
out.
We
weren't
quite
sure
how
to
represent
them,
since
everything
that
we
had
that
existed
was
very
image
specific.
D
So
like
this,
this
was
actually
recommended
at
the
time,
and
the
support
and
distribution
was
intentional
to
get
this
working.
There
was
even
there
was
even
a
last
minute
push
or
discussion
to
generalize
the
index
before
the
oci
image.
Spec
went
1.0
to
make
the
index
more
generic
so
that
it
wasn't
just
lists,
and
it
it
it
all
kind
of
circles
around.
It's
the
same
problem
that
that
steve's
been
talking
about
for
years
about
how
we'd
find
artifacts
and
this
this
was
a
recommendation
at
the
time.
D
J
D
J
I
mean
this
is
why
I
added
support
for
this
thing
to
artifact
registry
so
and-
and
you
know
when
I
was
implementing
this
stuff,
I
was
reading
the
spec
and
it
was
not
clear
to
me
whether
or
not
an
index
could
be
recursive
and
there's
a
bunch
of
issues
in
pr's,
and
I
think
the
reason
this
stuff
got
added.
You
know
this
should
support
the
following
and
you
know
should
other
media
types
is
I
pushed
on
that
issue
like
can
an
index
reference
another
index?
J
D
J
D
There
was
a
few
like
bad
attempts
at
like
differentiating
differentiating
types,
and
there
was
a
requirement
put
in
at
the
time
for
docker
hub
to
explicitly
like
separate
namespaces,
so
that
you
couldn't
actually
push
different
types
of
images
or
you
couldn't
push
like
plugins
and
images
to
the
same
repository
and
older
versions
of
docker
that
that
didn't
handle
the
media
type
so
well
so
yeah.
I
think
the
history
of
it.
D
It
just
wasn't
very
clean
before
and
it
ended
up
with
some
of
this
and,
like
that's
that's
where
a
lot
of
the
ambiguity
comes
today
I
mean
it's
some
of
it's
almost
intentionally
ambiguous
because
they're
dancing
around
some
of
these,
like
use
cases
that
had
been
put
in
place
that
we
knew
weren't
well,
but
I
mean
they
they
exist,
so
we're
trying
not
to
break
them.
Yeah.
J
I
I
think,
like
what
most
people
have
done
now
is
either
fall
back
or
use
the
media
type
to
determine.
If
a
thing
is
a
manifest
or
a
blob,
I
think
that's
one
reasonable
approach
to
interpret
an
index.
The
other
is
assume
everything
is
either
a
manifest
because
it's
in
the
manifest
field
or
it's
a
blob,
because
it's
in
the
layers
config,
that's
another
reasonable
interpretation
and
I'm
fine
with
both
of
them
as
long
as
we
all
agree
and
actually
make
the
specs
say
that
steve
has
his
hands
up.
A
Yeah
I
just
wanted
to
bill.
I
mean,
like
your
point
about
the
manifest
in
the
indexes
and
the
index
can
reference
another
index
and
another
index
and
there's
this
recursive
thing-
and
I
remember
we
in
such
a
way.
Remember
was
talking
about
this
camera.
What
we
would
end
up
doing
to
support
it,
but
the
I
think,
regardless
the
the
difference,
does
go
back
to
this
life
cycle
management
problem,
which
I
think
all
of
us
have
been
running
right.
The
longer
you
want
to
register
the
longer
this
problem
or
the
bigger.
A
A
They
want
to
get
rid
of
this
content
because
now
they're
getting
alerts
for
stuff
that
they
just
don't
even
want
to
maintain
so
to
come
back
from
the
tangent,
the
the
idea
that
a
manifest
is
a
way
to
say
this
is
the
thing
I'm
defining
a
life
cycle
around
makes
me
is
the
defining
boundary
that
at
least
I
we've
been
thinking
about
it.
That
way
in
acr
is
whether
it's
a
manifest
list,
whether
it's
a
manifest
an
image,
manifest
an
image
index
or
an
artifact
manifest.
A
It's
a
way
to
define
a
thing
that
you
reason
about
as
a
life
cycle
and
then
the
fact
it's
got
a
blobs
or
layers
collection
is
yeah.
Here's
where
all
the
details
are
and
here's
how
I
can
do
cool
things
like
deduping,
but
that's
a
it's
like
a
an
intentional
line
of
delineation
between
the
two
that
lets.
You
be
efficient
about
storage
while
being
efficient
and
optimal
around
what
it
is,
I'm
trying
to
store,
if
that
makes
sense
from
the
two.
J
Did
I
go
on
too
much
of
a
tangent
there?
Does
that
make
sense?
I
guess
I
mean
I.
I
agree
like
a
thing.
That
is,
if
you
put
something
to
the
manifest
handler,
that
thing
is
a
thing
in
and
of
itself
right.
It
is
sufficient
to
have
identity
and
you
can
pull
it
and
you
can
delete
it
right.
It's
a
unit
of
thing,
so
I
agree
with
that.
A
Well,
I
think
that's
the
thought
process
is
that
the
because
of
manifest
collect
the
thought
is:
is
that
an
index
the
way
the
index
is
defined
today
because
it
says
manifest
in
it?
It's
still
a
collection
of
manifests,
that's
that's
kind
of
like
the
thought
process
and
and
earlier
at
some
point
in
the
artifact
stuff,
we
were
looking
at
putting
like
media
type,
for
instance,
or
config
media
type
on
index,
so
that
we
could
also
say
hey.
A
This
collection
of
things
also
means
it
is
a
cnap,
I
think,
was
the
canonical
example
of
the
time,
but
it's
still
a
definition
of
a
thing.
The
fact
that
the
definition
of
a
thing
is
a
collection
of
other
artifacts
is,
you
know,
images,
because
we've
kind
of
backed
off
from
that
proposal.
It's
still
a
collection
of
things
that
you
have
life
cycle
management
around.
A
So
it's
great
to
think
about
it
like
we
should
definitely
clarify,
I
think,
leaning
towards
clarifying
that
it
is
a
way
to
represent
life
cycle
of
things
you
store
in
a
registry
and
the
one
use
case
that
we
know
is
using
or
abusing
taking
advantage
of.
This
lack
of
clarity,
they're
more
than
willing
to
switch.
You
know
like
that.
B
Yeah,
I
know
last
time
one
of
the
key
things
was
we
defined
the
manifest
of
that
link
to
say
there
was
an
oci
manifest
and
we
don't
want
to
say
it's
just
no
ci
manifest,
so
that
needs
to
go
away
and
figure
out
how
we
want
to
find
this
if
that
needs
to
be
part
of
the
image
spec
within
the
distribution.
Spec
findings
get
into
garbage
collection
at
some
point.
Unfortunately,
I
think,
or
just.
A
Separate
the
two
like
this
is
the
refactoring
conversation
we
keep
on
trying
to
have.
Is
the
distribution
says
hey,
it
knows
how
to
persist,
manifests
here's
of
a
couple
that
it
knows
about
and
then
that
that
image
spec
knows
how
to
say.
This
is
exactly
how
an
image
spec
works
for
a
container
image
that
gets
used
for
something
else
great,
but
the
distribution,
side,
distribution,
spec
side,
not
distribution,
distribution,
the
distribution
spec
says
hey.
I
know
how
to
receive
things
through
the
manifest
api
that
defines
things
to
be
oci
compliant.
B
A
Just
to
pile
on
to
the
yeses,
I
mean
honestly
like
I
said
this
is
the
only
reason
acr
even
implemented
it
like.
We
didn't
intend
to
do
it.
It's
just.
We
supported
build
kit
and
tasks
and
all
of
a
sudden,
I
don't
know
exactly
because
it
was
working
on
one
support.
I
guess
they
switched
their
implementation
to
index
and
all
of
a
sudden
customers
were
saying.
A
H
Hombre
creates
industries,
so
the
thing
is,
I
think,
john's
gonna
hit
one
interesting
point
here,
which
is:
if
we
agree
on
falling
back.
If
it
doesn't,
if
it's
not
a
manifest,
we
can
look
at
the
cash
store
and
find
out
that
it's
blocked.
That's
a
good
enough
implementation
for
everybody
to
fall
as
a
reference.
That's
what
we
did,
I'm
guessing
most
of
the
implementations
would
go
down
that
route.
H
If
we
don't
want
to
mandate
anything,
but
there
are
two
scenarios
that
I
think
people
are
kind
of
like
as
part
of
the
whole
ambiguities
space
here
when
we
move
an
index.
What
is
the
expectation
here
right
like
you
copy
an
index
over,
we
actually
block
the
whole
chain
and
bring
the
whole
thing
over.
That's
one
way
of
kind
of
like
moving
content
across
clouds
and
whatnot.
H
The
second
part
is
what,
if
we
did
have
manifests,
we
didn't
understand.
Do
we
expect
that
move
to
actually
function,
or
do
we
just
ignore
them?
When
we
consider
an
index,
I
think
the
whole
aspect
of
keeping
the
index
on
the
distribution
side
he
kind
of
like
skirts
the
problem
and
why
I
think
the
life
cycle
is
important.
Is
we
have
customers
who
have
requested,
keep
this
image
around
for
three
years
or
keep
the
stack
around
for
three
years?
H
What
do
you
keep
for
three
years
when
you
say,
pin
that
index
for
a
compliance
perspective?
So
it's
not
easy
to
just
kind
of
say
that
we
can
just
keep
this
forever
because
they,
after
three
years
they
wanted
god
they
don't
want
the
cloud
to
hold
on
to
the
data
from
a
compliance
standpoint,
so
we
have
to
work
the
entire
chain
and
clean
it
up.
A
Both
sides
of
it
like
at
first
we
thought
like
as
long
as
we
don't
delete
it,
it's
fine,
but
then
we
have
customers
come
back
and
say
you.
We
want
to
make
sure
we
delete
it.
It's
actually
gone
because
there's
no
legal,
you
can't
go
back
and
you
know
prove
that
we
had.
They
had
something
that
and
we
get
I
mean
the
gdpr
there's
lots
of
different
examples
of
it.
So,
and
I
think
this
is
not
meant
to
impose
one
thing
from
one
provider
to
another.
A
A
Just
I
just
want
to
read
sorry
john,
the
last.
This
is
why
I
keep
on
trying
to
bubble
up
his
life
cycle
and
not
gc,
because
I
totally
agree.
Gc
is
an
implementation
detail
that
each
registry
should
figure
out
how
they
do
it's
the
life
cycle
management
that
I
keep
on
trying
to
bubble
up.
I
think
that's
the
consistency,
because
that's
the
end
user
experience
they're
looking.
J
J
A
A
What
are
the
expectations-
and
this
was
the
insightful
thing
for
me
when
justin
was
talking
about
how
docker
hub
works,
is
that
they
keep
the
tag
history.
So
if
you
delete
the
like
in
acr,
we
don't
have
that
capability.
If
you
delete
a
tag,
we're
only
going
to,
we
only
actually
delete
the
tag
and
then
the
digest
just
sits
there.
You
have
to
actually
say
I
want
to
delete
untagged
digest,
which
I
think
a
couple
of
us
implement.
A
What
they
did
was
they
keep
track
of
all
the
digests
were
associated
with
that
tag
and
when
they
delete
the
tag,
that
chain
is
ref,
counted
to
be
fair,
because
if
that
digest
is
also
associated
with
another
tag,
then
it
gets
ref
counted
down
and
it's
only
until
it
hits
zero.
I
actually
thought
that
was
a
pretty
cool
idea.
I'm
not
suggesting
we
necessarily
that
would
be
a
conversation
have
for
standards,
but
do
we
want
at
least
char
to
have
some
level
of
if
you
delete
a
tag
or
a
digest?
A
A
They
have
apis
on
things
too,
whether
it's
part
of
our
the
oci
specs
is
a
different
question,
but
I
can
just
tell
you,
as
we've
been
trying
to
remove
all
the
content
from
hub
and
try
to
keep
it
on
mcr
so
that
the
costs
are
reduced
to
docker
and
customers
have
a
consistent
experience
or
not.
It's
not.
It
turns
out
that
the
deletions
aren't
happening
the
way
they
should.
I
don't
want
to
bring
up
any
laundry
just
the
clarity
here
would
be.
We
agree,
it's
something
we
have
to
solve.
J
Other
registry
does,
and
maybe
there's
a
there'll,
be
an
intersection
we
can
be
happy
about,
but
yeah
I
mean
like
there's
an
explicit
delete.
This
blob
api
right,
like
it's
not
necessary,
that
registries
do
clean
up
for
you.
It
could
be
that
clients
are
responsible
for
cleaning
up
after
themselves
and
that
would
maybe
solve
the
life
cycle
quandary
of.
If
I
delete
this
thing,
I
want
to
make
sure
it's
gone.
Well,
there's
an
api
for
that.
I.
J
C
J
A
J
I
would
like
that
I've
I've
suggested
this
in
the
past,
I'd
like
to
because
there's
a
lot
of
things
around
deletion
that
are
hard
and
everyone
does
it
slightly
differently,
and
so
it's
hard
to
know
what
we
can
even
say
to
change.
You
know
yeah.
I
think
that
would
be
great.
If
someone
wants
to
file
an
issue,
we
can
collect
these
behaviors
and
maybe
do
something
about
it.
A
A
But
I
think
to
john,
I
think,
just
writing
down
what
we
think
we
do
like
docker
believes
when
you
delete
a
repo
things
are
gone,
you
leave
the
tag,
things
are
gone,
there's
bugs
bugs
are
bugs,
but
what
is
our
expected?
Behavior
across
the
registries?
Just
documenting
that,
as
a
seems
like
a
good
starting
point,
so.
G
Yeah
and
if
this
idea
actually
works
and
people
are
able
and
willing
to
share,
there's
kind
of
other
things
that
I
think
would
be
interesting
to
look
at
too,
not
not
just
specific
to
registries
but
like
command
line
clients
tool
like
I
was
just
thinking
about.
Caching,
the
other
day
like
there.
You
can
go
online
and
read
kind
of
the
high
level
things
about
docker,
but
for
different
implementations.
G
A
Cool
and
vanessa,
my
response
to
the
day
was
like
I
trying
to
how
much
we
can
do
in
this
group
was
kind
of
the
the
question
like
if
we
can
just
store
cash
results
in
a
registry
in
a
consistent
way.
That'd
be
good
and
I
think
the
different
projects
are
doing
different
things,
they're
innovating,
in
their
own
space.
I
don't
know
if
they're
ready
to
be
standardized
as
opposed
to
this
is
what
each
tool
does
and
let
them
fight
it
out,
because
I
think
we're
seeing
some
better
things
happen
because
they're
battling
each
other.
G
I
forget
who
said
it,
but
someone
had
an
idea
like
we
need
one
of
those
tab
thingies
where
you
have
like
the
different
languages,
and
so
I
can
imagine
someday
that
oci
says
like
here's
projects
that
implement
this
thing.
Oh
and
here's
a
tab
for
each
one,
and
it
shows
you
like
how
you
do
this
interaction
like
that
would
be
super
cool.
A
A
J
So
I
don't
see,
any
problem
is
the
reason
I
don't
want
to
take
this
action
item
is,
I
think,
everything's
fine.
I
don't
want
to
change
anything
and
I
think
this
works.
So
my
the
issue
is,
if
you
do
see
a
problem
and
you
want
some
language
to
change
to
make
it
so
that
there
is
a
problem
for
the
spec,
some
future
version
of
the
spec.
Then
I
would
like
to
discuss
that
spec
change
on
its
own,
like
I
don't
want
to
cast
some
value
judgments
right
now
about
what
we
think
should
happen.
J
J
A
J
I
think
that
is
a
reasonable
way
to
interpret
that,
but
I
don't
think
it's
necessarily
correct
to
interpret
it
that
way,
and
so,
if
you
want
that
to
be
truth,
then
I
would
request
that
you
make
spec
language
changes
that
make
it.
So
I
mean
I,
like
the
flexibility
right
like
I
use
an
image
index
to
store
all
kinds
of
random
stuff
on
my
disk.
It's
a
nice
like
I'll,
sell
you
on
the
gospel
of
like
the
generic
merkel,
dag
in
the
sky,
that
I've
been
building,
but
you
know
I'm
one
guy.
A
A
C
J
The
the
point
I'm
making
is
like
I'm
not
using
this
really
there's
no
registry
feature
that
enables
this
it's
just
that
per
the
spec.
You
are
allowed
to
implement
a
registry
that
allows
this
kind
of
thing,
and
so
I'm
using
this
clients,
I'm
not
doing
anything
with
the
registry,
really
I'm
using
an
image
layout
as
a
client-side
like
nice,
well-typed,
dag
storage
mechanism
and
some
registries
allow
you
to
push
arbitrary
things
in
an
index
which
means
I
can
use
a
registry
to
move
around
my
store
of
arbitrary
content
with
a
strongly
typed
safe
type
system.
J
It's
really
beautiful,
but
if
we
make
the
changes
such
that
registries
have
to
reject
this
thing,
I've
been
doing
for
years,
I'm
gonna
be
a
little
upset,
not
that
upset,
but
a
little,
and
so
that
that's
where
I
want
to
see
what
change
do
you
want
to
make?
Can
I
still
operate
in
the
margins?
If
not
I'm
going
to
argue
against
it,
but
I
obviously
have
one
vote
of
money.
K
A
K
A
So
the
question
john
is:
could
is
there
a
reason
like
the
same
question,
went
to
the
build
kit
folks?
Is
there
a
reason
you're
using
index
versus
if
you
use
manifest
with
the
collection
of
blobs
and
they're,
not
ordinal,
would
that
mean?
Would
that
solve
the
same
thing
because
and
I'm
not
trying
to
micromanage
what
you
do
for
your
gcr
thing?
What
I'm
trying
to
figure
out
is:
how
do
we
define
a
general
way
so,
whatever
you're
doing
you
can
continue
to
do?
What
build
kit
can
do
and
wasm
can
do
like?
A
J
You
only
need
to
care
about
all
the
artifact
types
if
you've
designed
your
registry
in
such
a
way
that
you
have
to.
There
are
a
lot
of
registry
implementations
that
do
not
care
that
a
manifest
and
a
blob
are
uploaded
through
different
paths
right
and
so
like
I
I
don't
know.
I
think
the
premise
is
faulty,
but
yeah.
I
can
bend
over
a
little
bit
more
backwards
by
introducing
an
extra
level
of
indirection
by
having
like
an
additional
hop
between
the
top
level
index
and
blobs.
I
can
add.
J
J
B
A
And
I
I'm
trying
we're
with
five
minutes
left
we're
not
going
to
get
another
topic,
and
so
I'm
just
using
this
to
figure
out.
There's
an
action
item
on
this
one,
like
I,
I
think,
which
is
this,
is
kind
of
the
core
of
what
again
we're
just
trying
to.
How
do
we
capture
a
set
of
requirements
for
for
john
whatever
it
is
that
you're
doing
like
what's
missing,
because
today,
cnab
is
you
know?
This
is
what
the
interesting
thing
about
cneb
is.
A
It
was
a
collection
of
artifacts
and
we
couldn't
figure
out
how
to
properly
do
it
without
revving
the
image
index,
and
so
I
think
I
believe
what
we've
been
doing
lately
with
the
artifact
stuff
does
allow
these
kind
of
things.
So
that's
the
part
that
I'm
just
trying
to
figure
out
without
trying
to
get
the
detail
of
exactly
what
you're
doing.
What
is
what
is
this
use
case
and
scenario
so
that
we
can,
we
can
generalize
it,
so
we
don't
have
to
be
on
a
call
every
time.
B
And
there
was
an
attempt
looking
through
a
lot
of
the
other
instances
like
the
helm,
charts
and
some
of
those
things,
and
they
point
out
here
a
whole
bunch
of
different
examples,
they're
all
using
the
oci
manifest.
You
know
why
can't
bill
can't
do
that
too.
Every
single
one
of
them
had
a
config
object
and
every
single
one
of
them
had
a
single
layer
and
that's
a
very
specific
model
that
fits
a
lot
of
people
but
doesn't
fit.
I
Everything-
let's
actually
point
to
what
I
would
like
to
suggest-
a
change
to
the
spike,
because
that
currently
is
a
must.
The
layers
must
be
in
order
with
the
base
layer
on
the
first
place
and
then
the
others,
but
order
only
matters
if
the
application
that
you're
trying
to
address
as
that
concern
or
not
for
build
kit,
for
example,
or
that
doesn't
matter
for
room
brew
for
wasn't
any
other
non-container
image
use
cases.
I
J
A
We'll
all
implement
things
as
fast
as
our
customers
need
them,
and
I
do
say
customers
in
case
to
differentiate
users
versus
customers.
So
I
think
that's
the
cycle
that
we
keep
on
getting
ourselves
carved
into.
It
doesn't
exist
yet
so
we
won't
use
it.
But
if
we
don't
start
creating
what
exists
we'll
never
get
to
there,
it's
just
the
the
infinite
cycle.
You
have
to
start
somewhere.
B
So
I
know
this
is
going
to
hog
up
a
lot
of
the
time
with
the
last
few
seconds
here
left.
I
hate
to
keep
continuing
this
every
week,
and
so
I
don't
want
to
push
this
into
the
next
week,
but
probably
needs
to
get
pushed
into
some
github
issues
and
stuff,
like
that
or
other
specific
action
items.
Next
steps
people
want
to
see
come
out
of
this.
J
A
That's
right,
I
think
you
know
there's
there
is
some
folks
that
have
been
you
know.
Jo,
has
been
helping
help
the
building,
build
kit,
build
x,
team
kind
of
figure
out
what
could
work
and
how
to
get
them
unlocked
on
things
and
that
his
list
of
what
works
and
what
doesn't
work
was
pretty
pretty
insightful.
So
looking
for
the
next
steps
there,
I
think
the
only
thing
that
was
on
there
we're
not
going
to
get
to
it,
but
it's
the
the
next
steps
on
the
working
group
proposals.