►
From YouTube: OCI Weekly Discussion - 2022-02-24
B
B
B
B
B
Did
did
you
say
image
given
spike
yeah,
we
were
being
really
productive
last
week
on
distribution
specs,
so
I
threw
in
like
the
queue
today
of
saying
hey.
Do
we
want
to
look
through
some
of
the
image
spec
pr's
to
try
to
clean
some
of
those
up,
and
then
I
started
looking
through?
Who
would
need
to
approve
them
and
I'm
just
thinking
we
don't
have
a
lot
of
maintainers
that
show
up
to
this
group
that
could
go
through
and
do
that
proving.
B
D
Yeah,
I
I
would
just
say
you
know,
for
the
record
that
there
isn't
really
a
requirement
that
maintainers
show
up
to
this
call
so
yeah.
The
bigger
signal
that
I'd
be
looking
for
is
our
maintainers
being
active
on
on
the
repository
itself
and
like
talking
on
issues
and
and
looking
at
pull
requests.
Things
like
that.
D
B
No,
no,
I
I
was
thinking
more
along
the
lines
of
do.
We
have
enough
people
to
make
progress
on
doing
some
cleaning
because
we
want
to
have
at
least
two
maintainers
to
approve
any
of
these
things,
and
we
don't
have
to
there's
no
point
in
no
point
in
fighting
through
it
but
yeah.
My
thought
process
for
today
was
just
kind
of
go
through.
We
got
a
couple.
Sorry,
that's
artifacts
fact
other
tab
here.
B
E
B
E
Well,
that's
where
encrypted
came
in
first,
and
that
was
during
the
time
when
artifacts
was
even
launched,
and
that
was
historically.
That
was
one
of
the
confusions
between
some
folks
that
thought
that
the
artifacts
repo
was
just
going
to
be
like
a
moving
like
not
spec
but
table
of
different
media
types
you
might
encounter
and
where
to
where
and
how
to
deal
with
them.
B
B
C
B
B
B
B
B
B
If
I
was
to
take
if
I
was
to
pull
the
actual
blob
for
that
layer,
so
I'm
looking
at
like
9d
2f.
If
I'm
reading
that
right
and
I
pull
that
specific
blob,
I
get
back.
Okay,
here's
a
whole
bunch
of
data
there
and
that's.
If
I
pull
that
blob
and
I
base64
encoded,
then
I
can
just
stick
a
field
that
says
here's
the
data
with
that
base64
data
right
there.
So.
B
B
E
E
E
E
E
F
B
C
D
B
D
B
Yeah,
I'm
trying
to
sort
out
do
we
need
to
hold
this
up
for
that
versus
what
their
concerns
be.
Orthogonal
to
this,
such
as
saying,
hey,
we're
we're
concerned
about
adding
any
other
unknown
thing,
not
just
this
one
field
here
we're
we're
not
worried
about
the
additional
data,
we're
worried
about
arbitrary
code
injection
or
something
like
that.
D
I
think
those
are
those
are
two
different
things.
So
in
one
respect
there
is
a
concern
around
unknown
fields
that
they
may
have,
which
I
don't
know
the
details
of
and
second
to
that,
if
you're
adding
this
as
a
known
field,
is
there
concern
around
the
the
data?
That's
actually
getting
embedded
in
there
and
those
are
those
are
two
different
concerns,
so
I
just
want
to
make
sure
that
they
have
you
know
if
they
have
concerns
around
it.
E
B
E
B
Yeah,
and
so
if
I,
if
I
were
able
to
get
something,
I
don't
think
I
probably
could,
but
if
I
attempted
to
get
something
approved
over
there
on
like
container
d
or
some
of
my
own
projects,
some
of
that
stuff,
you
might
see
this
data
in
there
three
times,
rather
than
just
once
so.
The
nice
thing
about
having
this
one
is
that
we
can
get
that
data
in
there
once
in
one
well
known
place,
instead
of
everybody
doing
individually.
G
B
F
I
I
wouldn't
expect
like
I
would
expect
clients
to
do
this
correctly
when
they're
producing
the
artifact
I
would
expect
clients
to
like
must
verify
that
it
matches
when
they
actually
use
this
field.
I
don't
actually
expect
registries
to
care
about
this
or
validate
it,
because
none
do
right
now,
and
so
this
has
to
work
even
if
they
don't,
which
it
does
and
so
like
you
could.
G
E
F
A
problem
if
registries
just
completely
ignore
this
field
like
there
are
a
lot
of
things
registries,
currently
don't
validate
and
keeping
registries.
Dumber
is
ideal
for
me
so,
like
I
wouldn't.
I
wouldn't
advocate
for
a
conformance
test
that
registries
do
this
validation
like
I
don't
know
that
we
have
a
conformance
test.
The
registries
validate
the
size
field
either,
like
most
registries,
didn't
the.
C
B
G
Manifest
does
fail
if
the
if
the
link
files
don't
exist
right
like
if
the
digest
doesn't
exist,
so
we
do
go
back
and
validate
the
storage,
so
I
think
my
question
is
like:
should
we?
How
would
we
write
the
conformance
test
for
this
field
if
we
did
have
this
field
in
schema
and
that's
kind
of
what
I'm
trying
to
understand
here
in
general?
I
think
I
do
support
this.
G
B
And
keep
in
mind
everything
we're
doing
here
is
on
image
specs.
So
we're
we're
not
saying
the
registries
have
like
an
api
response
to
this
one.
It's
just
an
extra
field
that
could
be
there
and
so
potentially
they
could
validate,
but
I
I
kind
of
tend
to
agree
with
john
that
I
wouldn't
require
them
to
validate.
B
I
also
want
to
point
out
you're
saying
if
the
we're
requiring
that
that
the
blob
exist
on
the
registry
already,
and
we
put
this
one
up,
I
think
I'm
looking
at
the
right
one
here
previously.
It
said
that
registries
don't
necessarily
have
to
validate
that
they
can,
but
they
don't
have
to,
and
it's
typically
a
best
practice
that
a
client
does
send
the
blob.
G
B
B
G
I
understand,
but
again
all
I'm
trying
to
say
is
that
we
in
the
conformance
test
say
that
we
do
not
validate
this
as
in
matching
the
digest
on
the
registry.
This
is
for
distribution,
not
for
image
spec,
because
for
image
spec,
we
actually
introduced
the
media
type
back,
because
distribution
had
a
bug
so
they're,
not
in
totally
disconnected
just
want
to
make
sure
that
we
clearly
specify
that
there
is
no
guarantee
that
these
may
match,
but
good
clients
are
expected
to
validate
it
on
the
client
that
keeps
the
messaging
clear.
Also.
F
F
D
E
E
B
B
A
A
A
B
A
B
A
A
C
B
B
B
I
kind
of
feel
like
we've.
We
have
stuff
in
here
in
oci,
there's
one
day
specific
in
the
past,
like
the
external
layers,
foreign
layer,
stuff,
that
we
regret
it.
After
doing,
or
at
least
some
people
regret
after
doing,
but
once
it
got
added,
people
could
use
it
for
all
kinds
of
stuff
going
forward,
and
so
it's
not
easy
to
get
back
out
again.
B
B
B
All
right
last
one
for
the
day
is
as
long
as
I'm
only
going
through
the
green
check
marks,
unless
somebody
has
something
they
want
to
throw
up
for
the
meeting
group
here,
because
I've
been
hogging
it
all
for
just
issue
spec,
but
yeah,
adding
c
and
rust
libraries
b
bats.
What
are
you
doing
to
us?
Why?
Why
are
you?
Why
are
you
throwing
this
in
there.
E
Yeah
and
then
I
think
the
guy
actually
said
that
there's
a
couple
of
other
libraries
that
are
more
useful.
So
you
know
this
is
where
things
can
become
a
long
tail,
but
I
forgot
honestly
forgot
that
we
had
an
implementations
page
and
it
is
kind
of
nice
to
at
least
you
know
if
people
are
using
it
or
calling
out
to
some
of
these
pieces
like
who
actually
uses
this
thing,
or
you
know
like
how
can
I
put
my
hands
on
it
rather
than
reading
a
very
exciting
spec?
E
B
E
A
B
B
Artifacts,
because
I
don't
know
if
we
have
anybody
that
does
artifacts
this
one
came
in
just
the
other
day,
it
looked
good
enough
to
help
chart
one.
I
have
a
lot
of
tabs
clean
up
when
I'm
done
with
this
page,
but
they're
just
changing
a
couple
of
media
types
to
match
what
helm
is
already
doing
today
and
so
they're
just
adjusting
some
of
the
fields.
I'll
drop.
This
link
over
here
as
well.