►
From YouTube: OCI Weekly Discussion - 2022-11-17
A
B
B
A
B
A
D
B
E
B
E
B
Yeah
so
hello,
hello,
everybody
today,
I
already
was
in
this
meeting,
but
I.
Don't
think
I
only
remember
Brandon
like
six
months
ago
or
so,
and
in
the
meantime
the
next
Community
has
been
thinking
out
quite
increasing,
with
increasing
intensity,
to
connect
some
of
their
good
stuff
to
the
good
stuff
that
the
oci
framework
is
offering
and
actually
that's
happening
in
multiple
Direction
and
Brandon.
I
just
recently
saw
that
you
did
a
s.
Slsa
implementation
go
for
NYX
and
I
was
like
well,
it's
that
the
same
render
yeah.
It
was
so
so.
B
Essentially
there
are
a
couple
of
forks
in
the
community
starting
to
think
out,
louder
and
louder
about
a
way
how
we
can
incorporate.
Maybe
the
Nyx
well
not
actually
Nick's
way
of
doing
things,
but
how
we
can
incorporate
mix
into
the
oci
layer,
semantics
and
last
time
we
have
been
discussing
a
little
bit
like
okay.
What
are
the
characteristics?
Well,
mixed
layers?
Don't
ever
conflict,
so
we
don't
have
the
problem
with
overlay
of
s.
We
don't
have
to
compose
it
and
things
like
that
and
then,
but
then
there
was
I.
B
B
And
then
you
know
the
path,
and
it
has
this
weird
format,
which
is
reproducible,
which
is
called
Nar.
It's
a
tar,
but
it's
reproducible
by
just
removing
things
like
timestamps
and
these
type
of
things.
So
so
what
so?
Oh
give
me
a
second
I
need
to
close
the
window
here,
because
sorry
so,
but
then
John
said
hey
forget
about
this.
This
is
really
just
an
implementation
detail
and
we
don't
really
need
to
care
about.
B
So
what
we
are
actually
left
with
is
a
system
of
store
paths
that
represent
binaries
or
whatever
dependency
it
actually
is,
could
be
a
file
and
those
don't
conflict
ever
so
we
don't
have
to
deal
like
in
the
Run
sea,
for
example,
we
wouldn't
have
to
deal
with
the
overlay
assembly.
We
could
just
take
the
path
and
copy
them
once
over
the
other.
We
there
would
never
be
any
sort
of
conflicting
operation,
anything
that
would
have
to
be
removed.
It's
just
taking
a
bunch
of
store
paths
and
copying
them
into
the
image
granted.
B
We
wouldn't
have
a
typical
file
system
hierarchy,
but
that's
also
not
needed,
because
there
is
a
Twist
to
the
story,
namely
that
in
the
next
Spectrum
or
in
the
next
community
in
the
in
the
wenix
works,
there
is
a
patching
of
Library
loading.
So
all
binaries
everything
that
is
in
the
next
door
knows
how
to
find
things
in
the
next
store
and
doesn't
usually
depend
on
the
on
the
usual
file
system
hierarchy.
C
C
You're
saying
that
the
each
layer
would
report
as
being
non-conflicting
in
some
way.
Is
there
any
way
to
mix?
Is
there
any
way
that
you
would
mix
conflicting
and
non-conflicting
layers,
or
do
you
need
to
just
say
all
of
the
layers
I'm
about
to
give
you
none
of
them
will
conflict
or
is
it
like
certain
pairs
of
them?
You
know
these
three
won't
conflict,
but
they
might
conflict
with
the
fourth.
B
The
cat,
as
long
as
they
are
on
the
slash
Nicks,
they
can
never
conflict
except
some
other
malicious
actor
would
claim
that
namespace
on
the
file
system.
So
everything
in
slash
Nick's
wouldn't
conflict.
But
if
somebody
maliciously
decides
to
and
I'm
saying
maliciously,
it's
probably
a
strong
word
yeah.
C
C
B
Well,
we
probably
can
do
that.
However,
I
found
in
work
that
it
is
useful
to
have
a
such
constructed
image,
but
then,
when
it
goes
to
developers,
they
can
still
do
from
whatever
yeah
and
kind
of
do
their
thing
right.
It's
still
sort
of
there.
The
only
thing
how
they
would
connect
to
those
binaries
would
put
them
in
the
path
and
they
are
there.
So
yeah.
C
C
Okay,
that
makes
that's
I,
think
that's
the
thing
that
needed
to
click
in
my
head.
The
other
question
that
I
had
and
related
to
that
was
again
not
like
necessarily
maliciously,
but
probably
I
wrote
a
bug
that
two
things
do
actually
conflict,
even
though
they
say
they
don't
conflict.
Would
you
expect
the
run
time
pulling
that
trying
to
make
the
file
system
coherent?
Would
you
would
you
expect
that
to
fail,
or
would
you
expect
it
to
be
validated.
A
B
F
Yeah,
that's.
That's
me.
Sorry,
I
I
played
around
with
geeks
and
tried
to
try
to
create
a
container
out
of
the
resulting
store.
It
works.
So
I
guess
maybe
I
missed
the
previous
Parts
about
what
the
motivation
is
to
use
container
layers.
It
seems
to
me
like
you,
could
you
could
build
a
store
that
has
the
required
parts
set
by
an
environment
and
then
create
a
container
from
all
of
that
information.
B
B
But
then
again
we
already
have
that
data
as
binary
data
or
as
layered,
but
set
set
layer
type
data
in
the
cache.
So
it
would
be
a
whole
lot
of
d-duplication
and
obviously
it
would
as
an
ecosystem,
where
you
bring
both
ideas
closer
together,
like
I,
think
it's
very
valuable
to
get
the
next
folks
into
the
tune
of
oci,
because
it's
like
Docker,
it's
like
Enterprise.
It's
like
not
something
that
we
want
to
deal
with.
B
But
if
we
open
up
that
door,
then
it's
kind
of
a
lead
for
the
ecosystem
to
catch
on
that
hook,
and
it
probably
is
also
for
the
oci
community,
an
interesting
thing
to
think
about
non-conflicting
layer
type,
which
is
really
all
because
we
have
been
spoken
speaking
about
Greeks
the
other
time
we
were
thinking
about.
Okay,
can
we
make
it
somehow
Nick's
agnostic
like
too
agnostic
and
say
just
it
is
a
non-conflicting
layer,
so
it
could
would
have
produced
the
same
way.
F
F
A
D
Comparing
this
to
what
the
build
packs
are
looking
at
I
think
what
they're
seeing
on
the
next
side
is
instead
of
packaging
together
a
whole
chunk
of
code
since
they're
doing
individual
binaries
they're
hitting
the
layer
limits
when
they
start
to
go
through
it.
They
just
package
it
without
doing
anything
else.
Fancy
yeah.
F
D
Yeah,
so
the
goal
I
think
they're
looking
at
is
not
not
use
NYX
as
part
of
your
build
and
then
create
a
layer.
That's
got
all
the
different
components
in
there,
but
make
NYX
part
of
your
package
repository
and
so
that
you're
reusing
the
same
tar,
not
the
same
car.
The
same
individual
Nix
packages
across
multiple
of
your
images.
F
B
Is
that
is
essentially
what
we're
currently
doing
right
so,
but
it
yeah,
but
it's
it
sort
of
stops
short
of
a
really
good
embracing
integration,
which
is,
which
is
a
little
bit
of
The
Proposal
that
that
we're
putting
forth
here
and
I've
brought
John
Erickson
here
he's
the
core
maintainer
in
next.
So
if
there
is
anything
on
the
next
side
that
we
need
to
do
to
make
that
marriage
between
the
ecosystem
happen,
he's
probably
the
one
who
can
make
that
happen.
B
So
today,
I
wanted
to
kind
of
renew
that
interest
and
and
and
bring
bring
the
idea
forth
that
we
have
come
to
a
point
where
it
can
say
we
can
make
a
store
layer
that
is
completely
agnostic
of
anything.
The
only
predicate
that
it
would
have
is
it's
non-conflicting,
which
could
be
a
new
type
of
story.
It
wouldn't
have
any
knowledge
of
next
or
Greeks
or
whatever
it
would
just
be
non-conflicting.
It
would
have
where
to
fetch
things
and
where
to
put
them
on
the
file
system,
so
that
is
essentially
what
it
would
do.
B
A
A
So
if,
on
the
next
side,
we're
constantly
baking
everything
together
into
one
layer,
yes,
you
could
do
that,
but
I
think
that
would
mean
we're
not
getting
everything
that
oci
offers
and
we'll
have
our
own
sort
of
crummy
hand,
roll
flatten.
The
things
make
it
terrible
implementation
that
will
just
become
a
new
bottleneck
and
a
new
reason
to
be
tempted
to
do
everything
non-invented
here
again.
A
The
hope
is
that,
as
we
are
like
increasingly
fine
grained
without
compromising
on
sandboxing
versus
I
know
and
the
more
mainstream
World,
maybe
you've
got
like
very
fine-grained
basal
rules
but
like
extremely
coarse
grained,
Docker
images
you're
running
basil
on,
whereas
we
want
the
every
rule
to
be
its
own
sandboxing,
just
as
fine
grain
and
it's
likely
no,
no
two
of
them
have
exactly
the
same
dependencies.
So
there's
very
little
reuse.
If
you
do
bake
everything,
you
know
be
it'd,
be
wonderful.
A
If
oci
could
just
solve
that
problem
for
us
and
we
can
just
throw
at
extremely
fine-grained
layers
added
and
they
can
deal
with
it.
Maybe
that
is
just
something
that's
out
of
scope
for
oci
and
that's
fine
or
every
every
time.
I
say
OCR.
I,
suppose
I
mean
an
implementation
of
the
interface,
but
hopefully
that's
clear
but
yeah.
If
we
have
anything
that
that
the
sandbox
scene
in
Linux
is
not
too
hard,
but
that's
the
manipulation
of
the
data
that
were
most
naive
at.
D
Yeah,
what
oci
is
going
to
bring
to
the
table
is:
we've
got
three
main
specs
out
there.
The
distribution,
spec
I,
think
is
going
to
be
relatively
unchanged
by
what
we're
doing,
because
what
NYX
does
fits
very
nicely
within
our
CI
of
saying
push
a
blob
up,
pull
the
block
back
down,
possibly
when
we
change
the
Manifest
a
little
bit.
Maybe
we
have
to
touch
that,
but
hopefully
not
too
much.
D
The
image
spec
I
think
is
going
to
be
the
big
place
that
you've
been
looking
at
in
terms
of
how
do
you
define
these
layers
as
being
the
non-conflicting
layers,
and
so
how
do
we
change
their
respect?
To
be
something
that
you
can
use
on
your
side
and
the
the
other
half
I
really
wanted
to
ask
about?
Was
the
runtime
spec,
because
that's
the
one
that
says:
here's
how
you
take
this
image
you're
finding
out
with
this
manifest
and
all
the
description
and
turn
it
into
something
you're
going
to
run.
D
B
My
question
would
be
right
back
like
I,
assume
and
I've
seen
something
in
the
chat.
I
I
wasn't
I'm
on
the
phone,
so
I
wasn't
able
to
to
read
it
in
detail,
but
my
assumption
is
something
in
or
around
the
runtime
would
do
the
assembly
and
something
there
around.
There
does
the
overlay
and
the
overlay
is
probably
not
really
fast
so
or
it
is
at
least
compute
Cycles.
So
is
there?
B
I
I
think
compatibility
is
still
key,
so
we
shouldn't
kind
of
ignoring
the
value
of
overlay
and
just
as
said
before,
if
I
give
that
image
to
a
Docker
to
a
developer,
they
still
want
to
do
from
whatever
and
add
stuff
right.
The
traditional
way
it
would
just
be
a
way
to
really
do
the
next
base
image
really
cool
and
then
have
it
on
one
single
layer
and
maybe
leave
it
with
that
for
protection.
If
it's
okay.
D
Is
there
any
value
in
clarification
from
that
point
because
I
don't
know
the
answer
this
to
saying:
here's,
the
normal
layer,
here's
a
set
of
next
layers
where
it
packs
together
a
couple
things:
here's
another
normal
layer,
here's
another
set
of
mixed
layers
and
they're
distinct.
Or
would
you
basically
say
no
matter
what,
when
we
start
seeing
some
NYX
pieces
in
there
they're
all
going
to
get
conglomerate
into
one
layer.
B
G
B
E
And
it's
not
just
owned
by
the
runtime
there's
also,
you
know,
kubernetes
does
volume
mounts
and
that
into
that
same
root
of
us,
so
that,
and
that
would
also
be
applicable,
that
you
would
have
to
make
sure
those
volumes.
Don't
overlay
your
past
right,
hey
the
it's
sort
of
an
issue
of
permissions
and
what
kind
of
file
system
would
support.
You
know
half
of
it
being
overlay
and
these
paths
not
being
overlaid
now.
Would
that
be
set
up,
doable
I
think
you
get
you
got
Derek
on,
he
might
be
able
to
chime
in
not.
B
B
Sure
I
I
thought
I
thought.
Maybe
the
the
right
point
would
be
started
to
make
sort
of
a
pull
request
or
something
really
tangible
to
the
image
spec
and
think
really
about
what
it
would
mean
for
the
image
back
and
I
think
that,
naturally,
the
other
questions
would
come
up
and
be
directed
to
the
right
places.
D
It
might
be
a
good
place
to
get
the
discussion
started,
we'll
probably
hold
off
on
merging
it
until
we
can
start
to
see
someone
implement
it
on
the
runtime
site,
and
so
it's
going
to
be
a
combination
of
the
two
of
saying.
Here's,
a
change
of
how
we
Define
the
image-
and
here
is
someone-
that's
actually
doing
it
and
showing
that
it
works.
D
B
I
I
thought
maybe
a
way
would
be
to
take
the
run
time
and
make
a
patch
manage
that
with
Nyx
in
our
infrastructure
and
see
how
it
goes.
Then,
if
that
patch
turns
out
working
but
I
hear
that
there's
containerdy.
So
if
I
want
to
Target
really
roll
out
of
this,
it
looks
like
I
would
be,
we
would
be
looking
at
run,
C
and
continuity.
No
wait
just
continually
right!
D
D
B
Okay,
well,
this
is
good
because
I
know
some
people
in
Nicks
have
already
started
kind
of
thinking
about
this,
but
probably
being
shy
of
showing
up
here,
I'm,
not
done
not
you!
It's
I,
don't
know
the
name
that
a
chat
a
couple
of
days
a
couple
of
weeks
ago,
so
so
I
I,
guess
also
a
little
bit
of
John.
We
can
probably
take
back
the
oci
folks,
they're,
really
welcoming
and
friendly,
and
it's
it's
no
big
deal
to
show
up
and
discuss
things
here.
F
B
F
That
actually
was
something
I
appreciated,
because
that
was
my
biggest
problem
on
trying
to
move.
The
conversation
further
is
that
the
learning
curve
for
Nicks
and
Geeks
is
very
Steep
and
because
well
Geeks
in
particular,
the
code
is
written
in
scheme
and
what
is
it?
Is
it
the
Haskell
that
it's
based
on
the
functional
programming
language
I
forgot.
F
F
Yeah
so
I
mean
so
the
learning
curve
received.
First,
you
have
to
figure
out
like
the
functional
programming,
functional
programming.
You
have
to
know
functional
programming,
then
you
have
to
know
how
you
write
the
definitions
and
then
you
have
to
figure
out
like
how
to
put
them
together.
I
worked
with
the
Octo
too,
so
in
the
end,
it
ends
up
being
really
complicated
and
I.
Think
what
you're
looking
for
from
oci
and
just
the
container
space
is
to
make
that
easier
for
folks
to
adopt
and
use.
B
That
right,
yeah
and
probably
plus
plus
that
from
the
oci
perspective,
I
mean
on
the
next
side,
I
think
it's
80,
000,
plus
already
packaged
binaries
with
recently
up-to-date
sources
and
everything
keeping
itself
updated
and
from
gooig
side
I
think
it's
another
20
000.,
so
that
would
probably
even
beat
Alpine
or
whatever
is
currently
the
name
of
the
game
in
terms
of
up
to
date
and
availability
and
wealth
of
packages.
It's
really
astonishing
I
think
next
is
currently
the
most
up-to-date
sorry
mixed
packages.
B
F
Yeah
I,
don't
see
any
of
the
chain
guard
folks
here,
but
that's
precisely
what
they
were
doing
with
the
Wolfie
is
use
Alpine,
binaries
and
assemble
them
together
to
form
like
root
assesses
for
a
certain
purpose.
But
what
we
found
out
like
three
years
ago
is
Geeks
pack
does
basically
the
same
thing.
The
only
issue
is
that
you
have
to
convert
from
like
slash
the
new
slash
stored
into
a
file
system
that
the
runtime
understands.
I,
guess
you
know
Linux
or
you
have
to
I
put
in
the
chat.
F
B
Yeah
yeah,
some
sometimes
binaries,
have
hard-coded
assumption
about
the
file
system
hierarchy.
Sometimes
it's
working
without
it
sometimes
yeah
Brandon.
You
said:
maybe
it's
as
simple
as
I
thought,
maybe
maybe
there's
a
way
to
say
we
have
a
non-conflicting
image
layer
towards
an
index
like
or
towards
a
prefix,
so
that
would
make
it
very
open
to
sort
of
any
other
non-conflicting
file
system
organization
out
there.
Besides
of
Nixon
saying
okay,
this
is
Celia
who's
going
towards
the
Splash
and
X
prefix,
and
everything
that
has
this
predicate
is
going
to
be
non-conflicting
amongst
each
other.
B
D
Yeah
I
was
thinking
on
the
lines
of
if
you
have
an
annotation
and
you
can
put
annotations
not
just
on
the
overall
manifest,
but
in
the
layers
within
the
Manifest
and
so
each
one
of
those
layers.
If
you
put
in
The
annotation
on
one
of
the
layers
that
said,
I'm
not
conflicting
for
the
path
slap,
slash
store
or
something
like
that
on.
D
To
create
for
this
and
the
runtime
conceived,
it's
got
four
or
five
of
those
layers
in
there.
It
could
assemble
all
those
into
one
of
those.
You
know
pseudo
layers,
the
end
of
the
you
know
on
the
image
down.
It
could
assemble
all
those
into
one
of
those
little
pseudo
layers
at
the
end
of
all
the
other
overlay
AFS
things,
and
that
way
it
knows
it's
not
going
to
have
any
conflicts.
You
know
if
something
in
the
base
image
puts
something
in
that
path
that
you
didn't
like.
D
You
would
have
right,
because
you're
you'll
be
the
last
overlay
on
top
of
everything
else.
So
I
feel
like
there's
potential
to
make
this
really
easy
to
implement
without
any
changes
on
the
oci
site.
Just
needs
to
have
runtimes
that
pick
up
on
that
annotation
and
sees
okay,
that
that
annotation
is
there
is
for
that
path.
Let
me
take
these
extra
steps
to
implement
it.
B
D
It
is
our
free
form
place.
You
can
put
things
that
already
exist,
it's
already
defined.
You
do
have
to
potentially
worry
about
other
people
using
it,
but
anything
is
under
their
CI
namespace.
We
technically
here
on
our
side,
so
we
can
say
what
that
means,
and
then
it's
just
up
to
run
times
to
pick
up
on
it
and
the
nice
part.
If
the
runtime
doesn't
pick
up
on
it.
B
A
B
F
A
B
One
interesting
fact
I
know
a
a
friend
of
mine
he
what
he
did.
He
made
a
base
container
image
which
just
Nixon
it,
and
then
he
just
faked
the
assembly
on
during
like
during
the
run
time,
so
he
did
that
inside
the
container
and
he
consistently
got
the
startup
times
down.
I
didn't
know
by
how
much
but
noticeably
so
what
he
found
is
that
this
is
can
be
actually
faster
to
to
start
up
and
the
only
conclusion
we
had
was
like.
B
B
D
E
B
E
B
But
by
the
way,
Mike
some
some
of
the
ones
who
have
been
trying
to
do
things
here
from
the
next
Community.
They
were
thinking
about
hijacking
sea,
junk,
C
standard
chunked
in
order
to
to
annotate
the
metadata
and
get
that
information
there.
And
it's
like
no,
no,
no,
let's,
let's
go
back
to
the
meeting
and
have
a
chat
first.
If
we
can
make
this
so
I'm
less
happy.
E
B
D
D
The
cmcf
is
over
on
the
or
sorry
container
D
is
over
on
the
cncf
slack,
so
multiple
slacks,
multiple
River
parties
here
from
coordinating
the
Nick
from
understanding
the
next
part
when
it's
assembling
all
this
together
is
my
understanding
correct
that
there's
like
a
next
store,
that's
on
the
local
machine,
and
then
you
collaborate
a
bunch
of
those
into
one
usable
path
or
something
like
that
using
hard
links.
Is
that
how
it
does
things
under
the
covers.
A
D
A
A
D
Yeah
I'm
trying
to
think
of
what
the
input
what
the
implementation
looks
like
when
you
try
to
build
those
layers
or
something
like
continuity,
and
if
you
can,
can
you
do
well?
Of
course
you
can,
because
you
can
do
volume
amounts
in
there.
So
I
was
thinking
the
overlay
FS,
combined
with
one
of
the
layers
that
has
a
whole
lot
of
buying
mounts
in
there.
I
think
that'll
still
work.
B
We
we've
been
doing
Brian
loans
kind
of
in
some
previous
implementation
for
the
nomad
runtimes.
Actually
it
was
then
spawn
I,
guess
yeah
and
do
it
just
fine
mounted
all
the
layers
into
that
thing.
One
one
benefit
of
sort
of
doing
that
about
that
I.
Don't
know
how
this
would
look
like
is
that
you
may
just
on
the
host
having
these
stores
also
stick
around,
and
then
you
don't
have
to
download
them
again,
so
it
kind
of
double
up
as
a
cache,
but
I'm
not
sure.
That's
already
a
case,
I
guess
so.
A
A
D
A
D
D
F
F
D
D
D
E
Yeah
that
that
one
entirely
I
get
the
more
we
talk
about
it
Brandon.
What
do
you
think
about
the
idea
of
actually
supporting
both
models
as
a
must
requirement
for
1.1?
In
other
words,
you
would
presumed
in
some
past
the
refers
API
isn't
going
to
be
supported
in
the
chain
of
mirrors,
for
example,
and
although
it
may
be
in
some
other
cases,
and
so
therefore
you
should
probably
be
required
to
go
ahead
and
push
that
that
you
know
the
refers
schema
image
index
in.
D
All
cases,
so
it's
one
of
those
things,
that's
pretty
easy
to
copy
on
a
mirror,
because
you
query
the
refers
API
if
it
exists,
you're
going
to
get
back
the
whole
index
and
if
you
are
now
pushing
that
to
a
mirror
that
doesn't
support
it,
you
query
and
say:
does
the
repairs
exist
so
I
see
the
info
I'm
looking
for,
if
not
push
that
refers
content
that
you
just
pull
down
from
the
Upstream
to
the
next
mirror
as
the
digest
tag.
So
it's
you
don't
have
to
do
any
translation.
You've
got
all
the
data.
E
The
it's
a
little
confusing
I
think
when,
when
a
client
is
first
writing
the
code
to
figure
out
what
it
means,
I
pushed
I.
I'm
writing
support
for
pushing
an
artifact
and
now
I've
got
to
go.
Call
refers
to
see
if
the
registry
I
just
pushed
the
1.1
artifact
to
supports
pulling
that
artifact
and
if
it
doesn't,
the
current
must
requirement
is
that
the
client
should
then
pushing
it
an
image
index
with
this.
E
This
is
being
pushed
as
well
with
some
tag
they
didn't
even
know
about
or
that
you
fail
and
require
the
user
to
create
this
image
index
with
a
new
tag
right
with
additional
client
tooling,
and
then
push
that
up.
So
they
can
pull
these
artifacts
they
just
created.
So
it's
a
little
it's
a
little
confusing.
D
E
E
D
So
the
the
response
should
come
back
and
just
the
fact
that
there's
response
and
that
it's
got
an
image
index
in
there
says
you've
got
the
reverse
working
and
if
we
ever
change
for
a
new
refers,
then
something
that
new
API
is
going
to
be
visible
inside
that
response.
So
you
query
the
same
thing,
but
something
should
be
different
in
that
response
and
I.
Think
Sanjay,
you
were
probably
the
one
that
was
talking
about
using
the
all-zers,
for
the
digest
is
that
right
am
I.
Remember
that
right.
H
Yeah
I
mean
that
was
one
way
to
kind
of
get
around
the
problem,
because
we
couldn't
query
the
registry
right.
My
suggestion
Just
go
with
it
because
the
spec
was
a
little.
Let
me
know
many
edge
cases.
If
the
repo
doesn't
exist,
you
have
to
check
for
a
substrate
score
called
error
not
found,
like
name
not
found,
which
is
there
in
the
spec.
You
literally
have
to
dig
down
quite
a
few
cases
to
figure
out
that
the
thing
is
not
implemented,
but
I
want
to
kind
of
like
raise
up
the
conversation.
H
We
have
tools
like
when
you
do
Google
version.
It
tells
you
the
server
version
of
what
it
is.
Is
there
general
interest
in
making
the
distribution,
spec,
support
and
endpoint
that
we
can
query,
irrespective
of
reference
or
not
and
just
kind
of
like
have,
because
there
is
a
magic
error
in
there
like?
If
you
look
at
it,
there's
a
Docker
version
1.0
in
there
somewhere
exactly
yeah.
H
So
can
we
should
we
standardize
it
and
we
have
these
quarks
right
in
in
these
implementations,
so
that
that's
what
I
want
to
kind
of
replace
it
up
to
yeah
it'll
benefit
in
general
that
if
1.1
is
supported?
Okay,
we
don't
have
to
do
anything,
and
this
API
can
be
a
Simple
Head
API
and
we
Define
all
clients
can
take
dependency
on
quick,
fast
and
not
depend
on
a
a
route
or
something
like
that.
I
mean
these
are
all
proposals
but
nothing's.
H
E
H
I
mean
we
could
that's
what
so
I
think
the
point
is:
should
we
form
or
improve
the
spec
to
ad
capabilities
in
general?
And
yes
before
the
pro?
The
other
thing
is.
One
challenge
that
we
face
during
implementation
is:
should
I
push
the
OC
artifact
manifest
requires
me
to
First
query
the
registry
to
see
if
that
capability
is
supported
in
the
workflow
forget
querying
the
thing
itself.
Just
creating
the
artifact
workflow
was
I
need
to
query
a
remote
to
kind
of
determine
my
workflow
and
create
the
content
like
if
I'm
on
a
build
machine.
H
E
You
know
down
down
the
road
and
I
just
wanted
Brandon
for
you
to
think,
or
at
least
discuss
a
little
bit,
think
about
it.
The
idea
of
requiring
backwards
compatibility
with
the
later
apis,
for
example,
this
one
one
go
ahead
and
require
the
push
of
the
index
because
of
the
cases
where
people
are
going
to
be
looking
for.
A
tag
refers
yeah.
E
D
D
The
the
registry
only
has
to
incorporate
what
was
in
the
tag
at
the
time
they
enable
the
API
once
the
API
exists,
then
there's
no
more
obligation
for
clients
to
maintain
that
tag
anymore.
We
never
said
and
I
think
it's
potential
for
our
registry
to
implement
this,
where
they
not
only
import
all
that
stuff
into
the
refers
API,
but
they
also
delete
the
tag.
E
Right
and
and
we've
got
a
1.6
LTS
that
doesn't
have
this
in
it,
but
we'll
probably
put
it
in
eventually,
which
means
we'll
have
a
1.5
release
of
container
D
that
doesn't
know
what
the
artifacts
are
at
all
we'll
have
a
1.6.10,
maybe
or
11.
That
does
right,
but
the
prior
version
won't,
but
some
people
are
using
it
already
to
pull
these
things.
E
It
just
gets
more
complicated
when
you've
got
multiple
versions
of
clients
out
there
and
sometimes
you're
supporting
you
know.
The
newer
client
is
pushing
something
that's
needed
for
an
older
client
right.
It
just
gets
complicated.
That's
all
I'm
saying
we
we
might
want
to
think
about
the
backwards
compatibility
issue.
You
know
for
other
clients
and
I
mentioned
mirrors
because
they're
in
the
path.
But
if
you
think
that
that's
not
a
really
viable
scenario,
then
that's
different.
E
E
H
Those
repositories
won't
have
capabilities
for
reference
API
now,
but
if
you're
pushing
the
other
registry,
you
can
use
the
reference
API,
so
composing
is
going
to
be
challenging.
So
maybe,
if
you
could
query
for
that
specific
repository,
the
same
way
like
for
refers
it's
kind
of
solved
in
some
way
right
like,
but
you
cannot
push,
or
maybe
someone
API
is
not
enabled.
So
all
I'm
saying
is
I
think
mirroring
is
challenging
unless
you
have
standard
way
to
kind
of
like
at
least
find
out
what
the
Caps
are
on
that
so
yeah.
D
The
pause
of
my
brain
was
realizing
that
you're,
going
from
like
a
pull
through
mirror,
rather
than
a
manually
maintained,
mirror
because
I
manually
maintained
mirror
would
have
been
super
easy
that
whatever's
doing
that
maintenance
copy
and
stuff
across
would
do
it
for
you,
but
yeah
pull
through
cash.
It
is
an
issue
yeah.