►
From YouTube: 2019 08 14 - Weekly OCI Developer's Discussion
Description
Distribution Spec (Derek)
Artifacts TOB discussion (Steve Lasker)
https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#August-14-2019
A
A
D
All
right,
I,
don't
I,
don't
really
have
a
too
long
of
a
discussion.
I
see
who
was
on
the
call
today,
okay,
yeah,
there's,
there's
a
few
issues:
I
opened
up
in
the
distribution
spec,
yet
it's
set
for
a
little
bit,
so
I
think
it's
time
to
try
to
talk
about
where
stuff
is
at
and
I
have
some
specific
change
that
I've
added
as
well
as
notice,
some
things
that
need
to
change
before
we
get
a
version
out
there.
So
let
me
start
with
the
more
general
stuff
so
Vincent
you
already
lgt
him.
D
There's
kind
of
a
big
fat
sign
right
in
the
middle
of
the
spec.
That
says
basically
ignore
everything
past
this
point,
because
it
may
be
wrong,
so
resolving
that
I
think
is
something
we
should
try
to
get
done
as
soon
as
we
can
as
soon
as
we
can,
especially
if
we're
talking
about
doing
an
RC.
So
there
was
there's
some.
There
was
one
related
to
blob
patching
that
had
been
sitting
in
the
container
de
backlog
for
a
while
that
somebody
pointed
out
so
I
went
and
I
opened
a
PR
for
that
and
then
John
Johnson.
D
That's
who
point
out
right
yeah
pointed
out
that
this
isn't
the
only
place
where
that's
wrong
so
really
need
to
take
a
pass
through
the
header
or
the
the
front
section
or
I.
Don't
know,
there's
like
that.
There's
a
detail
section
that
the
second
part
and
then
there's
kind
of
the
definition
section
at
the
top
for
the
in
section
as
we,
the
source
of
truth
and
the
detail
is
supposed
to
just
be
that
detail
to
see
now
exactly
exhaustively
what
what's
in
the
protocol.
So
it's
that
detail
section
that
isn't
necessarily
correct
today.
A
D
So
I
mean
these
are
these
are
pretty
small
to
pretty
small,
but
basically
it
forces
today
that
some
some
registries
may
send
one
return
code.
Some
registries
may
send
another
and
then
clients
just
end
up
saying:
oh
well
as
long
as
it's
like
between
200
and
300,
then
whatever
so
in
some
cases,
that's
fine
from
a
client
perspective,
but
there.
D
Where
the
there's
a
difference
between
whether
or
not
like
it
created,
was
returned
or
an
accepted
like
when
you
create
a
new
like
upload,
I
created,
would
mean
like
a
successful
like
cross
repository
amount
or
as
like
an
accepted,
would
be
okay.
Now
you
can
start
uploading.
So
there
are
a
few
cases
where
that's
really
important,
so
we
don't
want
people
just
ignoring
it,
just
because
it
may
be
wrong.
Okay,.
A
A
E
A
Because
that
was
even
one
of
my
questions
almost
like
how
various
projects
have
like
he
has
on
his
manifest
tool
project
like
run
this
to
see
if
the
remote
registry
can
even
support
what
you're
trying
to
do
it.
Just
some
some
kind
of
check
for
for
that
is.
We
do
have
a
basic
test
and
there's
more,
we
need
to
merge.
A
D
A
Basically,
I'm
wondering
either
a
can.
We
merge
this
now
or
do
we
want
to
say
because
those
that
that
number
39
is
also
just
needing
review.
So
a
lot
of
this
is
just
like
basically
to
give
this
to
an
RC
and
a1
dot.
Oh
I
think
we
just
have
to
breathe
enough
feet
from
this
furnace
to
get
stuff
moving
for
it
again.
I
think
everybody's
going
to
slow
to
a
crawl
myself
yeah.
D
D
D
Yeah
yep,
that's
fine,
I,
don't
when
I
don't
think
we
need
to
predicate
getting
the
PR
in
on
that
I
think
we
should
make
a
general
pass
through.
Maybe
maybe
we
need
like
a
three
three
columns.
One
is
what
we
just
need
to
enumerate
all
the
end
points.
We
need
to
say
what
what
status
code
is.
It
is
it
defined,
as
in
the
top
section,
what
status
codes
is
it
defined
in
the
details
section
and
what
status
code
is
the
test
using
just
make
sure
those
are
all
the
same,
see
what
I
mean
it's
like.
D
A
D
A
A
E
A
A
D
F
F
F
Happens
to
the
teeth,
the
registries
they
didn't
implement
it
are
they
not
compliant
because
we've
included
it
and
what
we've
audible
added
api's
to
our
registry,
so
catalogue
just
happens
to
be
basically
it
once
it's
becoming
a
reserved
one.
That
says
it's
a
reserved
one,
but
if
you
implement
it
great,
if
you
didn't
you're
not
incompatible,
it
basically
says
it's
fine.
We're
gonna,
do
something
different
as.
F
H
F
F
E
Considering
the
fact
that
lake,
but
people
would
get
in
woman
and
I'll,
do
it
differently,
it
I
can
agree
with
that
statement.
So
it
makes
little
sense
to
me
even
like
including
optional
and
giving
their
prior
description,
because
nobody
even
follows
that
really
they
love
your
caveats
for
reserving
it
just
to
click
the
nail
on
the
coffin.
A
A
A
D
F
F
Okay,
so
we'll
strip
the
catalog
portions
put
a
reference
to
catalogue,
say
it's
reserved,
maybe
I'll
put
it
to
two
Jimmy's
previous
planner
I'll
put
a
note
and
those
that
have
implemented
catalog
API.
Should
you
know
or
I,
don't
know
what
the
right
words
I'm
sure
you
get
lots
of
thing,
but
effectively
is,
can
keep
it
it's
just
by
reserving
it
or
saying
that
distribution
will
not
implement
something
on
top
of
it
in
the
future.
Right.
H
H
F
We'll,
if
we
can
get
I
think
that
where
we
left
the
other
part
of
it
is
if
we
can
get
some
agreement
and
we've
had,
you
know,
obviously
a
ton
of
progress
on
the
other
one
and
so
forth.
If
we
happen
to
get
the
other
one
done
by
the
time,
the
one
oh
spec
is
complete,
we'll
trim
it
in,
but
we're
not
gonna
hold
up
the
one
oh
spec,
for
whatever
the
new
thing
would
be
agree.
A
H
H
D
And
then
the
last
one
is
that
Mearing
section
added
PR
this
one's
kind
of
weird,
because
it's
a
feature
that
having
to
kick
off
for
like
multiple
years
are
unable
to
implement
because
they
may
lack
recitation.
So
we
kind
of
deferred
putting
it
in
the
specification
when
the
distribution
spec
was
going
to
OCI,
and
there
was
some
discussion
I
think
it
was
one
of
the
first
issues.
I
opened
up
on
distribution
made
sure
that
we
get
that
in.
Yes,
is
one
of
the
fungus
open
one
issue.
D
We
have
open
now
the
idea
of
it's
pretty
simple,
that,
like
there's
no
way
and
the
because
of
the
way
the
registry
or
the
clients
in
the
registry
communicate
today,
it
doesn't
actually
give
the
server
the
full
name
that
the
client
is
using.
So
if
you
were
talking
to
docker,
docker,
hub
or
Quay
or
any
registry,
the
registry
just
assumes
that
you
as
a
client
are
talking
to
one
end
point
and
the
registries
are
hard-coded
for
that.
D
So
that's
fine
for
most
use
cases,
but
for
the
case
where
you
want
to
actually
proxy
or
have
like
multiple
mirror
serving
one
location
or
you
want
to
proxy
all
your
traffic
through
a
through
a
cache.
Those
caches
don't
actually
know
what
upstream
you're
trying
to
talk
to.
So
you
end
up
in
this
weird
situation
today,
where,
if
you're
trying
to
have
a,
if
you
have
a
proxy
cache
that
proxy
cache
can
only
have
a
single
upstream
and
it
must
cook
behave
as
if
it's
basically
as
tries
to
look
like
that
upstream
and.
A
D
For
example,
yeah
say
you
wanted
to
have
a
single
cache
that
a
bunch
of
your
servers
are
using.
You
wanted
that
to
be
the
only
out
from
your
cluster,
so
you
want
to
you
want
a
proxy
just
like
you
would
with
like
an
HTTP
proxy,
the
HTTP
proxy.
You
contact
the
proxy.
You
tell
it.
You
know
where
to
open
up
the
connection
to,
and
then
you
would
continue
doing
your
proxy
today,
there's
no
equivalent
to
that
in
in
the
registry
API
other
than
just
using
an
HP
proxy.
D
D
This
was
one
of
the
reasons
behind
that
it's
kind
of
weird,
like
you
can't
just
there,
was
that
PR
for
like
having
this
really
complex
configuration
so
that
you
have
to
basically
enumerate
every
single
possible
server
you're
talking
to
and
then
have
a
like
a
one-to-one
relationship,
as
in
you
have
like
for
every
for
every
name
that
somebody
might
give
docker.
There
has
to
be
a
mere
associated
with
that.
D
D
So
there's
there's
kind
of
different
different
ways
to
solve
this
on
the
client.
One
is
that
you
fully
enumerate
everything
and
just
assume
that
such
a
server
that
can
cache
for
multiple
up
streams
doesn't
exist
or
you
can
just
pass
in
the
full
information
which
that's
all
this.
Does
this
basically
defines
an
optional
query,
parameter
where
you
can
say
you
know
this
is
the
is
the
namespace
that
I'm
working
in
here?
It's
docker
IO
or
it's
quite
a
Oh,
use
it
or
don't
use
it
it's
up
to
the
server.
F
Read
from
our
point
of
view,
we
we'd
like
to
see
the
mirror
being
more
robust,
but
I,
not
my
remembering
of
this
area
was.
It
wasn't
completely,
didn't
support
anything
within
docker
hub,
so
I'm,
not
sure.
If
you're
asking
is
this,
should
the
spec
be
completed,
or
should
we
just
close
it
out
because
we're
we're
just
trying
to
get
to
a
100
when
we
want
to
tighten
up
anything's,
not
complete,
you
just
be
pushed
out.
I
know.
D
What
I'm
suggesting
here
is
that
this
really
should
be
since
it's
something
that
is
optional,
we
should
get
it
in
so
that
it's
defined
how
it
can
be
used.
Otherwise
it's
it's
going
to
force
clients
to
want
to
implement
this
and
we're
trying
to
implement
on
container
D
to
basically
define
something
and
just
use
it
and
then
yeah.
We
can
just
do
that
and
then
try
to
merge
it
in
later.
As
I
said,
it's
it's
optional,
so
it
doesn't
really.
It
doesn't
no
requirement
that
a
server
implements
it,
but
I
mean
it
to
me.
D
H
H
A
D
I
think
a
lot
of
the
conversation
was
more
at
a
higher
level
than
than
the
specifics
like
Jimmy's
question
wasn't
necessarily
related
to
the
details
of
it,
but
just
kind
of
about
the
general
use
case.
So
I
think
maybe
there's
some
questions
about
use
case,
and
if
this
section
and
there's
kind
of
not
defined
in
a
use
case
very
clearly,
then
it
could
add
confusion.
E
E
The
clients
have
no
idea
that
this
is
even
the
case
so
like
that
has
more
complexity,
basically
in
their
registry
out-of-band,
that's
not
in
the
Specht,
but
that
work
could
potentially
be
just
because
they're,
considering
that
the
spec
is
not
something
that's
actually
malleable,
right
and
I.
Don't
think,
there's
anything
like
concrete
there.
Yet.
E
D
E
D
Into
yep,
I
think
from
from
that
perspective,
yeah
making
adding
the
feature
that
you're
describing
would
be
kind
of
difficult
in
terms
of
like
the
spec
change
just
from
a
line
on
this,
maybe
maybe
that's
enough
to
implement
the
feature,
but
it
sounds
like
there's,
probably
other
things
or
other
features
that
are
doing
in
that
mirror.
So,
for
example,
users
are
explicitly
specifying
this
mirror
I.
D
So
it's
like.
We
have
this
functionality
and
the
open
source
registry-
it's
kind
of
weak,
because
you
have
to
define
like
one
upstream
but
yeah
this.
This
would
basically
give
the
option
to
like
segment.
You
can
still
share
the
blobs,
but
you
could
segment
the
namespace
based
on
what's
coming
through
here
and
in
terms
of
like
what
you're
contacting
upstream,
that
all
that
stuff's
related
to
like
the
registry
implementation
I,
don't
think
the
stops
Jimmy.
E
D
I
think
we're
I
think
where
you
guys
could
leverage.
This
is
if
you
wanted
to
do
like
a
catch-all
through
Quay.
You
could
use
this
to
basically
proxy
everything
through
your
registry
and
then
at
that
point
you
know
you
can
map
that.
If
you
have
specific
mirrors
or
specific
versions,
you
could
do
that
or
you
can
pull
stuff
down
from
the
upstream
or
you
for
this
404
and
let
tell
the
client
to
go
directly
to
the
upstream.
So
it
really
just
gives
that
that
option.
D
E
I
mean
the
only
fear,
then,
is
that
everyone
implements
that
differently
in
in
fragments,
because
all
my
users
assume
that
Quay
does
the
whole
proxy.
Like
the
whole
thing,
acts
like
a
proxy
and
in
reality
we
just
have
a
subsection
of
repositories
that
are
configured
for
that,
and
maybe
like
people,
maybe
dr.
hook,
for
example.
Does
the
proxy
through
less
entirely
thing
and
then
there's
just
this
awkward
scenario
where,
like
some
registries,
are
basically
proxies
and
other
ones
are
manually
configured
for
repository,
that's
kind
of
definitely
user
experience
and
location
right.
D
Yeah,
so
this
just
gives
clients
that
that
option
to
do
that.
Just
said
like
it's,
it's
really
up
to
the
client
to
know
when
they're
talking
or
to
configure
their
clients
in
such
a
way
that
if
you
define
a
proxy,
that
registry
should
actually
be
a
proxy,
and
that's
kind
of
true
today,
already
like,
if
you
define
some
random
proxy
to
be
like
your
docker
hub
proxy,
for
example
like
there's,
not
really
even
any
checking
that
it's
going
to
do
it's
just
going
to
start
pulling
down
whatever
it
gives.
You.
D
Yeah
I
think
in
terms
of
just
like
the
extra
data
that
it's
it's
giving
it's
you
can
always
just
404.
If
you
don't
have
it
and
I,
don't
know
if
we've
defined
it
anywhere
in
this
in
the
spec.
Oh,
that
should
be
handled,
but
generally
404.
It's
up
to
the
client
to
make
a
decision
whether
it
wants
to
continue
looking
or
wants
to
stop.
If
you
know
that
what
you're
talking
to
you
is
a
proxy
and
you
and
you
have
other
options
that
404
usually
means
you
should
try
them.
A
E
The
thing
that
that
white
people
working
on
this
functionality
just
to
make
sure
that
they're
like
aware
and
can
weigh
in
opinions
to
make
sure
that
we're
comfortable,
could
I'm
sure
other
industries
like
Lasker
I.
Don't
know
if
you
have
opinions
on
this
like
if
you
guys
were
just
waiting
for
somebody
else
to
like
cement.
What
this
isn't
this
backer
or
anything
like
that?
No,
what
you
guys
are
currently
doing
with
your
registry.
F
Look
at
this
I
think
we
all
hit
this
problem.
I.
Think
the
question
is
whether
it's
a
client
side
with
the
server
side
to
me
want
to
do
blind
proxy,
and
should
it
be
some
kind
of
buffering,
you
know
if
somebody
pushes
a
bad
image
up
to
dock
or
hug.
Do
we
want
that
to
automatically
come
through?
You
know
so,
I
think
it's
an
interesting
set
of
scenarios.
We
should
just
work.
F
F
Just
so
you
know,
obviously,
we've
been
talking
about
this
for
a
while
when
I
first
did,
the
initial
PR
was
on
image
spec.
We
then
realize
it
probably
should
be
on
distribution,
because
we're
talking
about
how
we
were
implementing
additional
storage
and
distribution
and
then
first
I
think
we've
come
to
a
consensus
on
what
we'd
like
to
achieve
that.
We
do
want
to
be
able
to
support
different
artifact
types
in
side
of
distribution
and
for
the
most
part
we
can
do
that
with
the
existing
spec.
Using
the
same
manifest
for
image
and
index.
F
This
is
a
Tod
following
previous
process.
So
what
that's?
What
I've
done
so
at
this
point,
I
believe
what
we're
voting
on
or
having
a
discussion
on
is
opening
the
repo
creating
the
repo
so
that
we
can
actually
have
an
artifact,
Rico
and
then
I'll
take
the
content
that
I've
been
working
on,
that
buries
people
imbued
in
various
states
and
create
PRS
into
that
repo
that
talk
about
here's,
how
we
use
the
manifest
and
index
CMAs
to
submit
additional
types.
F
There
will
be
a
place
within
that
same
repo
that
people
can
submit
well-known,
artifact
types
that
will
define
here's
the
collection
media
types
that
they
subsume.
This
way
registries
can
easily
ingest
this
file
or
collection
of
files
that
that
part
of
the
PR
will
discuss
what
those
are
and
support
well-known
types,
such
as
helm
or
singularity
or
OPA,
but
it
also
leaves
registries
to
support
customer
specific
types.
If
your
particular
company
wants
to
support
something,
that's
unique
to
their
company.
F
The
registry
can
support
that
and
there
is
and
quote
a
well-known
type,
because
it
would
only
be
specific
to
that
one
customer.
So
that's
the
general
apprentice
and
the
discussions
that
we've
had
so
far
are
is
because
it's
not
a
spec,
it
won't
have
version
and
release
history.
It
will
the
way
I've
got
a
framed
right
now.
Is
it
will
rent
a
reference
versions
of
distribution
spec?
It
will
reference
the
versions
of
the
manifest
and
index
schemas.
So,
for
instance,
one
of
the
popular
conversations
has
been
if
we.
F
D
B
F
A
A
A
Not
quite
a
quorum,
but
I
can
we
can
discuss
now
I
I'm
from
what
I
have
not
intensely
followed
a
lot
of
the
the
pieces.
I
think
it's
fine
to
have
a
discussion,
or
at
least
a
recommended
approach
where
there's
those
from
things
I
still
think
that
it
would
be
as
it
would
work
its
way
into
the
distribution.
Spec
would
be
probably
eventually
some
API
had
added
in
of
like
the
client
asking
the
server
asking
the
registry.
A
What
pieces
that
it
supports,
like
I've,
told
Jimmy
I,
could
very
very
easily
imagine
this
being
like
a
very
simple
API
that
the
client
asks,
especially
maybe
once
they're
authenticated
that
any
registry
you
know
like
paid
registry
company
could
have
a
value-added
service
of
like
these
are
the
mime
types
or
media
types.
We
support
and
you've
authenticated,
and
you
can
push
those
to
your
account.
A
You
know
at
the
tier
that
you're
on,
but
if
you
want
to
check
this
little
box
of
enable
other
mime
types
or
arbitrary
mime
types,
then
you
know
at
a
dollar
a
month
or
whatever
I
don't
care,
but
some
little
API
would
be
like
the
next
step
of
that.
So
having
a
place
to
discuss
those
and
how
that
the
nature
of
that
behavior
works.
Sure
that
seems
fun.
E
E
Like
VMware
has
their
own
VM
image
and
Red
Hat
as
a
different
VM,
and
they
sure
like
OpenStack
or
something
like
that,
and
so
maybe
like
way,
doesn't
want
to
implement
the
VMware
image
because,
like
competitive
reasons
right,
that's
when
I
would
kind
of
fear.
For
for
for
that
exact
thing,
I,
don't
know
like
the
idea.
Is
that
hey,
you
just
wouldn't
emerge
anything
that
could
possibly
have
that,
but
then
that
couldn't
literally
be
everything.
E
F
To
be
fair,
what
we're
the
thought
process
today,
because
Jamie's
point
is
valid
in
peer
pressure
or
whatever
for
a
company
to
if
they
want
to
take
that
approach.
But
the
point
is:
is
that
the
the
clear
equal
Clearing
House
doesn't
necessarily
be
you
have
to
like
my
my
thought
process
so
far
with
me.
Here
are
the
well-known
types
that
you
can
if
you
want
to
import
them,
so
you
it's
not
just
that.
F
Here's,
the
media
types
that
you
open
up
to
your
filtering,
it's
the
media
types
themselves
are
not
human
friendly;
they
don't
have
icons
associated
with
them.
So
the
idea
is
here
is
a
way
to
have
a
namespace
that
computers
need
to
know
for
uniqueness,
but
humans
can
then
see
them,
and
then
humans,
you
know,
get
the
pretty
look
with
icons
and
so
forth.
It's
not
a
state
that
says
if
it's
in
the
repo
that
you
must
like
my
bill.
F
My
assumption
is
that
we,
the
appropriate
wording
and
says
you
can,
and
you
may
whatever,
and
that
here
is
a
schema.
Here's
a
collection
of
information.
What
I'm
going
to
look
at
mutations
I
have
a
proposal
out
there
already,
but
here
is
a
collection
of
those
media
types
and
for
each
artifact
type,
there's
a
collection
of
media
types
for
the
config
and
for
the
layers.
F
Your
registry
must
implement
version
through
dois,
but
the
approach
so
far
is
not
just
because
it
gets
the
media
tips
get
accepted
to
this
repo
that
Quaid
must
or
anybody
just
using
Cuevas
example
must
implement
anything
now
to
be
fair,
I
think
the
just
for
the
sake
of
what
we're
voting
on
here
is
where
this
one
we're
just
voting.
There
should
be
a
repo
that
we
could
discuss
and
have
documents
that
you
know
talk
about
this
and
I.
F
F
So
many
conversations
that
we
can't
get
anything,
and
so
I
was
thinking
about
what
is
the
MVP
of
what
is
the
first
PR
to
go
in
once
the
repo
was
created
and
I
do
expect
that
the
quote
Clearing
House
of
media
types
will
be
a
long
discussion
and
that
would
be
an
isolated
PRS
that
we
can
hook
this
conversation
on
it.
Well
other
things
in
the
phone
yeah.
E
E
E
The
idea
of
having
specification
in
a
place
where
people
can
like
are
gonna
create
over
over
that
I'm,
like
less
convinced
on
the
Clearinghouse
thing,
but
I
think
that's
gonna
happen
regardless
right,
there's
gonna
be
some
common
implementations
or
artifact
implementations,
so
I
don't
know,
I,
don't
and
in
a
place
where,
like
everybody,
has
all
the
features
across
the
registries
like
nobody
can
migrate
from
any
registry.
I
think.
F
Just
was
scoping
because
we
do
have
five
minutes
is
what
it
sounds
like
this,
and
a
couple
of
things
that
we
had
in
the
comments
on
the
pure
or
great
discussions
to
have
for
pr's
into
the
repo
that
we
would
create
for
today's
vote
can
be.
Do
we
agree
that
we
should
create
the
repo
and
then
start
those
conversations
on
individual
PRS.
G
D
G
G
A
E
A
C
C
F
Just
to
echo
something
mike
was
we
were
discussing
last
week
is
so
we
cannot
scramble
the
day
up
to
forego.
We
should
be
on
a
call.
We
were
gonna
move
with
the
process
that
a
week
before
or
I,
think
by
Friday
I.
Think
Mike.
You
said
that
the
Friday
before
the
Wednesday
that
will
have
an
agenda,
so
people
can
decide
whether
we
should
even
have
a
call
or
should
we
blocked
on
for
the
call
because
topics
are
relevant
to
us.
That's.