►
From YouTube: OCI Weekly Discussion - 2020-12-09
Description
OCI weekly developer's call recording from Wednesday, 9th Dec 2020. Agenda/call notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#December-9-2020
B
The
rc2
for
distribution
spec,
we
had
targeted
early
november
and
it
is
now
early
to
mid
december
and
there
is
basically
a
number
of
issues
that
are
coming
up
sort
of
at
the
final
hour,
which
I
don't
see
anything
wrong
with,
but
I
think
I'm
wondering
if
some
of
these
things
can
be
postponed
for
a
subsequent
release.
I
know
some
there's
some
strong
feelings
on
certain
things,
but
some
of
them.
I
think
we
do
need
a
little
bit
of
help
in
the
form
of
pool
requests.
B
I
I
just
opened
number
the
latest
one
number
218:
to
try
to
open
up
a
pathway
to
solve
the
accept
header
content
negotiation
stuff.
Basically,
I
created
a
new
document
called
content
negotiation
that,
maybe
you
know
sebastian
or
john,
could
take
a
pass
at
and
then
added
back
the
language
about
accept
headers
from
the
spec
that
I
pulled
up
from
last
year,
and
then
I
also
reached
out
to
the
maintainers
to
see.
B
If
maybe
next
week,
we
can
do
like
just
a
long
sit
down
and
just
kind
of
release
the
next
rc,
because
it's
sort
of
a
holding
pattern
and
then
the
link
that
I
have
on
there
is
the
milestone
where
I'm
adding
issues
that
I
think
should
be
resolved
prior
to
that
release.
So
if
you
don't
see
your
issue
in
there
and
you
feel
very
strongly,
please
make
a
note
or
shout
now:
is
there
any
any
comments
on
that
before
I
move
on.
C
C
B
Okay
and
I'm
happy
to
meet
with
you
know,
just
the
two
of
you
whenever
you
have
the
time
as
well.
The
next
one
I
had
was
really
simple,
but
you
know
in
trying
to
you
know,
be
more
mindful
of
words
and
language
changing
the
name
of
the
branch
which
github
is
now
doing.
I
think,
by
default
from
master
to
main,
and
I
don't
see
any
issue
with
it-
I've
had
issues.
I
tried
this
on
a
few
other
places
and
it's
it
will
auto
close
pr's.
A
So
that
has
been
a
hassle.
We
did
that
in
a
bunch
of
places.
I
don't.
I
thought
the
github
folks
were
doing
something
to
fix
that,
so
it
doesn't
auto
close.
I
don't
know
if
anybody
else
has
followed
has
had
any
conversations
with
them
to
know.
If
that's
in
the
works
because
it'll
be,
it
certainly
would
be
nice
if
we
didn't
have
that.
B
Yeah,
maybe
what
we
do
is
we
wait
until
we
get
1
0
out
and
then
make
the
switch.
So
it's
not
affecting
prs
that
are
open
for
that,
but
I've
had
it
both
ways
like
I've
had
it
where
the
prs
auto
update
to
maine
and
then
the
other
ones
other
ones
that
just
don't.
I
think
it
has
to
do
with
how
they
were
put
together.
A
Does
anybody
know
I
could
reach,
I
could
find
the
person
and
reach
out.
I
just
I
don't
know
if
anybody's
already
knows
what
they're
thinking,
what
they're
planning
there
like
is
there
some?
I
thought
they
were
doing
a
feature
that
you'll
be
able
to
change
the
branch
and
it
doesn't
lose.
It
doesn't
auto
close.
It
will
just
transfer
over
to
the
other
branch,
but
I
could
be
underestimating
what
that
really
means.
A
B
B
B
B
B
B
F
Okay,
I
had
one
quick
announcement
before
this.
I
forgot
to
put
on
the
thing,
which
is
that
we're
in
the
process
of
donating
daca
distribution,
which
is
the
registry
reference
implementation
and
to
cncf-
and
this
will
happen
in
january-
but
I
hope
he's
admitted
shortly,
so
I'm
going
to
submit
it
through
the
sandbox
process
and
the
incubation
process.
At
the
same
time,
if
anyone's
interested
in
being
a
maintainer
at
ping
me
we've
appoint
I've
appointed
like
eight
maintainers
from
github
get
lab
digital
ocean
darker
everyone.
F
Basically,
everyone
who's
using
it
in
production,
yeah,
so
z,
standard.
We
it's
really
the
spec
that's
been
agreed-
is
very
problematic
to
actually
use
in
a
way
that's
compatible
with
any
kind
of
old
client,
because
basically,
the
only
workflow
that
seems
to
work
is
that
you
just
use
z
standard
instead
of
normal
compression
and
there's
no
way
for
an
old
client
to
be
able
to
use
it.
F
F
A
A
How
much
can
you
stuff
into
the
existing
manifest,
and
it
just
seems
we
need
to
get
some
more
definitive
information,
so
clients
can
know
what
they
are
aren't
pulling,
whether
it
actually
fits
in
the
manifest.
I
hadn't
gone
that
far
with
thoughts
the
memphis
list
rather,
but
it
seems
right
now
I
mean.
F
F
Unfortunately,
was
designed
in
a
kind
I
mean
it's,
the
is
the
right
place
logically
for
it.
Unfortunately,
the
design
of
it
isn't
very
extensible,
which
is
makes
it
difficult
to
just
put
new
things
in
it,
which
is
really
unfortunate.
But
it's
logically,
the
manifest
list
seems
exactly
the
right
place.
There's
an
image
for
lyrics.
F
If
you
understand
gzip,
which
everyone
does
and
there's
it
or
you
know
by
default,
and
then
there's
one
for
if
you
understand
z,
standard
and
then
we
can
put
them
both
in
and
then
the
clients
can
all
pull
the
nice
fast
standard
ones.
If
they're
new
and
the
old
ones
are
they're
not-
and
that
seems
perfect.
F
Yeah
yeah
absolutely,
but
I
mean
there's,
there's
fundamentally
like
if
you
care
about
storage
space
you'll,
just
you
have
to
use
gzip
because
you
only
want
one
of
them,
but,
for
example,
for
for
official
images
we
bandwidth
is
the
cost
that
matters
for
us
into
it.
So
we
we
would
have
both
and
then
we'd
hope
that
new
clients
would
download
the
nice
small
ones
and
it
would
save
us
lots
of
bandwidth
costs
and
we
wouldn't.
We
would
eat
the
storage
costs,
because
the
difference
is
enormous.
F
So
we're
not
sorry,
but
otherwise
I
mean
like.
If
people
know,
if
people
know
all
their
clients
and
you,
then
they
can
switch
permanently
and
like
in
some
years.
Everyone
can
do
that
potentially,
but
right
now,
there's
just
we
just
simply
can't
use
them
at
all,
because
it'll
just
break
all
old
clouds,
and
this
basically
means
it's
useless.
A
Yep,
we
generally
don't
see
customers
concerned
about
their
storage
costs
per
se.
It's
the
bigger
problem.
Is
they
have
stuff
stored
that
they
don't
know
how
to
they
don't
know
if
they
can
delete,
because
they
don't
know
whether
they're
referencing
or
not,
so
for
them,
it's
cheap
to
keep
it
and
not
worry
about
it.
A
G
I
think
the
manifest
list
is
the
right
way
to
do
it.
Has
there
been
any
testing
to
make
sure
that,
like,
if
you
have
to
say,
x86
images,
same
architecture,
just
the
one
happens
to
come
after
that?
Has
the
standard
that
any
1.0
client
will
support
that
correctly
or
I
don't
even
know
if
we
have
a
yeah.
Unfortunately,.
F
Yeah,
unfortunately,
I'm
not
sure
that
this
was
really
thought
of
when
the
manifest
this
was
great
because
it
doesn't
have
kind
of
extensible
keys.
Even
it's
as
far
as
I
remember.
It's
only
got
the
architecture
thing,
so
I
right
now,
I
don't
think
there's
I
think,
that's
a
that
makes
it
probably
even
more
difficult.
H
Well,
there's,
I
guess
maybe
I
don't
know
what
you're
talking
about
about
the
manifest
list,
but
if
it's
just
a
list
of
like
manifest
objects
like
the
way
it's
tagged
in
an
image
is
the
it's:
it's
like
a
map
of
keys
to
values
and
my
understanding
is,
you
can
put
whatever
keys
in
there.
You
want
right
so
isn't
that
extensible
or.
G
I
think
that
is
accessible
today.
I
think
the
problem
is
the
clients,
don't
have
a
way
to
like
programmatically
say
this
is
this:
is
the
rules
for
how
you
should
resolve
this?
It's
just
platform
and
that's
pretty
much
it
and
I'm
not
even
sure
how
well
that
is
defined
today
in
the
manifest
lists
and
index.
G
But
I
I
believe
that
a
docker
container
d,
client
at
least,
should
handle
that
correctly.
If
you
had
two
images
with
the
same
platform,
the
second
one
just
had
us
an
extra
annotation
that
it
would
resolve
that
correctly.
But
I
think
that's
that's.
What
would
need
to
be
defined
in
the
spec
because
yeah
in
order
for
it
to
be
a
1.1,
it
has
to
be
compatible
like
1.0,
clients
need
to
be
compatible.
I
think.
I
So
there
was
another
trick
that
we
did
in
quay
when
we
were
supporting
both
like
rocket
and
docker
back
in
the
day,
which
was
basically,
if
you
tried
to
request
one
like.
If
you
tried
to
request
an
aki
image
and
it
was
uploaded
as
a
docker
image.
We
would
basically
transcode
it
on
the
fly
the
first
time
and
we
would
stream
it
to
the
customer.
At
the
same
time,
we'd
be
uploading
it
to
s3
in
our
permanent
storage,
and
then
any
subsequent
polls
would
be
cached
from
that
trans
code.
I
So
it's
basically
on
demand
transcoding
and
we
just
basically
implemented
the
routes
for
it.
So
we
like
you,
could
theoretically
do
this
in
the
worst
case
scenario,
where
you
know
the
legacy,
clients
are
not
going
to
trust
any
changes
to
the
manifest
list,
but
instead,
like
you,
could
look
at
accept,
headers
or
even
version
headers
on
your
server
and
basically
serve
legacy,
images
and
transcode
them
on
the
fly
and
cache
them.
F
F
Very
reluctant
to
kind
of
require
that
registries
do
any
work
at
all,
because
the
whole
point
is
they
should
be
as
scalable
as
possible
for
shipping
bits
out
and
that's
their
kind
of
function.
I
think
I
mean
as
a
as
I
said
in
the
kind
of
content
negotiation
discussion.
I
don't
I
I
don't
think
we
should.
We
should
be
requiring
any
work
to
be
done
on
connect
either.
J
A
This
is
one
of
the
way
that
clients
are
aware
of
the
new
standard,
z
or
otherwise,
and
we
don't
want
to
break
the
existing
stuff
out
that
it
doesn't
know.
So,
wouldn't
this
be
something
we
could
do
a
versioning
on
index
that
adds
this
other
stuff
and
then
the
client
that
makes
a
request
basically
says.
I
don't
know
how
to
support
this
thing,
so
it
fails,
but
new
ones
would
be
able
to
get
it.
A
A
E
Indication
or
something
so
one
of
the
things
I've
been
thinking
about
is
how
to
have
an
alternative
represent
how
to
present
an
alternative
representation
of
the
image,
and
I
think
the
z
standard
argument
kind
of
works
with
that
I've
been
thinking
about
some
other
things
like.
How
can
we
distribute
like
a
flattened
image,
as
you
know,
chopped
up
bits
or
whatever
and
how
like?
How
does
that
fit
into
the
spec?
And,
unfortunately,
it
just
doesn't
work
out
very
well
outside
of
sidelining
it
in
headers,
or
something
like
that
saying.
E
A
But
it
is
specific
to
the
artifact
type,
where,
like
this
kind
of
goes
in
that
conversation,
is
you
know
what
singularity
wants
to
do
separate
from
the
container
image?
They
should
be
separate,
and
this
looks
in
fact
we
won't
I'm
going
to
yield
the
time
back
for
the
artifact
manifest
conversation,
because
other
topics-
I'm
not
as
prepared
as
I
want
to
be,
but
the
if
image
spec
wants
to
add
some
new
capabilities.
A
Those
two
manifest
you
know
are
great
for
manifest
and
we
are
indexed
as
well,
and
maybe
we
should
consider
adding
the
necessary
information
so
that
they
could.
We
have
to
obviously
test
what
the
down
level
clients
would
do
when
they
got
some
new
information
that
they
don't
expect.
You
know,
I
think
we
said
once
we
joked
once
before,
like
there's
it's
not
that
many
clients
that
pretty
much
show
up
on
this
call.
A
We
know
the
person
that
built
it,
so
we
can
figure
out
what
the
right
behavior
should,
what
the
behavior
would
be
on
a
down
level,
client
that
doesn't
know
how
to
negotiate
the
new
version.
It
seems
like
we
need
to
make
this
more
version
proof.
So
we
don't
create
a
set
of
instability
in
the
ecosystem.
A
Now
I
mean
there's,
obviously
the
docker
client
there's
container
declines,
there's
things
like
scopio
and
other
tools,
there's
what
maybe
six
or
eight,
because
remember
it's,
not
just
clients
that
know
that
do
other
things
with
the
registry
like
this
would
not
affect
the
helm.
Client,
the
home
client
doesn't
even
look
at
that.
Manifest
type,
even
juarez,
doesn't
focus
on
container
images.
So
it's
it's
really
a
smaller
set
of
tooling
the
historical
versions
of
docker,
the
container
d
versions.
D
A
Well,
you're
you're
kind
of
moving
forward
right,
you're
kind
of
saying
new
clients
will
know
what
we're
trying
to
do
is
protect
the
old
clients
and
I
think,
I'm
just
kind
of
asking
a
more
fundamental
thing.
If,
if
we
expect
to
be
able
to
innovate
here,
we've
got
to
have
some
kind
of
versioning
and
differentiating
capabilities.
We
can't
just
keep
on
forcing
clients
to
guess
and
if,
depending
on
how
many
older
versions
or
clients
to
john's
point
of
you
know
internal
tools
that
people
have,
if
they
start
breaking,
then
maybe
that's
not
a
bad
thing.
H
H
Convert
easily,
and
so
if
I
ship
a
new
image
with
this
new
thing
that
I
can't
backwards,
convert
from
it
will
necessarily
break
old
clients,
and
that
that
seems
okay
to
me
and
you
know
just
because
it
is
possible
to
backwards
convert
from
z
standard
it
doesn't
I
mean
I
understand
why
docker
is
concerned
about
storage,
space
and
stuff,
but
I
don't
work
for
doc.
We're.
A
A
H
A
There,
it
is,
there's
been
some
debate
on
whether
anybody's
actually
looking
at
it
or
can
it
even
be
changed
yeah
I
mean
I
really
just
think
that
we've
got
we.
We
know
enough
about
the
innovations
in
beau
is,
if
I'm,
if
I'm
reading
his
name,
pronounced
right,
it's
kind
of
touching
on
this
as
well.
We
need
to
be
able
to
have
a
versioning
scheme,
otherwise
we're
just
locked
in
you
know:
stone
tablets.
H
And
I
guess
my
claim
is:
we
are
lucky
in
this
case
because
you
can
convert
between
the
two
formats,
whether
you
do
it
on
the
fly
or
not
they're
kind
of
interchangeable,
but
someday
they
won't
be,
and
so
like,
I'm
thinking
of.
If
I'm
you
know
a
person
who's
deciding
which
image
to
ship,
maybe
I'm
just
gonna
decide
I'm
only
gonna
ship,
these
standard
images,
because
you
know
I
only
want
people
to
use
new
clients
or
whatever
I
mean
it's
a
way
to
encourage
people
to
upgrade.
F
F
F
F
We
can
leave
the
oldest
image
format
of
basically
the
standard.
One
is
the
lowest
common
denominator
that,
if
you
you
can
always
ship
a
copy
of
that
as
well,
so
that
your
things
portable
and
then
you
can
share
the
newest
image
format
with
the
new
features
for
the
new
clients,
and
you
can
share
both
these
at
once,
and
you
probably
never
need
more
than
two
because
the
ones
the
people
in
between
they
can
use
to
use
the
old
one.
And
that's
you
know,
that's
how
you
know
that's
how
compatibility
should
work.
F
F
G
G
H
H
F
F
H
A
So
that
I
I
want
to
go
back
to
the
virginia
thing
I
mean
the
beauty
of
open
source
is
we
can
agree
on
what
we
should
be
able
to
change.
This
is
not
like
we're
trying
to
stuff
this
into
some
old
microsoft
or
old,
ibm,
fixed
thing
that
we
can't
influence
them
to
change,
we're
trying
to
use
it.
It's
like
we
have
this
body
here
specifically
designed
to
be
able
to
bring
the
community
forward
with
some
sense
of
stability.
A
I
mean
I,
I
know
it's
not
rocket
science,
but
I'm
just
saying,
then:
let's
do
some
fork
branch
and
kind
of
play
with
it,
but
if
we're
really
trying
to
put
this
into
the
core
ecosystem,
it
seems
we
need
to
provide
a
way
that
that
has
a
much
better
sense
of
stability
and,
if
they're,
using
some
client,
that's
five
years
old
at
this
point,
then
suck
it
up
and
get
a
new
version
or
don't
use
that
image.
I'll
say
that
also
like
we
played
this
thing
with
multi-arc
manifest
with
you
know.
A
F
I
So
there's
two
orthogonal
ideas
here:
there
is
changing
the
spec
so
that,
in
the
future,
clients
will
have
understood
behavior
so
that
we
can
actually
make
breaking
changes
and
understand
what
the
implications
of
those
are
and
then
what
docker
has
to
do
right
now
for
the
hub
is
related
to
the
pre-existing
clients
and
the
population
of
those
clients
what
behavior
they
have.
So
we
have
to
figure
out
what
behavior
they
actually
have
make
sure
there's
a
solution
that
they
can
use
to
make
sense
to
solve
this
problem
now
for
them.
A
F
Because,
again
like
then,
everyone
like,
if,
if
I
update
my
tags,
to
use
z
standard
in
my
you
know
in
my
qb
ammo,
then
so,
but
my
cluster
hasn't
done.
One
of
my
clusters
hasn't
updated,
yet
my
entire
thing
doesn't
work.
It's
just
testing
this
for
totally
broken,
I'm
not
I'm
just
like.
We
need
to
be
able
to
find
somewhere
synchronous,
we're
seriously
just
considering
whether
we
can
drop
v1
support
like
this
is,
we
can't
just
say,
yeah
we're
just
going
to
allow
people
to
push
stuff
that
doesn't
work
with
most
clients
like
this.
F
F
You
can't
choose
unless
you're
fully
in
control
of
every
everything
in
your
entire
tool
chain
in
a
distributed
system.
That
involves
lots
of
different
people
who
are
not
you,
it's
not.
It
doesn't
work
like
that
in
reality
and
reality
you
get
images
from
other
people
and
you
send
them
to
servers
that
belong
to
other
people
and
you
can't
control
which
things
have
been
updated
exactly
which
time
on
these
things.
It
just
doesn't
work
like
that,
but.
A
A
F
D
A
F
A
A
H
F
F
A
B
A
B
A
F
F
You
should
never
get
to
an
image
which
then
has
some
mime
types.
You
don't
understand
because
you
should
have
never
pulled
that
image
unless
it
was
not
a
manifest
list
and
under
controlled
circumstances
where
that
was
fine,
but
in
general
we
should
not
have
a
situation
where,
like
there's
stuff
flashing
around
that
people
download
and
then
explode-
and
you
know
that
kind
of
explains.
A
That's
right:
it
goes
back
to
the
stability
question,
so
it's
kind
of
like
there
needs
to
be
a
pivot
and
a
versioning
scheme
to
understand
how
to
do
this
pivot
and
I
think
there's
it's
not
just
utecho's
trying
to
get
this.
I
think,
there's
a
general
desire,
so
I
don't
think
that
we'll
be
trying
to
how
do
we
solve
versioning?
For
this
one
feature:
it's.
How
do
we
solve
versioning,
and
this
will
be
maybe
the
first
feature
that
uses
it
yeah.
F
H
F
A
A
A
A
C
A
C
E
J
F
F
I
F
A
K
K
K
We
have
come
up
with
a
new
nano
snap
shoulder
which
can
recognize
this
new
abuse,
the
annotations
so
for
our
internally
used
usage,
the
client
will
look
for
this
new
annotation
and
for
the
old
clients
which
are
not
going
to
know
this.
They
were
just
looking
for
the
old,
also
everyone
image
and
that's
how
we
do
it
in
a
compatible
way
and
besides
that.
K
Let's
save
a
lot
of
memory,
space
and-
and
another
case
I
want
to
mention-
is
that
we
also
support
different
storage
backend
for
the
both
bootstrap,
and
I
mean
the
metadata
and
the
data,
because
we
have
a
scenario
that
we
can
store.
Two
things:
sorry
we
can
switch
on
the
flying.
We
can
switch
the
bootstrap
and
blob
file
access
point
from
two
different
start
back
backend.
K
A
Yeah,
it's
cool.
I
just
want
timing
to
present,
probably
just
make
sure
you
get
early
in
the
list.
We
have
enough
time
to
to
cover
everything,
because
it's
definitely
cool.
There's
about
a
bunch
of
stuff
around
that
that
it
goes
back
to
previous
conversations.
We
want
to
do
a
lot
more
renovations
here.
D
K
Oh
yeah,
let
me
specify
a
little
bit
more
so
for
foot
for
content
for
starting
a
container.
We
need
to
first
download
the
bootstrap
part
to
local
file
system,
because
that
way
we
can
start
container
with
all
the
metadata
information
and
in
the
meantime,
we
will
download
the
data
part,
which
is
a
blob
file
from
object
storage,
which
has
a
higher
bandwidth
than
us
and
and
before
that,
before
that
downloading
completes,
we
will
just
use
the
nas
blob
file.
K
A
A
So,
just
for
the
sake
of
time,
because
we
always
try
to
respect
people's
schedules
for
other
meetings,
I'm
up
for
folks,
I
do
we're
getting
to
the
end
of
the
year.
Wrapping
things
up.
Some
people
want
to
continue
working.
Do
folks
want
to
have
a
meeting
next
week
and
then
cancel
the
christmas
and
new
year's
week,
so
we
set
proper
expectations
or
people
want
to
keep
meeting
and
there's
recordings
for
people
that
want
to
take
time.
F
D
F
A
So
here's
what
else,
here's,
what
I'll
do
and
we
can
I'll
put
next
week-
leave
it
open
and
people
want
to
put
an
agenda
I'll
leave
it
open
before
people.
Do
I'm
not
going
to
submit
mine
and
then
I'll,
just
post
the
week
of
23rd
and
30th
yeah,
23rd
and
30th
as
no
meeting
with
the
following
meeting
on
the
6th
of
january.