►
From YouTube: OCI Weekly Discussion - 2021-07-28
Description
Recording of the weekly OCI developer's call; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#July-28-2021
B
C
A
A
Town
all
day
tomorrow,
so
yeah
I
it
was
quick
enough.
I
didn't
really
try
and
do
much
other
than
the
team
events
that
were
already
set
up
but
hoping
to
be
back
depending
on
comet.
But
if
open
source
summit
still
happens
at
the
end
of
september
should
be
back
for
that
week
and
speaking
of
that
amy
said
her
only
status
update
was
that
she
is
working
on
space
at
open
source
summit
here,
make
sure
I
get
it
right
september.
A
B
A
Yeah
I
mean
so,
I
think
vbats
said
yesterday
in
the
channel
trying
to
think
what
the
next
step
needed.
I'm
thinking
it's
just
bringing
the
repo
and
point
dns
I
mean
I'm
I'm
on
the
same
page
that
it
seems
valuable.
So
you
know
I
it's
not
like.
We
have
any
heavyweight
process
for
something
like
this
I
mean.
Does
anyone
else
have
a
strong
feeling
in
either
direction
about
this.
A
B
A
A
E
Yeah,
so
thank
you
to
everybody
who
filled
out
the
doodle.
I
think
we
got
17
20,
something
like
that.
Respondents
and
the
most
popular
time
among
the
options
was
an
hour
later
in
the
day,
which
is
good
signal,
but
doesn't
help
me
who
wanted
to
move
it
earlier,
the
the
other.
There
were
a
number
of
second
place
times.
One
of
the
second
place
times
that
was
earlier
was
like
11
on
tuesdays.
I
think
I
wrote
it
down
and
I
copied
the
thing
into
the
packing
d.
E
I
should
go
look
at
that
yeah
eleven
to
noon
on
tuesdays
since
sending
this
out
and
talking
to
people
about
it,
the
options
weren't
very
asia-friendly.
They
were
maybe
a
little
europe-friendly,
but
not
very
asia-friendly
if
people
it's
unlikely.
But
if
someone
is
in
this
meeting
who
is
interested
in
having
an
asia
friendly
time,
I
think
we
should
consider
that
and
push
for
that.
F
I
feel
I
feel
bad,
not
piping
up
when
we
were
doing
this
again,
because
I
remember
doing
this
a
few
years
ago
and
we
came
up
with
this
doodle
in
it
and
it
landed
on
two
a
few
years
ago
the
to
do
the
european
times
you
have
to
do
it
at
9
a.m,
pacific
and
then
to
do
the
asia
compatible
time.
That's
usually
you
can
kind
of
squeeze
in
for
but
that's
really
early,
but
anything
after
like
5
p.m.
Pacific.
C
A
A
A
A
I
don't
know
if
this
came
up
on
the
email
or
slack
or
somewhere
but
like
to
me
there's
no
formal
process
like
we
just
get
to
pick
and
try
and
be
as
communicative
about
when
things
are
happening.
So
people
don't
get
confused,
but
I
think
the
comment
was
basically
you
either
do
a
series
like
sort
of
staying
in
one
and
then
switch
to
the
next.
A
E
So
we
mentioned-
I
think
I
wasn't
here
last
week,
but
I
was
here
two
weeks
ago
when
we
talked
about
the.
I
think
steve
mentioned,
like
a
quarterly
blocks
of
meetings.
I
think,
like
you
know
like
in
q1,
it's
it's
pacific
time
friendly
and
q2,
it's
asia,
time
friendly
whatever
etc.
I
think
the
risk
there
is
that
if
someone
starts
to
get
involved
in
the
community
because
the
meetings
are,
if
they
get
involved
and
the
meetings
are
friendly
to
them,
it
might
shake
them
off
of
future
contributions.
E
When
the
meetings
move
away
from
their
friendly
time,
I
don't
there
is
no
good
answer
for
it.
If
there's
a
good
answer
for
it,
please
please
let
me
know
so
that
I
can
spread
the
word
to
every
other
open
source
project
that
has
the
same
global
problem
but
yeah,
I
kind
of
I
I
don't.
I
don't
really
like
the
model
of
the
like
quarterly
shifting
meetings.
I
understand
that,
like
weekly
shifting
meetings
are
also
confusing.
E
A
A
F
So
I
just
did
a
couple
of
random
cities
on
there.
That
might
be
helpful
to
find
a
time
for
everybody
that
website,
but
basically
it's
like
well
afternoon
and
afternoon
in
australia
or
super
early
in
the
morning
for
europe
and
super
late
at
night
for
the
on
the
pacific
time.
So
it's
kind
of
hard
yeah.
A
E
D
A
Yeah
I
yeah
I
mean
I
can't
speak
for
all
the
other
folks,
but
I
think
we're
kind
of
at
the
point
where
we'd
like
steve
to
make
you
know
there
were
some
comments
that
seemed
like
there
was
agreement
like
on
some
slight
wording,
changes
or
how
to
describe
something
a
little
clearer,
but
you
know,
and
talking
to
a
couple
other
tob
members
like
it's.
It's
at
the
point
like
my
comment
was.
D
A
A
A
B
A
D
Yeah
I
like
these
meetings
because,
like
we
can
just
discuss
things
and
I
can
get
a
bunch
of
opinions
from
people
who
aren't
me
like.
There
are
a
bunch
of
conversations
that
happened
five
four
years
ago
about
expressing
dependencies
within
descriptors
and
between
artifacts
and
I've
not
like
gone
through
those
threads.
But
if,
if
steven
day's
here,
I
would
love
to
pick
his
brain,
because
this
seems
relevant
to
like
today
right.
D
D
F
F
F
D
So
I
don't
know
that
we
have
this
notion
in
oci.
World
like
this
may
be
a
hold
over
from
a
different
universe.
Where,
like
you
would
have
you
could
aggregate
multiple
images
into
one,
or
is
this
like
your
suggestion
being
that
you
can
aggregate
arbitrary
things
into
one
thing
where
a
descriptor
can
depend
on
other
descript
things.
F
F
The
idea
of
being
able
to
do
like
a
a
composed
image
where
you
like
have.
Let's
say
you
have
like
an
app
image
like
a
runtime
image
and
then
like
an
application
image
or
a
system
image
and
an
application
image.
Whatever
terminology
you
wanted
to
use
there,
the
problem
with
doing
that
in
a
cast
system
is
that,
like
it
there's
not
a
whole
lot
of
advantage,
because
now
you
have
to
push
an
updated
application
image
anyways,
because
you're
directly
referencing
it
via
it's.
It's
it's
digest!
F
F
C
D
C
It's
going
to
say
it's
the
same
syntax,
but
is
it
the
reverse
direction?
And
so
the
new
references
is
saying.
Here's
my
object
here
are
other
things
that
potentially
point
to
this
or
you
know
we
might
want
to
use
an
api
to
query
it.
So
we
could
have
a
signature
put
out
there
and
then
have
other
images
that
need
that
signature,
and
so
you
put
the
image
reference
on
the
signature.
This
feels
like
it's
the
reverse.
F
Yeah
yeah,
I
wouldn't
strictly
use
point
it's
it's
more
like.
It
was
more
of
a
way
to
allow
us
to
extend
other
types.
The
registry
didn't
understand,
but
still
support
garbage
collection
right
so,
like
you
could
imagine
this
descriptor
before
it
pushes
the
application
runs
down
the
tree
of
types
whatever.
You
know,
however,
deep
it
is
and
unrolls
those
blobs
into
this
references
dependencies
would
probably
be
a
better
name
here
and
then
you
know
unrolls
it
into
this
list,
and
then
the
registry
knows
hey.
F
An
inch
so
there's
nothing
that
says
it
has
to
be
a
manifest
and
we
don't
really
define
like
I,
I
think,
there's
I
think
it
says
it
should
be
a
manifest,
but
I
think
we
left
it
specifically
open
and
michael
brown
went
and
looked
at
the
language
and
validated
this,
and
I
thought
he
had
like
a
pretty
like.
We
left
it
specifically
open
the
reason
I
don't
think
we
we
introduced.
F
This
is
because
you
can
kind
of
hack,
manifests
and
manifest
lists
to
already
do
this,
so
it's
not
that
necessary
and
I
think
the
artifact
project
has
also
shown
that
you
know
it
can
be
accepted
in
different
ways,
and
we
just
haven't
you
know
introducing
another
extensible,
abstract
type
is
like
I
don't
know,
that's
kind
of
adding
gasoline
to
the
fire.
Sometimes
so
you
know
don't
add
what
you
don't
need.
That
said,
I
guess
john,
what
what
problem
did
you
besides?
D
So
I
think
it's
relevant
to
the
like
build
kit
cache
manifest
stuff
right,
which
is
but
not
exactly
right.
So
the
way
I
see
this
being
used
would
be,
if,
like
you,
want
to
refer
to
something
that
has
its
own
dag
or
defend
dependency
graph
of
anything
and
want
to
pinned,
pin
those
dependencies,
but
you
can't
reference
them
directly.
So,
like
let's
say
you
were
to
reference
a
git
repository
or
a
git,
commit
from
an
image
and
wanted
to
have
each
commit
be
its
own
blob.
D
F
Yeah,
the
the
naming
layer
is
kind
of
the
thing
I
feel
like
we're
missing
for
that,
and
maybe
we
there
was
like
an
old
pr
and
distribution.
We
had
for
adding
first
class
tags
where
you
could
have
like
a
kind
of
strong
relationship.
It
was
like
a
it
was
like
a
tuple
of
a
name
and
then
a
descriptor
right,
and
then
now
you
could
say
hey.
I
am
referencing
this
thing
that
has
this
name
and
then
you
have
a
strongly
consistent
system
that
says
for
this
name.
I
resolve
to
this
descriptor.
F
So
if
I
have
two
values
for
the
name,
a
I
want
to
know,
I'm
going
to
be
able
to
tell
which
one
is
the
latest
current
value
like.
How
do
you
solve
that
problem
and
can
we
sort
kind
of
went
into
that
a
little
bit
as
far
as
I
understand
it's
similar
to
like
the
update
framework,
the
problem
solved
by
the
update
framework,
so
it's
it's
a
little
difficult
to
solve.
But
if
it's
something
that
like,
if
it
enables
like
a
really
important
use
case,
then
maybe
it's
something
that
needs
to
be
tackled.
D
F
F
F
That's
without
stepping
on
the
toes
of
signatures
and
other
systems
like?
Does
it
require
that,
like
cryptographic
like
a
cryptographic,
ledger
like
we
would
do
with
signing
or
tough
or
what's
the
one
they
use
in,
go
for
the
package
system?
It's
also
a
similar
kind
of
system
like
do
you
have
to
do
that
and
if
you
have
to
do
that
like
how,
like
you
launch
that
whole
project
or
is
something
lighter
weight
like
just
having
the
first
class
object
with
that
work,.
F
The
the
nice
thing
about
introducing
a
first
class
tag
type,
though,
would
be
that
you
could
kind
of
have
a
root
type
to
traverse
through.
So
like
a
single
kind
like
like
one
one
problem
I
see
in
in
the
artifacts
repo
is
we've
re-embedded
the
media
type
to
like
re-embed
the
type
inside
of
the
thing
and
there's
some
security
issues
with
that?
D
Yeah
yeah.
What
so
one
thing
that
I
think
would
be
interesting
is
my
proposal
to
just
allow
pushing
of
descriptors
just
like
a
descriptor,
their
references,
anything
else,
and
we
could
even
have
an
end
point
where
you
would
like
get
a
tag
that
points
to
a
descriptor
and
the
registry
could
jump
through
it
for
you.
So,
instead
of
returning
like
the
media
type
is
descriptor,
it
has
this
size.
It
could
basically
dereference
that
pointer
and
just
return
that
to
you.
F
D
C
D
Right,
we
could
make
everything
a
blob
you
know,
and-
and
maybe
this
is
where
we
would
need
the
dependencies
thing
right.
You
could
list.
Oh
everything
that
is
referenced
by
this
object
is
in
this
list
and
so
pin
all
that
stuff
call
it
a
day
wait.
What
pr
is
that
I
just
opened
an
issue
on
distribution
spec,
because
I
had
an
idea
once
upon
a
time,
but
if
we
combine
it
with
the
dependencies
thing
we
were
just
talking
about.
Let's
see
it's
250
times.
F
Work
but
well
I
mean
like
okay
yeah,
so
you
take
a
descriptor
and
you
start
adding
generic
things
to
it
say
dependencies
and,
dare
I
say
if
I
get
tomatoes
thrown
at
me
in
2017,
but
a
name
right
like
now.
You
start
having
an
interesting
that
becomes
an
interesting
segue
into
a
root
object
that
would
provide
us
this,
like
generic
cavs
thing
that
we've
kind
of
been
talking
about
over
the
last
month
or
so
so.
D
D
C
D
C
C
C
F
C
Steve
is
not
here
to
defend
his
point
of
view,
so
I'll
just
throw
his
out
here,
even
though
I
don't
necessarily
agree
with
it,
which
is
that
they've
made
architectural
decisions
for
a
manifest
should
be
small
and
therefore
easy
to
put
through
some
kind
of
caching
mechanism,
and
so
anytime
people
talk
about
putting
other
random
things
as
a
manifest
object.
He
gets
nervous.
C
F
F
D
D
F
I
I
would,
I
would
probably
roll
the
dice
between
like
four
and
eight
megabytes
as
not
causing
too
much
trouble,
but
then
there's.
I
did
this
something
similar
for
nearly
every
type
in
container
d
docker,
the
registry-
and
I
can't
recall
a
time
somebody
didn't
send
a
pr
or
request
to
have
it
bigger,
so
yeah
yeah.
C
So
that
takes
us
to
issue
number
260,
which
was:
should
we
be
able
to
define
a
limit
just
after
you
got
done,
saying
no
limits.
The
thought
process
I
had
is
that
the
registry
should
be
expected
to
support
at
least
a
minimum,
and
clients
should
be
expected
to
not
try
to
exceed
that
minimum
without
realizing
they
might
run
into
compatibility
issues.
F
C
It
but
it
would
be
nice
for
interoperability
if
we
said
look
if
your
registry
supports
at
least
this
much
in
your
client
make
sure
that
doesn't
exceed
that
limit.
Then
everything
just
works.
If
you
do
exceed
it,
then
you're
getting
into
platform-specific
issues
where
you
might
have
compatibility
issues,
and
you
just
agree
to
understand-
that's
pushing
the
spec.
D
F
D
Yeah,
but
so
this
is
very
related
to
the
data.
Pr
that
I
had
and
I've
been
experimenting
with,
and
it's
great,
but
right
like
I
don't
want
you
to
find
a
limit
for
the
data
field,
because
you
don't
always
push
something
to
a
registry
like
I
might
want
to
use
this
outside
of
http
entirely.
So
it
feels
silly
to
limit
the
flexibility
of
something
based
on
a
web
server
if
you're
not
even
going
to
encounter
it.
F
Yeah
well,
and
I
wouldn't
put
the
limit
on
the
data
field,
because
then
you
have
registries
that
are
now
required
to
unpack
and
validate
the
data
fields
which
might
we
might
not
also
want
to
do.
We
might
want
to
just
have
it,
take
the
data
and
then
opaquely
put
it
into
its
storage
location
without
validating
it.
The
so
the
setting
would
really
be
at
the
distribution
spec
layer
rather
than
the
image
spec
layer.
I
mean,
in
my
opinion,
yeah.
C
I
I
know
steve
has
been
pushing
to
hold
up
the
the
proposal
on
the
data
because
he
was
worried
about
some
of
the
stuff
with
the
size
and
I
feel
like
he's
pushing
at
the
wrong
level.
Just
because
the
manifest
itself
is
the
overall
thing,
you're
trying
to
control
and
you
can
have
20
references
in
there
and
each
one
has
their
individual
data,
and
you
might
have
you
know.
C
Same
same
issue,
so
that's
where
I
feel
like
it
should
be
in
the
manifest
object
itself
and
not
yeah.
Yeah
he's
been
fighting
this
fight
for
a
while
and
he
keeps
pushing
back
because
of
their
design
on
the
manifest
how
they
cache
that,
and
I
just
feel
like,
if
you're
going
to
solve
that,
we
should
solve
it
with
the
manifest.
Not
the
data
field.
D
C
F
Yeah
yeah,
but
but
you
know
like
in
ten
years
somebody
writes
a
blog
post
and
hopefully
they
care
enough
and,
and
they
say
well,
five
megs
was
you
know
it's.
It
was
really
short-sighted.
There's
all
these
things
that
are
stored
in
manifest
now
and
networks
are,
you
know,
everybody's
got
terabit
to
their
home
or
something
like
that.
So
it's
so
optimistic.
A
F
Their
cloud
storage
size,
so
it's
they're
there
and
they're
like
a
platform
concern
and
you
kind
of
run
into
them
and
work
around
them
as
they
come.
We
put
them
in
the
spec
and
then
you
have
to
go
to
the
spec
to
change
it,
and
then
you
have
to
release
the
spec
and
then
now
the
cloud
providers
can
update
it.
F
D
My
my
thinking
is
that,
like
it
is
reasonable
to
inline
anything
that
falls
under
the
mtu
of
like
tcp
right
like
this,
doesn't
even
affect
your
like
manifest
get
because
it
all
fits
in
the
same
packet.
So
who
cares
but
like?
I
can
definitely
see
people
in
lining
many,
many
large
things
which
I'm
about
to
do
to
see
what
happens
with
acr
but
yeah.
I
agree.
I
don't
want
to
put
any.
A
F
F
D
C
D
D
F
D
D
D
Cool
jason
wanted
us
to
look
at
the
standard
base
and
image
annotations
thing
again.
I
don't
know
if
anyone
cares
about
that
other
than
me
and
jason,
I
did.
I
built
the
rube
goldberg
machine
that
I
swore
I
would
for
an
internal
hackathon,
basically
index
images
by
their
base
image
and
just
rebase
them
anytime.
D
D
D
D
C
I'm
not
contentious,
but
I
know
that
we
were
talking
about.
It
should
be
the
pointer
to
the
oci
index
and
not
their
ci
manifest,
and
I
want
to
throw
out
like
an
extra
thought
on
there,
which
is
that
if
we
have
an
image
that
itself
is
an
index
that
has
multiple
manifests,
you
can
have
annotations
on
those
individual
manifest,
and
so
could
you
at
the
index
level
point
to
the
other
index
and
that
they
manifest.
That
will
point
to
the
other
manifest.
C
D
D
So
if
you
depend
on
ubuntu
latest
you
should
reference
the
index,
because
then
you
can
know
that,
oh,
it
is
the
index
that
changed
right.
If,
if
you
reference
the
child
base,
then
it
will
never
map
to
the
tag
digest
you'd
have
to
like
traverse
the
tag
index
to
find
like.
Oh,
this
is
actually
not
changed.
One
extra
hop,
you're,
saying
yeah
yeah,
makes
sense.
D
D
D
F
D
D
A
D
A
F
A
A
C
F
D
F
Yeah
yeah
and
that
that
was
kind
of
my
suggestion
that
this
needed
to
be
at
like
a
higher
level,
build
layer,
but
I
I
don't
think
that's
we
don't
really
have
that
in
the
oci.
So
this
suffices
and
like
I
like
this
because
it
gives
you
a
way
like
I
can
just
look
at
it
and
go.
Oh
ref
got
okay.
I
know
where
this
came
from
boom
and
go
find
it.
D
Yeah
and
like
you
could
imagine
having
your
own
annotation,
that
is
like
a
key
to
something.
That's
like.
Oh,
you
need
to
send
a
pub
sub
message
to
this
topic
and
that'll
trigger
a
rebuild
or
whatever
yep,
or
you
could
even
just
surface
in
a
ui
and
say.
Oh,
this
is
out
this
is
out
of
date
or
even
click.
Oh
the
base
image
over
here.
Yes,.