►
From YouTube: OCI Weekly Discussion - 2022-06-02
A
A
I
I
had
to
back
out
the
version
I
couldn't
go
with
the
latest
version.
A
B
A
D
D
Don't
distract
me
okay,
so
I
suppose
that
any
image
spec
maintainers,
no
no.
D
Is
it
something
like
if,
if
I
want
a
pull
request
to
be
merged,
and
there
are
no
image
spec
maintainers
to
take
a
look?
What
do
I
do
do
I
do?
I
bother
them
on
the
mailing
list.
A
D
I
know
that's
that's
why
I
asked
because
yes
github
sends
a
notification
asking
for
review,
but
I
think
that
is
too
spammy.
D
Yeah
and
it's
a
good
start
right,
let's
see
where
all
the
let's
see
where
all
the
hiccups
are
and
then
we
can
document
the
hiccups
and
then
we
can,
you
know,
have
a
discussion
with
the
tob
on
their
mailing
list
and
saying
like
okay.
So
here's
a
documented
dropping
the
ball
thing.
A
F
I
will
I'll
send
a
ping
to
stevo
he's
pretty
good
about
like
if
he
gets
a
thing
clicking
buttons.
F
Oh
I'll
do
I'll
hit
him
on
slap.
D
D
Did
you
did
y'all
reach
out
to
them
individually
or
like?
Are
they
in
a
channel.
A
D
A
A
A
E
E
E
A
D
E
A
E
A
C
E
A
E
Basically,
just
we
in
oci
land
for
some
reason,
with
some
of
our
apis
we've
always
liked
to
consider
what
are
the
weird
things
we
can
do
with
it
like
how,
when
we
did,
you
know
a
shy
api.
You
know
what
kinds
of
weird
shots
could
we
make
it's
just.
D
A
running
it's
a
running,
you
know.
A
C
I
can
give
up
maybe
one
conversation
that
we've
been
having
is
the
current
proposal
that
is
not
yet
submitted
by
docker.
That's
bringing
a
lot
of
conversations
right,
so
you
need
to
probably
like
get
something
written
up
and
have
people
follow
the
process
so
that
everybody
can
kind
of
sign
off
on
it
in
some
way.
C
C
It
it
has
changed
the
conversation
of
how
we
wanted
to
do
an
api
and
not
to
an
api,
and
I
think
it's
also
bringing
up
the
the
challenges
that
many
operators
don't
want
to
change
distribution
in
any
way.
That's
something
maybe
for
the
oci
itself
like.
Is
it
going
to
be
a
hesitation
in
any
kind
of
new
long-term
vision,
or
is
it
something
that
we
understand
as
status
go
and
stay
with
it
and
make
it
like
linux
abi,
where
binaries
are
going
to
be
always
compatible
those
kind
of
things?
F
Actually,
if
you
look
at
the
final,
the
very
bottom
comment,
like
I
already
started
thinking
about
sort
of
like
yeah.
I
put
this
together
yesterday.
I
I
was
like
back
and
forth
of
whether
to
just
put
it
up
or
not,
but
I'm
already
like
you
know,
I'm
already
like
looking
at
what
you
know
what
exactly
it's
saying
it
seems
it
seems
like
there's
special
case
for
signatures
and
everything
else,
there's
still
needing
to
be
some
sort
of.
F
But
I'm
just
thinking
about
ways
in
which,
like
this
is
not
going
to
scale
like
I
was
talking
to
jason
like
what,
if
you
have
something
that's
scanning
an
image
every
day.
Does
that
mean
that
you
have
an
index
with
365
times
number
of
scans
per
day.
E
A
One
way
is
all
the
race
conditions
is
by
saying
that
we're
gonna
push
everything
in
in
an
added
an
important
way,
so
that
each
different
manifest
out
there
can't
overwrite
each
other
all
going
to
have
independent
digest,
but
there's
still
some
way
for
the
registry
link
that
together
on
directory
site
or
by
looking
at
a
tag
listing
and
the
other
option,
is
to
say
no
we're
going
to
keep
mutating
this
index,
and
if
we
keep
mutating
the
index
that
has
different
values,
you
keep
adding
a
new
entry
in
there.
A
A
Immutable
conditional
request
how
we
handle
the
e-tags
and
if
we
support
e-tags
and
how
that
would
look,
there
have
been
concerns
on
this
one,
that
the
backing
for
the
registry
is
not
potentially
isn't
or
it
potentially
is
eventually
consistent,
and
so
that
would
be
a
challenge
if
you
have
an
eventually
consistent
backing
and
you
try
to
do
e-tags,
that's
just
not
going
to
work
because
you
don't
really
know
what
you're
backing
is
at
any
one
point
in
time,
but
the
comment
came
back
was
saying:
well,
no
s3
and
from
aws,
and
if
I
go
look
up
like
mineo
that
they're
even
saying
as
long
as
you
pick
the
right
storage
file
system,
you'll
get.
A
You
know
some
immediate
consistency,
you
don't
have
the
venture
consistency
concerns
over
there,
so
it
might
be
something
that
registries
can
implement,
but
at
the
same
time
it's
no
guarantee
that
any
registries
out
there
already
today
does
implement.
And
so
we
would
have
raised
conditions
with
current
registries
until
they
support
e-tags.
F
Yeah,
just
really
quick.
I
also
need
to
go
at
the
half
hour,
but
I
I
think,
like
I'm,
trying
to
compared
to
proposal
e,
which
seemed
like
we
were
like
going
straight
in
that
direction.
F
It
like
it
seems
like
the
docker
people
are
not
are
less
concerned
about
changes
to
the
registry
and
more
concerned
about
changes
to
the
schema,
and
I'm
wondering
if,
like
the
entire
filtering
and
discovery
piece
like
I
don't,
I
don't
feel
like
that
is
a
the
biggest
concern
of
theirs.
So
it's
more
about
not
changing
the
types.
A
I
I
agree
with
your
assessment
and
the
reason
that
I
would
look
at
it
from
their
side
is
they're.
The
image
originated
for
a
lot
of
stuff,
with
the
official
images
there's
only
one
time,
they're
pushing
this
and
they're
not
going
to
mute
it
ever
again
after
that,
and
they
don't
really
have
the
downstream
concerns.
I
think
some
others
of
us
have.
D
For
sajay-
and
I
I
wonder
like
because
your
team
was
the
one
that
actually
did
like
quite
a
bit
of
work
around
this.
What
what
made
you
decide
to
go
in
the
direction
of.
C
I
can
maybe
describe
some
history
there
if,
if
folks
know
content,
trust
or
the
doctors,
implementation
of
trust
was
actually
done
as
a
different
catalog.
They
actually
keep
an
entire
different
database
and
you
have
to
run
it
as
a
different
service
and
you
attach
signatures
and
it's
disconnected
from
the
registry.
The
problem
is
that
became
highly
non-portable,
which
means
that
you
have
one
set
of
content
that
is
signed
and
has
a
different
sha,
and
you
have
the
same
tags
and
different
system.
That's
maintained
differently.
C
That
makes
it
hard
for
me
for
you
to
take
it
from
one
origin
and
pass
it
over,
even
though
it's
there's
federation
underneath
so
the
whole
idea
was
that
you
have
one
content
store.
Why
not
use
it
to
store
other
types
like
signatures,
because
in
the
end,
you're,
not
the
you
know:
you're,
not
trusting
the
registry
to
be
the
source
of
truth,
the
it's
not
the
trust
source,
it's
only
the
source
of
the
content,
so
you
still
pull
it
down
on
the
kind
of
client
from
the
same
place.
C
I
can
maybe
give
you
some
perspective
from
implementing
the
network.
Lockdown
secure
registries,
which
is
one
of
the
harder
ones
that
most
customers
want
right.
They
don't
want
you
to
go
out
to
the
internet.
They
don't
want
you
to
go
out
to
some
random
endpoint
and
things
like
that.
So
opening
up
every
dns
in
their
environment
is
really
hard.
C
So
once
they've
opened
up
a
set
of
firewall
rules,
it
becomes
easy
for
them
to
say
hey,
I
can
acquire
other
stuff
also,
and
if
it's
an
image,
why
wouldn't
I
get
the
same
content
or
similar
content
from
the
image
from
the
same
endpoint?
So
that
was
one
of
the
motivations
why
we
rallied
around
making
the
registry
support
these
things.
Does
that
answer
your
question?
It's
more
of
a
historic
reasoning.
More
than
anything
else.
D
So
it
answers
the
question
of
why
you
want
to
store
all
of
the
associated
content
in
the
same
registry,
but
I'm
wondering
like
as
far
as
things
on
top
of
that,
which
is
the
discovery,
the
filtering,
the
content
management,
I
mean
those
could
have
been
implemented
separately
right.
You
know
the
digest
of
the
dag
and
you
can
kind
of
right
manage.
C
The
digest
separately
yeah,
I
think
the
conversation
of
the
working
group
is
to
come
to
agreement
where
all
clients
can
implement
it.
The
same
way
because
we
I
mean
I
personally
would
love
it
if
docker
aws
gcr,
all
of
us
could
kind
of
share
the
same
images
with
signatures
without
having
to
worry
about
portability
and
each
client
and
cloud
doing
their
own
thing.
C
That's
the
whole
point
of
this
group
right,
so
we
could
have
implemented
it
on
top,
but
we
felt
that
distribution,
api
and
the
image
spec
were
the
place
where
these
agreements
happen
and
so
coming
to
the
table
and
taking
that
forward
was
the
motivation.
Does
that
doesn't
make
sense,
because
even
adding
a
new
api
distribution
would
mean
that
all
cloud
providers
somehow
need
to
understand
the
spec
and
implement
it.
C
E-Tags,
I
totally
support
e-tags,
but
if,
if
the
other
cloud
providers
don't
support
it,
then
our
client
tooling
won't
use
it,
so
it
becomes
the
lowest
common
denominator
for
all
these
apis.
I
do
it.
D
Yeah
yeah,
I
I
agree
with
that,
but
I
mean
the
the
counter
proposal
is
that?
Well,
if
you
know
these
kind
of
features
like
the
filtering
and
the
content,
management
is
not
something
that
everyone
like
not
something
that
is
commonly
used,
maybe
that
shouldn't
be
in
the
realm
of
oci
in
the
first
place.
D
So,
yes,
we
can
talk
about
like
how
to
fix
race
conditions.
We
can
talk
about.
You
know
how
to
get
clients
to
understand
nested
indexes.
D
Maintenance
of
whatever
is
existing
right
now,
so
that
doesn't
really
change,
developer
workflows
so
much,
but
the
other
stuff
is
all
like
enhancement
features.
I
mean
we
can
still
pull
things
by
digest.
We
can
still
pull
blobs,
can't
that
implementation
be
like
you
know,
offloaded
to
something
else.
A
Chuck's,
I
had
a
point
in
starting
faith
there,
but
when
we
get
into
some
of
these
scenarios,
where
you
have
a
mutating
digest
that
that
was
a
big
concern
early
on,
I
think
they
found
a
way
to
solve
that.
So
that
might
not
be
as
big
of
an
issue,
but
when
you
have
race
conditions
in
there
and
when
you
have
nested
indexes,
those
are
things
that
aren't
easy
to
solve
with
the
existing
environment.
A
E
When
I
say
you're
using
basically
an
annotation
as
as
an
additional
reference
type,
you
know.
E
A
I
feel
like
they
over
focused
on
that
part
of
their
thing.
I
think
they
could
have
easily
left
that
completely
out
and
said:
here's
just
how
we're
going
to
do
a
reference
in
general
and
then
come
back
later.
On
said,
oh
by
the
way,
here's
an
optimization
we
want
to
add
using
an
annotation
that
might
have
been
easier
to
look
at,
but
they're
very
focused
on
signatures
right
now,
so
they're
looking
at
that
optimization
really
hard.
E
C
E
A
A
It's
it's
a
confusing
scenario
there,
but
I'm
hoping
we're
going
toward
a
good
situation.
That's
going
to
work
long
term
when
we
start
throwing
a
whole
bunch
of
stuff
at
registries
and
short
term
with
whatever
the
current
state
of
the
registries
is
today
across
a
whole
variety
of
use
cases,
and
I
think
each
of
us
is
coming
with
our
own
individual
use
cases
to
this
one,
and
so
it's
we
need
to
make
sure
we're
finding
the
solution.
Everybody
can
work
with.
A
B
B
D
D
D
D
A
F
And
I'm
I
am
curious
to
follow
the
proposal
f
for
the
reference
stuff.
So
that's
why
I'm
joining.
A
F
A
Yeah,
I
think
all
these
means
are
about
lunch
time,
but
yeah
that
one
hopefully
they'll
have
a
proposal
ready
by
next
week.
We're
pushing
them
very
hard
on
that
cool.
A
Are
you
in
a
bookstore?
I
am
not,
it
looks
like
I
am
though,
but
no,
I
am
not.
E
A
Cool
well,
if
nothing
else,
nichole
I'll
try
to
help
debug
your
issue
for
you,
but
I
think
we're
all
done
with
agenda
stuff.