►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello:
everyone
today
we're
going
to
go
through
the
manifest
push
code
path
for
the
file
system
metadata
and,
let's
get
started,
we're
going
to
start
and
we're
going
to
look
at
the
diagram
for
pushes
just
to
review.
Although
it
is
not
going
to
be
particularly
helpful
for
today
and
you'll
see
in
a
second.
A
So
here
we
are,
we
have
the
diagram
and
so
last
episode
we
went
through
and
we
got
all
of
the
blob
stuff.
We
even
managed
to
get
across
a
depository
blob
mounting.
A
A
So,
let's
start
with
the
code
path,
then.
B
A
Just
reiterate:
if
you
want
to
know
more
about
the
structures
we're
talking
about,
I
explained
them
a
little
more
deeply
in
the
first
of
these,
which
is
the
push
of
the
pull
request
flow
video.
That
is
where
we
go
into
deep
dive
with
the
different
kind
of
objects
that
we're
going
to
be
talking
about
today.
A
A
A
So
the
first
thing
we
do
is
we
just
get
a
bytes
buffer
and
we
do
copy
full
path
payload,
which
we
saw
at
the
previous
video,
so
we're
just
reading
into
that
buffer
from
the
from
the
request,
so
we're
getting
that
out
of
the
body.
A
So
what
we're
doing
here
is
we're
getting
the
content
type
and
that
should
be
the
media
type
of
the
manifest
and
we'll
use
that
to
unmarshal
the
manifest
into.
A
A
distribution
manifest
which
is
pretty
generic,
but
it
is
something
we
can
work
with
in
the
code
a
little
easier
than
raw
bites.
So.
A
So
if
we
have
a
diet,
so
next
what
we're
going
to
do
if
there
is
a
digest
that
was,
if
this
is
put
by
digest,
then
the
digest
that
we
got
from
unmarshalling
it
needs
to
match
the
digest
that
it's
put
by
it.
So
we
can't
put
it
into
you
know:
digest
is
a
you
know,
and
we
had
marshall
it
and
we
said
like
well,
we
hash
it
and
it's
it's
b
we're
not
going
to
put
b
into
a
for
example,
because
it's
got
to
address
the
storage.
A
A
B
A
You
know
it
could
be:
maybe
the
manifest
body
didn't
come
through
correctly
over
the
wire.
It
is
a
little
odd
how
often
we
get
it,
but
it's
not
often
enough
to
to
really
worry
about.
A
A
It
appears
so
you'll
see
that
occasionally
yep
yeah,
so,
but
if,
if
we
are
putting
it
by
tag,
we're
going
to
do
a
we're
just
going
to
set
the
digest
of
the
handler
to
be
the
digest
that
we
got
from
unmarshing
it
so
and
I'm
not
sure
I've
ever
seen
this
this
era,
like
I
don't
it's
part
of
the
route,
so
how?
How
would
that
would
just
be
a
pretty
that'd,
be
a
pretty
funny
one
to
see
in
real
life
but
yeah.
A
A
You
know
spec
that
we're
trying
to
get
wider
adoption
for,
ideally
if
they
should
all
be
oci
manifest
we
shouldn't
be
using
docker
manifests
after
you
know,
in
a
perfect
world
we
would
not
have
docker
manifests,
we
would
just
be.
Everyone
uses
the
oci
standard
right.
B
And
that's
on
that
note:
do
you
have
like
a
registry
where
you
can
get
oci
manifest
because
you
know
pulling
from
the
docker
their
registry
they're
all
docker
manifests.
A
And
docker
you
know
I'm
gonna
spill.
The
secret
is
oci
manifest
docker
manifesto
very
similar.
A
So
it's
not
that
big
of
a
difference,
but
it's
a
client
decision
of
how
it
builds
the
manifest.
A
So
it's
not
like,
if
you
get
an
image
from
docker
hub,
for
example,
nothing
about
that
makes
it
be
a
docker
manifest
it's
100,
client
based.
You
know
we
could
choose
to
refuse
any
ocm
manifest
it's
something
that
we
could
do
as
an
implementation.
It
would
be
a
strange
thing
to
do,
but
typically
you'd
expect
that
all
this
to
be
like
a
client
decision
as
long
as
they
do
it
right
as
long
as
the
registry
knows
how
to
handle
it.
B
A
Well,
yeah,
a
docker
client
will
usually
make
a
docker
manifest,
there's
cases
where
it
won't,
but
those
are
cases
where.
A
It's
it's
a
bit
of
an
edge
case
than
what
I'm
thinking
of,
and
so
here
is
the
well
actually
just
hitting
the
edge
case
on
the
code.
So
one
of
the
things
we're
doing
here
is
we're
looking
to
see
if
it's
a
manifest
list.
So
manifest
list
is
what
the
is.
What
you'll
generally
call
a
docker
manifest
list?
A
multi-arch
manifest
is
what
they're
usually
used
for
so
this
manifestless
deserialized
manifest
list
that
also
includes
oci
image
indexes,
unlike
the
two
sort
of
like
like
regular
manifests.
A
I
guess
it's
not
not
the
best
way
to
say
it,
but
you
know
the
ones
that
you're
more
familiar
with
as
a
user
that
are
just
like
an
image
they're
implemented
as
two
different
kind
of
two
different
separate
objects:
oci
image
indexes
and
docker
manifest
lists,
they're
implemented
as
the
same
object,
which
is
it's
good
and
bad.
A
There
are
definitely
conveniences
to
just
having
a
manifest
less
as
a
manifest
list
as
a
manifest
list,
but
one
of
the
things
that
we
encountered
is
that
it's
you
know.
Sometimes
we
get
something
we
don't
expect
and
there's
a
particular
use
case
which
build
kit
will
put.
A
Like
layers
in
a
manifest
list
and
that
that
is
something
we're
tracking
here,
it's
it's
a
bit
of
a
surprise.
It's
a
bit
of
an
odd
thing
to
encounter
in
that.
I
can
give
you
more
context.
I
don't
want
to
get
too
heavy
into
it,
because
it's
such
a
such
a
niche
thing
in
this
video,
but
we
can
definitely
catch
you
up
in
particular
on
it,
because
it
will
start
to
matter
very
soon.
A
Then
we
apply
resource
policies.
We
can
go
back
and
look
at
that
later,
it's
not
too
interesting
and
then
just
like
we
did
for
the
pulse.
We
have
something
that
just.
A
Sort
of
smooths
out
the
differences
between
using
the
database
and
using
the
file
system,
the
manifest
handler
is
by
far
the
most
complicated
of
all
the
handlers
like
there's
just
more
there's
the
most
stuff
to
do
so,
it's
easier
to
just
have
something
that
takes
that
logic,
and
this
instructor
basically
figures
out.
Are
we
using
the
database
or
are
we
not,
and
so
then
we
just
put
the
manifest
and
that
puts
it
by
digest
into
storage.
A
So
if
you're
thinking
about
paths.go,
that's
going
to
be
you
know,
repositories
underscore
manifests
current
revision.
You
know
something
like
revisions
current
or
something
like
that
and
then
later
in
a
separate
operation.
We
tag
it
and.
A
And
that's
just
a
header
that
we
set
for
the
client
be
like
this
is
where
you
can
get
that
manifest
that
you
just
put
so
we
give
them
the
digest
back.
We
say
that
we
created
it
and
we
do
some
logging
for
our
purposes
our
metrical
metric
gathering
purposes.
A
A
Yeah,
let's
just
look
at
the
manifest
writer.
Sorry
I
don't
want
to
get
into
that.
It's
just
there's
a
lot
to
it.
So
there's
a
lot
to
why
we
have
to
do
that
for
the
migration
and
stuff
so
fastest
to
manifest
writer.
We
have
the
tag
store.
We
have
the
manifest
store,
so
the
tag
stores
the
tag
store
that
we've
explored
another
other
in
the
first
video
and
we
have
the
manifest
service,
which
is
the
linked
blob
store.
That's
configured
to
link
into
the
manifests.
A
A
A
So
we
look
and
see
if
the
content's
already
present,
so
we
get
the
digest
again.
Wait
is
this
oh
yeah
yeah,
so
we
get
the
digest
again,
but
we,
you
know
static,
hey,
is
it
present
or
did
you
get
an
error?
A
Oh,
if
we
get
an
error,
that's
not
distribution,
blob,
unknown
distribution,
error,
blob
unknowns!
That's
just
like
the
404
of
the
of
the
distribution
errors.
Okay
with
this,
we
don't
know
about
this
blob,
it's
not
there.
It
shouldn't
be.
A
You
know
a
bad
error,
I
guess
it's
just
like
translating
file
not
found
from
the
storage
driver,
basically
there.
So
we
get
the
path
from
the
digest,
and
that
is.
A
A
A
So
if
that
goes,
okay,
we
return
a
descriptor
here's
the
size
of
the
content,
it's
an
application,
octet
stream,
because
it's
just
a
blob
at
this
point,
because
the
bob
store
only
knows
bob's.
It's
you
know,
even
though
it's
a
manifest
we're
going
to
say
it's
application,
octet
strain.
We
give
the
digest
and
then
in
a
pattern
that
I
dislike
heavily.
A
We
do
a
massive
operation
at
the
very
end
and
return
the
error
from
that.
A
A
But
then
we
do
set
set
descriptor
and
again
that's
part
of
the
the
blobs,
the
bob
descriptor
cache.
So
that's
just
setting
the
setting
that
up
making
sure
that
the
cache
knows
about
it
if
it's
configured
and
then
we
do
link
blob.
A
So
what
is
that
and
we'll
go
back
to
the
past
that
go
and
that
is
going
to
be
repositories,
name
and
repository
underscore
manifest
revisions
shot
256
almost
always,
then
the
digest
and
then
link.
So
that's
where
the
manifests
live
in
the
metadata.
A
A
So
any
questions
about
all
that.
A
Okay,
all
right,
so
then,
with
the
manifest
writer,
we
do
text
or
tag.
So
let's
look
at
the
tag
store.
A
A
So
I
was
only
blob
store
and
the
link
path
function
is
the
manifest
tag
index
entry
link
path,
spec.
So
let's
look
at
that
manifest
tag.
Entry
link
pass
back
is.
A
A
This,
what
this
does
is
it's
sort
of
a
reverse
lookup.
So
if
I
have
a
manifest,
we
can
say
what
are
the
tags
and
if
we
get
delete
manifest
today,
we'll
see
that
in
action
not
just
not
to
spoil
it,
so
we
will
first,
we
link
the
blob
into
the
index
and
then
we
will
overwrite
the
link
so
that
this
is
the.
A
This
is
the
regular
sort
of
tag
path.
This
is
the
tag
path
that
you
you
think
of
when
you
yep,
and
it's
just
put
content
we're
just
writing
to
that
link
file.
So
it
might
be
easier
to
review
this
so
first,
we
put
it
in.
A
You
put
it
in
this
location
first
right
here
and
that's
just
sort
of
an
index
for
a
kind
of
reverse
lookup,
and
then
this
is
the.
This
is
the
tag
that
you
think
of
so
the
current
link,
which
is
pretty
easy
to
remember
so
current
link,
is
how
this
is
where
you'll
look
when
you
say
like:
oh
pull,
pull
this
tag
down,
it's
gonna!
Look
here,
always
that's
and
that's
what
you
think
of
when
you
push,
and
this
is
going
to
get
overridden
as.
A
A
It's
gonna
overwrite
this
link
file
with
the
digest,
so
this
file
is
mutable
and
tags
are
one
of
the
very
few
things
in
the
registry.
That's
mutable!
In
that
way.
That's
not
just
you
either
write
it
or
delete
it.
This
is
one
of
the
few
things
you
can
actually
edit
on
the
registry,
and
so
when
tags
are
involved,
things
get
a
bit
trickier
because
mutability
makes
things
trickier
as
as
any
programmer
knows
so.
A
A
All
store,
so
that's
it,
you
know
the
file
system
version
of
the
put
is
actually
relatively
easy,
but
I
feel
like
we're
forgetting
something.
Oh
yes,
we
very
much
are.
A
A
A
A
A
So
before
the
puts
we
were
talking
about
before
the
tags,
this
is
this
is
before
we
put
the
manifest
blob
into
the
blob
storage.
So
hopefully
that's
clear,
we'll
switch
on
the
type
and
see
what
kind
of
manifest
we
have
and
it's
the
it's
deferred
to
these
storage
handlers.
So
each
of
these
handlers
knows
how
to
put
a
particular
manifest.
A
A
A
So
the
big
thing
is
that
we're
going
to-
and
this
is
the
part
we
talked
about-
where
it's
putting
it
into
blob
storage.
So
the
big
thing
here
is
we're
going
to
talk
about
verify
manifest
stuff.
So
these
had
to
be
split
out,
but
we
now
use
little
validators
because
the
path
that
it
takes
was
in
the
database
does
something
a
bit
differently
than
these,
but
we
need
to
have
the
same
validation
logic.
A
So
it's
this
is
a
little
bit
of
an
odd
function
now,
but
let's
explore
the
logic
in
the
validation
step.
So
this
is
just
for
shima
2
manifests
and
what
we
could
check
is
that
a
manifest
exists
and
we
have
a
interface
that
can
only
do
that.
We
have
a
blob
saturn
that
can
only
stop
blobs.
So
you
need
to
check
if
the
layers
exist
skip
dependency,
verification.
A
You
actually
cannot
skip
this
for
the
api,
so
we're
not
going
to
talk
about
it
too
much.
That's
a
pull
through
cache
thing,
a
reference
limit
which
is
new
in-
and
you
know
it's
very
straightforward.
It's
limited
number
of
references
that
you
can
have
and
the
manifest
urls
are
for
something
called
foreign
layers,
which
is.
A
We're
just
gonna
we're
gonna
gloss
over
it
because
it's
it's
a
bit.
It's
a
bit
fussy.
To
be
honest,
so
we
do
a
little
version
like
shima
version
check.
You
know,
that's
not
too
difficult.
We
count
the
references
here
in
this
little
helper
function
because
it's
the
same
for
all
manifest.
So
all
that
is
is
is
the
length
of
the
references
greater
than
the
length
of
the
limit.
A
You
know
it's
not
that
I'm
not
that
involved.
A
If
we
skip
dependency
verifications,
we
just
stop
here,
but
we'd
never
do
that
for
the
api,
so
we're
going
to
do
references
and
this
references
function
for
a
schema
to
manifest.
That's
it's
like
a
like
a
docker
image.
That's
going
to
be
the
configuration
blob
and
each
layer
for
a
manifest
list.
That's
going
to
be
all
the
manifest
that
it
lists.
A
So
that's
so
keep
that
in
mind.
This
is
not
references
does
not
mean
layers,
it
almost
does
and
it
almost
mostly
does
most
of
the
time,
but
it
does
not
mean
layers
you'll
get
different
stuff,
so
we
just
do
some
different
stuff,
so
we'll
switch
on
the
media
type.
A
So
this
is
the
foreign
layer
we
need
to.
It
needs
to
have
urls
at
least
one,
and
we
need
to
make
sure
that
the
url
passes
the
valid
year.
So
the
the
the
manifest
urls
are
just
reg
x's.
So
we
need
to
make
sure
that,
because
the
registry
is
not
configured
to
block
particular
urls,
all
right,
so
in
the
case
that
it
is
a
shima
2
or
she
made
one
manifest,
it
checks
the
existence
of
the
manifest,
and
this
is
weird
I.
B
A
Asked
and
I've
never
seen
this
in
real
life.
I've
never
seen
it
anywhere
that
ashima
team
manifest
would
have
manifest
as
a
as
a
reference.
You
know
it's
all,
it's
all
config
blob
or
layers.
So
it's
pretty.
This
is
sort
of
lost
to
time
why
this
is
here,
but
it's
pretty
surprising
to
see,
but
in
any
case,
if
we
do
encounter
that,
we
will
also
check
the
blob
stores.
If
it's
not
a
foreign
layer,
which
is
what
this
check
is.
A
So
if
it
doesn't
have
any
urls,
it's
not
a
foreign
layer,
so
we
just
stop
and
if
the
error
is
arab
unknown,
we
pin
it
to
the
list
of
errors
that
you
can
get
in
validation
and
we
always
append
this
era
manifest
blob
unknown
at
the
end.
A
So
and
if
there
are
no
errors,
we
return
nil.
There's
errors
return
errors.
So
this
is
a
little
weird
because
it
catches
this.
This
is
not
that
complicated.
You
know.
A
Let's,
let's
say
you
know
mostly
what
you're
going
to
get
is
this
code
right
here
like
this,
is
what's
going
to
execute
99.99
of
the
time,
so
we
just
basically
set
every
layer
and
make
sure
it's
there
for
the
most
part,
but
since
it's
validation,
it
does
have
to
catch
all
the
possibilities.
Everything
that
a
manifest
can
be.
It
needs
to
catch.
This.
A
Is
also
interesting,
this
I
will
just
shima
we'll
do
oci
too.
Actually
just
so,
we
can
go
through
them
and
see
them
multiple
times,
because
these
are
where
these
are,
where
the
differences
really
start
to
matter,
yeah
so
same
things
like
is
it
a?
Do?
We
have
the
right
shima
version.
A
Does
it
exceed
the
references
limit?
Are
we
skipping
dependency
verification?
No,
so
all
that's
fine.
We
check
every
reference
so,
and
this
is
really
close
to
the
shima
2,
but
the
media
types
are
different,
so
we
check
the
foreign
layers
are
the
urls?
Are
they
blocked
by
the
registry
configuration.
A
If
they
yeah,
the
logic
is
written
differently
here.
So
this
is
like
anything.
Then
we
check
and
see
if
it's
not
if
it's,
if
it's
a
foreign
layer,
four
yeah
for
every
range
near
l,
which,
if
so
like,
if
there's
no
urls,
we
skip
this
and
then
we
always
check
the
blob
store.
So
it's
doing
the
same
thing
just
differently.
I
think
mostly
the
same
thing
I
think,
with.
A
There
might
be
some
differences
in
what
like
a
docker
layer,
media
media
type
and
a
and
a
ocm.
Mediatek
can
do
I'm
not
I'm
not
100
sure
this
is.
This
is
one
of
those
things
where
all
the
edge
cases
of
the
spec
and
all
the
weird
use
cases
of
like
the
ecosystem,
like
as
it
actually
exists.
This
is
where
it
sort
of
happens.
A
This
is
where
it
matters
and
again,
if
it's
a
manifest,
but
I've
never
seen
this
it'll
check
for
the
manifest
and
we
also
stat
the
blob
storage,
again
distribution
bob
unknown
in
the
air.
If
that
is
oh
sorry,
this
is
a
that
gets
me
every
time.
It's.
If
the
error
is
not
distribution,
blob
unknown,
we
will
append
it,
especially
if
there's
any
otherwise.
A
We
expect
the
error
to
be
distribution
blob
unknown,
and
we
need
to
always
append
this.
The
the
error
manifest
blob
unknown
to
the
detail,
because
when
the
push
fails,
you'll
get
in
the
detail,
you
get
a
list
of
shots
that
were
wrong
in
some
way
and
theoretically,
the
client
can
take
that
error
and
respond
to
it.
A
A
So
that's
that's
very
similar,
and
this
is
code
that,
if
you're
working
with
it's
worth
to
really
look
at
it,
you
know
because
there
are
you
don't
want
it
to
be
subtly
wrong
and
it's
really
easy
for
that
good
to
be
subtly
wrong
just
because
of
the
nature
of
what
it
is
so,
and
this
is
a
manifest
list.
So
this
is
going
to
account
for
docker
manifest
lists
and
oci
image
indexes
it's
much
the
same
thing,
the
shima
version,
2
great,
doesn't
exceed
the
ref
limits.
Great
we're,
not
skipping
dependency,
verification.
A
We're
gonna
skip
that
this
is
the
so
this
is
the
build
x
cache
which
is
like
it
will
look
like
a
manifest
list.
It'll
have
that
content
structure,
but
it
will
have
blobs.
So
if
we
detect
it
we'll
set
the
blobs
instead
and
that's
just
the
same
as
the
end
of
shima
2
and
oci
validation
steps.
So
that's
a
weird
one.
It's
worth
reading
this
comment.
A
So
if
it's
like
you
know,
the
error
is
just
like
an
unknown
error.
We're
done
on
error,
we're
also
going
to
say
manifest
blob
unknown
just
to
give
the
client
some
information
back.
That's
consistent
over
different
types
of
errors,
and
then
you
know
if
everything's
checked
out,
we
will
just
return.
No,
so
I
know
that's
a
lot.
Is
there
any
questions
with
that.
B
A
A
So
we
have
some
extra
time.
Let's
check
out
the
manifest
delete.
A
A
This
is
the
other.
This
is
the
other
place
that
the
tag
store
puts
information
about.
So
this
is
like
the
look
up
by
digest.
So
every
tag
that
points
to
this
digest
and
then
for
each
tag
in
the
reference
tags,
we
untag
it
so
we're
just
deleting
that
link
so
that
doesn't
sound
too
difficult,
but
there
are
a
number
of
problems
with
this
method
which
make
it
problematic.
A
Shall
we
say
so
one
we
delete
them.
Let's
say
we
delete
this
manifest
great
and
then,
when
we're
doing
tag
service
lookup
we
get
an
error.
Then
we
return,
so
we
haven't
actually
unlinked
any
tags.
So
it's
like.
We
have
dangling
tags
now,
so
let's
go
ahead
and
call
that
delete
again,
so
we
call
manifest
deletes
and
then
there's
an
error
because
we're
not
finding
that
manifest
and
return,
which
means
that
the
now
these
these
tags
are
dangling
and
you
cannot
get
to
them.
A
You
can't
delete
these
tags
anymore
because
you're,
always
you
always
error
out
when
you
try
to
delete
the
manifest
that
doesn't
exist
because
you
deleted
it.
Another
thing
that
happens
is
to
look
up
the
tags.
A
A
So
text
for
all
just
gets
all
the
tags,
nothing
exciting.
So
for
every
tag
we
open
the
you
know
we
read
that
digest
out
of
the
tag
link
path
and
then
you
know
we
append
it
to
the
list
of
tags.
If
the
tag
digest
equals
the
descriptor
digest,
then
we
return
the
tags.
A
A
It
is
exciting
and
that's
one
of
the
cool
things
about
the
database
because
we
just
say
on
delete
cascade.
A
B
A
So
the
things
we
there's
an
issue
for
this
actually
so
there's
a
couple
ways
you
could
do
this.
The
the
meat
and
potatoes
of
this
is
that
we
now
have
a
tag
delete
which
is
just
that's
how
we
operate
if
you're,
using
our
database
with
rails.
When
you
delete
a
tag,
it
just
deletes
the
tag,
it
doesn't
delete
the
manifest-
and
that's
like
that's
just
that's
just
this
untagged
operation,
where
the
links
the
link
deletes
the
link.
So
it's
a
bit
more
economical
in
that
way.
A
A
Yes,
I'm
gonna,
I'm
gonna
shop.
Stop
the
screen
share.
Just
as
we
you
know,
talk
more
questions
so
yeah,
that's
that's
the
long
and
short
of
the
code
path.
I
mean
that's
the
you
know.
I
think
we
didn't
talk
about
tag
delete.
It's
not
particularly
interesting.
We
didn't
talk
about
list,
it's
also
not.
A
Super
complicated,
but
it
might
be
a
good
one
for
you
to
explore
on
your
own
now
that
you've
seen
me
jump
through
so
that
I
think,
would
be
a
good
one
for
you
in
particular,
as
your
onboarding
to
look
at
the
list
and
that's
tag.
So
it's
it's
a
it's
under
the
tags
handler.
So
look
at
the
tags
list
and
see
if
you
can
go
through
the
layers
like
I've
done
in
the
past
few
days.
A
A
You
know
that
I
think
that's
a
little
like
a
little
easier,
so
yeah
try
to
go
through
that
you'll
have
all
the
you'll.
Have
you
know
a
lot
of
the
the
same
kind
of
components
to
look
through
so
yeah?
I
think
that
would
be
a
good
one
for
you
to
do.
B
B
A
So
that's
that
is
that's
great.
That
is
the
one
that
is
one
of
the
non-repository
scoped
requests.
We
have
another
one
and
we've
skipped
it
every
time,
but
it's
the
the
v2
endpoint
right,
where
it's
just
like.
B
A
Are
you
a
v2
registrar,
ain't
ya,
so
yeah
the
the
the
coward
list
is
interesting,
a
we'll
be
working
on
that
because
the
spec
is
pretty
open
on
it
and
it'd
be
nice
to
give
that
some
functionality
for
com
that
regular
users
can
use.
So
that's
something
that
we'll
be.
We
will
be
revisiting
it
after
the
database
was
all
migrated.