►
From YouTube: OCI Weekly Discussion - 2021-03-24
Description
Recording of the weekly OCI developer's discussion from 24 Mar 2021. Agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#March-24-2021
B
B,
all
right,
so,
let's
talk
a
moment
about
the
agenda
to
maybe
time
box
some
stuff
and
figure
out
how
we
want
to
do
this
because
we
have
some
big
items.
Welcome
back
jason.
I
know
we
were.
I
was
thinking
about
you,
the
last
couple
of
days
when
we
were
on
a
couple
of
other
pr's
and
didn't
mean
to
get
back,
because
I
think
yours
to
some
extent
is
almost
the
easiest,
with
some
clarity
on
a
couple
of
things
we've
been
talking
about,
but
yeah.
C
B
The
larger
discussions
there's
been
a
couple
of
different
approaches.
We've
been
looking
at
various
would
say
we
this.
This
larger
group
has
been
looking
at
around
it's
centered
around
signatures,
but
it's
really
about
linking
artifacts,
I
think,
is
the
the
main
piece,
one
of
the
artifacts
being
a
signature,
the
there's
a
base
of
a
larger
discussion
of.
Can
we
make
changes
to
the
existing
manifest?
B
Then
there's
another
conversation
should
and
maybe
should
we
start
something.
I
guess
one
manifest
to
rule
them
all.
If
I
were
to
say
something
about
what
justin's
been
proposing.
So
I
did
inject
to
be
fair.
John
did
have
some
stuff
in
there
first
around
the
descriptors
and
about
the
references,
but
there
and
then
there's
the
one
about
the
lincoln
artifacts
with
the
artifact
spec.
The
one
of
the
fundamental
differences
to
those
two
approaches
is
whether
we
can
make
changes
to
the
existing
schemas.
B
If
we
decide
we
can,
then
either
approach
can
do
that.
We
just
have
to
decide
that
we
can,
and
that
kind
of
is
a
based
on
a
discussion
we
had,
I
guess
two
years
ago
when
we
started
the
artifact
stuff
and
decisions
there
there's
another
approach
which
basically
has
been
something
justin's
been
working
on,
of
whether
we
should
take
a
more
holistic
approach
to
how
we
store
things
in
registries
and
be
a
little
more
flexible.
B
B
The
thing
about
justin
zach
is,
I
think,
it's
I
think
it's
rooting,
a
bunch
of
stuff
that
we've
been
all
been
dealing
with
for
a
while,
and
it's
probably
worth
a
read
so
that'll
might
help
give
context
to
the
other
two
conversations,
because
just
these
are
an
additive
per
se
like
if
we
agree
with
the
general
direction
of
what
justin's
proposing
it
kind
of
mitigates.
The
other
two
conversations
we've
been
having.
E
B
E
B
So
it's
the
point
is,
is
that
we
did
want
to
get
this
done.
He
had
some
good
ideas.
We
wanted
to
get
it
written
down.
We
wanted
to
get
it
shared.
It's
not
fair
to
dump
this
on
everybody
and
expect
to
read
it
because
to
read
and
digest
we'll
take
the
majority
of
the
slot
we
have
here.
I
do
think
it's
a
really
good
read
to
help
us
really
think
about
how
we
want
to
think
about.
B
If
we
agree,
then
I
think
we
can
give
more
time
to
getting
through
some
of
the
actual
items
and
we
can
defer
the
or
maybe
we
can
start
a
conversation
actually
all
right.
So
I
think
if
you
read
justin's
doc,
you
kind
of
say
well,
do
we
really
need
to
make
changes
to
the
current
one
or
just
fix
it
once
and
for
all?
B
G
E
G
E
E
E
So
it's
making
the
proposals
more
generic
and
really
addressing
the
upgrade
issue
and
a
couple
of
other
issues
like
indirect,
being
able
to
reduce
indirection
as
well,
but
really
trying
to
resolve.
The
upgrade
issue
which
is
really
kind
of,
I
feel
has
been
blocking
us
because
the
formats
we
designed,
which
is
not
actually
in
practice,
upgradable
in
any
useful
kind
of
way,
which
is
why
we're
running
into
problems.
G
B
There's
there's
two
fundamental
pieces
that
we've
been
talking
about:
one
is
being
able
to
store
additional
individual
things
in
there,
whether
it
be
an
s
bomb,
whether
it
be
a
signature
that
can
already
be
done
today.
There's
an
optimization
john
is
proposing
on
using
the
data
element,
which
is
what
I
assume
he's
trying
to
do
with
some
of
these
pieces,
but
storing
another
thing,
but
still
storing
an
individual
artifact.
It's
you
know
whatever
it
might
be,
the
one
that
stores
links
so
that
you
can
say
the
signature
or
the
cess
bomb
is
associated
with
this.
B
G
G
F
B
B
Totally
agree,
I
was
trying
to
be
careful.
I
wanted
to
make
sure
that
we
didn't
rush
through
those
to
get
to
the
things
that
were
originally
on
the
agenda,
so
I'm
I'm
bringing
this
up,
as
does
everybody
agree
with
what
you're
suggesting
and
then
let's
just
go
through
that
not
rush
through
those
make
those
actionable
things
done
and
then
cue
up
that
whole
other
one
for
some
reading
to
conversations
over
the
week
and
we
can
pick
up
next
week.
G
The
annotation
part
about
recording
the
image
from
which
the
current
manifest
is
derived
from
it's
a
little
bit
confusing
for
me,
because
I
had
you
know
I've
been
working
on
this
for
a
while,
and
I
I
have
like
s-bomb
structures
that
describe
all
of
that
stuff
as
a
basic
annotation.
I'm
totally
fine
with
it.
B
Let's
do
that,
let's
do
the
actionable
ones
we'll
park
the
rest,
depending
on
how
much
we
get
through
the
first
three.
We
can
figure
out
what
we
want
to
do
about
reading
or
some
discussion
about
the
last.
So
why
don't
we
because
we're
already
jumping
into
it?
I
just
I
just
want
to
make
sure
everybody's
cool
with
that.
B
B
This
is
a
targeted
thing
that
says
that
customers
have
been
trying
to
do
this
for
a
lot
of
users.
Customers.
I've
been
trying
to
do
this
for
a
long
time.
How
do
they
do
the
the
very
simplistic
thing
of
what
is
this
image
based
on?
So
if
any
changes
happen
to
it,
can
I
trigger
a
rebuild?
It
is
not
trying
to
cover
the
whole
s
bomb
things.
It's
literally
just
that
base
piece
is
that
fair,
jason.
C
Yeah
very
fair,
I
think
the
conversation
in
the
pr
has
sort
of
meandered
into
complex
cases,
which
I
agree
exist
in
which
I
agree
should
be
solved,
but
I
think
there
is
value
to
having
a
very
common,
very
narrowly
defined
case.
That
is
well
understood.
I
don't
know
who
I'm
trying
to
convince.
I
think
misha
is
already
convinced.
So
that
is
my.
That
is
my
weekly
reminder
that
this
annotation
is
a
possibility,
if
you
but
want
it
to
be.
C
B
Thank
you.
I
think
the
only
thing
we
saw
in
the
base
annotations
one
was
there
was
this
conversation:
are
we
making
it
for
humans
or
make
it
for
automation?
And
if
it's
for
automation
for
general
use,
then
we
should
just
be
specific
about
it.
So
tooling
would
know
exactly
what
to
expect,
and
I
thought
it
was
really
close.
I
think
there
was
a
combination
of
some
examples
of
something
we
could
refer
to
in
docker
hub
that
exists.
We
could
throw
a
digest
on
there
of
something
that
exists.
B
You
know
something
like
whether
it's
be
the
hello
world
image.
That's
I
don't
know
what
hello
world's
based
on,
but
whatever
hello
world's
based
on
and
then
have
that
hello
world
be
the
ref
name,
I
think
it
was
and
the
digest
be
of
that
and
then
the
base
name,
I'm
butchering
the
property
names
jason.
So
help
me
with
what
you
were
trying
to
do.
C
You
all
have
more
experience
writing
this
spec
than
I
do.
Is
it
helpful
to
have
actual
names
referenced
I
find
sometimes
in
documentation
when
real
things
are
used
in
sample
values.
It
can
muddy
things
because
people
say:
oh,
the
hello
world
image
is
no
longer
based
on
ubuntu.
It's
based
on
busybox
and
now
there's
like
all
this
confusion
about.
I
don't
think
you
could
have
just
said
my
image
and
some
digest
right.
I
think.
C
Yeah
terrible
example
so,
like
I,
I
I
defer
to
all
of
you
who
know
what
you're
doing,
but
as
a
as
a
reader
as
a
potential
reader
of
the
spec,
I
think
I
might
find
it
useful
to
say
some
image
clearly
an
example,
fake
dummy
value
and
some
fake
dummy
digest
than
to
base
it
on
a
real
thing.
That
being
said,
I
just
want
to
get
it
merged.
So
if
you
tell
me
to
put
in
puppies
I'll
put
in
puppies,
I
don't
care.
F
C
F
Is
that
we
are
defining
what
a
base
image
is,
and
I
mean
if,
if
everyone
disagrees
with
me,
that
we
should
definitely
define
what
that
base.
Image
means
this
exact
thing:
okay,
fine
I'll
I'll,
let
it
go,
but
I'd
rather
be
able
to
interpret
a
little
bit
what
a
base
image
means
and
I'm
happy
with
even
suggesting
the
common
use
of
a
base
image.
But
that's.
C
C
F
I
just
would
omit
the
perhaps
omit
the
definition
of
what
a
base
images,
or
at
least
I
guess,
since
it's
a
should,
I
do
have
some
flexibility
to
ignore
it,
but
if
it
were
a
may,
be
you
know
the
zero
indexed
contiguous,
whatever
whatever
I
would
be
slightly
happier,
is
the
only
difference,
I'm
looking
for
really
is
there
another
definition.
Sorry
go
ahead.
B
You
know
using
docker,
build
when
I
say
from
it's
bringing
the
layers
in
from
that,
and
my
layers
add
upon
that.
So
it's
that's
layers,
my
layers,
minus.
I
guess
you
know
and
then
there's
other
ways
to
build
images
as
well.
So
I
I
don't
know
if
people
would
object
to
base
base
reference
based
name
base
image.
C
D
C
F
F
F
So
when
I
use
docker
files,
I
don't
have
any
froms,
but
I
do
use
other
tools
that
depend
on
an
image
and
when
I,
when
that
image
changes,
I
need
to
rebuild
my
image.
That's
all
I'm
looking
for.
Basically,
I
I
don't
want
to
only
like
be
out
the
should
makes
it
feel
like
I'm
doing
something
wrong
if
I'm
not
using
docker
files-
and
I
think
that's
incorrect
and
kind
of
over
focuses
on
one
specific,
build
tool.
C
B
So
you
kind
of
have
an
arbitrary
image.
That's
got
everything
that
you
would
want
in
it
like
just
just
randomly
saying,
there's
a
bunch
of
npm
packages,
a
bunch
of
rpms
whatever
it
is
that
your
image,
if
anything,
changes
in
that
you
would
know,
and
if
that
so
there's
a
digest
associated
with
that.
So
if
that
changes
for
any
reason,
you
would
trigger
a
a
rebuild
of
your
thing.
Yeah.
E
B
F
C
C
C
C
B
B
F
E
F
A
E
H
I
mean
it's:
it's
vincent's
image
if
he
wants
to
move
it
to
quay
and
he
opens
the
pr,
then
let
him
do
that
doesn't
really
matter.
If
he's
owning
where
the
image
is.
I
think
the
bigger
problem
here
is
that
there's
not
enough
active
image,
spec
maintainers
to
actually
just
approve
it
and
merge
it
yeah
the
subset.
F
J
J
H
B
H
F
H
H
B
B
Do
you
want
to
focus
on
the
data
element
because
to
me
the
data
element
is
relatively
small.
I
I've
raised
the
concerns
around
the
size,
turning
a
manifest
into
a
blob,
and
we
we
can
certainly
talk
about
that,
but
if
we
feel
that
the
other
things
circumvent
the
the
use
of
the
data
field,
then
maybe
we
don't
worry
about
data.
We
get
onto
the
larger
conversation,
it's
your
pr,
so
I
want
your
opinion.
F
F
E
F
F
E
F
I
F
F
G
F
I
think
that
is
what's
happening
today
in
two
contexts:
there's
in
the
registry,
most
any
a
lot
of
things
start
with
a
pointer
to
an
image
you
can
head
that
url
and
get
back
a
set
of
http
headers
that
can
be
used
to
construct
a
descriptor.
You
have
the
content
length
that
becomes
the
size.
You
have
the
content
type
which
becomes
the
media
type,
and
then
you
have
the
docker
content
digest
which
becomes
the
digest
from
there.
L
If
there
is
favorable
opinion
of
the
descriptor,
can
we
call
out
like
what
limits
they
should
have,
because
the
serialization
is
an
attack
vector
how
much
you
can
stick
into
a
descriptor
becomes
a
problem
right
now.
We
can
trust
the
manifest
in
terms
of
how
much
can
be
downloaded.
So
I
want
to
make
sure
that
the
data
data
element
length,
if
at
all,
we
do
agree
to
kind
of
put
it
in.
There
has
a
limit
of
what
it
defines.
It
also
affects
caching
in
the
front
and
right,
like
the
memory
footprint
because
manifests
are
cached.
L
We
want
to
kind
of
make
sure
that,
as
soon
as
people
start
sticking
in
random
data
into
the
data
field,
how
much
of
that
is
going
to
impact
from
a
performance
profile
as
well,
so
getting
some
guidance
around?
What
is
an
acceptable
data
length
would
help,
at
least
from
folks
who
want
to
kind
of
run
the
front
end
as
well.
F
I'd
up
to
one
problem
I
have
with,
I
agree
with
you
right,
I
mean
that's
a
problem.
One
issue
I
have
with
defining
a
limit
is
that
the
descriptor
could
be
used
in
context
where
there
is
there's
no
limitation
right,
like
there's
no
reason
say
if
I'm
storing
something
on
disk
that
I
should
really
limit
the
size
of
this
practically,
which
is
why
I
added
language
to
this
pr,
to
the
effect
that,
if
you
care
about
portability,
you
should
not
just
embed
arbitrary
things.
H
At
container
d,
we
have
a
four
megabyte
limit
for
any
any
manifest
that
we
download.
So
anything,
that's
basically
a
download
is
started.
You
don't
know
the
link
beforehand.
We
will
limit
the
download
to
form
eggs
because
you
never
want
arbitrary
downloads
of
any
user
defined
or
any
user
defined
name
to
just
go.
Unlimited,
so
in
reality
manifests
are
much
smaller
than
that,
but
yeah,
I'm
not
sure
if
oci
should
call
that
out,
but
it's
probably
worth
just
calling
that
out
to
somewhere
as
registries
and
clients,
if
they
define
that
differently,
you
could
have
problems.
F
Yeah-
and
I
mean
it
would
be
silly
to
pick
a
number
that
is
higher
than
some
registries
could
support,
because
that
would
arbitrarily
pick
on
them.
So
I
I
don't
want
to
be
responsible
for
picking
a
number,
and
so
I
don't
think
we
should,
and
but
I
mean
that's
why
I
wrote
the
guidance
about
portability
if
you
think
that
can
be
clarified
in
some
way
or
made
stronger,
I'm
open
to
suggestions.
B
So
if
there's
now
content
in
it
that
can
be
of
a
size
or
an
attack
vector,
then
that
actually
kind
of
makes
another
problem.
So
I
I'd
be
personally,
I
think
it's
if
we
it's
already
in
the
spec,
it's
already
there.
It's
just
a
matter
of
clarifying
its
usage.
If
we
put
a
size
constraint
to
it,
that
said
this
is
not
meant
to
upload
videos
into
the
manifest.
It's
meant
that
I'm
not
trying
to
pick
on
mark.
It
was
just.
It
was
an
interesting
conversation
about
how
he's
trying
to
use
it.
B
Then
it
says
great:
we
have
some
additional
data.
You
don't
have
to
make
the
round
trip
on,
but
it's
a
clear
intent
that
this
is
not
meant
to
replace
blobs.
It's
meant
to
be
an
optimization
for
a
decision
criteria.
If
you
will
and
if
we
don't
put
a
size
on
it
to
some
reasonable
size,
then
then,
why
don't
we
put
in
the
spec?
Let
registry
a
say,
tell
our
customers.
They
can
use
it
for
this
and
that's
all
it's
promised
to
do.
E
Bytes
might
not
be
interrupt,
for
example,
to
pick
a
random
number
and
that's
a
reasonable
compromise
for
people
who,
because,
given
you,
don't
have
to
use
this
thing
at
all,
but
giving
people
256
bytes
lets
them
put,
say
a
signature
in
it
which
is
kind
of
useful
for
reducing
round
tripping,
but
it
doesn't
let
them
put
a
more
than
a
very
minimal
image
in
it.
A
picture
in
it.
For
example,
I
can't
say
I
don't
know.
E
Yeah
so
there's
a
there's,
a
there's,
a
minimum
that
everyone
has
to
support.
So
if
everyone
has
to
support
256
bytes,
but
you
don't
have
to
support
more
than
that,
but
you
can't
say
I
only
support
12
bytes,
because
that
would
mean
that
no
one
could
use
it
at
all
because,
like
it
would
just
be
unusable,
you
might
as
well
just
not
use
it.
L
L
E
F
E
B
I
don't
want
to
say
protect
from
because
there's
so
much
stuff
he's
trying
to
get
to,
but
that
is
kind
of
the
things
that
break
like
nobody's,
expecting
an
annotation
to
have.
You
know
a
gigabyte
worth
of
content
or
even
10
megs
worth
of
content.
Yes,
it's
and
that's
kind
of
why
I
was
using
the
circuit
breaker.
The
power
panel
is
the
example,
if
you
add
up
all
the
individual
breakers.
Of
course
it's
going
to
exceed,
but
it
gives
flexibility
within
it.
B
I
think
defining
the
circuit
breaker
for
that
element
where
all
the
individual
elements
added
is
more
than
what
a
max
manifest
would
just
would
support
anyway,
but
it
defines
a
usage
boundary
that
would
be
clear
to
him
like
okay.
This
isn't
really
what
I
thought
it
was.
Let
me
do
this
other
approach.
H
The
registry
shouldn't
be
as
opinionated,
but
I
think
it's
more
the
clients
that
have
to
be
careful
here
in
terms
of
like
downloading
from
potentially
unknown
sources,
whereas
registries
are
handling
data
of
an
unknown
size
quite
often
but
yeah.
I
think,
defining
some
minimum
in
the
spec
here
to
say
that
clients
and
registries
should
handle
at
least
manifests
of
this
size.
B
As
another
example
of
something
that
got
big,
there
was
a
conversation
that
tough
would
take
all
manifests
or
references
and
put
it
in
an
index
and
submit
it
to
kind
of
support.
The
tough
metadata.
So
that's
another
place
where
I
can
see
this
position,
the
fact
whether
it
was
stable
at
any
one
point
to
support
it.
B
If
you
try
to
put
everything,
that's
in
a
repo
or
even
obviously,
a
registry
that
would
be
huge
as
well.
So
I
think
both
sizing
the
element
and
sizing
the
total
would
be
a
good
constraint
to
add-
and
maybe
it's
a
minimum
as
opposed
to
a
maximum
is
a
better
way
all
to
use
this
manifest.
You
with
registries,
are
expected
to
support
up
to
or
minimum
support
a
minimum
of
x.
E
F
B
Yes,
I
think
the
point
is
there
is
some
existence
of
constraints
that
we've
been
identifying
and
building
more,
and
that
is
good
and
look.
I
think
I
think
you've
got
some
actions.
I
think
we
all
agree
that
if
this
thing
would
be
useful,
if
there
was
a
minimum
size
to
set
expectations
so
that
somebody
could
know
that
as
long
as
they
fit
within
this
size,
they
will
get
consistency
across
if
they
want
to
optimize
for
a
cloud
specific,
a
registry,
specific
solution,
then
that
registry
can
say
well.
B
I
certainly
support
the
minimum,
but
you
can
also
stick.
You
know
a
movie
in
there
if
you
want
and
they
will
and
that
registry
will
support
it,
but
there's
no
expectations
that
it
would
be
consistent
to
move
it
across
and
it's
fair
for
a
customer
to
have
that
expectation,
and
then
registries
can
say,
as
we
do
today,
we
all
have
various
size
constraints
expectations,
whether
it's
a
tiering
thing
or
a
max
size
or
whatever,
and
then
customers
can
understand
that
as
long
as
they
stay
with
this
minimum,
it's
got
transportability.
E
I
guess
the
only
other
thing
is
I,
when
I
was
thinking
about
this
as
a
semantic
for
a
new
specification,
I
was
assuming
that
it
would
be
well.
Obviously
it
would
be
required
to
be
supported
because
it
was
part
of
this
back,
but
the
other
thing
I
was
assuming
that
you
could
have
a
data
uri
like
I
mean,
like
I
mean
like
a
data
uri
on
the
web,
you
would
not
actually
have
to
have
that
object
in
the
registry
at
all
it
would
it
could.
E
B
Well,
we
said
we
were
gonna
further
the
topics
to
the
reading
for
next
week.
So
we're
that's
why
we
had
that
conversation
up
front
to
say
we
have
time
for
the
quote:
actionable
ones
and
then
we'd
set
expectations
for
next
week
that
we
read
the
docs
and
have
the
ability
to
have
a
thorough
conversation
on
the
the
following
things.
B
And
that's
what
I
was
confused.
John,
that's
where
I
was
trying
to
get
some
clarification
is.
Can
I
use
this
standalone?
I
put
some
data
in
it.
I
may
not
have
any
blobs
whatsoever.
The
image
spec
currently
says
you
have
to
have
at
least
one
one
layer,
but
I
should
my
thought
was.
The
observation
is
I
can
put
stuff
in
it
and
I
can
use
it.
It
has
nothing
to
do
with
anything.
It's
a
layer.
It's
not
meant
to
be
one
or
both.
F
F
B
B
Thank
you.
Thank
you.
Try
not
to
do
the
echo
thing.
I
think
it's.
The
thing
that
was
confusing
a
little
bit
is
that
the
real,
the
real
optimization
was
it's
in
the
manifest,
and
I
don't
it's
not
on
a
descriptor
it's
on
the
manifest
and
if
I
have
a
manifest
that
is,
that
is
a
signature.
There
is
no
blobs.
I
don't
need
a
blob.
E
B
B
If
a
manifest
could
have
a
chunk
of
content
in
it
and
a
manifest
represents
an
artifact,
then
I
can
submit
a
signature
as
a
matter
in
a
as
a
manifest
using
what
we
have
today
and
if
the
data
element
was
just
on
the
manifest
not
on
the
descriptor,
then
I
could
submit
a
manifest
with
the
data
mode.
That
is,
the
signature
somehow
link
it,
which.
F
F
B
We
could
yeah,
I
think
today,
we
think
of
registries
that
manifests
are
the
entry
point,
the
definitions
of
things
and
the
blobs
make
up
the
thing
and
we've
been.
We've
definitely
been
talking
about
shortcut
short-circuiting
that,
but
that's
a
whole
yet
another
discussion,
so
in
the
one
minute
we
have
left,
I
think
the
action
items
are:
let's
take
everything.
That's
in
the
presentation
agenda.
Let's
start
with
justin's,
let's
invert
it
because
I
think
either
justin's
makes
sense
and
we
should
figure
out
how
to
digest
all
of
that.