►
From YouTube: OCI Weekly Discussion - 2023-01-19
A
A
A
C
Looks
like
we've
got
a
decent
showing
who
put
the
second
item
on
the
list.
The
runtime
spec
issue.
C
C
And
I
I
think
the
answer
is
best
to
understand.
If
anybody
wants
to
take
a
look
at
it,
this
was
the
injecting
metadata
into
a
container
from
the
runtime
level.
D
Okay,
so
what
what
what
is
something
I
I
can
do
to
let's
say
rewife
this
issue
just
add
some
comments
there
once
again
or
what's
what's
a
good
cause
of
action
for
that.
C
We
can
I
think
we
can
ping
the
maintainers
on
the
into
that
issue
and
say:
hey.
Can
we
get
something?
Let
me
I'll
throw
that
on
there
right
now.
D
That's
awesome
because
I
mean
even
if,
if
the
answer
is
like
hey
this,
this
is
never
going
to
happen.
Then
I
at
least
know
like
this.
This
is
not
something
I
I
should
follow
up
on
right
and
maybe
think
more
about
different
approaches,
but
just
just
to
add
this.
This
is
really
painful
right
now
to
to
get
some
observability
things
running,
if
you,
if
you
have
have
a
situation
where,
where
you
cannot
pick
this
up
reliable.
So
that's
why
I'm
trying
to
to
figure
out
what
to
do
with
that.
E
C
A
That
one,
but
as
far
as
like
an
active,
you
know
core
folks
like
akahira
and
Cipher,
and
some
of
them
are
really
more
GitHub
based
occasionally
you
can
start
a
a
an
email
thread
on
if
you
use
the
maintainers
file
and
start
something
in
CC
Dev
at
open
containers,
you
might
be
able
to
get
a
thread
going,
but
it
does
seem
to
be
that
that
spec
particularly
tends
to
be
more
GitHub
focused.
D
C
C
C
D
D
C
I
keep
linking
people
into
this
because
I
see
this
request
coming
up
in
different
places
and
I,
say
well
put
some
attention
around
this
issue.
Give
it
a
thumbs
up
or
something
like
that,
just
so
yeah
the
maintainers
know
that
this
is
something
that's
wanted.
E
Awesome
yeah
and
give
me
a
ping:
we've
been
doing
some
correlation
IDs
across
the
stack
from
Google
it
down.
We
put
some
additional
stuff
inside
of
containers.
Well,
if
you'd
like
to
talk
about
it,
give
me
a
ping.
D
B
And
but
I
might
just
keep
talking
and
talking
so
I
start
I,
so
I
started
a
PR
and
then
I
realized
the
issue
needed,
refinement
and
then
I
realized.
It
was
probably
two
PR's
and
then
I
was
like
two
issues,
so
I
separated
out
in
the
issue
to
discuss
more
publicly
will
say
inadvertently
stepped
on
Brandon's
previous
observations,
which
I
did
not
mean
to
do
and
so
made
yet
another
post,
and
so
now
I
just
kind
of
want
to
discuss.
B
What's
in
that
issue,
I
do
have
PR's
started,
I
think
it's
two
I
think
I'd
like
to
decouple
the
capabilities:
endpoint
versioning
discussion
from
guidance
on
clients,
adopting
new
features,
I
think
we
do
have
an
abstract
thing
to
address
there,
as
this
is
the
first
minor
update
of
any
of
the
specs
great
time
to
do
it.
But
you
know
in
the
future
there
might
be
new
things,
so
I
think
it's
it's
good
for
us
to
tackle
this
and
I.
B
Think
generally,
my
observation
on
reflection
of,
like
your
concerns,
Brandon
in
particular,
was
really
that
it's
not
about
fallback
or
adoption
of
new
features.
It's
about
clients,
automating,
that
fallback
and
potentially
surprising
users,
so
I
think
that's
the
context
for
the
discussion
as
I
see
it.
C
Yeah
I
think
that
sums
up.
My
big
concern
is
that,
if,
if
a
client
automatically
switches
from
one
manifest
type
to
another,
that
I
see
a
lot
of
other
I
see
a
lot
of
client
use
cases
that
are
not
in
the
cloud
and
those
environments,
they
typically
have
a
registry
next
to
their
production
cluster.
That
registry
is
upgraded
last,
not
first,
and
so,
if
we
do
that,
we
automatically
change
from
the
the
image
manifest
to
the
artifact
manifest.
C
Then
those
artifacts
can't
be
pushed
to
the
registry
Associated
production.
Suddenly
they
start
losing
all
these
signatures
and
S
bumps
and
everything
it
production
relies
on
to
deploy
images,
and
you
have
an
outage
that
that's
kind
of
the
scenario
I
look
at
and
see
a
lot
of
out
there
in
the
in
the
field,
so
I'm
I'm,
trying
to
avoid
the
coming
train
wreck.
That
would
happen
from
this.
E
I
actually
work
both
ways
around
and
I've
seen
people
come
on
with
their
own
private
Registries
using
you
know,
new
stuff,
as
an
application.
I've
also
seen
them
used
at
default
registry.
You
know
associated
with
local
Registries
in
the
cloud
when
you,
when
you've
already
looked
it
up
to
your.
You
know
your
storage
system,
so
it
depends.
E
C
I
was
just
gonna
say
that
there
are
a
lot
of
different
scenarios
out
there.
This
was
just
one
of
the
big
ones
that
I'm
seeing
like
we're
we're
going
to
create
something:
that's
going
to
break
down
the
road.
It's
easy
enough,
not
to
break
it
and
so
shouldn't.
We
prefer
the
scenario
where
we
break
the
fewest
number
of
people
possible.
B
Well,
yeah,
so
I
think
I,
think
kind
of
the
the
I
think
the
discussion
has
been
around
you
know.
Do
do
do
clients
fall
back.
Do
we
promote
moving
forward
versus
that
that
real
central
question
of?
B
Should
we
guide
clients
to
be
very,
very
aware
that
if
they
automate
a
fallback,
that
means
one
day
they're,
you
know
their
producers
are
creating
certain
types
of
artifacts
and
the
next
day
different
types
of
artifacts,
so
conversation
again
from
Brandon
and
also
just
with
with
Sanjay
who's
on
the
call
here
in
a
different
context,
has
kind
of
swayed
me
towards
saying
yeah
as
a
spec.
B
E
B
E
B
I
think
I
think
before
I
kind
of
pull
Triggers
on
PRS
I
just
wanted
to
make
sure
they
weren't
going
to
fall
flat
or
be
totally
off
base.
So
I
think
I
think
that
what
we
could
tease
it
apart,
maybe
if
it
helps
so
I,
think
the
one
thing
that's
the
least-
maybe
the
least
nuanced,
but
maybe
still
controversial,
is
a
capabilities.
Api
endpoint,
I
I,
don't
think
it's
rocket
science
to
do
it
I,
don't
think
it
should
delay
us.
E
E
We
shouldn't
make
it
mandatory.
I,
don't
believe
I.
Think
Brandon's
initial
pattern
is,
is
a
good
mandatory
for
the
1.1
time
space
and
then
you
know,
as
we
go
to
1.2,
we
could
maybe
make
it
a
mandatory
API,
but
we
would
have
to
have
recommendations
in
code
that
the
one
would
support
the
1.1
plan
and
the
reason
for
that
is
because
we've
got
so
many
people
on
the
field
that
have
already
been
doing
artifacts
three
1.1
and
we
need
to.
E
G
B
E
C
The
direction
I
want
to
look
at
was
we
kind
of
worked
through
a
process
in
there.
That
said,
yeah
thanks
thanks
for
joining,
we
we
had
a
process
in
there.
We
were
saying
here's
how
you,
when
you're
interacting
with
the
registry,
if
you
try
to
query
this
thing,
here's
how
you
detect
it.
If
you
don't
see,
if
you
get
a
404
from
that,
you
know
that
that
refers
API.
Isn't
there
you
do
the
fallback
if
we
introduce
the
capabilities
API.
E
C
B
B
B
E
We
might
need
a
small
work
group
Jesse
for
it
because
of
things
like
proxies,
you
know,
maybe
the
artifacts
are
being
fooled
from
a
remote
location
with
the
same
password
depends
on
the
implementation
in
the
registry
right.
What
does
capabilities
mean
right?
It
capabilities
that
it
can
pull
or
capabilities
on
the
proxy
chain
to
the
back
end
or
capabilities
at
the
client
right
I
mean
we
haven't
talked
about
that
yet,
but
the
same
thing
May
apply.
Usually
when
we
do
an
API,
it's
we
look
at
it
from
two
sides:
right
notice.
E
A
What
I
was
gonna
ask
is:
do
you
have
a
link
to
more
of
this
capabilities
piece
because
not
that
I'm
in
any
ways
endorsing
its
use,
but
that
whole
extension's
end
point
and
well
in
a
way
that
people
could
make
extensions
to
the
distribution.
Api
yeah
was
partially
for
the
same
reason.
At
some
point
we
were
people
were
talking
about
like
how
do
you
query
the
server
to
see
like
has
it
implemented
certain
endpoints
or
otherwise
like
optional
or
extendable
endpoints?
A
Just
like
a
capabilities
like
flag,
it
does.
Is
it
able
to
do
certain
things
sounds
similar,
but
not
to
say
that
it
would
be
reused,
but
that
was
like
one
of
the
reasons
why
that
conversation
even
happened,
yeah.
B
I
I
do
remember
that
and
I
I,
it
kind
of
did
cross
it's
across
my
mind
and
I
and
again
I
talked
to
Sanjay
and
I.
Don't
know
if
he's
he
wants
to
contribute
here,
but,
like
I,
don't
mean
to
throw
you
out
on
the
bus,
but
we
did
talk
about
this
briefly
and
he
also
called
that
out.
Like
is
this
possibly
something
we
do
in
extensions?
Does
that
sort
of
violate
the
spirit
of
extensions?
Is
it
more
of
a
core
API
I?
B
You
know
this
to
this,
to
me
is
just
something
where
if,
if
some,
if
a
server
is
versioned
I
want
to
know
what
version
I'm
talking
to
as
a
client,
it's
it's
just
that
simple.
So
so
then,
going
from
you
know
from
there
to
say
well
what
does
that
mean
right
like
you
can
be
like
right
now
we
have
1.0
ish
Registries
right.
B
We
all
know
that,
like
we
have
one
wish
Registries
so
so
the
idea
is
to
have
a
little
bit
more
fluency
on
what
it
means
to
be
1.1
or
1.4
or
whatever
it
is
in
the
future.
By
adding
the
capabilities,
which
would
you
know
be,
you
know
effectively
like
maybe
manifest
types
supported
or
just
a
block,
you
know,
kind
of
Boolean
is
referrers
there
that
sort
of
thing.
B
So
a
client
could
optionally,
say:
okay,
it's
1.1
I'm,
going
to
use
1.1
spec
features
and
if
they
fail
then
I'm
going
to
open
a
bug
right
versus
it's
not
there
at
all.
I
may
assume
now
that
that's
a
1.0
registry,
that
seems
to
me
to
just
be
a
a
sort
of
yeah.
Like
an
obvious
thing.
We
need,
but
it's
obviously
not
obvious,
because
people.
A
A
B
Or
me
I
yeah,
it's
come
up
multiple
times,
I
I,
actually
thought
of
it
like
wait,
grab
a
bit
field
and
then
I
was
like
it's
because
I'm
a
sea
guy
from
way
back,
that's
dumb.
We
have
Json,
but
yeah
like
I.
B
Just
I
want
to
say
something
and
then
I'll
be
quiet,
because
because
Brandon's
hand
is
up
I,
all
of
that
sounded
right
and
I
don't
disagree
with
any
of
it
and
it
all
sounds
like
guidance
for
client
implementation
like
if
you
see
this,
you
may
assume
that
right,
but
it
doesn't
mean
that
this
is
like
a
magic
incantation
that
can
only
be
uttered
in
a
direct
way
once
right.
It's
it's
just
information.
C
C
Are
the
Manifest
supports
inside
of
some
capabilities,
API
and
say
query,
it
says
I
support
the
artifact
manifest
and
then
you
go
to
push
the
artifact
and
it
says
rejected,
and
it
rejects
it
because
it
doesn't
accept
an
artifact
manifest
because
it
has
a
subject
field
on
it
and
they
didn't
implement
the
subject
field,
and
so
they
don't
want
the
subject
field
and
so
yeah.
It
did
accept
an
artifact
manifest
if
you
format
the
artifact
manifest
just
the
right
way.
There's.
C
I
mean
I
I
did
contact
the
registry
when
they
did
that
and
said
hey.
Can
you
please
change.
B
C
Their
credit,
no
it
wasn't
you
to
their
credit,
they
did
work
on
they,
they
did
get
it
going
better.
So,
but
that's
kind
of
the
direction
I'm
saying
is
that
just
because
someone
says
I
support,
this
manifest
doesn't
mean
that
your
manifest
push
is
going
to
work
and
so
from
a
client
I
care
less
about
the
Manifest
list
that
are
supported
and
more
is
my
push
going
to
work
and
I
want
to
do
my
error
handling
once
not
two
three
four
different
times
throughout
my
code.
B
I,
don't
I
don't
want
to
turn
this
into
you
all
asking
me
questions
that
I
have
answers
for
like
there's
a
ton
of
people
here
like
I,
put
hands
up
or
just
come
on
camera
and
start
talking
to
that.
I
would
say
that
that's
not
new
right.
Like
just
talk,
you
know
again
not
throwing
anybody
on
the
bus.
You
don't
have
to
come
on
camera
or
speak,
but
toddy
wrote
A
Blog.
C
That's
kind
of
why
I
say
if
we're
going
to
add
this
feature,
I'm
looking
for
the
let's
spell
out
how
we're
going
to
use
it,
let's
not
just
add
a
feature,
because
a
new
feature
is
cool.
Let's
spell
out
here's
the
problem,
we're
solving
here's,
how
the
feature
solves
the
issue,
work
through
the
problem
and
not
just
say,
add
a
version,
because
we,
like
version
numbers.
E
Yeah
I,
don't
think
this
would
be
a
version
it's
more
of
a
when
we
have
a
should.
You
probably
need
to
have
a
bit
so
that
you
can
know
whether
the
registry
at
least
claims
that
that
which
decision
they've
made
on
the
should
statements
right
or
maze
like
you
may
support
you
have
to
put
support
pull,
but
you
don't
have
to
support
right
push.
C
B
H
H
The
only
thing
is
that
it
will
not
save
me
writing
some
code,
but
at
least
I
will
save
some
Network
calls
to
the
registry
if
I
know
that
something
is
not
supported
and
that's
how
I
I
look
at
that
right
and
on
the
client
side
will
be
like
okay,
if
I
don't
support,
let's
say
the
artifact
manifest
I
will
not
try
to
even
push
it
because
I
don't
know.
I
should
expect
error
right.
It's
already
clear
that
I
should
try,
expect
error.
H
It's
it's
having
some
Network
traffic
when,
when
you're
actually
know
in
advance
what
is
supported
and
what
eventually
is
supported
right,
it
may
fail
again
right,
but
instead,
like
making
five
Network
calls
and
try
this
try.
This
try.
This
try
this
until
we
figure
out
what
is
not
supported.
If
you
have
some
Advanced
information
yeah
for
sure
we
don't
support
those
things
and
I
will
know
to
not
try
five
things.
I'll
try
only
three
things.
That's
how
I
see
it
working.
B
Yeah
I
I'm.
Sorry,
it's
starting
to
sound
like
compliance
right
like
this
sounds
like
to
me
like.
Well,
if
you're
gonna
say
you
support
this,
but
you
don't
then
well
that's
a
compliance
thing
and
again
I
think
we're
veering
toward
then.
What
should
a
client
do?
Is
the
client
workflow
stuff,
so
at
the
risk
of
sounding
pedantic
or
like
I'm,
defending
myself,
I
just
want
to
say
like,
as
as
a
concept
do
do
we
do.
We
have
tangible
concerns
about
a
capabilities
endpoint,
or
are
they
more
related
to
well
what?
B
If
what
if
a
register
is
not
compliant?
What
should
a
client
do
with
that
information
like
because
I
I
mean
I,
hope
I
didn't
give
the
impression
that
I
think
this
is
just
cool
right,
I
see
a
problem
in
at
least
three
different
client
development
projects
that
are
happening
at
the
same
time.
I
see
I,
see
a
tangible
problem
in
that
they're
all
doing
what
toddy
described
or
have
to
right.
C
So
I
wanna
work
through
the
what's
the
problem
to
be
solved
first
and
how
we're
going
to
solve
it
before
we
say:
okay,
now
we
need
the
the
API
to
do
this.
So
I'm
I'm
working
the
problem,
the
other
direction,
instead
of
saying,
let's
start
from
this
API
and
then
how
can
it
solve?
How
can
it
help
everything?
Let's
actually
start
with
the?
What
are
we
solving
then?
How
do
we
solve
it
to
tati's
comment
there?
He
was
saying
you
know
you're
going
to
try.
C
There
are
not
a
lot
of
scenarios
that
I
think
we
have
doing
that
and
the
few
scenarios
we
have
it's
either
you're
trying
to
think
it's
works,
and
then
you
fall
back
to
the
fallback
and
it's
one
and
done,
and
so
you
would
save
one
network
call
by
not
doing
one
network
call,
and
so
it's
a
it's.
An
even
trans
is
an
even
trade-off
at
that
point.
C
You
might
as
well
have
just
done
that
first
Network
call
and
if
it
succeeded,
you
just
say
the
second
Network
call
in
that
case,
so
that
from
a
standpoint
it
feels
like
a
better
scenario.
If
you
just
start
right
from
the
beginning
and
just
say:
let's,
let's
take
the
happy
path,
try
to
see
if
it
works.
If
it
doesn't
work,
we
know
the
one
fallback
that
we've
got
the.
C
H
C
I
usually
start
if
it's
one
of
the
known
200
codes
and
I'm
happy.
If
it's
anything
else
and
I
just
figure,
it
didn't
work.
The
the
second
part
there
that
I
want
to
dig
into
you
know
I
was
freaking
is:
is
that
some
of
the
concept
of
trial?
How
long
list
of
things
implies
that
you're
going
to
push
an
artifact
or
registry
three
different
ways
and
I
get
that's
one
option?
C
The
other
option
is
I,
say
you're
only
going
to
push
it
one
way
and
it
doesn't
work
you're
going
to
fall
back
to
the
user
and
say
hey
your
registry
doesn't
even
work
with
that,
throw
there
right
back
to
the
user
instead
of
trying
multiple
paths
and
that
way
the
user
can
say.
Oh
I
tried
to
do
this,
and
the
registry
said:
hey
I,
don't
support
this.
C
You
should
have
used
a
different
flag
on
your
command
line
and
that
pushes
the
owners
back
to
the
user
to
actually
tweak
how
they're
shipping
and
interacting
with
the
registry
or
gives
them
the
concept
that
hey
I,
asked
my
tour
to
do.
One
thing
the
registry
doesn't
work,
maybe
I
need
to
upgrade
my
registry.
A
While
you
were
talking
Jesse,
the
almost
comedic
dovetail
was
you're
going
to
introduce
and
I
have
no
problems
with
the
capabilities.
Api
I
was
actually
for
it.
You
know
even
just
feature
Flags
or
whatever.
If
we
could
talk
about,
tie
that
back
to
conformance
and
have
like
here's
the
things
that
you
you
know,
we
do
support
like
unique
field
numbers
or
whatever,
like
here's,
a
Json
list
of
all
the
conformance
things
that
we
do
cool
great.
B
Yeah,
it
starts
yeah,
exactly
yeah
I
think
that
was
Mike's
question
I
actually
raised
my
eyebrow
with
that
I
think
I
think
we'd
have
to
say
they
must,
because
the
only
because
then
you
know,
then,
if
then,
if
it's
not
there,
then
a
client
may
assume
Capital.
All
may
assume
that
it's
a
1.0
registry,
if
it's
not
there,
simply
because
they
didn't
feel
like
it,
then
it's
useless.
A
B
A
I
think
we've
I
think
we've
danced
around
having
some
some
of
those
kind
of
like
musts
just
because
of
the
way
the
oci
and
all
the
different
projects
have
evolved,
but
it
might
be
that
it's
like
we
see
that
we
collectively
see,
as
you
know,
all
the
different
major
registry
providers
and
ability
to
talk
to
the
different
projects
that
have
registries
like
this
is
a
necessary
cleanup
or
whatever
so
I'm.
Just
saying
like
introducing
a
new
endpoint.
That
itself
must
be
mandatory
so
that
you
can
even
discover
this
kind
of.
I
I
was
just
going
to
say
that
kicking
it
back
to
the
user
ran,
which
you
said
is
not
always
possible.
If
we
have
an
automated
system,
you
can't
you're
not
going
to
have
a
user
in
the
loop
to
make
that
determination.
Every
time
we
need.
We
need
tools
so
that
our
systems
can
talk
to
each
other.
C
But
there's
error
messages
logs
yeah,
all.
C
B
C
B
But
that's
not
the
capabilities,
endpoint
discussion
and
on
that
discussion
we
have
talked
about
maybe
making
that
manual.
All
the
time
like
through
specification
so
that
again,
like
I,
think
we're
still
conflating
automatic
fallback
and
using
manifest
versus
artifact
images
versus
artifacts
I
that
I,
don't
I,
don't
understand.
Yeah.
E
B
I
E
I
I
think
the
answer
Brandon.
You
said
that
you
don't
want
your
clients
necessarily
automatically
of
letting
some
change
in
Behavior
due
to
capabilities
API,
but
that's
a
client
decision
right
like
if
I
choose
to
have
my
system
Implement
and
use
the
fallback.
The
fallbacks
are
not
a
must
right.
I
can
choose
to
require
that
my
copy
be
a
full
Fidelity
I'm,
going
to
copy
manifest
manifest
because
maybe
I
have
things
like
I
could
be
signing,
for
example,
the
Shah
of
the
Manifest,
and
that's
just
you
cannot
down
convert
that
to
a
image
manifest.
I
H
Yeah
I
don't
want
to
derail
the
whole
conversation,
but
we
also
had
some
discussions
of
just
providing
a
head
out
for
every
response
to
say
the
compliance
is
that
something
that
we
also
don't
think
will
be
useful.
Or
so
you
don't
have
a
separate
capabilities
API,
but
at
least
in
the
header
responses,
for
you
can
say:
okay,
I'm,
one
zero
or
1.1,
actually
1.1,
1.2
compliant
or
something
like
this.
B
Like
so,
you
can
just
do
a
get
on
V2
and
look
at
the
header
versus
again
capabilities.
Yeah
I
mean
Json
in
a
response
body
just
feels
nicer,
but
you
could
do
that.
I
think
we
I
mean
regardless
I
think
we're
still
hung
up
on
being
scared
of
what
clients
will
do
and
automate.
Based
on
this
information
versus
you
know,
presenting
the
information.
I
I
C
Yeah
and
it's
that's
kind
of
the
big
fear
that
I've
got
is
when
you're
walking
down
a
path
of
the
client
is
following.
A
workflow
client
is
saying:
I'm
trying
to
send
this
data
over
here
or
pull
some
data
from
a
registry
one
way
or
the
other
is
going
through
a
logical
set
of
steps
where
it's
going
to
hit
some
API
get
a
response.
C
Take
some
action
based
off
of
that
and
different
clients
could
take
different
paths
and
that
could
really
fracture
the
user
experience
from
users
down
the
road
and
so
I'd
really
like
to
start
with
the.
What
is
the
path
that
oci
recommends
that
everybody
goes
down,
because
we
we've
got
that
today
for
the
rest
of
the
spec.
C
B
I'm
going
to
look
back,
quick
I
want
Aaron
said
because
I
took
it
a
different
way
and
it
it
actually
literally,
is
the
same
description.
I
used
for
Desiring
a
version
and
not
a
capabilism
point,
so
I
first
floated
a
version
endpoint,
because
I
didn't
want
I
wanted
to
basically
have
a
register
to
be
able
to
say
I
support
version
1.2
with
a
spec,
not
I
support,
1.2
ish
of
the
spec,
and
these
are
the
ways
that
I
do
and
don't
so
that
I
mean
I.
B
That
I
think
that
a
lot
more
clearly
is
the
risk
there
and
I
I
appreciate
you
calling
it
out
when
I
think
in
and
I
I,
maybe
multiple
PR's
I
don't
know.
But
that
was
my
concern
with
capabilities
of
saying.
Well,
you
say
you're
1.1,
but
you
don't
have
a
refers
endpoint.
What
does
that
mean
right
that
that
things
start
getting
fractured?
I,
don't
think
things
start
getting
fractured
when
we
version
a
spec-
and
we
say
this
is
1.1.
This
is
1.2.
That's
not
fracturing!
That's
versioning
in,
in
my
opinion,
foreign.
B
More
than
half
an
hour
about
half
an
hour
into
this
conversation,
I,
don't
feel
like
we're
any
closer
I
feel
like
we're
still
not
even
closer
to
untangling
things
which
I
was
trying
to
do.
I
really
am
trying
to
decouple
the
concerns,
so
we
can
address
them
one
at
a
time.
I
would
like
to
say
for
posterity
that
I
am
thinking
about
the
user.
Experience
too
and
I'm
not
just
willy-nilly
suggesting
things,
because
they're
cool
and
they'll
look
good
on
an
album
cover.
B
That's
really
not
what
I'm
doing
I'm
trying
to
actually
reflect
the
experience.
I
have
in
past
protocol
and
line
spec
work.
This
is
how
we
do
it
so
having
kind
of
a
client
guess
what
it
might
be
able
to
do
just
seems
not
nice
to
me
and
and
again
like.
If
we
want
to
go
through
the
specifics,
what
happens
when
you
try
to
push
an
artifact
and
you
get
a
403
which
is
an
off
error?
It
isn't
I,
didn't
accept
that
because
it's
an
artifact,
it's
an
author.
So
what
do
you
do
there.
D
C
I
pretty
much
start
with
the.
If
you
don't
give
back
one
of
the
happy
200
codes
that
I
was
expecting
I
treat
everything
else,
it's
just
a
failure.
At
that
point,
you
know
oh
I'll,
give
the
user
a
response
back.
That
says
this
was
the
failure
I
saw,
and
hopefully
it
was
a
well-defined
failure,
but
I
treat
him
well
as
failures.
E
D
G
Which
is
why
I
think
the
version
proposal
makes
more
sense
than
a
capabilities:
API
I'm
caveat
I'm,
not
a
distribution.
Maintainer
I've
just
been
part
of
this
community
for
a
very
long
time,
because
if,
if
a
registry
says
I
support
distribution,
spec,
1.1
and
then
I
try
I
go
oh
yeah.
That
means
I
can
push
right,
so
I
go
push
and
then
the
push
fails.
That's
a
different,
like
I
I,
have
an
expectation
that
that
registry
probably
supports
oci
artifacts,
but
I.
E
G
Unless
it
knows
the
exact
payload
you're
trying
to
insert
you
can't
it
can't
really
tell
you
whether
or
not
it's
willing
to
accept
it,
because
you
might
check
that
the
registry
accepts
artifacts.
It
says
yes,
and
so
you
try
to
upload
100
gigabytes
and
it
goes
no
I.
I
won't
accept
that.
That's
not
reasonable
at.
H
Because
in
this
case,
you
will
get
like
403
right,
which
hopefully
every
registry
will
return,
that
and-
and
they
will
be
honest
on
that
so
I
think
we
should
not
mix
like
the
the
access
control
with
the
capabilities
right.
You
need
to
make
decisions,
also
on
your
Access
Control.
H
C
I
think
the
reason
that
the
author's
interesting,
though,
is
that
it
really
brings
up,
because
there
are
a
lot
of
different
reasons,
that
a
push
could
fail,
but
it
brings
up
that
I.
Think
what
we're
trying
to
do
is
say
that
before
I,
even
try
to
do
the
push
I
want
to
know
will
the
push,
work
and
I
think
what
we're
getting
at
is
that
you
don't
know
until
you
do
it,
because.
B
B
The
problem
is,
is
that
with
with
artifact
types,
there's
literally
no
way
to
know
now,
and
so
you
just
poke
a
registry
and
try
to
discern
the
truth,
and
you
still
don't
know,
that's
the
problem,
so
at
least
but
I
think
that
if
that
registry
tells
you
it's
1.0,
you
could
be
like.
Oh
they
don't
support
that
or
if
it
tells
you
1.1.
C
That
that's
the
big
thing,
though,
is
that
I
suspect
what
Mike's
going
to
say
but
feel
free
to
raise
your
hand
as
soon
as
I
say
this.
If
it's
not
is
that
a
registry
can
say
on
1.0
and
still
accept
an
artifact
manifest
there's
nothing.
E
E
But
when
we
run
our
conformance
test,
we
actually
have
a
table
of
how
they
support
right
and
I
in
in
some
respects.
Our
compliance
testing
with
our
conformance
table
is
already
a
capabilities.
You
know
API
if
you
will,
but
only
from
the
perspective.
If
we
run
it
and
these
things
did
work
or
don't
work
and
what
we're
sort
of
saying
is
well
for
some
of
these
shoulds.
C
The
challenge
I
have
with
the
version
number
is
I,
don't
know
how
I
can
use
it.
So
let
me
walk
you
through
the
scenarios,
because
this
this
is
what
I'm
trying
to
get
from
this.
C
B
C
But
so
walking
through
this
as
a
client.
If
I'm
writing
my
client,
if
I
create
a
registry-
and
it
said
I'm
a
one
dollar
registry
as
a
client
I,
don't
know
what
to
do
with
that
and
the
reason.
Why
is
because
they
may
partially
support
an
artifact
or
referrer
they
they
may
support
one
or
the
other.
Maybe
they
support
both
and
just
something
else
isn't
implemented,
but
I
don't
know
which
of
the
apis
that
I
want
to
try
to
run
against.
B
I
I
will,
for
the
purposes
of
my
own
feelings.
I
will
stop
replying
to
this.
You
have
made
that
clear.
You
have
said
it
before.
You
have
iterated
several
times.
I
still,
don't
understand
why
it's
a
concern
you
as
a
client,
developer
or
implementer,
can
build
whatever
you
like,
and
a
1.0
registry
can
do
whatever
kakamami
stuff
it
wants
to
do,
and
your
client
can
support
that
cockamami
stuff,
all
cool.
What
we'd
like
is
for
a
happy
path,
1.1
and
Beyond
to
have
a
clear
failure.
B
Mode
I
might
build
a
client
and
say
I'd
like
to
push
an
artifact
check.
The
version
It's
1.0
not
even
going
to
try
and
then
I
write,
just
clean
code
that
doesn't
that
doesn't
push
an
artifact
I,
just
use
fallback.
It
says:
1.1
I
push
an
artifact
I
expect
refers
if
it's
broken,
I
open
a
book.
That's
all
I'm,
saying
like
I,
don't
understand
why
that's
a
problem.
C
Because
that
and
honestly
I
feel
like
that's
important
Behavior.
If
a
registry
starts
to
support
artifacts
and
the
client
says,
I
want
to
push
an
artifact
up
to
there
with
artifact
manifest
I
feel,
like
you,
shouldn't.
Look
at
the
registry,
saying
I'm
a
1.0
registry
and
say
I'm
not
even
going
to
try,
because
all
the
inputs
in
there
were
saying
attempt
it
and
the
registry
is
saying
I
support
it.
I
just
don't
support
this
other
thing,
and
so
I
couldn't
put
the
1.1
personal,
my
registry,
because
it
didn't
have
it
there.
J
Hey
I
can
maybe
give
some
context
on
that
specific
conversation.
So
one
of
the
discussions
was
I
think
this
came
as
a
part
of
the
auras
implementation
as
well.
They
wanted
to
push
the
artifact
manifest
and
use
the
refers
now.
The
problem
is
when
they
try
to
work
with
Docker
Hub.
Once
you
push
the
artifact
manifest,
you
cannot
use
the
reference
API
right
now.
The
other
thing
is,
you
cannot
delete
the
artifact
manifest
in
Docker,
also
because
there's
no
delete
API
so.
J
Of
in
an
inconsistent
state,
so
what
I
recommended
was
check
the
reference
API
then
try
pushing
the
artifact
manifest,
and
that
way
you
have
a
clean,
1.1
implementation,
otherwise
use
emit
manifest
and
update
index.
This
might
be
one
option
if
there's
another
way
to
kind
of
like
determine
this,
maybe
that's
kind
of
the
motivation
for
hey.
Should
we
even
try
this?
Can
you
tell
us
whether
these
things,
this
New
Path
should
even
be
used,
is
what
a
client
can
quickly
fail
and
get
an
error
saying
that?
J
Okay,
this
doesn't
support
reference,
it
doesn't
support
artifacts
and
then
just
go
with
the
1.0
full
implementation,
which
is
using
the
fallback
or
you
go
to
a
person
artifacts,
the
hybrid
of
which
I'm
not
a
fan
of,
but
I
I.
Don't
think
we
can
escape
that
the
way
it
is
today.
Somebody
bought
our
facts.
Somebody
might
support
refers,
we
might
be
in
between,
but
which
way
do
we
want
to
go
I
just
want
to
kind
of
like
give
you
context
on
the
scenario
of
where
this
came
from.
That's
that's
awesome.
C
So
let
me
follow
up
with
that
scenario.
Can
Docker
Hub
ever
say
that
they're,
a
1.1
oci
registry,
even
after
they
add,
refers
and
the
artifact
manifest
because
they
don't
support
deletion
or
they
don't
support
some
other
API
that
we
say
they
need
to
support?
And
so
well
you
never
upgrade
to
the
new
capabilities,
even
after
Docker
Hub
adds
all
the
features
that
you
wanted.
J
I
think
that's
that's
a
question
for
the
registry
implementer
right
like
do.
They
want
to
call
themselves
1.1
in
the
iso
oci
or
do
they
want
to
say
that?
Yes,
we
support
all
these
apis
and
you
have
to
make
a
choice.
For
example,
we
don't
support
the
lesion
API,
even
though
it's
there
on
the
spec
there's
portion
of
respect
that
they
don't
support.
J
But
the
point
is:
if
clients
are
using
this
error
in
a
particular
way,
like
you
said,
I
totally
support
like
let's
call
out
the
use
case.
Let's
call
it
why
it's
necessary
before
we
recommend
the
capabilities
or
a
header
API,
that's
a
precondition,
in
my
opinion,
even
to
get
this
thing
moving.
But
these
are
the
scenarios
that
would
help
Define
why
the
header
how
the
header
would
be
used.
You
know
document
decides
that.
J
Yes,
this
header
is
used
in
so
and
so
away
and
so
it'll
help
clients
and
then
we'll
publish
it
as
1.0.
But
we
won't
allow
a
portion
of
the
specification
like
image.
Spec
extension
fields
are
not
supported
in
ECR
right.
That
might
be
an
implementation
thing
and
they
can
call
it
out.
As
a
caveat
as
these
portions
or
not
it
is,
it
is
up
to
the
client
in
some
way,
but
just
to
answer
your
question.
J
These
are
the
scenarios
that
I
see
as
why
the
header
might
be
used
as
a
quick
fail
and
quick
fall
back
and
don't
even
go
with
1.0,
because
we're
not
ready
yet,
rather
than
making
two
API
calls
right
now,
which
is
artifact
push,
plus
the
reference
versus
maybe
on
V2
and
you
ping.
J
One
of
the
options
that
I
suggested
was
actually
send
out
a
header
so
that
you
don't
even
try
this
other
path
and
you
can
catch
that
had
a
value
across
multiple
requests
across
like
you,
don't
even
prepare
the
artifact
manifest,
so
you
save
CPU
Cycles
on
that
you
don't
try
to
create
annotations
or
like
there's
options
that
we
can
use
for
this
perf
optimize.
If
we
have
some
indication
that
don't
go
down
this
path
across
automation,
because
if
you're
writing
to
disk
you're
wasting
time,
also
so
yeah
a
little
different
scenarios,
it
might
help.
C
Yeah
I
I
definitely
get
the
you
don't
want
a
third
chunk
up
to
register
you're,
not
gonna,
be
able
to
use
later
on.
My
the
fear
that
I've
just
got
is
that
Hub
is
going
to
upgrade
and
you're
not
going
to
support
their
upgrade,
because
you
don't
see
that
1.1
version
in
there,
and
so
it's
I,
don't
think
we
have
enough
detail
in
either
the
capabilities
API
and
especially
not
the
version
field
to
be
able
to
make
a
logical
conclusion
there.
K
H
Yeah
so
Brendan,
maybe
one
more
genetic
question.
So
what
I
hear
you
saying
is
that
Registries
may
or
may
not
support
something.
Is
it
our
expectation
that
there
will
be
no
common
set
of
functionalities
that
all
Registries
like
support,
because,
like
the
way
I
I
imagine
it
is
like
look?
H
I
I
have
certain
functionalities
that
I
can
expect
from
every
registry
based
on
whatever
the
specification
is
right
and
if
there
is
any
additional
functionalities
that
the
Registries
provide,
then
that's
fine,
then
I
can
do
all
this
magic
on
quitting,
trying
and
failing
and
and
so
on,
but
at
least
for
the
basic
things
that
we
put
in
the
specifications
they
they
should
be
expected.
Based
on
the
the
version
of
the
specification.
H
This
is
like
the
the
way
I
think
about
that
is
like
right
now,
I
am
feeling
in
the
situation
like
I
will
go
and
plug
in
my
my
laptop
in
the
outlet
and
if
it
doesn't
burn,
then
it
means
it's
110
volts
if
it
burns
it's
like
220
volts
right.
It's
that's.
The
trial
and
error
like
and
sometimes
the
trial
and
error
can
be
quite
expensive.
C
Yeah
I
saw
John
give
a
thumbs
up
to
your
original
question,
though,
and
I
suspect
his
answer
was
along
the
lines
of
it's
hard
to
have
any
registry,
give
you
a
guarant
it's
hard
to
say
from
the
from
the
oci
spec,
that
every
registry
must
support
a
certain
superset
of
everything,
of
multiple
things
or
whatever.
Just
because
so
many
Registries
take
just
a
slice,
some
Registries
are
push.
Only
some
Registries
are
pulled.
Only
some
Registries
don't
allow
the
tag.
Api
and
part
of
our
conformance
test
was
give
us
a
list
of
things.
C
H
F
H
Then
I
can
do
those
things
which
are
the
same
things
that
I
can
do
in
this
registry
and
this
registry
and
this
registry-
and
it's
not
the
superset
more.
The
common,
a
set
of
capabilities
right
I
understand
that
every
registry
will
support
different
things,
but
there
should
be
some
common
set
of
capabilities.
That
I
should
expect
from
every
register.
C
I,
don't
know
if
we
can
say
there's
a
common
set
across
everything
just
because
from
the
conformance
test
you
can
pick
and
choose
among
those
different
categories
and
say
this
one
I
want
to
test
this.
One
I
don't
want
to
test
and
we're
going
to
give
you
that
green
check.
As
long
as
you
passed
a
set
of
tests
that
you
want
to
run
for
a
certain
thing.
C
Yeah
I,
it's
a
good
question.
John
I
see
you
chat
and
I
see
you
give
a
thumbs
up.
I,
don't
know
if
you
want
to
chime
in
here
and
give
your
own
take
on
this
one.
C
H
Sorry,
just
to
to
kind
of
I'm
reading
John's
comment.
Well,
if
I
say
that
the
registry
is
one
zero,
they
are
common
like
capabilities.
But
let's
say
if
we
go
to
spec
one.
One
and
I
know
that
when
the
registry
returns
that
it
is
compliant
with
spec
one
one,
they
are
a
common
set
of
capabilities.
That's
what
I
meant
I'm,
not
saying
that
all
Registries
in
the
world,
like
one
registry,
will
be
complied
with
version,
one
zero
another
with
one
one
another
with
one,
two
and
and
so
on.
H
C
And
that's
where
it
gets
really
complicated,
because
in
the
past
we
very
much
said
that
you
can
be
oci
conform
and
not
support
the
tag
API
for
example,
and
so
you
couldn't
list
tags
on
a
registry,
even
though
they
are
conformed
with
all
the
other
1.0
specs
and
so
I
think
it's
hard
to
say
your
1.1
and
therefore
you
must
support
all
of
these
things
because
we've
never
done
it
in
the
past.
Okay,.
D
B
And
and
again,
not
not
part
of
the
proposal
right,
not
not
the
the
1.0
spec
is
so
loosey-goosey
is
to
not
even
qualify
as
like
RFC
quality.
Spec
right,
it
is
open.
Compliance
is
flexible
and
malleable.
No
one
has
suggested
that
if
you
report
1.1,
you
must
Implement
all
things
right
it
it.
The
question
is:
do
we
care
about
sanity
for
clients?
If
most
client
people
are
represented
by
Brandon's
voice,
then
the
answer
is
no,
and
if
nobody
wants
to
talk
about
this
anymore,
we
can
just
drop
it.
B
E
B
E
B
E
Okay,
I!
Don't
care
if
it
takes
four
years,
but
how
do
we
get
there
right
so
that
we
can
have
a
little
bit
more
common
Rich
for
implementations,
at
least
with
respect
to
the
apis?
That
we
think
in
in
distribution
are
important
for
the
users
of
OCR
all
right
and
that's
both
sides,
Registries
and
clients
and
I,
think
I
think
that's
necessary.
E
We
want
to
use
these
artifacts
for
very
important
things
and
we're
going
to
have
a
lot
of
expectation
that
that
content
can
go
from
registry
to
registry
people
can
copy
things
down
and
then
replicate
them
back
up
to
another
registry,
and
it's
still
going
to
work.
Eventually,
we've
got
to
get
there,
I
think,
in
my
opinion,
it's
my
opinion.
C
K
Put
there
fine,
don't
worry
about
it.
Basically,
like
the
research
team
reached
out
to
me
and
said:
hey,
we
have
a
survey
around
the
state
of
Open
Standards.
If
you
want
to
weigh
in,
please
weigh
in
the
end.
K
Get
to
the
knock
down
drag
out
heated.
This
group
gets
clearly
it's
very
exciting
still.