►
From YouTube: 2019 05 01 - OCI Weekly Developer's Discussion
Description
/_catalog https://github.com/opencontainers/distribution-spec/pull/45#issuecomment-487030819
new listing api disucssion https://hackmd.io/s/BJPAUxDvV#OCI-Catalog-Listing-API---Workgroup
artifact registry update
new hooks for runtime-spec https://github.com/opencontainers/runtime-spec/pull/1008
https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#May-01-2019
A
I
start
the
recording,
okay
common,
so
yeah
to
kick
off
the
meeting
the
the
catalogue
API
were
going
back
and
forth
on
this
and
Jimmy
szalinski.
He
he
he
chimed
in
on
that
issue.
That
said
something
on
this
past
week
about
the
removal
of
it
and
it's
I
guess
it's
contentious,
because
there
are
a
few
people
using
it
that
probably
shouldn't
be
using
it.
A
There
was
an
alternative
to
it,
but
that
even
the
mention
of
removing
it
has
called
some
people
be
like
well,
I,
guess:
I'm
not
going
to
be
going
with
the
OCI
distributions
back
I'll,
just
stick
with
docker,
be
to
schema
tube,
so
that
I
can
make
sure.
There's
an
catalog
API
called
cuz
they've
already
written
to
that.
That's
kind
of
like
the
no
take-backsies
rule
of
open
source,
so
I'm
kind
of
two
ways
about
it.
A
The
adoption
will
be
sparse
if
it's
not
effectively
a
drop-in
replacement,
so
I'm
I'm
kind
of
like
I,
guess,
I'm
saying
on
two
ways
about
it
and
having
heard
a
few
people
express
that
they
were
disinterested
in
any
kind
of
open
standards
and
we'll
just
stick
with
what
they've
got
because
of
the
catalogue:
API,
the
catalog
endpoint.
Being
there
was
my
motivation
for
start
Reece
purring.
The
conversation
was
not
just
a
fine,
a
needless
piece
of
thread
to
work
on.
You
know,
unwrapped
unraveling,
a
conversation.
A
B
I
I
get
that
people
usually
think
of.
In
fact,
we,
you
know
ourselves
implemented
it.
What
I'm
struggling
a
bit
is
since
not
everybody
has
implemented
it,
putting
it
in
the
spec
almost
says
like
we
must
and
what
I'm
kind
of
missing
what
seems
fairly
obvious
is
we
can
all
implement
something
that
isn't
in
the
spec,
and
in
this
case
we
say
well
having
API
in
the
spec
isn't
proving
their
valid
because
many
haven't
it's
got
some
difficulties
for
various
for
industries
to
implement
because
of
the
assumptions
or
our
namespaces
and
others.
B
So
what's
the
downside
by
saying
we're,
gonna
remove
it
from
the
spec.
That
doesn't
mean
we're
removing
it
from
any
of
the
implementations,
and
when
we
come
in
with
a
new
one,
then
we
would
hopefully
be
at
a
point
where
everybody
does
agree,
that
it
is
a
replacement
and
it
would
be
implemented
consistently.
So
wait.
My
struggle
is,
if
we
leave
it
in
the
spec,
then
we
have
a
bunch
of
registries
that
are
just
not
gonna.
Be
spectrum
plane
and
they're
gonna
have
very
valid
arguments.
Why
they're
not
spectrum,
fine
mm-hmm.
A
B
Spec,
let
them
keep
the
API,
including
us,
and
let's
work
on
the
new
one
without
you
know,
worry
about
this
elephant
in
the
room
and
I
think
that
there's
no
real
good
standard
on
the
catalogue,
API
being
the
fact
that
even
the
the
scanning
companies
we've
all
in
the
ones
that
have
actually
employed
the
catalog
api
have
implemented
slightly
differently
because
of
the
complexities
of
it.
So
every
one
of
the
scanners
that
have
implemented
across
our
various
clouds
and
distributions
of
distribution
and
distribution.
How
did
you
put
nuances
it
if
AWS
do
this?
B
A
C
Really
good
opportunity
that
someone,
some
group
some
person,
whatever
someone
with
a
better
idea,
can
implement
it
and
then
slowly
kind
of
get
adoption
get
support.
And
that
says
nothing
that,
like
you,
still
can't
have
the
catalog
and
I
see
it
more
as
an
opportunity
to
kind
of
develop
something
new
and
better,
but
not
like
break
everyone.
That's
potentially
using
it.
But
again
that
doesn't
really
say
much
about
it
being
or
not
being
in
the
spec
I.
D
Mean
I
would
I
would
see
a
good
document
that
we
should
not
mandate
it,
but
it
should
be
effectively
at
the
very
least
reserved
as
endpoints
and
I
would
hope,
at
least
describing
terms
of
like.
If
you
implement
this,
here's
what
it
should
look
like,
but
any
other
hands,
that's
just
like
adding
croft
from
day
one.
You
know
I
think
yeah
I.
B
Could
say
totally
putting
in
the
spec
that
the
under
store,
catalog
api
is
reserved
for
backwards,
compatibility
and
anything
new
that
we
do
and
unfortunately,
I
was
picking
Michael
Brown
being
the
wrong
one.
So
he's
got
Michael
Brown
AWS
to
clarify.
Thank
you
I
offered.
If
we
can
get
him
a
hat,
would
he
be
able
to
step
in
anyway?
The
point
is
that
we
should
anything
new
we
do.
We
should
absolutely
make
sure
it
doesn't
sit
on
top
of
that
one,
because
we
obviously
would
do
it
differently,
because
the
current
didn't
work
as
expected.
B
C
A
B
We're
using
it
because
we
all
need
one,
it's
just
a
matter
of
it
didn't
match
our
individual
cloud.
You
know
configurations
and
scenarios
we
disabled
it
on
MCR
proved
it
because
we
didn't
have
it
set
up
for
the
scalability
and
that
MCR
gets
queried
on,
which
is
the
same
problem
that
docker
hub
has.
So
we
wound
up
putting
an
index
in
and
fixed
all
that
because
we
had
such
a
high
demand.
So
it's
definitely
a
need.
Unfortunately,
the
implementation
doesn't
match
the
need,
so
I
guess
I
mean
I'm,
just
struggling
with
I,
really
I'm
struggling.
B
A
How
that
you
know
how
feasible
it
is
because,
having
a
like
you
said,
Steve,
a
more
approachable
and
agreed
upon
listing
and
not
the
terrible
catalog
API
would
even
make
more
of
a
suitable
vendor
playground
and
I.
Think
that
was
even
Jimmy.
Zelinsky's
point
is
that,
right
now
it's
not
been
very
suitable
for
four
vendors
or
various
tool.
Things
like
scanners
to
work
with,
because
it
does
Thresh
the
registries
and
even.
A
A
B
What
I'm
suggesting
is
this
decoupled?
The
let's
put
the
catalog.
You
know
the
underscore
as
a
reserved
word
and
not
have
it
as
a
definition
in
the
spec,
and
you
know
obviously
not
send.
You
know,
cease
and
desist
orders
to
those
that
have
implemented
it
and
leave
it
alone
and
the
ones
that
haven't
implemented
it
and
but
the
ones
that
happen
implements
that
implement
something
else
in
John.
Maybe
he
can
remind
me
what
Google
did
I
thought.
Google
did
something
a
different
API
altogether
to
enable
this
scenario.
Oh
he's.
B
I
saw
him
typing
I
know
if
he
has
another
micro
can't
talk,
but
I
would
love
to
just
let's,
just
literally
just
put
that
away
and
focus
well
couldn't
get
a
room:
okay,
but
tuck
that
aside
and
literally
work
on
you
know
the
new
one,
and
you
know
that
one
that
John
had
put
an
issue
on
was
a
great
conversation
story.
I
think
that's
what
we
used
as
the
basis
for
what
Mike
had
proposed.
We
could
have
a
working
group
around
I.
D
Want
to
say
that
I
think
I
would
be
in
favor
of
having
something
mainly
because
I
feel
a
little
bit
strange
about
having
a
distribution
spec
that,
like
doesn't
have
a
way
to
search
things,
especially
when
you
think
about
it.
I
mean
at
that
point:
it's
just
another
way
of
pushing
blobs
onto
a
server
I
mean
without
a
such
API.
It's
a
little
bit
strange
to
have
a
one,
oh
that
so
they're
bones
and
I
mean
we've
had
that
problem
across
other
aspects
of
like
bill
delays
to
later
and
then
later
never
comes.
B
I
guess
all
I'm
asking
is:
unless
we
think
the
underscore
catalog
API
can
be
fixed,
which
I
don't
believe
anybody
believes
it
can
be
I,
don't
understand
the
leave
it
in
which
which
nobody's
gonna
change
their
implementation
versus
leave
it
as
reserved
and
close
this
issue
and
move
on
to
the
new
one.
Unless,
unless
the
we're
not
thinking
we're
gonna
finish
up
the
catalog
as
the
distribution
spec
until
the
end
of
the
world
in
the
world
and
in
the
year
I
think
is
what
Vincent
said.
B
B
I,
don't
remember,
I'd
have
to
hire
somebody
anyway.
Maybe
do
we
want
to
just
tuck
this
just
because
I'd
rather
be
spending
this
time
actually
working
on
the
design
which,
unfortunately,
we
can't
do
at
this
meeting.
There's
other
things
we
could
talk
about.
Do
we
want
to
just
I
guess
I
defer
to
you
Vincent
as
being
the
one
with
the
gavel?
B
Do
we
just
leave
this
as
a
placeholder
for
now
and
see
if
we
could
make
progress,
and
in
three
months
we
revisit
again
nobody's
arguing,
we
want
to
finish
the
catalog
API,
we're
focused
on
a
new
one,
that
is
the
right
sneer
as
the
right
capabilities,
the
right
granularity
for
namespace
space
repose
versus
domain
space.
Repose
is
one
of
the
complexities
that
follows
our
back
as
well,
because
that's
that's
part
of
the
it's
not
just
a
perf,
because
those
of
us
that
implement
it
we
did
implement
some
type
of
indexing
behind
it.
B
A
Me
what
the
gabble
a
terrible
place
to
be
the
new
listing,
API
discussion,
I
think,
is
literally
the
next
item
up
on
the
agenda.
So,
okay,
so
I'm,
always
I'm
I'm,
I'm
game
for
being
persuaded.
I.
Think
Alexa
just
set
just
said.
My
concern
with
why
I
knack
for
rejected
my
own
support
of
removing
it
right
away
is
that
I.
A
I
guess
it's
just
a
concern
that
we
remove
it
and
that
the
listing
API
takes
forever,
because
people
would
debate
about
it
or
haven't
quite
implemented
or
put
their
hands
on
an
implementation
and
the
benefits
and
drawbacks
of
it
like
a
solid
client
use
case
and
the
solid
server
implementation
and
could
actually
work
through
to
say
this
is
what
we
found
and
it
actually
has
severe
performance
implications
or
whatever
or
severe.
You
know,
like
you,
said,
access
control
implications,
that's
pretty
much.
The
concern
is
the
devil.
You
know
versus
the
devil.
A
Removing
it
and
working
on
the
listing,
API
I,
do
see
that
most
of
the
conversation
is
already
there.
It's
probably
literally
just
in
the
hands
of
somebody
who
has
their
hands
on
an
actual
client
used,
client
and
use
case
and
a
server-side
implementation.
Even
if
it
is
the
doctor,
the
doctor
distribution
registry
code,
as
a
reference
implementation.
A
Have
hands-on
experience,
eped
and
experience
or
attraction
to
a
particular
implementation
that
we
can
work
through
would
cause
it
to
just
not
happen,
and
then
it
would
continue
to
I
skew
based
on
Mike
one
team
implementing
one
thing
and
another
company
implemented
another,
and
they
just
stick
with
what
they
got,
which
maybe
that's,
maybe
that's
an
okay
approach.
It's
just
not
going
to
actually
foster
any
adoption
at
all.
It'll
make
life
harder
on
security
scanners
and
new
tools
in
the
future.
B
Because
we
we
kind
of
anointed
him
as
the
leader
brought
it,
with
atlas
myself
being
quarterly
working.
Of
course,
although
had
your
own
name
there,
we
took
a
half
an
hour
just
for
this
one.
Maybe
we
just
we
make
more
progress
to
you
point
on
the
dock
and
bring
it
back
with
a
more
scoped
conversation,
because
I
think
we
were
in
the
you
know
the
explore
phase
of
the
things,
and
then
we
have
to
kind
of
scope.
It
back
I
think
not
having
this
entire
group
taken
on.
B
That
journey
is
probably
other
than
those
that
one
opt
it
can't.
So
that's
what
I
would
probably
suggest
at
this
point,
I
still
meeting
sorry
I
would
like
to
get
a
meeting
at
coop
con
just
because
it's
well.
These
calls
aren't
necessarily
as
effective
I
think
being
an
in
person
in
room
sketching
on
something
is
really
productive,
even
said
napkin,
as
opposed
always
just
iterating,
on
a
half-empty
or
a
spec,
and
then
we
could
bring
those
dynamic
conversations
back
to
the
group,
and
that
would
be
my
hope.
D
Yeah,
what
doesn't
say
is
that
I'm
one
thing
that
I
think
that
we
could
do
better
across
all
of
us
here
actually
is
handling
the
problem
of
actually
coming
up
with
the
community
consensus
or
something
because
I
mean
if
we
look
at
a
lot
of
the
stuff
that
we
want
to
change
within
our
CI.
There
are
plenty
of
examples
of
this.
D
There
isn't
really.
An
obvious
process
for
like
here
is
what
the
community's
decided
on
them.
Pretty
nosy,
I,
I,
still
sort
of
not
very
good
at
all
of
that.
I
think
would
agree
that
most
of
the
changes
that
have
controversy
I
have
been
like
the
blessed
implementation.
Has
it,
or
rather
we
came
with
the
best
information
they
move
there
through
the
spec,
so
I
think
it
will
be
nice
to
sketch
out
a
way
of
doing
that
as
well
as.
C
A
contributor
I
would
really
like
to
see
some
solid
examples
for
what
project
or
points
have
been
contributed
and
have
successfully
gone
through.
I
can
kind
of
imagine
the
scenarios
in
my
head,
but
when
push
comes
to
shove,
I
keep
having
sort
of
an
idea
of
what
it
means
to
contribute,
and
then
it
looks
like
something
different
and
if
you're
a
new
person,
it's
not
totally.
You
need
to
see,
for
example,
this
video,
that's
gonna,
be
on
YouTube
or
whatnot
with
all
of
us
talking.
C
It's
not
totally
clear
like
who
are
the
people
here
and
why
we
here
and
how
do
we
actually
sort
of
get
things
done
because
for
it
from
the
lay
person
point
of
view
and
feels
like
there's
a
lot
of
talking
about
things?
But
it's
not
clear
what
is
the
actual
path
to
like
here's,
an
idea
and
out
here
it's
like
implemented
in
the
wild.
C
So
I
guess
I
should
make
a
constructive
suggestion
for
what
we
can
do
thinking
how
about
to
start.
It
would
be
really
nice
to
see
like
from
the
start
of
OCI
to
this
point,
what
ideas
initiatives
entire
projects
have
been
successful.
How
can
we
just
make
like
a
list
of
those
things
that
we
can
then
share
with
people?
Any
ideas.
A
A
That
I
mean
you
I
mean
to
some
extent
several
several
folks
on
this
call
are
already
doing
some
of
that
with,
like
the
Deus
labs
heaven
they
are
as
tool
just
to
experiment
with
pushing
and
pulling
different
mime
types
and
those
kind
of
implementations
that
there's
just
a
in
the
past.
Some
of
those
tools
either
fit
a
very
specific
use
case.
So,
like.
A
A
Did
it
a
certain
way,
so
those
tools
could
breathe
to
respect
the
runtime
spec,
and
you
know
whether
they're
cotta
containers
or
railcar
or
sea
run
or
Chee
visor
na
blah,
whatever
there's
a
list
of
those
tools
and
read
the
spec,
but
then
they
would
also
try
and
implement
bug
for
bug
compatible
with
the
behavior
of
Runcie,
and
it
was
it's.
It
was
because
they
each
solved
a
specific
use
case,
but
they
had
to
be
able
to
be
able
to
be
dropped
in
in
place
and
used.
A
They
every
like
scope,
EO
did
a
certain
thing
with
the
registry
and
image
format
and
people
used
it.
It
wasn't
just
an
academic
like
look
at
how
I
did
a
thing.
It
was
more
like
I
need
to
be
able
to
remote,
inspect
images
or
copy
to
disk
without
a
register
without
a
daemon
running,
and
it's
like
it
got
adoption
for
that
can
use
case.
A
A
A
When
you're,
when
you're,
showing
some
of
the
examples
you've
written
in
and
around
container
diffing
those
kind
of
tools,
and
it
will
they
will
they
end
up
blending
or
you
know,
will
it
blend
or
will
it
just
be
a
an
example
of
how
to
do
something?
That's
that
was
always
what
Tom
would
tell
there
was.
There
was
a
lot
of
tools,
I'm
sure
I'm,
not
remembering,
but
the
ones
that
solved
a
specific
use
case
and
they
were
using
what
we
were
talking
about
actively
in
the
meetings
to
solve
that
use
case.
A
B
Just
being
the
one
that's
relatively
new
to
the
group
and
how
we
were
trying
to
add
some
stuff
yeah,
the
whole
artifact
stuff
for
me
trying
to
get
engaged
with
the
group,
because
we
had
this
idea,
we
wanted
to
go
with
it.
We
had
some
experience
with
trying
to
do
helm
as
a
one-off
in
registries,
and
that
was
this
sucks.
We
want
to
make
it
better.
B
There
was
a
process
by
not
understanding
what
the
engagement
model
was
to
your
point.
Vanessa,
I
and
I
think
I
struggled
on
how
to
figure
out
how
to
engage
with
the
team
and
only
because
of
persistence
did
I
figure
it
out,
I'm
sure,
being
working
at
Asher
helped
a
little
bit
for
people
to
continue
to
pay
attention
when
it
seemed
like
I
was
being
really
annoying
about
something.
B
So
I
was
able
to
navigate
and
figure
that
out
and
buy.
The
thing
that
I
was
trying
to
understand
is
here's
an
idea.
Where
does
it
fit
and
then
wasn't
this
as
an
expectation,
hey
take
my
PR
on
the
spec
or
even
code?
It's?
How
does
the
group
think
about
this?
So
we
can
now
go
off
and
work
on
it
and
it's
kind
of
the
phase
were
in
now,
and
that
was
that's
kind
of
where
I
was
gonna.
B
Bring
up
on
the
artifact
registry
update
is
you
know
we
have
a
pretty
good
structure
of
how
we're
doing
we've
had
a
lot
of
conversations
on
how
to
work
with
the
team
and
where's
the
agreed-upon
space
and
then
where's
the
tenacious
space
we
know
index
is
still.
You
know,
a
very
contentious
space
to
figure
out
how
to
solve,
but
we
can
do
a
playground
and
figure
out
at
the
in
this
one
area.
B
Let's
just
call
it
at
the
actual
image
instead
of
the
index,
and
we
got
the
auras
library
which
we're
iterating
on
we've
got
singularity
now
I
was
supported
as
another
format.
Thank
you
for
your
help
on
it.
So
we're
really
excited
about
that.
So
now
we're
validating
it
and
I
feel
like
we're,
building
up
enough
momentum
that
we
can
come
back
and
reassess,
for
instance,
the
index
one
because,
like
we
had
a
lot
of
agreement
at
the
artifact
level
at
the
image
level,
we
had
a
lot
of
contention
at
the
index.
B
C
If
you're
at
a
company
and
you're
working
on
a
registry
or
some
some
cool
sort
of
arm
off
of
OCI,
what
is?
Is
there
any
means
for
you
to
reach
back
to
people
in
the
asite
sky,
community
and
say:
hey
I'm
working
on
this
really
cool
thing?
Are
there
people
that
want
to
help,
or
that
can
help
tests
or
or
basically
do
anything,
so
he
could,
for
example,
could
me,
as
a
contributor
and
someone
who's
interested
you
teeners,
who
listened
to
the
OCI?
C
B
It
allowed
us
to
work
in
the
same
building
as
others,
but
just
you
know,
having
our
own
rooms,
but
there's
like
the
hallway
and
the
cafeteria
that
everybody
could
kind
of
navigate
in
that
was
very
abstract
way
of
thinking
about
the
slack
stuff
is
we
can
you
know,
I
could
DM
somebody
hey
we're
having
this
conversation,
if
they're
not
worried,
you
have
not
focused
on
it,
but
at
least
we're
in
the
same
area.
I
struggled
with
the
the
other
thing
they
just
drew
like.
That
was
my.
That
was
my
suggestion.
B
That
was
my
proposal
on
how
we
do
that
and
I'm
hoping
everything
from
the
artifact
stuff
we've
got
is
a
select
channel
there
to
the
to
even
this
catalog
listing,
assuming
we
spend
the
time
and
actually
work
on
it
that
we
can
have
those
discussions
off
to
the
side,
but
still
in
the
same
body
that
you
know
others
can
be
visible
to
because
just
having
something
offensive,
random
github,
you
know,
that's,
that's!
Just
a
piece
of
sand
in
the
desert,
you
know
it's
just
this
way
too
many
of
them
I.
D
A
B
From
the
catalog,
when
I'll
just
use
that
I
think,
as
you
mentioned,
the
the
process
when
we
failed,
as
we
didn't
actually
set
some
timeline
and
we're
not
actively
running
to
any
timeline
for
certainly
more
aggressive
than
nothing
so
I
think
setting
an
expectation
of
hey.
We
agree
won't
want
to
do
this.
What's
the
timeline
on
it,
let's
make
sure
we're
following
up
on
an
irregular
basis,
and
if
we're
not,
what
does
that
mean?
Is
it
really
not
that
important?
Is
it
whatever?
B
The
reasons
are
for
me:
I've
just
been
super
busy
and
but
I'm,
but
at
the
same
token,
we're
not
blocked
because
we
did
implement
the
catalog
one.
For
now
and
it's
you
know
it's
not
it's
not
right.
It's
not
great.
We
were
able
to
work
around
its
current
limitation
so
but
we're
the
artifact
registry
stuff.
We
are
blocked
by
that
I
am
making
progress
on
that.
You
know
we're.
So
that's
an
example.
B
There
is
a
set
of
people
working
on
we're
not
really
discussing
it
here
per
se,
but
the
auras
stuff
we've
been
working
on
the
scene.
Up
conversations
have
been
continuing
on
that,
so
I
think
part
of
it
is
there's
probably
more
regular
engagement
when
there's
active
development
going
on
or
I
think
right
now
a
bunch
of
us
are
trying
to
spend
free
time
trying
to
make
some
progress
on
this.
B
A
B
We've
got
the
singularity
stuff
which
we
announced
and
we
have
working.
That
is
all
working.
You
know
with
the
the
agreement
that
we've
made
to
date
on
losing
the
media
type.
The
scene
out.
Conversation
has
come
back
around
and
I
I'm,
seeing
more
active
conversation.
It
was
a
call
this
morning
on
it
which
that
one
is
going
to
tease
that
the
index
challenge
that
we
have,
because
we
don't
have
a
way
to
define
these
things
that
min
decks.
I
still
have
the
retaking.
B
B
A
distribution
I
have
a
I've
been
rejected,
accepted
as
a
reject
for
the
pre
condom
con,
so
I
do
have
a
session
there,
that
I've
been
working
on
and
as
I
work
through
the
presentation,
I'm
I'm,
trying
to
identify
some
of
stuff
like
Vanessa
was
mention
you
like.
How
does
somebody
understand
how
this
works?
They
encounter
somebody
ramped
up
so
I'm,
hoping
that
will
flush
out
the
details
of
what
I
want
to
submit
as
a
PR
to
the
image
to
the
distribution
spec.
B
A
B
A
B
D
A
E
Far
as
I
can
see
this
layer
of
the
this
extra
layer
of
information,
it
seems
a
little
hard
to
stuff
into
the
current
spec
and
my
understanding
is
that
we
you
can
do
some
I
mean
there
is
some
level
of
declaration
that
you
can
do,
but
the
way
that
containers
do
like
get
reused.
It
can
quickly
bloat
up.
So
my
feeling
is
that
a
lot
of
these
concerns
might
be
able
to.
D
We
should
yep,
we
should
definitely
I
doubt
it.
Yeah
III
was
hoping
that
there
would
be
a
that.
Someone
would
have
an
idea
of
how
to
get
that
bill
of
materials
to
work
with
the
the
heavy
stuff
I
was
discussing
because
yeah
one
of
the
main
things.
That
is
what
the
mirror
images
for
the
past
five
years
is.
The
fact
that
we've
gone
backwards
in
terms
of
like
people
used
to
know
was
installed
by
machines.
Now
they
don't
anymore.
D
F
A
E
The
trouble
with
container
images
is
that,
because
they
get
reused
and
because
they're
so
they're
opaque,
whatever,
whatever
information
they're
no
place
in
the
container
image
itself,
where
you
can
go
and
you
know,
grab
for
or
query
or
inspect
that
kind
of
information
and
I.
Suppose
that's
just
the
nature
of
the
way
that
they're
packaged
or
the
way
that
they're
built
in
the
first
place.
E
E
C
Internals
to
the
container
that
is
able
to
provide
that
functionality
and
to
also
provide
an
entry
point
that
would
then
let
you
two
sort
of
inspect
and
any
kind
of
metadata
that
you
want
and
that
doesn't
necessarily
have
to
be
part
of,
for
example,
it
doesn't
have
to
be
like
part
of
the
container
itself.
It
could
be
something
that
someone
chooses
to
installing
then
they
say,
of
course,
then,
are
people
actually
going
to
install
it?
C
I
think
it
comes
down
to
having
to
develop
some
kind
of
software
and
then
prove
that
it's
useful
to
people
and
then
it
works
and
then
making
a
suggestion.
I
mean
I'm,
not
I'm,
not
sure
about
that.
It's
a
fine
line.
When
you
can't
force
people
to
do
anything
I,
don't
think
you
want
to
I,
don't
know
I,
don't
to
me.
It
doesn't
feel
like
making
a
specification,
for
this
is
how
a
container
must
serve.
This
particular
metadata
feel
it
feels
like
too
much
hard
coding.
C
D
I
was
just
so
there,
so
there
is
a
way.
So
currently
there
is
a
place.
You
could
stash
away
such
information,
which
is
unlike
the
annotation
of
of
basically
the
descriptors
of
like
when
appoints
delays,
but
that
would
be
an
awful
idea,
mainly
because
as
far
as
I
know,
no
like
no
tools
actually
touched
that
mainly
because
nobody
else
use
it.
So,
ultimately,
yet
it's
not
really
doable
at
the
moment.
I
would
argue.
D
Yes,
sorry
I
would
argue
that
effectively.
My
idea
for
how
this
sort
of
thing
should
work
is
that
you
would
be
able
to
get
so
with
regards
to
getting
a
bill
of
materials.
In
terms
of
like
in
the
middle
of
a
build
process,
I
mean
it
depends
ability
you
use,
for
instance,
on
the
openSUSE
side,
when
we
build
container
images
right
now,
we
do
have
a
bill
of
materials,
it's
necessary
in
order
for
OBS
to
dewater
rebuilds.
It's
like
the
idea
is.
D
A
D
Ley
lines
in
the
chain
actually
have
signing
and
so
on,
but
I
think
that
definitely
argument
made
that
there
is
a
use
case
for
it.
I
mean
I,
know
that
motions
would
jump
it.
The
idea
to
say
to
give
more
securities
in
this
way
sort
of
down
to
what
sort
of
tool
then
we
can
come
up.
Unfortunately,
I
think
that
scanning
approach
to
images
is
quite
intricate.
It's
quite
complicated
to
get
right
and
I
think
that
the
problem
is.
D
D
D
E
To
use
okay,
if
you
were
to
use
so
it's
past
3:00,
so
we
can
talk
about
this
later.
I
mean
it.
It
definitely
is
a
like.
It
gets
really
complicated,
really
quickly
yeah.
This
is
just
using
like
the
base
layer.
You
can
use
tools
like
ODB
or
even
he
also
to
build
your
base
layer,
and
you
know
exactly
what's
in
the
container,
but
once
people
start
you
know
reusing
containers
to
build
like
some
higher
levels
of
abstraction.
Then
it
becomes
harder
and
harder
to
track.
B
Sorry
might
suggest,
as
a
perfect
example
of
breaking
something
off
to
the
side
and
continue
the
conversation,
because,
if
there's
anything,
that's
blocking
making
progress
because,
like
from
a
artifact
registry
perspective,
I
love
this
because
it's
yet
another,
it's
not
a
copy
of
one
of
the
ones,
we're
very
tired,
so
just
really
testing
something
new
on.
Where
do
you
put
this
information?
Because
this
isn't
a
new
artifact?
B
This
is
adding
information
to
the
existing
type,
though
this
is
like
one
that
I
would
not
drive,
but
I
would
watch
you
know
from
the
back
and
kind
of
you
know,
hook
it
on
some
things
and
then
let
others
drive
it.
Then
I
keep
on
kind
of
asking
questions
and
learning,
so
it
back
to
the
initial
question
that
Vanessa
asked
is:
how
do
we
iterate
our
new
things
in
this
working?
Very
mystical.