►
From YouTube: OCI Weekly Discussion - 2021-05-05
Description
Recording of the weekly OCI developer's call from 5 May 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#May-5-2021
A
B
A
It's
one
of
those
like
signing,
so
many
people
like
yes,
so
what
like,
what
really
changed
for
them
like?
Basically,
this
is
just
the
stuff
that
everything
that
works
for
cloud
native
works,
because
this
thing
has
been
there
for
several
years.
I
mean
it
is
part
of
kind
of
interesting
that
it's
a
unsung
hero
in
many
ways.
A
C
Cool
so
yeah,
I
mean
we've
discussed
this
one
before
I
went
ahead
and
I
talked
to
our
crypto
people
internally
and
discussed
the
other
models
around.
How
can
we
possibly
build
a
secure
mechanism
to
deduplicate
uploads,
where
there
is
a
mixed
model
of
trust
between
trusted
people
and
untrusted
people
that
have
access
to
the
same
registry
with
different
repositories
in
the
trust
model
being
associated
with
repositories?
C
They
basically
spent
like
an
hour
tearing
me
down
being
like
there's
no
way
to
do
this,
and
I
mean
they
came
up
with
some
more
esoteric
solutions.
Like
you
know,
you
talk
to
repo
a
it
gives
you
an
token.
You
pass
that
back
to
repo
b
repo
b.
Can
then
verify
that
token,
and
you
know
you
can
make
that
timing
attack
tolerant.
C
Unfortunately,
I
think
that
that
is
outside
of
the
scope
of
the
discussion
or
the
the
proposal
that
I
put
together
and
the
idea
there
is
just
that
if
you
had
a
special
parameter,
specifically
the
digest
parameter,
the
repository
would
respond
in
a
specific
manner.
That
would
say
this
blob
has
already
been
uploaded
and
give
you
the
location
of
that
blob
as
opposed
to
giving
you
the
accepted
and
then
the
upload
location
instead.
C
C
A
The
thing
that
so
we've
been
this
is
part
of
where
I
know
enough
to
know
what
can
be
done,
but
not
exactly
how
it's
implemented,
because
we
support
cross
repo
mounting
and
acr,
and
I
meant
to
talk
to
sasha
and
ask
him
how
we
were
doing
this,
because
what
I
thought
I
was
reading
you
suggesting
was,
if
I'm
based
on
alpine
and
I
push
image
one.
Can
I
push
image
two,
that's
also
based
on
alpine,
and
you
basically
want
to
share
the
alpine
layers.
C
I
think
that
the
idea
is-
and
this
is
this
is
the
way
that
the
like
docker
distribution
works-
is
that
the
blob
store
is
independent
of
the
repositories.
So
the
problem
with
the
current
cross
repository
amount.
Api
call
is,
you
have
to
have
built
off
of
alpine
in
the
repository
that
you
were
working
in
or
another
depository
registry.
Excuse
me
that
you
were
working
in
so
like.
Let's
say
that
you're
using
acr
for
everything
you
would
have
had
to
use
the
base
alpine
layer
from
acr
and
then
push
back
to
acr.
C
These
the
cross
repo
mounting
is
only
within
the
same
instance
of
the
registry
and
in
addition
to
that,
you
to
track
the
provenance
of
each
blob.
So
with
the
rise
of
like
stateless
builders,
they
just
kind
of
download
the
blobs
and
don't
really
have
like
a
database
to
say
where
these
came
from
our
specific
problem
is
someone
will
go
build
from
ubuntu
upstream,
which
is
like
pretty
tiny.
C
It's
like
two
or
three
hundred
megs,
and
then
they
push
a
layer
to
our
internal
registries,
and
this
means
they
have
to
re-push
those
those
layers
every
time,
because
you
can
actually
do
a
crosstreat
bomb
out.
A
There
so
I
was
trying
to
figure
out
is
that,
because
different
registries
have
different
auth
models
right.
This
is
the
the
one
of
the
things
that
we
didn't
get
standardized,
which
is
fine
right.
It's
part
of
the
differentiations
like
how,
if
they
have,
I
think,
questions,
and
maybe
it's
it
really
is
up
to
each
registry,
how
they
want
to
do
it
and
it
which
is
a
freedom,
because
if
there's
a
defined
easy
way,
then
different
people
just
the
same
way.
Storage
could
be
implemented
differently.
A
So
how
could
we
do
that
in
a
generic
way,
so
that
you
can
do
something
super
special?
If
what
you're
doing
is
unique
to
you
guys-
and
you
know
the
different
cloud
providers
that
are
serving
lots
of
customers,
whatever
can
do
it
in
a
way
as
well.
C
I
mean
so
in
this
model
it
addresses
the
once
you
have
accessed
the
registry,
you
have
access
to
the
entire
registry
use
case
and
it
also
serves
the.
I
have
access
to
individual
repositories
with
read
and
or
write
permissions,
but
I
do
not
have
access
or,
but
the
registry
is
not
trying
to
hide
what
information
that
it
contains.
C
So
what
you
would
need
to
do
there
for
in
order
to
support
that
auth
model
is
when
the
user
pusher
tries
to
do
this
dedupe
you
check
the
blob
store.
Does
this
blob
exist
in
the
bulb
store?
If
this
blob
exists
in
the
blob
store,
then
see,
if
any
of
the
other
repositories
that
they
have
access
to?
Have
this
blob
in
it.
D
Are
you
talking
about
cross
repo
deduplication?
D
I
mean
a
cross
registry
d
replication.
So,
for
example,
you
copy
a
blob
from
one
instance
to
another
instance.
C
D
A
C
Yeah
I
mean,
like
everyone
kind
of
mirrors
like
a
bunch
of
the
base
images
from
docker
hub,
like
I
think,
aws
ecr.
Does
this
now
google
container
industry?
Does
this
like
docker
distribution
has
a
feature
where
you
can
say
like
just
do
this,
but
the
user
might
not
have
their
from
being
that
registry.
C
So,
like
even
more
specifically
in
our
model,
we
have
six
registries
around
the
world
and
if
you
have
the
from
as
like
us
east
one,
and
then
you
try
to
push
to
us
west
too,
even
though
it
might
have
be
able
to
redo
it
like
there's
no
way
the
client
could
know
to
do.
The
cross
rebound
call.
A
So
that's
the
thing
that
was
transferred
because,
like
with
within
acr,
we
we
debated
that
whole
shared
cache
thing
and
then
people
scared
us
down
what
could
be
hacked
into
digest
and
the
layers.
So
we
actually
don't
share
across
customers.
Registries,
the
as
long
as
that
digest
is
available.
A
It
doesn't
matter
like
what
repo's
in
there
if
it,
if
that,
if
the
user
has
access
to
it
from
a
creds,
then
we
allow
it
to
be
deduped,
but
there
is
this
is
the
part
that
I
always
forget
I
have
to
double
check
is
unless
it
was
initiated
from
my
client.
Somehow
my
client
doesn't
know
so
it
actually
does
go
up
and
gets
tossed.
A
So
there
is
a
wasted
upload
of
that
blob
for
it
to
get
before
it
gets
de-duped,
and
that's
the
problem.
I'd
love
to
see.
If
there's
a,
I
called
it
a
handshake,
but
I
wasn't
trying
to.
I
was
more
referred
to
some
piece
of
data
that
can
go
up
and
say
nope.
I
already
have
that.
Don't
even
bother
sending
it
to
me.
C
I
mean
this
is
kind
of
why
this
is
why
the
digest
is
passed
as
part
of
the
uploader
initiation
and
when
you
pass
the
digest
with
the
descriptor,
the
registry
can
then
like
it's
effectively
the
handshake
it
just
needs
to
then
perform.
E
F
A
A
F
I
mean
so
so
they've
got
a
shot
and
they
used
it
right
and
then
we
duped
it
and
then
and
then
I
changed
my
mind
on
my
initial
push
right
and
I
and
I
in
my
repo
I
say:
okay-
make
this
private
now
and
yeah
yeah.
I
I
admit
that
there's
there
still
could
be
a
sha
out
there
living
around,
but
you
should
no
longer
be
able
to
log
in
and
use
it.
So
there
needs
to
be
some.
F
C
Data
I
mean,
but
this
is
the
way
that
distribution
works
right
now,
which
is,
if
you
do,
if,
like
I
docker
push
to
repo,
if
I
have
an
image
called
foo
and
foo
is
built
from
alpine
and
I
push
foo
as
foo
once
and
then
foo
as
bar
once
and
then
alpine
decides
to
go
offline
and
like
let's
say
they
take
their
repository
entirely
off
docker
hub.
That
blob
will
still
exist
and
be
shared
amongst
the
foo
and
bar
repositories,
and
it
is
unrevocable
in
the
current
distribution.
F
C
If
the
registry
needs,
if
the
registry's
blob
storage
model
is
tied
to
the
authorization
model
and
authentication
model,
that,
I
think
is
a
independent
thing
that
the
registry
can
do
and
it
isn't
like,
if
that
is
the
auth
model,
which
is
not
the
docker
distribution
off
model,
it
can
then
say
I
don't
want
to
support
this
feature.
Please
go
away.
A
And
when
it
says,
don't
support
the
feature
it
just
basically
reverts
back
to
what
it
would
do
normally.
So
it's
not
even
like
it's
a
failure
state,
it's
like
it.
If
I
push
to
the
same
repo,
you
know
the
mounting,
is
you
know
it
says?
Oh,
I
already
have
that
blob.
So
the
fact
that
the
blob
might
be
another
repo
that
I
have
permissions
to
is
a
totally
transient
state,
so
the
beauty
of
it
is
different.
D
G
D
G
So
the
case
that
sargon
is
pointing
out
here
is
say:
I'm
a
user.
I've
created
an
image,
that's
from
ubuntu
and
I'm
pushing
it
to
my
private
registry
and
now
let's
say
I
build
an
updated
version
of
it
in
a
completely
clean
environment
that
doesn't
have
the
old
image
and
I
push
it
to
the
same
registry.
Even
the
same
repository
namespace
that
ubuntu
layer
is
already
pushed
it's
already
there.
G
A
C
Yeah,
I
mean
there's
more
sophisticated
approaches
to
solving
this
problem
where
the
handshake
gets
progressively
more
sophisticated
and
allows
you
to
do
things
like
you
know
what
john
said,
which
is
like
how
do
you
avoid
the
or
like
how
do
you
deal
with
the
timing
attack
problem?
Unfortunately,
talking
to
like
our
security
folks
about
this,
it
is
really
hard
to
get
that
right,
especially
if
you're
operating
something
like
an
azure
or
gcr.
C
The
way
that
aws
solves
this,
and
you
know
any
aws
people
feel
free
to
correct
me,
but
at
least
the
last
time
I
looked
is
that
each
ecr
instance
is
dedicated
to
a
given
account,
and
that
means
that,
within
that
account,
the
s3
storage
is
also
dedicated
and
they
don't
do
things
like
share
blobs
between
different
registries,
so
that
kind
of
solves
the
problem
for
like
that
registry
model.
But
when
you
get
into
this
like
hyper
shared
model
like
gcr,
then
the
benefits
of
a
more
sophisticated
handshake
model
become
super
useful.
A
Unfortunately,
but
even
in
the
gcr,
because
it
sounds
like
we
do
the
same
thing
that
ecr
does
is
that
we
by
default,
don't
do
any
sharing
and
it
sounds
like
gcr
does
and
whether
it's
true
or
not,
the
point
is
that
allows
the
register
or
even
the
customer
I
mean
I.
I
would
imagine
that
a
customer
on
gcr,
if
they
wanted
to
say
I
don't
want
to
share
layers.
That
is
a
feature
that
they
could
choose
to
implement,
because
all
of
these
are
just
the
multi-tenant
services
where
we're
abstracting.
A
lot
of
this.
C
C
So
brandon's
comment
is:
you
can
automatically
dedupe
from
the
head?
Is
that
the
I'm
not
following
what
that
flow?
Would
look
like.
D
I
was
actually
going
to
ask
if
you
know
what,
if
the
client
checks
whether
the
blob
already
exists
before
pushing.
H
Yeah,
so
so
my
my
first
pr
as
a
professional
adult
was
to
change
doctor's
client
behavior
to
send
a
head
request
before
doing
anything,
for
reasons
that
you
may
understand
now,
so
just
to
clarify
gcr
does
not
deduplicate
blobs
between
projects
by
default.
Just
want
to
get
that
out.
There.
A
H
Like
single
tenant
versus
shared
multi-tenant
architecture,
which
I
think
is
what
certainly.
I
I
So
yeah
kind
of
to
put
you
back
on
what
john
was
saying.
If,
if
the
client's
already
doing
a
head
request,
I
feel
like
a
lot
of
the
stuff.
That's
in
the
pr
that
you're
putting
is
to
say
how
can
we
verify
that
you
already
know
the
content
of
this
digest
so
that
you're
not
just
putting
random
stuff
out
there
and
trying
to
get
access,
something
you
shouldn't
have
access
to
is
that
is
that
my
understanding
of
the
pr
that
we're
looking
at.
C
Is
so
that
was
the
original
idea
of
like?
Can
we
come
up
with
a
secure
way
to
do
that?
The
conclusion
was
no.
We
can't
come
up
with
a
secure
way
to
do
that,
but
you
do
need
some
way
to
say.
Do
this
cross
repository
mount
from
any
repository
that
I
have
access
to
and
as
a
client
I
want
to
be
oblivious
to
where
that
blob
might
come
from
just
make
sure
that
it
doesn't
violate
the
registry
authentication
model,
an
authorization
model.
I
Yeah
so
trying
to
bridge
the
halfway
point,
because
I
know
you
got
people
like
steve
over
there
that
wants
to
make
sure
that
everything's
private
nobody
has
access
to
anything.
You
could
potentially
say
here
are
the
public
things
we're
mirroring
a
bunch
of
stuff
from
docker
hub
all
the
main
library
images
that
everybody
uses.
I
H
I
think
that
violates
some
http
musts,
but
you
know
why
not?
You
could
also
have
some
protocols
that
says,
like
the
client
can
say,
does
this
exist
and
as
a
header
like
I
really
wanted
to
you
know
please
mutate
for
me:
I
don't
care
about
rfcs.
Alternatively,
the
registry
could
reply
like
it
does
not
exist,
but
it
does
over
here.
Please
send
a
mount
request
for
us.
Do
you
have
access
to
this
one?
You
know
something
like
that.
C
A
At
the
end
of
the
day,
the
beauty
is
digestion
unique.
So
as
long
as
you
send
the
digest
up,
the
registry
can
decide
whether
you
have
access
to
it
or
not,
and
you
know
to
brendan's
point
whether
or
not
there's
a
shared
mirror
aspect
or
not
or
a
team
that
that
company
has
made
their
layers
available
to
others.
The
point
is
that
does
the
customer?
Does
the
user
have
access
to
that
digest?
If
they
do,
please
don't
send
it
don't
waste
time.
A
H
H
H
Yeah,
the
the
you
can
do
it
on
head,
but
the
problem
with
that
is
you're
violating
rfcs
and
it's
not
clear
that
the
user
does
want
it
to
be
there.
They
might
just
be
doing
an
existence
check
for
the
sake
of
an
existence
check
if
you
do
it
on
the
post.
It's
a
clear
intention,
like
I
want
this
to
be
there.
You
know.
C
Yeah,
I
mean,
I
think
we
were
talking
also
about
eventual
consistency
models
previously
and
when
you
get
into
like
mutable
operations,
have
a
different
cost
model
and
a
different
consistency
than
read-only
operations.
H
I'd
be
in
favor
of
like
making
the
strong
parameter
on
prosper,
mounting
optional
and
maybe
just
called
mounting.
I
I
want
to
do
some
other
weird
things
with
mounting
that
I
haven't
proposed
yet,
but
that
seems
like
a
reasonable
path
to
go
down
because
it's,
it
doesn't
add
any
new
concepts.
It
just
kind
of
like
breaks,
one
into
two
sub
concepts.
H
I
was
thinking
if
you
don't
have
a
front
parameter
in
the
registry.
You
can
tell
that
you
have
access
to
that
blob.
It
just
does
the
mount
for
you
without
you
having
to
tell
it
where
it's
from.
H
H
Yeah
yeah,
I
clarified
that
too,
because
that
was
confusing,
and
so
this
is
very
consistent,
behavior
across
every
interaction.
So
I'm
in
favor.
C
H
C
A
C
I
mean
yeah
with
distribution.
We
can.
We
can
pretty
easily
push
up
our
stuff
here
with
the
the
like
distribution.
Behavior
is
pretty
liberal
in
terms
of,
like
you
forget,
to
put
parameters
in,
you
know,
usually
accept
it.
You
put
extra
parameters
in
you'll,
usually
accept
it,
the
behaviors
for
other
registries.
I
don't
know
how
they
work,
which
is
what
I'm
a
little
bit
more
worried
about.
C
C
I'm
kind
of
at
a
loss
of
what
to
do
or
like
what
even
to
test.
H
So
I
I
was
certain
to
make
sure
the
conformance
tests
expect,
like
a
failed
amount
to
return
a
202
continue
or
accept
it
or
whatever.
From
that
perspective,
I
think
registry
registries,
that,
like
don't
do
something
like
that
on
a
failed
mount
are
maybe
non-conformant.
You
can
maybe
use
the
spec
as
a
bludgeon,
but
I
think
the
best
thing
would
be
to
test
those
registries,
and
if
this
behavior
is
safe
across
most
of
them,
then
you
start
maybe
getting
this
in
the
clients.
C
I
mean,
if,
like
in
distribution
in
distribution,
you
can
set
like,
I
think,
actually
by
default.
If
you
don't
put
anything
in
the
odd
field,
it's
like
auth
is
off
so
like
if
auth
is
off
then
like
do
this.
If
auth
is
not
off,
then
be
conservative,
but
from
what
I
can
tell
most,
people
are
running
off
on
the
registry
off
and
they
just
have
a
thing
in
front
of
the
registry
like
an
aob
or
something
that's
doing,
ozzy
for
them
or
authentic
for
them.
Excuse
me.
B
H
I
mean
this
seems
reasonable
to
me,
especially
if
you're
only
changing
the
things
you
care
about.
I
might
open
a
distribution
proposal
to
like
soften
the
cross
street
by
mounting
stuff
a
little
bit
and
then
see
what
people
respond
with
and
like
what
implementations
will
be
broken.
C
Yeah
I
mean,
I
think,
like
I
I'm
just
reading
the
thing
there.
A
little
bit
definitely
saying
that
you
can
drop
the
from
like
the
from
is
optional,
seems
to
be
totally
reasonable.
J
H
We
want
to
drop
the
front
parameter
and
cross
repair
mounting
so
that
it's
optional,
so
that
you
can
ask
the
registry
to
cross-repromote
something
from
our
from
anywhere
as
long
as
you
have
access
to
it
cons
it's
susceptible
to
timing
attacks.
It's
there's
no
problem
other
than
if
you're.
If
you
have
a
problem
with
being
susceptible.
J
J
C
A
timing
attack
if
you
have
an
auth
z,
plug-in
because
the
first
check
you
do
is:
does
the
blob
exist
in
the
repository
and
then
from
that
blob.
You've
got
all
of
the
er.
Excuse
me
the
registry,
then
you
get
all
the
repositories
that
reference
that
blob
and
then
from
those
registries
you
see
if
the
user
has
access
to
any
of
those.
C
H
C
If
people
don't
think
that
it's
a
bad
path
to
go
down,
I
can
make
a
pr
formalizing
the
language
in
the
spec
unless
people
for
for
for
john's
reproposal
or
if
people
wanted
another
round
of
discussion
after
kind
of
drawing
out
the
issue,
I
can
do
it
depending
on
what
folks
want.
J
I
don't
I
don't
see
how
this
exposes
the
the
repo
set,
but
maybe
I'm
missing
something
I'm
I'm
looking
at
the
spec
right
now
to
refresh
my
memory,
so
you
sorry
you're,
arguing
that
it
would
expose
the
repo
set
from
by
waiting
for
that
access
check
on,
or
do
we
come
back
and
and
ask
the
client
for
more
access
checks.
In
that
case,
it.
H
A
But
it
is
something
it's
that's
also
a
timing.
You
can
do
that
you
can
make
sure
the
auth
is
enforced.
I
mean
we
only.
We
would
only
ever
expose
that
it's
available
if
the
person
has
access
to
it,
whether
it's
push
or
pull
it's
a
different
question
like
if
I
had
pull
access
like
I
should,
then
I
shouldn't
have
to
push
it
because
I
can
be
mounted
some
other
team
might
say.
Unless
you
have
push
access
you,
you
shouldn't
be
able
to
cross
free
from.
I
don't
agree
with
that,
but
that
could
be
a
decision.
C
It
specifically
problematic
in
the
case
where
you
might
have
like
either
censored
content
or
where
you
might
have
like
private
content,
that
you
don't
want
people
to
know
that
you
have
so
like
if
someone's
auditing
you
to
see.
If
you
have
like,
I
don't
know
oracle
in
your
registry.
J
But
don't
you
think
it
should
be
up
to
the
to
the
registry
owner
to
kind
of
decide
whether
that
they
they
want
to
expose
themselves
for
that
because,
like
like,
when
we
wrote
this
spec
around
the
time
like
concerns
about
exposing
information
about
the
existence
of
blobs
was
was
kind
of
a
that
was
a
hot
ticket
security
item
at
the
time
over
the
last
years.
I
I
haven't
seen
that
be
much
of
a
security
issue.
J
It
just
doesn't
it's
it's
more
theoretical
than
than
practical,
but
you
could
imagine
one
registry
provider
saying
well
hey.
You
need
the
from
parameter
to
make
this
work.
It's
it's
just
required
because
we
want
this
level
of
security,
but
you
can
imagine
another,
maybe
like
an
internal
registry
provider
where
the
where
the
the
client
set
is
a
lot
more
limited
than
say
something,
that's
open
to
the
public.
They
might
decide
that
hey.
We
want
to
drop
this
from
parameter
to
make
our
push
a
little
bit
more
efficient
in
our
infrastructure.
F
F
They
can,
you
know,
pull
by
shot,
unfortunately,
and
they
didn't
have
authentication
right,
it'll
just
get
cached
and
we're
about
to
push
a
pr
in
kubernetes
to
fix
that
hole,
and
now
it
sounds
like
it
might
be
opened
up
again,
but
as
long
as
as
long
as
we,
you
know
we're
making
sure
that
the
you
know
on
on
the
push
of
the
shot
that
they
add
original
authentication.
Then
that's
that's
fine.
F
J
Are
you
partitioning
the
tenth
of
the
tenants
by
the
access
to
the
poll
service
account.
A
A
F
J
It's
a,
I
think,
it's
a
parallel
problem
that
if
you
look
at
the
pods
and
then
the
registry
space
kind
of
in
the
same
regard,
you
can
accidentally
expose
the
blob
to
a
user.
In
both
cases.
B
I
just
had
a
quick
comment:
I'm
still
trying
to
understand
sargan's
proposal
like
in
depth,
but
with
what
john's
proposing
with
making
from
optional
does
that
kind
of
invalidate
some
of
what
you're
proposing.
C
So
the
the
the
seed
and
stuff
is
like
invalid.
If
you
look
at
the
comments
in
the
issue,
I
basically
state
that
our
security
folks
have
evaluated
that
and
said
that
it
they
have
a
counter
proposal
on
how
to
make
it
work.
The
counter
proposal
is
just
very
complicated,
so
the
I
think
that
the
successor
that
I
proposed
was
adding
an
additional
capability
to
the
standard
push
initiation.
B
C
I
can
I
can
create
a
pr
around
up
here.
I
guess
pr
for
distribution
with
this
and
what
so
I've
been
using.
The
google
registry
client,
but
I
know
the
google
registry
client
isn't
a
fully
fledged
client.
Is
there
a
preferred
client
for
like
reference?
Do
we
have
a
reference
client.
H
There
there
are
some
which
google
mine
go
container
registry
I'll
help
you,
if
you
want
to
use
that,
let
me
do
whatever
that's
fine.
C
Like
like
it
right
now,
it
says
the
front
parameter
should
be
passed
by
the
client,
but
I
think
they're,
just
dropping
the
from
requirement
would
make
it
so
that
clients
didn't
need
to
do
the
tracking
on
their
side
to
see
who
pushed
or
where
did
each
blob
come
from
yeah.
C
So
so,
like
first,
the
registry
would
have
to
relax
the
requirement
of
the
front
parameter
and
then
subsequently
the
clients
would
would
be
able
to
do
that
as
well.
D
Sorry
go:
go
ahead,
john.
D
Well,
I
I
don't
know
I
mean
I
may
have
missed
something,
but
I
figured
that
the
the
additional
metadata
that
we
were
adding
to
the
image
spec
would
account
for
trying
to
figure
out
the
provenance
of
the
images
such
as
the
base
image.
H
D
My
understanding
that
the
the
sagran's
concern
here
is
that
the
burden
is
on
the
client
to
verify
to
find
the
provenance,
but
I
would
figure
that
the
the
base
image
annotation
would
help
the
client
do
that.
C
People
aren't
necessarily
going
to
upload
like
ubuntu
or
not.
Ubuntu
is
about
example,
because
it's
like
a
standard
image
but
like
we
have
our
own
internal
standard
images
that
we
use
that
are
like
intermediary
images
like
we
have
a
go.
We
have
like
a
python
image.
That's
like
python-nflx,
that's
not
going
to
get
pushed
to
all
of
our
registries
that
are
our
production
registries,
because
that's
a
development
image.
D
C
D
Right
so,
okay,
I
see
what
you're
saying
this
is.
This
is
in
the
context
of
one
registry
that
you're
using
in
production,
yeah.
D
All
that
all
that
all
share
the
same
custom
image.
J
J
I
think
that,
even
if
you
filled
in
the
the
from
with
a
bunch
of
garbage
on
the
client
and
the
registry
still
mounted
the
bob
for
you
like
that,
would
be
sufficient
right.
J
I
mean
like,
like
noise,
like
you
know,
just
john
johnson's
typing
or
whatever
right
like
you
know,
just
keyboard
smashing
right
like
would
it
like,
if
I
did
that
if
I
said
mount
from
here
and
it
was
just
like
whatever,
but
it
performed
the
amount
like.
Would
that
endpoint
not
be
correct?
Oh.
J
G
H
My
my
reading
of
the
spec
language-
it
just
says
it-
you
can
do
this,
but
it
doesn't
say
like
it
must
also
include
the
front
parameter.
It
just
says
you
can
do
this.
We
could
clarify
that
front
is
optional.
I
don't
think
that
would
even
be
breaking
for
my
view
of
the
universe.
H
I
C
H
Yeah,
like
you
may,
you
may
want
to
still
do
the
head,
because
it's
generally
pretty
cheap
and
quick,
but
in
theory
you
could
only
do
the
post
like
a
bottle.
It
could
be
a
single
request
ever
which
would
be
nice.
D
C
D
C
I
I
don't
think
that
there's
any
problem
with
doing
the
head.
I
think
that
like
wasting
300
milliseconds
is
not
good,
but
I
think
that
the
head
definitely
should
not
do
it
right
because,
like
one
that
violates
http
specs,
two
that
definitely
just
won't
work
on
cloudfront
and
yeah,
just
it
like
from
a
registry
perspective
like
you,
should
not
have
to
do.
Read,
write
work
on
a
head
internally
within
the
code.
J
If,
if
I
get
ahead
and
speculatively
preload,
my
cash
like
eh,
like
how
bad
is
that
like?
If
it
knows
that
it
exists,
you
do
the
head
and
then
you
speculatively
preload
the
cash
and
then
when
the
the
get
comes
and
you're
serving
up
the
content.
And
you
block
it
while
you're
just
like
waiting
a
little
bit
for
the
content
to
show
up
like
how
about
that.
C
Oh
yeah,
I
mean
the
registry
can
can
do
that.
It's
just
like
for
the
most
part.
If,
if,
if
I
do
a
head
well
like
we
have
like
a,
we
have
a
lot
of
registry
instances
so,
like
that's,
gonna
be
icky
but
like
even
if
you
do
that,
then
the.
C
H
C
H
A
Sounds
good,
it
looks
like
ram,
did
post
something
for
zot
that
was
able
to
test
with
scopio,
so,
whichever
whichever
client
you
use
sounds
like
we
can
test
this
out,
the
distribution
is
easy
enough
to
make
changes
as
well,
especially.
J
C
In
progress
pushes
yeah
that
doesn't
happen
in
our
infrastructure.
Ever
I
mean
we
do
have
a
little
bit
of
tracking
about
about
it,
because
I
think
like
when
you
try
to
do
the
s3.
Recombobulate
call
it'll
fail
if
that
already
existed,
but
like
when
we've
looked
at
that
it's
so
rare
that
we
never
bothered
doing
anything
clever.
There.
J
Why
do
you
ask?
Oh
just
the
so
the
reason
we
didn't
really
do
this
like
upload,
so
we
didn't
allow
two
separate
clients
to
block
the
same.
Upload
was
just
because
there's
only
a
few
cases
in
which
they're
going
to
like
overlap
and
most
the
time
the
push
is
happening
in
some
sort
of
ci
system.
That's
serially
right
where
you'd
like
build
an
image
and
push
it
build
an
image,
then
push
it.
C
C
A
Yeah,
if
you
get
a
new
version
and
alpine's
kind
of
small,
but
if
you
took
like
ubuntu
and
if
your
new
version
ubuntu
that
gets
pushed
out,
then
you're
not
actually
storing
ubuntu
in
your
registry
that
triggers
two
builds
in
theory.
They
can
be
both
race
condition
for
who's,
going
to
push
the
two
layers
first,
but
it
seems
like
relatively
easy.
H
Can
I
can
I
steal
five
minutes
at
the
end
to
talk
about
my
thing?
Are
you
satisfied.
H
Okay,
someone
runs
up
earlier
and
so
I'll
talk
about
it
briefly,
but
I
was
planning
to
write
a
proposal
as
well
about
cross
registry
blob
mounting
in
my
head.
I've
been
calling
it
cross
origin
block
mounting.
H
Cross
registry,
so
for
a
lot
of
things,
this
doesn't
make
any
sense
and
a
lot
of
registries
have
a
single
host
name
like
say
docker
hub,
but
if
you
expose
any
type
of
variable
in
the
host
name
like
say
the
region
or
a
project
name,
you
can't
take
advantage
of
crosstable
mounting
at
all,
and
I
was
thinking
about
and
planning
to
implement
something
where
you
could
indicate.
H
I
am
trying
to
mount
from
this
other
origin
say
I
want
to
mount
from
us
west,
one
to
us
west,
two
and
the
registry
knows
it's
like.
Oh,
I
can
do
this
faster
than
you.
Let's
not
just
serve
you
all
these
blobs
for
you
to
give
them
right
back
to
me
and
it
kind
of
solves
a
similar
problem
as
just
dropping
the
front
parameter,
but
I
would
be
a
little
hesitant
to
mount
across
domains
entirely
without
that
without
a
hint
like.
No,
I
wanted
from
this
other
registry.
H
Yeah
yeah,
I
basically
just
don't
go
over
the
internet,
and
but
it
is
a
point-to-point
copy
once
instead
of
you
know,
serve
it
to
the
client
and
that's
a
common
answer:
let's
send
it
right
back.
J
Yeah
I
mean,
I
generally
think
features
that
can
service
some
sort
of
image.
Promotion
process
would
be
helpful.
I'd
like
to
like
see
what
that,
like
the
top
level
idea
for
image
promotion
is.
This
is
something
like
I've
kind
of
looked
at
over
the
last
six
seven
months
and
the
tooling.
J
There
is
not
not
great
just
because
you
have
to
do
this
like
pull
and
then
push,
and
the
options
are
basically
like
push
everywhere
before
you're,
ready
or
like
run
it
and
then
do
some
validation
and
then
push
it
up
when
you
do
your
promotion,
so
I
think
it's
an
interesting
problem.
I
I
don't
know
specifically
on
how
the
credentials
would
work
for
that
process,
but
I
think
if
you
can
get
those
two
pieces
right
and
get
it
semantically
in
place,
it
seems
reasonable.
J
We
can,
we
can
chat,
offline
and
and
get
you
know
some.
You
can
load
this
at
the
end
of
my
head
a
little
bit
more.
H
I'll
send
a
proper
doc
explaining
this
maybe
later,
but
I
just
wanted
to
float
that
into
people's
heads
and
get
him
excited.
F
Maybe
no,
I
just
don't
know,
maybe
you're
thinking,
maybe
if
we
had
our
host
tunnel
like
in
container
d,
we've
got
a
group
of
mirrors
that
you
could
do
a
push
and
then
some
have
some
new
api,
or
we
could
say
I
want
these
are
the
ones
we're
going
to
be
mirroring
on
pull
and
I'd
like
to
push
right
to
all
these
and
here's
my
off
for
each
of
them,
if
they're
all
in
the
right
in
the
same
domain,
like
docker
io
with
a
few,
you
know,
youth
caches,
that
sort
of
thing.
H
F
J
Hey
before
we
go
here,
I
just
wanted
to
say
hi
to
everybody
and
congratulations
on
the
1.0
across
the
board.
It.
It
really
looks
great.
I
I've
been
quiet,
I
know,
but
I'll
try
to
join
more
meetings
coming
forward.
I
have
I
have
this
blocked
off
on
my
work
calendar
now,
so
I
only
got
one
meeting
over
at
this
time.
So
that's
good.
Maybe
we
can
go
for
zero
meetings
next
time,
but
yeah.
J
Congratulations
to
everybody
and
it
looks
really
good,
it's
short
and
poppy
and
it
captures
like
the
original
intent
and
it's
a
good
base
to
build
on.
So
congratulations.
Everybody.