►
From YouTube: OCI Weekly Discussion - 2021-01-27
Description
OCI weekly developer's call recording from Wednesday, 27th Jan 2021. Call agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#January-27-2021
A
A
B
For
just
for
our
housekeeping
the
I
don't
call
it
kreb
or
not,
but
the
peter
galek
from
that
was
talking
about
the
not
conformant
but
benchmark
work
they
needed
to
reschedule
for
next
week.
So
I
saw
somebody
was
discussing
excited
to
see
what
they're
going
to
present,
but
they
did.
They
did
have
to
move
to
next
week.
B
You
seem
to
have
quite
a
few
people
here
already,
so
I
guess
neil
do
you
want
to
just
kick
it
off
with
your
first
topic?
Well,
first
of
all
actually
wait.
This
is
the
first
of
2021
right.
So
welcome
everybody
to
2021
good,
to
have
that
one
behind
us
and
it'll
be
a
pretty
packed
year.
I'm
sure
we'll
come
back.
Everybody.
D
D
So
I
so
I'm
here
to
introduce
myself
and
and
saying
that,
I'm
you
know
we're
working
on
containers.
I
think
where
I
s
where
I
started,
and
it's
going
to
be
a
journey
for
for
us
as
a
platform
to
bring
containers,
but
I
was
thinking.
One
thing
I
might
want
to
start
with
is
is
looking
at.
We've
already
been
looking
at
this,
but
looking
at
like
the
oci
runtimes,
spec
and
and
trying
to
introduce
z
os
as
a
platform
into
that
specification.
D
You
know
another
thing
about
z,
os
it
it
is
posix
com
is
a
posix
compliant
operating
system,
but
there's
a
lot
of
other
unique
aspects
to
the
os,
but
probably
to
start
it
would
probably
look
a
lot
like
the
solaris
aspect
of
the
runtime
that
regards
except
for
their
specific
solaris
platform,
specific
section.
But
you
know
I
expect
to
kind
of
ours
to
look
like
that
for
z,
os,
maybe
initially
and-
and
hopefully,
you
know-
evolve
as
needed
as
as
forward.
A
Cool
thanks
neil
yeah,
so
we'll
we'll
be
helping
shepard
yeah
right
through
the
process,
as
you
go
from
the
runtime
spec,
get
that
in
first
and
then
run
c
updates
and
things
like
that
right
and
then,
hopefully
you
know
through
the
rest
of
the
stack
outside
with
kubernetes,
as
as
you
bring
it
all
on
to
the
zos.
I
think
it'll
be
interesting.
Steve
he's
going
to
basically
be
a
you
know
the
windows
wcal
for
you
know
for
for
the
zos
mainframe
guys
they
also
there's
a
z
linux.
A
A
B
And
yeah
I,
while
I
obviously
I
know
the
folks,
I'm
not
the
expert
there.
So
if
you
need
any
connections
with
the
folks
over
at
windows
and
john
starks
and
others
that
are
working
on
it,
I'm
happy
to
connect
you
and
try
to
learn
from
what
they
learned
with
things
they
wish.
They
did
differently
and
the
things
they've
done
well
that
they,
like.
A
Exactly
yep
yep,
that's
yeah,
that's
the
kind
of
link.
I
was
hoping
that
we
could
give
with
neil.
You
know
with
you
guys,
since
you
guys
are
both
trying
to
push
a
new
platform
through.
You
know,
yeah
yeah
sure
linux
is
going
to
work
easy,
but
yeah
getting
other.
Other
platforms
isn't
going
to
be
as
easy,
especially
now
in
the
test.
Buckets.
E
Hello
happy
new
year,
I
was
chatting
with
nisha
in
slack
recently
and
she
was
interested
in
using
auras
to
work
on
some
experiments
and
noticed
that
trying
to
pull
from
docker
hub
was
not
was
not
initially
supported
or
it
would.
It
would
essentially
pool,
and
you
wouldn't
get
any
artifacts
out,
and
there
was
also
a
discussion.
E
And
I'm
looking
through
the
comments
and
the
number
one
issue
with
getting
it
in
was
from
basically
alexa,
who
is
noting
that
it
doesn't
support
images,
and
so
essentially,
why
be
an
open
containers
project?
If
it's
not
supporting
open
container
images?
Well,
it
does
enable
things
that
are
trying
to
use
the
same
distribution
api.
E
E
E
Can
we
just
put
something
like
a
road
map
file
that
says
we're
wishing
to
do
this,
or
will
the
tlb
members
want
to
see
that
implemented
prior
to
getting
it
in
and
the
third
thing
which
I
don't
have
written
here
is
there
was
another
issue
on
emoji
regarding
cooling,
oci
images,
and
does
it
make
sense
for
emoji
to
do
that,
or
should
there
be
a
tool
for
building
and
a
tool
for
push
and
pull
nisha?
Maybe
if
you
want
to
add
anything,
but
that's
pretty
much
the
gist,
I
think.
F
F
My
personal
opinion
is
to
have
the
push
and
the
build
operations
or
the
manipulation
operations
separate,
but
it
would
be
nice
if
they
were
in
sync
with
each
other,
so
people
can
plug
if
they
want
to
experiment,
they
can
plug
the
two
tools
together
and
say:
okay,
this
is
for
this
is
for
making
oci
images
in
your
local
environment.
Emoji
is
and
oras
is
for
uploading
or
downloading
those
images,
and
also
there
isn't
really
a
client
tool
that
out
there
that
supports
oci,
artifact
style
images.
F
So
the
one
with
the
index.json
and
I'm
wondering
if
auras
could
be
that
tool
that
can
push
and
pull
index.json
to
be
able
to
add.
You
know
other
man
list
of
manifest
or
append
to
the
list
of
manifests
and
yeah.
That's
all
I
have,
and
I
guess
the
final
one
is
it
would
there's
there's
not
much
support
on
auras
and
I'm
totally
willing
to
you
know
adds
the
you
know
contribute
to
it.
I
just
don't
know
well
what
the
community
is
like
for
that
project.
B
B
So
it
has
kind
of
expands
a
little
bit
and
by
calling
it
oci,
then
we
don't
really
have
to
spell
the
names.
I
can't
remember
what
right
good
examples
of
other
acronym
companies
are,
whether
it
be
ibm
or
xerox
or
something
I
don't
know
anyway,
so
we
definitely
kind
of
think
of
it
as
a
broader
charter.
That's
why
we
have
the
oci
artifacts
in
there
that
supports
things
that
are
not
images.
B
We
we,
we
didn't
really
start
auras,
I
mean
honestly,
it
was
josh
and
cheeway
that
did
most
of
it.
Some
ideas
that
we
were
tossing
around,
that
that
became
the
tool
to
enable
additional
things
pushed
to
a
registry.
I
mean,
even
or,
as
is
what
was
it
oci
registry,
as
storage,
I
think,
is
what
you
originally
did:
auras
josh,
which
was
the
name.
B
So
it
wasn't
really
meant
to
target
images.
So
that's
why
the
image
stuff
isn't
in
there.
We
were
trying
to
figure
out
how
to
address
the
index,
but
it
wasn't
necessary
to
be
a
collection
of
multi-arc
images.
The
thought
process
up
until
just
recently
was
let's
use
manifested
index
as
is
and
put
other
artifact
types
in
there.
B
There
is
a
new
set
of
oci
oci
artifact,
manifest
that
I've
been
working
on
that.
I'm
we'll
actually
talk
in
a
couple
of
minutes
about,
hopefully
we
get
to
it.
That
is
trying
to
address
the
things
when
we
were
trying
to
squeeze
things
into
manifested
index
and
I'm
hoping
that'll
actually
do
two
things,
one.
Let
the
image
spec,
which
is
where
image
index
image
manifest
and
image
index,
are
defined
stay
and
they
can
evolve
as
they
want
and
there's
some
work
around.
B
So
I
think,
there's
a
good
healthy
question
to
have
like
should
ores
target
images,
because
there
are
lots
of
other
tools
out
there
like
a
mochi.
That
target
specifically
target
images
and
can
auras
can
and
should
auras
target
the
other
things
that
you
put
in
a
registry
that
attach
things
to
images
right.
We
use
auras
as
part
of
the
notary
work
because
we're
adding
a
signature
to
an
image.
We
would,
in
theory
use
it.
We
use
it
for
home,
where
you're,
adding
charts
that
define
an
image,
but
it
doesn't,
it
doesn't
need
to
manipulate
images.
G
I
don't,
I
don't
think
any
one
of
them
should
be
particularly
first-class
citizens.
The
only
thing
that
it
could
or
should
you
know,
handle
in
that
situation
is
like
when
we
get
into
how
to
address
additional
things
like
layers
or
chunks
or
whatever.
It
is
the
same
kind
of
garbage
collection
story
like
if
you
embed
anything
that
points
to
other
objects.
G
F
Yeah
from
my
perspective,
since
I
work
on
s-bombs
it,
it
kind
of
actually
makes
sense
to
you
know,
have
a
collection
of
blobs
that
represent
either
a
number
of
s-berms
or
one
s-sperm.
For
you
know,
one
package
and
the
oci
layout
looks
really
ideal
for
this,
making
those
kind
of
references
saying
that,
okay,
this
the
this
s
bomb
references
that
blob,
which
is
included
in
this
image,
which
you
pull
down
using
this
image
name
and
this
tag,
and
it's
one
of
those
things
that
are
not.
F
F
F
But
it
would
be
nice
to
have
like
the
one
tool
to
rule
them
all.
I
suppose
I
mean,
and
I
and
I
I
suppose,
I'm
throwing
them.
I'm
thinking
about
this
more,
like
you
know,
an
architectural
decision
than
a
user
interface
decision,
because
they're
all
they're
all
artifacts,
the
blobs
are
the
the
image
layers
are
artifacts.
F
B
No,
that
makes
sense.
I
think
I'm
wondering
if
this
is
just
a
good
conversation
to
have
with
a
bunch
of
people
that
are
on
the
auras
group
and
because
I
think,
there's
you
know,
there's
been
a
bunch
of
these
conversations
that
have
circled
around
this
space.
The
piece
that
I
felt
as
we
walked
away
from
the
last
round
of
conversations
was
not
really
the
image
part
of
it,
because
that
was
a
conversation,
and
I
thought
we
landed
that
one.
It
was
more
hey.
B
B
I
haven't
seen
anybody
blocked
by
it
the
the
issues
that
we've
got
currently
and,
in
fact
recently
we
had
the
security
thing
that
we
everybody
jumped
on.
It
was
happening
behind
the
scenes
because,
as
most
of
these
things
do
so,
we
have
the
right
activity
on
it.
We
were
just
trying
to
figure
what
the
right
process
was,
but
as
we
discussed
what
projects
go
in
oci
versus
cncf
or,
as
is
not
meant
to
be
like
hey,
the
world
knows
about
it,
everybody's
using
it.
It's
like
thousands
of
maintainers.
B
It's
a
core
infrastructure
piece
that
there'll
be
a
couple
people
working
on
it,
take
contributions
from
whoever
and
it
enables
a
whole
breadth
of
tools
and
those
other
tools
might
be
in
cncf.
But
the
idea
is,
it's
meant
to
be
kind
of
this
stable
platform,
piece
that
other
people
can
use.
But
that
said,
like
I
forgot
to
help
pronounce
his
name.
Josh
help
me,
who
is
the
guy?
That's
been
working,
adding
making
all
the
auditions
recently
from
israel.
B
F
E
So
I
think
just
I
don't
know,
I
don't,
I
think,
for
auras
to
be
part
of
the
like
microsoft,
open
source
thing
might
be
not
it.
I
think
it
will
be
healthier
if
it's
elsewhere
and
if
it's
not
going
to
support
images
it.
Maybe
it
belongs
somewhere
in
a
cloud
native
world,
but
I
think
for
it
to
be
more
supported.
I'm
not.
I
don't
know
that
just
because
it
becomes
under
one
of
those
orgs
it
becomes,
I'm
not
automatically
more
supported,
but
it
seems,
like
it's
kind
of
eyes,
are
pointed
at
microsoft.
B
And
we
really
don't,
we
want
to
shepherd
it
and
support
it,
yeah
we're
not
trying
to
own
this
like
this
is
not
a
microsoft
software
project
that
we
take
contributions,
an
open
source
project
that
we
want
to
support
and
and
have
multiple
maintainers
from
other
companies.
You
know
help
us.
We
just
we're
here
to
support
it.
F
Docker
ad
docker
commit
those
kind
of
things
or
build
up,
and
so
builder
has
like
container
build
private
primitives,
I
think
like
auras,
could
have
like
containerish
push-pull
primitives,
and
it
supports
it
supports
that
just
not
all
the
way.
So
I
I
can't
use
auras
to
push
index.json
to
oci
compatible
registries
right
now.
B
We
purposely
thought
purposely,
we
did
not
add
index
support
yet
and
I
think
we'll
I'm
hoping
the
other
if
we
get
to
it.
This
other
conversation
around
the
artifact
manifest
will
help
address
that.
Maybe
we
don't
need
to
add
an
index
support
if
we're
not
adding
multi-arc
image
tooling
around
or
as
if
we
do,
then
we
should
do
that,
but
if
oraz
is
supporting
all
the
things
that
around
images
all
the
other
artifact
types,
then
I'm
hoping
this
other
thing
actually
cracks
open.
C
You
know
the
fact
that
run
c
is
quite
a
unique
case,
so
I
I
think
what
we
have
to
be
careful
here
is,
like
you
know,
I
feel,
like
I've
seen
the
last
six
months,
like
everybody's
writing
registry
tools,
there's
a
bunch
of
new
ones
on
github,
which
is
good,
I
mean
that's,
that's
great
people
are
trying
out
different
things.
People
are
playing
with
multi-arc
they're
playing
with
indexes.
C
C
You
know
those
are
maybe
viable
oci
projects,
but
you
know
the
actual
tooling
really
should
should
be
something
that's.
It
doesn't
even
have
to
be
an
official
cncf
project,
but
you
know
that
there
should
be
communities
around
interesting
tools
that
people
create,
and
you
know
that's
how
you
know.
Docker
grew
to
be
where
it
is
with
things
like
build
kit
and
linux
kit-
and
you
know,
red
hat,
created
podman
and
build
on
all.
You
know,
there's
a
whole
community
of
tools
that
can
do
different,
interesting
things.
C
You
know
what
do
we
want
to
have
here
in
the
oci
and-
and
you
know
once
it's
a
full-fledged
tool
now
you
know
we
have
like
the
discussion
we're.
Having
should
it
support
indexes
should
a
support,
pushing
pulling
images
or
this
kind
of
artifact,
and
I
I
think
I
think
that's
where
it
gets
tricky
to
understand
why
you
know
is
there
a
scope
and
an
understanding
of
why
that
needs
to
be
oci
versus
just
a
basic
library
that
that
lets
other
people
build
all
kinds
of
registry
client,
tooling,
in
a
consistent
way.
H
That
being
said,
like
I,
don't
have
any
anything
against
the
aorus
project
or
I
think
it's,
I
think
it's
a
good
project,
but
you
know
I
see
stuff
like
this
new
distribution
organization
coming
along,
and
I
wonder
if
places
like
that
could
have
room
for
these
sort
of
like
sub-projects
in
the
future
that
seem
to
have
better
or
us
is
better
scope
for
that.
I
feel
like
than
an
oci.
B
No,
actually,
they
actually
on
the
distribution
thing
that
happened
this
morning,
so
their
distribution
did
get
donated
to
cncf.
Justin
cormack's
been
working
on
that
there
was
a
meeting
this
morning
where
they
finally
were
able
to
press
the
button
it
turns
out.
Distribution
was
owned
by
some
bot
type
account,
so
they
were
able
to
get
up.
Folks
were
able
to
clear
that
up
and
it
did
get
moved.
Justin
is
moving
working
on
an
announcement
for
that
he'll
get
out
next
week.
B
I
guess-
and
maybe
that
is
a
good
question
like
auras
under
deus
labs,
was
always
a
staging
ground
until
we
got
something
else
done
to
find
the
right
home.
So
if
it's
not
oci,
maybe
distribution
is
the
right.
One
distribution
is
a
reference
implementation
and
maybe
your
as
a
reference
implementation.
That's
a
great
that's
a
great
conversation.
In
fact.
Just
for
the
sake
of
time
I
don't
know,
I
feel
bad
because
there's
a
bunch
of
other
things
on
the
agenda-
and
I
know
josh-
is
trying
to
get
to
the
distribution
spec.
B
B
I
think
it's
one
option,
I
think
there's
there's
some
cleanup
that
we
would
want
to
do
to
or
as
regardless
there's
an
issue
that
specifically
talks
about
the
cleanup
and
refactoring
that
we
wanted
to
do
in
auras.
That
should
happen,
regardless
of
where
it
goes
whether
it
goes
to
oci
cncf
under
distribution,
which
is
also
cncf.
B
I
think
the
question
we
had
last
time
around
the
stuff
why
something
goes
in
oci
versus
cncf
cncf
was
pretty
healthy
and
felt
like.
I
can't
find
those
notes,
if
that
you
know
it
wasn't
meant
to
be
like
a
highly
active,
bigger
project
and
again
I'm
going
into
the
discussion
again
but
yeah.
That
was,
I
think
we
need
to
do
some
cleanup
and
then
we
should
decide.
Where
is
the
right
place
for
it
to
go?
B
I
know
that
we
want
800
ways
to
have
registry
tools
to
do
various
different
things.
It'd
be
nice.
If
we
part
of
this,
what
I'm
trying
to
do
with
the
artifacts
manifest
is
help
enhance
the
distribution
spec
to
have
the
set
of
capabilities
that
we
think
we
really
want,
including
eventual
search
and
some
of
the
other
things,
and
how
do
we
handle
deletes?
If
we
can
add
those
to
a
spec,
then
I
think
it
makes
it
really
easy
for
people
to
write
registry
tools
that
actually
work
across
all
registries.
C
So
I
posted
in
the
zoom
chat,
which
I
guess
I
should
have
put
in
hack
md,
but
pull
request
76
and
the
tob
both
has
a
link
to
a
hackmd
set
of
notes
from
our
tob
calls
last
spring
and
then,
of
course,
the
pull
request
itself
has
chatter
on.
You
know
some
of
that
discussion
around
what
what
do
we
think?
How
do
we
figure
out
how
to
make
those
decisions
about
oci
versus
elsewhere,
which
I
guess
reminds
me
that
it's
been
since
last
may
that
I
haven't
spent
the
next
rev
of
that.
G
E
E
A
lot
of
discussions
came
in
since
then,
but
essentially
we
we
dropped
the
ball
on
that,
so
we're
I
want
to
propose
that
we
cut
the
release
by
the
end
of
by
the
end
of
february
and
just
kind
of
do
away
with
it.
So
there's
two
issues
in
the
milestone
and
unless
there's
any
objections,
myself
or
peter
will
try
to
address
those
in
the
pr
and
if
I
could
have
help
from
the
maintainers
to
get
those
in
in
a
reasonable
time
and
we
can
hopefully
release
by
the
end
of
february.
E
E
That
just
basically
says
this
is
in
progress.
Look
at
this
issue,
so
I
think
things
like
that
and
in
the
zoom
chat
we're
talking
about
off
stuff.
I
think
we
can
push
that
to
a
3.1.
3.2
timeline
get
something
out
there.
It's
been
like
three
or
four
years.
So
that's
all
I
have
if
there's
any
I'm
sure,
there's
not
many
objections,
but
if
there's
any
objections
to
doing
less
to
be
done,
please
speak
now
or
in
the
issues
very
soon.
B
B
Okay,
so
buried
in
the
details
of
what
nisha's
kind
of
poking
on
is
we've
been
trying
to
figure
out.
How
do
we
handle
artifacts
that
have
other
references?
Cneb
has
been
the
historic
one,
whereas
you
have
a
top-level
thing
that
points
at
others.
It
turns
out
that
notary
actually
is
the
opposite.
I
want
to
be
able
to
put
something
in
the
registry
that
refers
to
something
that
is
already
there
and
we
don't
want
to
change
the
digest
or
the
tag
of
the
thing
we're
adding
signatures
to
right.
B
So
there
was
a
fundamental
design
point,
so
we've
been
iterating
on
this
for
a
while,
and
I
finally
had
some
time
to
spend
on
this,
and
I
wanted
to
try
to
capture
all
the
loose
ends
that
we've
been
saying.
We
really
want
to
be
able
to
store
these
additional
things
in
a
registry,
but
how
do
we
do
it
and
how
do
we
decouple
the
work?
That's
around
image,
spec,
sorry,
image
index
and
image
manifest
in
the
image
spec
and
maybe
decouple
this
a
little
bit
more
and
the
idea
was.
B
We
definitely
don't
want
to
have
a
manifest
for
every
artifact
type,
because
registry
operators
and
registry
tooling,
you
know
generic
registry
tooling.
That
would
be
a
huge
burden
if
you
I
keep
on
thinking
of
the
registry
as
being
a
cloud
file
system
api
in
a
very
overly
simplistic
model
and
there's
no
office
apis
for
saving
and
loading
files
to
the
disk
right.
There's
no
excel.
There's
no
go
library
for
well.
B
It
goes
out
of
good
courses,
you
get
what
I
mean,
there's
no
application
specific
apis
for
how
you
save
files,
there's
general
file
system,
apis
that
support
copying
deleting
moving
renaming
so
forth.
So
if
we're
going
to
put
things
into
a
registry
and
have
these
generic
apis,
we
need
a
way
to
say
well
what
is
the
thing?
What
is
a
way
to
describe
this
thing
with
some
more
flexibility
than
we've
had
with
manifest
and
index
to
date?
B
B
So
from
a
design
point
there's
a
couple
of
them,
one
of
which
is
artifacts,
are
going
to
move
within
and
across
registries.
So
how
do
you
define
something
so
that
the
graph
can
move
in
the
level
of
granularity
that
somebody
wants?
How
do
you
define
that
graph
in
such
a
way
that
tools
don't
need
to
know
about
specific
artifact
types?
So
I
just
have
some
examples
here
where
you've
got
in-depth
a
couple
of
images.
B
One
of
the
things
is
there's
a
couple
of.
If
you
look
at
things
like
pi,
pi
and
other
package
managers,
there's
an
interesting
deferred
resolution.
Some
things
are
defined
that
you
absolutely
have
to
define
right.
An
image
has
no
value
unless
you
have
the
layers.
There's
no
reason
to
have
layers,
not
you
know
uploaded
with
the
image
and
the
windows
foreign
layer
thing
is,
I
think
we
all
agree
was
wasn't
a
wonderful
thing.
B
It
was
a
legal
thing,
it
wasn't
something
and
we're
actually
trying
to
detangle
that
for
a
host
of
reasons,
so
that
is
nobody's
proud
of
it.
Nobody
was
proud
of
it
yeah
it
was.
It
was
one
of
those
that
we
had
to
do
something.
This
is
the
best
we
could
do.
This
is
not
an
answer
to
to
map
to
mirror
image.
B
So
neil
take
note,
please
don't
follow
that
pattern,
we're
trying
to
undo
it
so
back
to
the
point,
is
you
know,
an
image
only
makes
sense
that
the
layers
are
right
there
with
it,
but
a
signature
is
something
I
would
add
on
later
I
may
or
may
not
have
signatures.
At
the
same
token,
a
signature
has
no
value
on
it
unto
itself
right,
a
signature.
If
I
delete
the
image
and
the
thing
that
and
the
signature,
the
signature
should
be
deleted
with
it
and
if
what's
interesting
here
is
look
at.
B
B
So
what
we're
proposing
in
this
manifest
is
a
way
to
do
just
that
the
wordpress
image
can
look
down
as
layers
the
manifest
has
that
manifest
gets
uploaded.
It
has
a
digest,
has
a
tag
and
lives
all
itself
later
on.
I
can
add
any
number
of
signatures
that
defines
its
blobs
the
signature
itself,
but
can
also
say
hey
by
the
way
I
am
signing.
B
This
other
artifact
happens
to
be
an
image.
So
how
do
you
describe
that
in
a
manifest,
so
that
a
registry
can
parse
that
know
how
to
represent
it
know
how
to
return
it
in
a
listing
api?
I
don't
want
to
use
the
search
term
yet
in
the
list.
Api
and
also
the
registry
would
know
how
to
delete
the
things
that
are
dependent
on
the
image,
because
they
don't
believe
they
don't
have
a
standing
on
unto
themselves.
B
What
we
want
is
a
way
for
a
registry
can
know
about
what
it
references.
So
this
way,
as
I'm
copying
it
from
one
place
to
another
I
can
make.
I
have
the
option
of
copying
those
images
I
might
say
I
don't
want
to
copy
those
images,
that's
also
a
fair
thing,
but
I
have
the
ability
to
be
able
to
retarget
it.
B
So
if
I
copy
the
wordpress
chart
from
helmhub
and
it's
referencing
images
in
docker
hub,
if
I
copy
that
to
my
private
registry,
where
I
want
everything
in
my
environment
and
no
dependency
externally,
I
want
to
be
able
to
say
very
easily
hey
by
the
way
when
I
copy
this
in.
If
I
put
the
wordpress
and
my
sql
image
in
my
registry
and
the
wordpress
chart,
is
there,
I
can
very
easily
describe
that
graph
in
a
in
an
easy
way.
B
This
is
this
dotted
line
where
it
says:
hey,
it's
it's
a
loose
reference
and
if
I
go
in
one
step
further,
a
cnab
is
actually
another
super
collection.
This
is
the
one
that
we
tripped
up,
that
we
never
got
to
index,
and
I
think
this
might
be
a
better
answer
where
a
wordpress
has
a
direct
dependency
on
its
what's
referred
to
today
as
the
invocation
image.
B
But
the
indication
image
should
really
only
be
the
cli
that
it
needs
to
run
whatever
it's
doing.
The
wordpress
chart
be
really
nice
if
that
wasn't
embedded
in
this
invocation
image,
if
it
was
external
and
then
we're
just
repeating
what
we
saw
be
above,
where
the
wordpress
chart
references,
a
wordpress
image
and,
of
course,
wordpress
charts
could
reference.
Sorry
charts
can
reference
other
charts
so
there's
a
another
team
has
been
working
on
a
bunch
of
dependency
stuff.
B
So
the
kind
of
the
scenarios
that
I've
been
trying
to
think
about
that
we
can
represent
with
this
manifest
are
discovery
winner
discovery
in
a
registry
through
a
listing
api
or
you
know,
through
pixels
that
would
use
the
listing
api.
How
do
you
copy
within
and
across
how
do
we
manage
deletion
without
having
to
guess
and
without
having
to
know
specifically
about
each
artifact
type
and
enhancing
content?
So
this
is
the
what
notary
and
s
bombs?
B
Do
you
add
a
notary
and
s
bomb
to
an
existing
artifact
and,
of
course
we
want
to
do
validation,
but
I
want
to
make
sure
that
the
manifest
has
enough
information
that
you
can
validate
and
then
the
client
whoever's
doing
the
validation
can
decide
how
much
deep
validation
that
they
want.
Maybe
I
don't
need
to
validate
that
these
images
were
actually
uploaded
when
the
helm
chart.
Maybe
I
do
that's
like
a
by
having
the
schema
defined.
B
If
we
look
at
the
way
you
know
a
listing
could
work
today
I
have
the
image.
This
is
the
tag
I
have
the
layers
here
and
then
I
have
other
artifacts.
Now,
of
course,
in
registries
we
don't
list
the
layers
at
the
same
level
as
an
image
right.
The
layers
are
part
of
an
image,
so
we
don't
even
show
the
layers
you
can
drill
in.
If
you
want,
but
wouldn't
show
those
as
peers,
the
same
thing
should
be
for
a
signature,
a
signature
wouldn't
have
a
tag
and
even
have
it's
going
to
have
a
digest.
B
B
B
B
Yeah,
I
can,
it
might
make
more
sense
when
I
show
the
proposed
schema
that
does
this,
but
the
idea
is
an
s-bomb
is
just
like
notary.
You
would,
I
might
have
the
artifact
in
the
registry
already,
but
I
want
to
add
an
s-bomb
to
it.
The
idea
is,
you
would
want
to
be
able
to
define
that
in
a
way
that
again,
the
digest
of
the
image
shouldn't
have
to
change
and
or
whatever
the
s
bomb
is
being
associated
with
or
the
the
tag
shouldn't.
B
How
do
I
add
something
to
it
and
if
I
maybe
I'll
just
I'll
skip
down
to
it,
I'll
skip
down
to
it,
bring
it
in
people's
eyes,
then
people
can
tell
me
to
stop
or
what
you
want
to
do.
Here's
the
example,
for
instance,
of
how
that
schema
would
represent
a
an
image.
Sorry,
a
signature
to
an
image.
So
here
is
the
the
there's
a
couple
of
things
I've
lifted.
If
we're
going
to
define
this
schema,
I
was
hoping
I
could
clean
up
a
couple
of
things.
B
So,
first
of
all,
this
is
the
new
media
type.
Sorry,
the
new
manifest
type
an
oca
artifact
manifest.
So
now
we
would
basically
have
three
manifest
that
a
registry
would
support
people
that
wanted
us
to
register.
They
want
to
support
this
there's
instead
of
us
playing
this
game,
where
we
have
to
dig
into
the
config
media
type,
because
we
wanted
to
stuff
it
into
existing
schemas.
B
B
So
this,
except
for
this
element
right
here,
this
is
exactly
the
same
thing
as
an
image
spec
except
I
renamed
blobs.
The
new
piece
is:
there's
a
new
collection
called
dependencies
and
the
dependencies.
What
this
thing
is
saying,
we're
trying
to
figure
out
dependencies
depends
on
who
you
know
well
who's,
my
daddy.
B
The
idea
is
this.
Manifest
would
be
put
on
the
specific
repo,
because
we
couldn't
figure
out
why
dependence
artifact
types
wouldn't
need
to
reference
things
outside
of
its
repo.
So
we're
saying
that
the
notary
signature
would
be
same
put
in
the
same
repo
as
the
image
it's
signing,
so
we
really
only
need
the
digest.
B
So
this
thing
is
saying
I
am
attaching
myself
to
this
digest
and
now
we
have
the
ability
to
represent
a
signature
or
an
s-bomb
for
you,
nisha,
the
other
one
I'll
just
bring
it
up.
Real
quick
for
the
helm
chart
is
in
the
helm,
chart
scenario:
you
have
same
thing
blobs
that
make
up
the
helm
chart
again,
I'm
being
creative
in
this
josh,
just
to
kind
of
show,
what's
possible,
not
what's
actually
home's
doing,
but
now
what
it's
saying
in
this
stuff,
as
I'm
referring
to
in
here
now
we're
saying
references
which
are
loose.
B
References
are
referencing
the
wordpress
image
and
its
digest
the
my
sequel
image
and
its
digest,
and
by
having
the
digest
and
the
the
repo
and
tag
the
client
can
decide
if
it
wants
the
latest
version
of
mysql8
for
ones
that
are
patched
or
it
wants
to
pin
to
a
very
specific
one,
because
we
store
both
values.
You
have
the
ability
to
at
the
client,
decide
which
way
you
want
to
do.
A
B
That's
that's
cool
yeah,
so
it's!
What
it's
saying
is
the
image
this
this
artifact,
this
notary
signature,
has
no
value
unless
this
is
independent
of
this.
So
it's
dependent
on
this
image.
The
image
isn't
dependent
on
the
signature,
because
we're
introducing
the
idea
of
a
registry
being
able
to
do
a
kind
of
reverse
lookup
have
an
index
that
says
when
I
submit
this
image.
B
So
now
a
registry
would
be
able
to
not
only
know
what
it's
looking
down
on
right,
the
manifest
that
points
to
its
layers,
but
we
also
want
to
say
when
a
manifest
comes
in
and
says
I'm
looking
at
something
else
that
that
could
get
indexed
as
well,
because
the
beauty
here
is
you
don't
really
want
to
ask
for
a
signature.
What
you
really
want
to
ask
is
hey.
I
want
the
helm,
chart,
sorry,
the
wordpress
image.
Let
me
stick
with
wordpress.
B
F
B
So
now
the
container
d
client
will
be
able
to
call
a
generic
registry
api.
That
says,
give
me
all
the
things
that
are
referent,
that
reference
the
word,
my
sequel
image
and
it'll
get
back
a
collection.
We
have
a
product,
we
have
a
prototype
that
shows
you
can
filter
that
collection
on
the
media
type.
So
give
me
all
the
references
to
the
word.
Sorry,
I
keep
on
saying
wordpress
give
me
all
the
references
to
the
mysql
image
that
are
of
type
cncf
notaryv2.
B
So
now
I
can
say
all
right
before
container
even
runs
the
image
it
can
look
and
find
the
signatures
that
are
associated
with
it,
and
if
it's
got
a
key
that
matches
it
with
a
policy
that
says
run.
If
I,
if
it
has
a
signature
that
matches
my
key
now,
I
can
deploy
it.
That's
a
scenario
that
kind
of
makes
really
sense
that
a
container
d
or
a
docker,
client
or
things
that
are
containerish,
would
might
want
to
embed
into
their
experience.
F
B
I
B
B
What's
what
was
the
best
example
here,
so
a
mysql
image
has
signatures
that
were
added
to
it,
and
these
signatures
are
dependent
on
this
image.
Again,
I
don't
like
the
word,
I'm
not
sold.
The
idea
is
that
this
thing
as
a
solid
line
can't
exist
unless
it
here
the
helm
chart
has
a
reference
to
the
mysql
image,
but
it
doesn't
actually
have
to
be
in
the
same
registry
is
this:
is
this.
I
B
F
If
you're
talking
about
like
supply
chain
security,
then
the
idea
is
that
all
the
artifacts
that
come
with
determining
supply
chain
integrity
will
be.
Let's
say
it
requires
mysql
a
to
be
present
in
order
to
be
valid.
So
it's
like
a
it's
like
a
requires
versus
provides
so
steve.
If
you
can
correct
me
if
I'm
wrong
here,
but
it
sounds
like
the
helm
chart
will
provide
all
of
these
artifacts,
the
wordplay
press,
the
mysql8.
B
I
B
Say
no
so
this
is.
This
was
the
interesting
thing
I
was
learning
from
pie
pie
and
when
we
looked
at
it
because
in
full
transparency
like
one
of
the
things
well,
I
I
won't
open
that
rattle
the
like
pie,
pie,
references,
don't
actually
have
to
live
in
the
same
pipe
registry.
They
just
say
hey.
I
depend
on
this
thing,
but
it's
totally
valid
to
not
have
them
right
now
and
if
you
look
at
like
a
lot
of
the
helm,
charts
are
in
one
place
and
the
images
are
in
a
different
place.
B
B
The
idea
that
the
chart
references,
images
that
may
or
may
not
be
in
the
registry
and
that's
totally
okay
on
the
client
when
the
work
when
the
helm
cli
is
trying
to
validate
things
before
it
deploys,
because
actually,
if
you
think
about
when
a
home
chart
is
valid
on
a
client,
you
don't
have
the
images
on
the
client.
You
run
a
helm
chart
on
the
client
and
you're
telling
another
service
to
run
these
images.
B
So
the
idea
is
that
now
I
might
want
to
say
hey
before
I
do
a
helm
deploy.
Let
me
see
the
images
that
are
being
referenced,
because
then
it
will
be
described
in
this
manifest
yep
got
them.
I
can
go
find
all
those
now.
If
I
tell
them
it's
deployment,
I
have
a
chance
of
successful
deployment.
Credentials
might
not
be
right,
there's
other
things
why
the.
I
Fairest
from
a
security
point
of
view,
if
I
host
the
signature,
let's
say
on
on
a
pgp
of
like
ubuntu
or
something
like
that,
it
should
still
be
valid
right.
I
can
just
get
this
signature
from
anywhere.
It
doesn't
have
to
be
from
the
same
registry
where
I
got
the
image
from,
and
this
is
as
good
as
the
reference
I
can
at
runtime
exactly
when
I'm
instantiating
the
container.
I
can
do
these
verifications
when
I
have
all
the
pieces
together.
B
Wherever
they
come
from
you're
getting
some
great
conversations,
that's
part
of
the
notary
things
like
we
actually
are
saying
that
the
signature
would
be
in
the
registry
alongside
the
artifact.
It's
not
to
say
that
you
couldn't
have
it
elsewhere,
but
we
are
trying
to
make
sure
we
can
support
that
scenario.
B
So
it's
a
good
debate
to
have
in
in
the
notary
of
coupling,
but
from
a
from
this
conversation,
let's
just
say
we
want
to
make
sure
that
the
registry
can
support
it.
So
if
I
do
push
the
signature
to
the
registry,
does
the
signature
have
valid?
Is
the
signature
valid
if
it
can't
find
the
thing
it's
signing?
Maybe
that's
the
other
way
to
look
at
it
got
it.
Thank
you.
B
B
There's,
obviously
lots
of
things,
including
the
name
of
collections.
So
please
give
us
the
feedback
on
it
and
tell
us
what
we're
thinking
you
know
how
we
should
revolve
it
and
for
the
the
sep
comp
notify
oci
stuff
just
to
just
move
that
to
next
week
get
in
there
quick.
The
craig
folks
are
going
to
talk
about
some
cool
stuff
next
week
as
well
and
same
thing
for
john
for
the
listing
listing
stuff.