►
From YouTube: OCI Weekly Discussion - 2021-11-04
Description
Recording of the OCI weekly developer's call from 04 Nov 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#November-04-2021
A
B
C
C
We
are
at
five
after
so
why
don't
we
kick
off
like
tasia
the
floor?
Is.
E
Yours,
hello,
everyone
yeah
just
to
introduce
myself.
I
am
new
to
this
call.
My
name
is
tejaswini.
Although
people
call
me
teja,
I
work
microsoft
and
azure
container
registry
team,
so
I
want
to
bring
forth
some
discussion
around
the
extension
proposal
on
specification
is
going
on.
I
just
want
to
talk
about
how
we
can
implement
it
in
the
distribution
and
some
of
the.
What
do
you
say,
some
of
the
documentation
that
we
have
written?
E
I
just
want
to
bring
that
to
the
panel
here
and
then
get
some
feedback.
Pardon
me,
I
am
the
first
time
in
this
call.
I
don't
know
the
process.
How
a
document
is
reviewed.
Just
let
me
know
like
do.
I
need
to
walk
through
share
the
document
and
walk
through
the
sections
or
like
people
just
review
and
add
comments
for
some
like
we
will
take
the
first
few
minutes
or
so
give
time
to
people
to
review
the
document
and
then
we'll
take
the
discussion
later
yeah.
What's
the
process
usually.
C
C
D
Well,
I
think
I
think
the
the
goal
here
right
was
to
so.
We
have
a
proposed
change
to
the
specification,
and
you
know
we
want
to
figure
out
what
the
you
know
if
it
can
be
implemented,
and
so
we
kind
of
want
to
evaluate
it
right.
E
E
This
is
not
the
meeting
where
we
wanted
to
go
deep
into
the
distribution
details,
but
we
just
set
some
principles
like
a
guiding
principles,
so
maybe
I'm
looking
forward
to
get
some
feedback
on
that
is
that
direction
good
enough
to
go
or
like
that's
where
I'm
looking
for
some
recommendation,
so
I
just
pasted
the
md
document
so
as
per
steve,
let's
take
few
minutes
to
go
out.
The
document
just
add
as
many
comments
as
possible
and
then
we'll
go
over
all
those
questions
and
feedback.
F
D
Yeah,
it's
it's
pretty
short.
It's
only
about
three
pages,
maybe
a
paid
wow
or
like
two
pages,
probably.
B
B
Sure
so
the
you
actually
shared
some
go
code
on.
E
B
E
No,
no
yeah,
I
think
I
I
have
a
draft
pr
that
I
sent
out
for
distribution
if
you
want
to
take
a
look
at
the
code,
yeah
I'll
share
that
one.
This
is
the
pr
that
sajay
has
raised
and
it
has
all
the
details,
maybe
I'll
post
it
in
the
chat.
We
also
have
a
draft
pr
for
that
sample
extension
also,
and
we
are
working
on
getting
another
br
for
the
actual
auras
and
the
reference
api
as
an
extension.
D
Can
I
ask
a
quick
question
so
in
the
spec
we
have
ns
as
a
namespace
right.
However,
in
the
modification
you
have
here,
you've
used
ext
as
the
namespace.
E
E
Nobody
one
thing
stiffen.
I
think
there
is
a
conversation
on
that
specification,
pr,
even
putting
the
discovery,
a
price
under
a
well-known
kind
of
namespace
called
oci
underscore
oci
that
was
proposed
by
brandon.
D
Yeah
yeah
I'm
fine
with
ext
or
oci.
I'm
I'm
just
reloading
this
back
into
the
old
brain
here.
So
apologies.
If
I'm
I'm
asking
obvious
things.
D
C
D
C
D
E
So
I
think
I
have
got
some
five
comments
on
the
dark,
so
I
can
share
the
scene
and
go
out
the
comments.
It's
that
orchestra.
E
Here
josh
has
a
comment
on
the
fork.
I
just
pasted
the
link
to
the
draft
pr
which
has
the
actual
code.
E
E
D
We
can
discuss
that
a
little
more
offline.
I
was
just
talking
about
the
storage
driver
injection
on
when
you're,
creating
the
the
extension
sure
yeah
yeah.
All
in
all,
I
I
think
the
spec
looks
really
good.
You
know
I
I
you
know
say
that
the
distribution
project
can
go
in
and
iterate
on
the
implementation
and
get
everything
you
know
up
to
their
standards.
I
did
call
out.
There
is
one
thing
that
I
just
commented.
D
I
noticed
there
was
discussion
around
this
a
couple
days
ago
between
sudobe
mitch,
you
tasia,
and
then
I
I
added
on
here
and
I'll
link
that
in
here,
but
I
thought
the
when
I
read
the
ext
part.
I
was
slightly
confused
and
I
wonder
and
then
looking
at
your
implementation,
it's
slightly
confusing
because
our
extension,
our
discovery
extension,
doesn't
follow
the
the
conventions
of
our
extension
model,
which
is
like
namespace
component,
and
so
it
might
be
good
to
follow
our
conventions
for
that
discovery.
D
Yeah
yeah
yeah,
well
yeah.
My
suggestion
was
that
we
we
squat
on
the
ext
namespace
is
oci
so
that
other
people
can't
take
that
for
their
own
means
and
then
and
then
we
put
extension
extensions
under
that
namespace
and
so
like
my
proposal
in
there
is
to
have
an
extension
discover
for
extension
discovery
and
hopefully
that
seems
like
a
reasonable
is
brandon
on
the
call.
E
E
The
I
was
like
the
biggest
thing,
I'm
more
concerned
is
some
of
the
principles
that
I
I
just
wrote
down
as
basic
things
before
we
people
start
ordering
extensions,
so
these
guiding
principles
is
that
good
enough,
like
is
that
a
good
thing
to
start
on
when
we
other
new
extensions?
F
So
I
think
I
have
a
question.
You
know
sorry,
I
didn't
catch
this
before,
but
are
these?
Is
this
the
specification
describing
generic
extensions
or
the
discovery?
E
E
F
How
would
someone
know
whether
their
specific
extension
can
be
supported
or
not?
I'm
gonna
make
up
one
just
as
an
example,
although
brandon
or
was
it
jason,
there
is
a
proposal
out
there
to
add
a
base
image
to
a
manifest
suppose.
I
wanted
to
create
an
extension
that
queries
all
the
base,
images
that.
F
E
E
D
The
yeah
so
there's
two
discovery
mechanisms.
One
is
the
extensions
discovery
api,
which
is
what
we
were
kind
of
talking
about
earlier,
which
is
you
know
some.
It
gives
you
a
list
of
the
extensions
and
then
there's
also
a
portion
of
the
proposed
specification
that
has
a
an
error
code
that
should
be
returned,
so
basically
you'd
hit
the
path
and
it
would
come
back
with
like
a
404
and
say
extension
unknown.
D
So
there's
two
there's
two
methods:
the
extension,
the
extension
endpoint
is
probably
good
for
giving
early
user
feedback
like
you
know,
maybe
checking
things
and
then
the
direct
one
is
good
for
a
single
operation
that
you
might
have
in
a
tool
or
other
process
that
does
that
answer.
Your
question.
F
I
guess
somewhat
so
it
seems
to
me
that,
in
order
for
someone
to
be
able
to
use
the
extension,
it
needs
to
be
supported
by
a
specific
registry
and
in
order
to
specific
registry
provider,
I
suppose,
and
in
order
for
that
registry
provider,
to
support
it
need
to
implement
set
extension
yeah
how
how
okay?
Yes,.
C
C
That
was
one
of
the
the
things
that
was
coming
up,
but
the
the
I
actually
read
heard
nisha's
questions
a
little
differently
if
I'm
registering
an
extension
with
an
oci
in
this
in
the
path
that
was
mentioned
here,
where's
the
pointer
to
the
spec
for
how
you
implement.
That
extension
is
the
idea
that
the
spec
is
also
implemented
or
just
a
pointer
to
a
spec
to
an
external
entity
is,
is
defined
and
I
guess
versioning
as
well.
F
Yeah,
I
think
steve
got
it
right.
F
So
yeah
sorry,
I
was
well
I
mean
I
was
just
using
that
example.
As
a
way
of
asking
questions
like
this,
it
does
oci
want
to
support
reference.
Implementations
of
these
extensions
does
oci
want
to
provide
a
list
of
known
and
supported
or
known
extensions.
I
suppose
yeah.
D
I
actually
have
that
question,
so
I
linked
this
out
in
from
the
pr
actually.
I
do
have
that
a
similar
question
to
that
it
seems
like
the
line
that
oci
should
run
is
that
oci
would
host
the
specification
for
an
extension.
So
if
you
say
hey
I'm
going
to
build
this
extension,
you
define
how
it's
behaved
in
oci
and
then
the
implementations
can
choose
to
implement
it
or
not.
C
D
It
that
that
that's
my
question
right
so
like
do
we
do
we
centralize
the
registry
of
extensions
or,
or
you
know,
or
you
know,
or
do
we
have
a
set
of
extensions
that
are
standardized
and
they
are
standardized
standardizing
oci,
but
or
do
we
allow
external
definition
of
extensions.
F
So
I
I
have
a
stupid
go
question
because
I
don't
know,
go
and
all
of
these
components
are
implemented
in
go
but
does
go
support.
Plugins.
D
Kind
of
but
not
well,
there
are
ways
to
do
plug-ins
and
go
though,
like
there,
there
there's
a
couple
of
different
pro
one
one
project
you
can
set
up
like
a
like,
an
external
plug-in
that
you
use
as
kind
of
a
rpc
server.
There
is
plugins
supported
in
the
standard,
go
distribution,
but
they
have
to
be
compiled
specifically
for
the
version
of
source
that
you're
using
to
compile
the
upstream
project.
D
So
the
distribution
is,
is
somewhat
difficult,
but
not
in
the
sense
that
say
like
you,
can
ship
a
dll
and
have
it
get
linked
in
with
it
with
stable,
abby
and
stuff,
like
that,
no.
E
I
also
want
to
bring
up
like
in
the
original
extension
proposal
it
was
called
out.
There
is
some
extension
dot
amd
which
talks
about
the
extension
and
how
to
use
that
extension,
this
one
I
it
was
not
clear.
How
do
we,
where,
where
is
this
or
where
is
it
expected
to
be
placed
or
how
people
discovered
this
and
all
those
things,
and
how
is
this
tied
to
the
discovery
api.
E
This
one
little
touches
upon
like
nisha's
question
as
to
I
have
an
extension.
We
discovered
it.
How
do
we
know
about
that
extension?
Is
this
md
document
will
be
reviewed
by
the
oci
maintenance,
and
then
it
will
be
checked
in.
Is
that
what
will
that
be
the
extension
approval
process
or
like
what's
the
procedure
here.
D
I
mean
yeah,
that's
the
question
that
I
have
out
on
that
on
that
pr
I
mean
I
don't
understand
quite
what
else
you
want
to
do
with
the
discovery
at
the
registry
level.
Like
are
you
talking
about
discovering
like
like
having
more
user-facing
discovery
of
the
extensions
like
or
is
it
more
like.
D
E
E
On
the
registry
who
are
maintains
or
provides
that
registry
implementation,
how
do
we,
how
do
they
install
an
extension
or
like
what
will
be
the
distribution
of
those
extensions
model
like
do
they
have
to
check
into
the
distribution?
All
these
extensions
are:
how
do
we
streamline
that
process
of
having
all
these
extensions
in
the
distribution.
D
Yeah,
I
I
don't
think
that
oci
has
an
opinion
on
that
right
like
we're,
I
don't
think
we're
building
a
like
extension.
Like
a
registry
extension
distribution
model,
it
doesn't
that's
going
to
be
between
registry
providers
and
their
clients
and
as
as
what
extensions
they'll
actually
provide
which
are
implemented,
and
I
don't
see
us
doing
anything
where
it's
like.
We
have
a
standardized
extension
spec
that
you
can
like
load
in
as
a
plug-in,
at
least
in
this.
D
This
version
of
the
work,
this
version
of
the
work
is
only
how
do
I
you
know.
Where
do
I
put
a
extension
in
the
path
space?
How
do
I
query
whether
that
extension
is
present
right
and
then
how
do
I
specify
that
extension?
So
I
think
I
think
from
in
the
context
of
your
question.
I
think
the
answer
would
be:
no.
We
probably
aren't
gonna.
We
aren't
talking
about
a
a
registry
extension
distribution
model,
but
I
think
you
bring
up
a
point.
D
Namespace
and
that's
kind
of
an
open
question
I
had
on
the
proposal.
I
have
varying
opinions
about
that,
but
I
I'm
not
clear
on
what
the
like.
I
think
it
would
be
bad
if
two
entities
stepped
on
the
same
extension
name
space,
but
also
there's
no
reason
you
shouldn't
be
able
to
create
extensions
on
your
own
registry.
D
With
you
know,
without
you,
shouldn't
have
to
come
to
oci
to
ask
to
put
extensions
on
your
own
registry.
That
makes
any
sense.
E
D
D
It's
it's
the
the
second
to
last
link.
I
I
put
in
the
chat.
E
And
also
our
request
to
just
if
we
can
provide
some
feedback
on
the
draft
proposal
that
we
have
with
sample
extension
of
tag
history
and
manifest
listing
manifest.
That
would
also
be
appreciative.
So
there
is
a
document
for
the
tag,
history
and
list
manifest
extension
and
its
details
of
how
it's
implemented.
E
D
Yeah,
I
was
just
gonna
say
it
looks
like
my
goal
of
bringing
this
into
this.
Bringing
this
pr
into
this
forum
was
like
okay,
we
wrote
a
thing
that
we
theorized
was
right.
Looking
at
the
implementation,
there's
a
few
unclarities
that
we
need
to
make
and
respect,
but
all
in
all
the
concept
seems
reasonable.
So
I
think
a
goal
achieved
here
and
I
think
that
the
pr
looks
pretty
good
and
there's
some
clarifications.
We
need
to
make
in
the
spec
proposal
around
discovery,
so.
D
D
Yeah
yeah
and
throw
me
an
invite
to
that
one
I
haven't.
I
should
I'd,
be
interested
to
see
what
y'all
are
doing
these
days
so
because
you're,
probably
working
around
my
mistakes,.
B
Sorry
yeah,
my
dog
is
making
noises.
No,
I
was
gonna
say,
is
I
I
think
it's.
B
Oh,
my
god
I
was
gonna
say
is
that
I
think
it's
pretty
neat
that
you're
coming
to
this,
like
this
thing
has
been
open
for
years,
and
you
know
this
is
just
a
way
that
it
could
work.
I
guess
my
only
question
is
like:
does
it
work?
B
E
Yep
yeah,
you
can
fork
that
pr
branch
and
then
try
it
out.
Even
we
have
the
another
extension
which
we
haven't
created
a
draft
pr,
the
next
one
most
sophisticated.
I
would
say
extension
that
touches
some
of
the
storage
aspects,
because
here
we
are
introducing
the
new
manifest
type.
Even
this
was
also
plugged
in
as
an
extension
using
the
same
concepts
that
we
talked
in
the
dark.
Yeah
we'll
raise
this
pr
very
soon.
E
C
You
just
and
ronkomar
the
your
question
on
the
extensions.
You
know
that,
like
the
ones
that
go,
I
think
most
of
these
would
be
optional.
I
mean
that's.
One
of
the
things
we've
been
discussing
over
time
is
now
the
registries
are
implemented.
There's
always
a
time
factor
on
how
fast
registries
implement
any
changes.
C
C
I
think
the
idea
is
the
extensions,
are
all
extensions
are
probably
optional
unless
there's
a
new
version
of
the
spec
that
says
this
must,
but
I
think
that'll
always
be
tough
and
then
it's
just
a
matter
of
what
name
they're
in
I
don't
know
if
it
matters.
D
Yeah
I
I
yeah,
I
think
we
have
to
go
with
optional.
It
would
be
really
weird
for
us
to
say
this
extension
is
required.
This
is
the
question:
is
there
a
path
for
some
of
these
extensions
to
become
part
of
the
disspec
over
time
now,
like
perhaps
some
of
these
become
core
use
cases?
So
I
know
there's
discussions
about
like
a
like
a
v2
or
something
like
that.
D
I
think
if
there
are
core
use
cases
that
we
are
covering
with
extensions
in
v1,
we
should
bring
those
core
use
cases
up
in
in
v2.
Like
one
example,
I
could
call
out
is
first
class
tags.
That's
something
I'd
like
to
see
in
in
the
two
but
like
I
don't
have
a
like.
That
would
be
hard
to
introduce
with
extensions
and
it'd
be
hard
to
prove
out,
and
it
would.
D
A
core
part
of
the
b1
spec,
so
yeah.
If
there
really
are
core
use
cases
like
they,
you
know
we
should
try
to
move
them
as
early
as
possible
and
argue
they're,
you
know,
argue
their
role
as
a
core
use
case.
I
I
do
see
that
that's
difficult,
because
I
don't
know
if
we
have
a
great
criteria
for
what
makes
up
a
core
use
case.
C
I
think
with
that
we
can
give
folks
a
couple
of
minutes
back
and
let
the
pr
progress
sounds
like
we're
in
good
shape.