►
From YouTube: OCI Weekly Discussion - 2020-10-28
Description
The OCI weekly developer's call recording from Oct 28, 2020. Agenda and notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#October-28-2020
B
B
B
D
D
D
F
B
D
B
C
C
But
there's
just
a
few
that
I
wanted
to
talk
about
with
everybody
that
we're
kind
of
some
of
them
were
not
sure
about
or
just
wanted
to
check
on
how
people
feel
about
it.
So
I'll
just
go
through
these
one
by
one,
just
one,
two,
three,
four:
six:
six
different
things,
so
I
don't
want
to
spend
too
much
time
on
one
topic,
but
so
the
first
one
is
mike
brown
note
regarding
process
section
that
is
being
removed
from
the
specification
text.
C
C
C
And
if
you
read
this
through
this
issue,
there's
some
conversation
between
me
and
rom,
and
my
last
comment
was
regarding
like
having
a
common
api.
Think
about
something
like
kubernetes.
Where
you're
I
mean
you
can
obviously
use
kubernetes
to
publish
images.
Don't
get
me
wrong,
but
in
a
general
usage
of
a
kubernetes
system,
you're
going
to
be
downloading
images
from
registries,
and
you
don't
really
care
about
these
three
other
scenarios.
So
I'm
wondering.
C
B
B
I
think
if
we
want
to
have
experiences
like
the
helm
cli,
which
is
in
the
active
conversation
today,
at
least
the
circle
11
or
auras
or
any
of
the
other
things.
The
whole
goal
here
is
we're
trying
to
create
a
stable
ecosystem,
so
developers
project
owners.
You
know
the
community
can
build
a
set
of
tools
that
they
don't
just
work.
B
A
Well,
I
I
think,
there's
a
difference
between
whether
a
registry
supports
it
or
whether
a
use
case
in
the
implementation
of
it
is
just
say
one
of
them.
I
could
you
know
so
for
poll
I
could
imagine
a
read-only
registry
for
people
to
be
able
to
pull
content
down,
but
because
it's
public,
they
don't
want
to
be
able
to
have
push
access
to
that
for
say,
more
private
images,
yeah.
B
No,
I
mean,
I
think,
that's
exactly
the
mcr
scenario,
but
we
don't
let
anybody
outside
of
microsoft.
Push
in
fact,
even
microsoft.
Employees
can't
push
there's
a
gated
workflow,
but
the
registry
itself
supports
push,
but
I'm
also
not
looking
to
have
mcr
show
up
on
some
conformance
test
that
customers
are
going
to
use
that
it
matters
and
like
if
you
I'll
just
pick
on
harbor
for
a
second,
you
know
if
harbor,
you
know,
is
being
a
pull
through
cache.
B
If
you
will-
or
you
know,
I'm
trying
to
think
of
I'm
trying
to
tie
it
to
the
kubernetes
thing,
maybe
I'm
just
reaching
here.
It
makes
sense
that
it's
set
up
for
pull
but
how'd
you
get
the
content
in
and
if
you
don't
want
to
be
conformed,
that
is
a
choice,
but
I
think
if
we
make
everything
optional,
then
what
does
being
conformant
actually
mean?
F
F
If
you
want
to
have
some
common
code
for
pushing
you
know
images
in
a
in
a
standard
way
across
a
plethora
of
registries,
so
that
you
can
actually,
you
know,
spread
out
the
pain
right
of
where
the
the
content
stored
and
being
you
know,
being
pulled
from
then
would
be.
It
would
be
nice
if
there
was
some
common
way
to
do
that,
and
certainly
the
the
reason
we
were
publishing
the
docker
api
was
to
allow
that
that
to
happen
right.
F
It
also
gives
you
the
ability
to
to
say
hey.
You
know,
please
don't
change,
because
you'll
break
my
clients
right
and
by
the
way
those
clients
are
cloud
solutions
that
have
been
deployed
right.
So
there's
a
couple
cases
to
why
why
you
don't
want
the
changes
to
occur
or
why
you
want
there
to
be
some.
You
know
clear,
understandable.
F
B
But
take
so
these
are
great
points,
so
the
the
thing
is
is
that
the
content
discovery
we
want
that
to
be
compliant.
We
will
be
compliant
with
that.
The
content,
management
and
push
they
are
supported.
It's
just
you
don't
get
credentials
to
it
like
the
apis
are
there
we
do
support
them,
so
it
is
completely
compliant.
B
F
B
F
H
F
Right,
that's
like,
like
an
access
requirement
thing,
an
ackel
that
you
know
it's
up,
yeah,
that's
different.
We
should
be
able
to
test.
If
you
had
a
service,
you
know
you
have
a
service
model
right
or
I'm
sorry,
a
service
account
with
mcr,
whether
it
would
work
correctly
or
not,
and
then
you
could
just
scope
it
to
you
know
for
properly
right.
F
B
Right
well,
but
to
be
fair,
they
could
test
it
because
you
just
created
an
org
and
then
you
can
push
to
it.
So
there
is
a
way
to
test
that
and
I
would
hope
that
they
would
meet
these
bars.
The
thing
that
I'm
worried
about
and
is
let's
say
that
an
acr
because
of
auth-
and
this
isn't
true-
so
I
am
in
fictitious
land.
True
yeah
put
me
under
the
bus,
where
I
don't
want
to
call
out
another
cloud,
I'm
not
even
sure
it's
true
for
another
cloud.
I
don't
want
to
tell
customers
that
yeah.
B
Of
course,
acr
supports
push,
but
you
have
to
use
the
azcli
to
do
that
because
of
excuse
one
two
and
three.
What
I
want
to
be
able
to
help
be
held
accountable
is
acr
supports
push,
because
we
follow
the
oci
conformance
spec,
and
it's
that
simple
I
don't
want
to
make.
I
want
to
make
sure
that
we
and
all
other
registries
are
held
compatible,
that
they
can't
say,
borrow
ci
conform
it,
but
that's
optional.
So
in
order
for
you
to
push,
you
have
to
use
this
other
cli.
C
In
the
interest
of
time,
I'm
just
going
to
suggest
what,
if
we
remove
optional
the
wording
from
the
spec
and
instead
in
the
conformance,
what's
wrong
steve
in
the
conformance
repo
we
talk
about,
the
breakdown
in
terms
of
your
repo
can
be,
or
your
registry
can
be
conformant
on
four
levels.
So
the
spec,
the
spec,
is
as
it's
written
talk,
assumes
that
everything
is
required.
B
F
Well,
yeah,
I
guess
I
might
have
missed
the
part
where
why?
Why
would
you
want
it
to
be?
You
know
mandatory
that
you
include
push
where
when
pull
is
the
minimal
requirement
and
you
can
push
any
way
you
want
yeah
outside
right.
But
if
you
do
do
push
here's
here's
the
specification
right,
it's
just
not
mandatory!
B
B
Well,
there's
a
physical
ways,
but
my
point
is
is:
do
we
really
want
to
say
that
there
is,
if
you
want
to
be
compatible
with
the
spec,
that
you
have
to
support
push
now
to
josh's
point
performance
tests,
we
could
say:
look
you
don't
have
green
on
that
one
you're
green
and
the
other
one
you're
green
on
po.
Great!
That's
all
you
want
to
be
like.
I
am
fine
if
mcr,
if
we
even
never
submitted
it
to
the
the
conformance
test,
and
I'm
just
I'm
making
a
hypothetically
here,
yeah.
F
B
Ever
submitted
it
I'd
be
totally
fine.
That
mcr
only
shows
green
on
on
pull
and
catalog
discovery
right
to
be
a
catalog
discovery,
because
the
others
are
just
they're,
not
supported
scenarios.
We
are
implementation
respect,
but
we
don't
expect
anybody
else
to
to
use
it
in
that
way
and
accept
our
internal
teams
like.
I
would
make
sure
our
internal
teams
don't
have
to
have
special,
tooling
yeah.
F
I
mean
other
other
than
the
requirement
for
dynamic
testing
of
the
registry.
Why
would
push
be
a
requirement
if
all
you
wanted
to
support
to
customers
was
pull?
I
think
that's
the
argument
for
saying
well
pool
is
a
man.
Is
the
only
one?
That's
mandatory
right,
the
other
part
of
it
being
already
it's
a
subtle
argument.
F
I'm
trying
to
make
is
that
if,
if
you
say
you
want
to
support
the
distribution
api
right,
the
ocr
oci
standard
for
distribution
and
you're
doing
and
you're
supporting
push
from
the
client
right,
then
I
think
you
have
to
support
it.
At
least
this
way
right,
you
can
have
additional
apis
for
push
other
ways
to
push,
but
you
can't
say
you
support
oci
distribution
push
unless
you
support
it.
The
way
it's
specified
at
a
minimum
right.
B
B
B
B
B
B
A
level
of
support
right
sorry,
I
was
thinking
the
other
ones
that
vincent's
been
talking
about
as
the
this
other
api.
So
for
signature
management,
yeah,
yeah,
okay,
I
imagine
that's
going
to
be
optional
for
a
while
until
we
get
you
know
that
better.
So
maybe
some
future
spec
either
make
it
require
core
or
there'll,
be
some
optional
features.
B
F
F
F
All
we're
saying
is
that
the
you
know
the
the
old
docker
distribution
api
supports,
pushed
this
way
and
we're
we've
analyzed
it,
and
we
think
that
if
you
want
to
support
the
the
current
specification,
our
specification,
for
you
know
push
here,
is
how
you
do
it
right
and
it's
supported
with
everybody
who
says
they
support
push
the
oci
way
right,
but
that
doesn't
say
somebody
else
can't
come
up
with
the
push
prime
right,
we're
not
we're
not
we're
not
enforcing
we're,
not
trying
to
stop
or
slow
down
that.
You
know.
B
H
H
H
A
F
B
F
C
C
E
F
G
Who's
gonna
want
to
be
conformant,
and
and
why
because
that
like,
if
you
look
at
kubernetes
conformance,
I
mean
that's
not
tied
to
a
spec,
it's
tied
entirely
to
their
conformance
tests,
but
the
reason
you
become
kubernetes
conformant
is
so
that
you
can
put
the
kubernetes
conformant
logo
on
your
product,
and
I
I
can
see
there
being
a
potential
future
where
that's
true
for
oci
as
well,
and
then
the
question
is
what
are
those
products
and
and
who
are
the
customers
for
them?
And
what
do
they
care
about
right?
F
Right
and
funny
you
mentioned
that
right,
because
this
would
be
a
part
of
that
in
some
respects,
because
if
you
don't
have
a
conformant,
oci
you're
going
to
have
a
hard
time
running,
oci
pods,
you
know
or
oci
containers
in
pods,
in
conformance
tests.
Once
we
move
the
oci
tests
into
the
conformance
test,
which
is
certainly
you
know,
one
of
our
goals
so
yeah.
C
C
B
C
B
C
Perfect,
so
this
is
just
regarding
how
the
current
basically,
the
current
spec,
if
you
look
at
it,
has
kind
of
it's
a
little
bit
empty,
especially
compared
to,
if
you,
for
example,
go
to
image
spec.
So
this
one
is
just
about
making
this
a
little
bit
cleaner
or
friendly.
So
do
people
have
any
issue
with
me
basically,
following
what
image
spec
has
done
as
far
as
the
layout
they
have
here.
B
C
B
If
you
don't
care
what
it
means,
I
I
think
there
was
some
good
conversations
that
was
discussed
around
the
case.
Should
we
maybe
have
some
docs
in
here.
That's
you
know,
pointers
to
articles.
I
think
the
reboot
doesn't
have
to
be
blank,
but
it
it
it
could
have
some
stuff
like
here's,
how
you
use
the
registry,
here's
what
it's
intended
for,
if
you're
trying
to
contribute
here's
the
thing
to
do,
but
I
think
there's
some
headings
in
there:
okay,
great
intentions
that
have
no
more
value.
C
All
right,
simple
enough
by
the
way
they're
speaking
of
faq,
there's
vanessa
sochette
opened
a
it
wasn't
merged.
There
was
actually
an
open
pr
here,
number
189
and
she
actually
implemented
a
registry
in
python
and
in
doing
so
came
up
with
all
of
these
kind
of
q
and
a's,
which
so
this
is
pr
to
be
into
the
readme.
But
it's
pretty
long
and
wondering
if
that
should
be
an
faq
md,
but
just
wanted
to
make
people
aware
of
this
all
right.
Cool.
C
C
C
C
B
B
G
C
C
Or
I'm
sorry
another
repo
in
the
same
registry.
However,
we
are
saying
that
this
will
basically
that
a
405
or
like
method
not
allowed
will
be
accepted.
If
you
don't
want
to
support
this,
and
it
also
introduces
a
new
environment
variable
that
you
need
to
use,
which
is
the
other
name
space
for
the
repo
that
will
have
the
cross
mount.
So
I
don't
think
that
this
peter,
I
don't
know
if
you're
on
it.
I
don't
think
that
this
is
going
to
be
required
as
a
variable.
I
I
B
So
I,
as
a
consumer
trying
to
see
if
this
this
registry
foo
supports,
is
feels
in
good
standing
and
has
all
the
features
I
want
to.
I
don't
even
know
about
cross
mounting
I'm
just
trying
to
get
it.
It
shows
green
across
the
board
so,
but
now
later
on
after
I
bought
it
stood
it
up.
Had
a
bunch
of
teams
start
using
it,
it
turns
out.
It
doesn't
have
that
feature.
B
I
So
you
know
I
just
made
a
judgment
call
with
the
405
system,
I'm
not
married
to
that.
You
know.
That's
just
what
I
went
with
and
you
know
you're
welcome
to
make
comments
on
the
pr
and
I'm
happy
to
change
it.
I
I
don't
have
a
strong
opinion
on
this
personally
and
if
anyone
else
wants
to
weigh
in
that'd
be
helpful
too,
but
you
make
you
make
good
points.
B
Here
are
a
few
other
conversation
of
either
the
spec
is
a
meaningful
spec,
and
if
you
support
the
spec,
then
I
that
I
know
you
support
it
and
I
can
use
it
and
I
want
to
know
which
registries
don't
support
it,
and
maybe
it's
okay,
that
they
don't
support,
feature
xyz
and
I'll
still
use
it.
But
so
the.
C
C
C
B
Here
suggestion
is
this:
I
actually
don't
know
about
this
feature
just
to
know
how
many
registries
do
and
don't
support
it.
If
all
registry
is
supported,
can
we
make
it
just
and
if
there's
a
certain
registry
that
doesn't
ask
them
hey,
is
there
some
good
reason
why
you
don't
want
to
support?
I
think
we
shouldn't
I
just
I
want
to
be.
I
think
the
spec
has
to
have
some
value.
C
B
B
So
I
don't
know
anybody
who
doesn't
do
this
and
there's
a
there's
a
there's,
an
idea
that
you
don't
there's
a
question
whether
you
share
layers
between
registries
on
the
same
platform
and
there's
a
security
argument
about
that
one
way
or
the
other.
But
that's
not
the
ask
that
that's
a
total
cloud,
optimization
that
you
know
teams
registry
should
expose
or
not
whatever
they
want
to
share
that.
But
I
I
would
think
that
I
is
especially
especially
the
docker
terms
of
services,
highlighting
that
running
registries
is
expensive.
B
I
think
I
would
imagine
all
registries
at
some
point
are
going
to
charge.
I
don't
know
who
doesn't
charge
customers
for
storage,
I'm
going
to
want
to
know
that
this
registry
doesn't
support
cross
mounting
and
they're
going
to
be
charging
me
more
than
registry
2..
So
I'm
going
to
choose
registry
2
unless
registry,
one
that
doesn't
support
cross
mounting,
has
got
some
super
good
value
that
I'm
willing
to
pay
a
lot
more
for.
C
Yeah
yeah,
so
I
think
especially
because
we're
already
in
the
rc
one
phase,
I
I
wish
john,
was
on
this
call.
But
to
get
that
opinion,
but
like
I'm
wondering
if
this
is
something
we
leave
out
of
the
spec
and
it's
still
like
other
registries
until
like
a
new
like
a
1.1
just
because
it's
so
close
like
it's
so
close
to
the
conformance
tests
haven't
been
touched
for
a
while,
and
this
is
a
new
thing.
B
H
Docker
push
does
cross
blob
mounts
if
it
knows
that
the
layer
that
it's
supposed
to
push
already
exists
in
another
repository
on
the
same
registry,
so
we
should
check
whether
or
not
that
behavior
is
unconditional
or
whether
it
actually
checks
whether
the
registry
supports
a
cross
blob
mount.
Does
it
assume
the
registry
does,
and
if
it
does,
then
I
doubt
there's
a
registry
out
there
that
doesn't
support
it.
C
B
I
I
I
B
I
think
it's
also
something
that
customers
are
going
to
want.
A
user
is
going
to
want
to
know
that
a
registry
supports
and
it's
a
kind
of
a
hidden
feature
that
is
going
to
be
have
an
impact
on
them
because
of
the
cost
factor.
The
cost
factor
is
either
they're
paying
their
registry
to
store
it
or
their
local
disk,
because
they're
running
something
like
hardware
where
they
don't
pay
for
storage,
but
they
they're
paying
for
the
storage.
That's
the
disk!
That's
supporting
something
like
hardware,
so
I
think
it's
an
important
thing
to
surface
up.
C
C
All
of
the
like
this,
this
one
change
will
close
all
of
these
or
not
all
of
the
ones
in
here,
but
the
ones
that,
with
the
exception
of
these
five,
that
we
are
kind
of
unsure
on
so
take
a
look
at
this.
But
like
steve.
That
has
your
change
regarding
being
more
agnostic
about
content
types,
and
there
was
something
about
the
the
docker
specific
headers
and
we're
just
putting
under
historical
context
that
hey
some
clients
may
request
or
send
these
or
require
these
headers.
But
they're
optional.
C
A
A
A
H
C
It's
just
so
the
so
the
endpoints
in
that
table
were
based
on
every
api
call
from
the
conformance
test.
So
it's
nothing
to
do
with
what
docker
or
anything
is
doing.
So
I
think,
if
we
were
to,
we
should
add
these.
We
should
add
a
head
check
in
the
tests
and
then
just
add
it
to
the
table
yeah.
I
I
I
think.
I
I
I
A
J
J
J
H
H
C
D
B
We
have
a
couple
of
minutes,
I'm
curious
what
people
think
about
the
regex
for
repos
and
what
and
no
I'm
totally
random
I'll
open
up
an
issue.
What
do
people
think
about
having
a
special
repo
that
we
can
project
images
in
to
project
yeah,
project
images
or
artifacts
into
a
registry
for
a
user?
But
it's
like
a
system
reserved
namespace.
B
It's
it
indirectly
falls
into
the
caching
model
to
be
completely
transparent.
The
the
thing
is
is
that
we
make,
as
customers
put
their
registries
into
v-nets.
They
don't
want
to
be
to
reach
outside
of
their
registry,
but
we
in
aks
support
the
aks
images
that
kubernetes
images,
but
we
tell
them
to
go,
pull
them
from
mcr
mc
has
a
public
endpoint.
They
don't
want
to
pull
it
from
there.
B
We've
been
experimenting
with
some
ideas
of
projecting
those
images
into
the
customers
registry,
but
where
do
we
put
them?
There's
no
name
space.
We
could
put
that
we
know
would
be
empty.
So
now
it
has
to
be
unique
per
registry-
that's
kind
of
weird.
If
there
was
this
system
name
space
that
underscore
underscore,
I
don't
know
something
that
it's
just
an
idea
and
I'm
curious
what
this
group
thinks
about
it,
and
I
know
it's
totally
random.
F
B
Scope
are
you
talking
about
steve?
Are
you
talking
about?
You
know
local
node
host
type
scopes,
or
I
would
love
to
be
able
to
say
that
every
acr
you
when
you
want
to
pull
even
the
ubuntu
I'll
go
to
an
extreme,
but
it's
probably
not
a
good
example.
We
want
customers
to
be
able
to
pull
a
set
of
images
like
the
ubuntu
image,
like
the
ak,
the
images
that
are
required
to
run
on
customer
vms
to
run
aks.
B
They
shouldn't
have
to
go
to
mcr
they
can
they
can
just
pull
them
from
their
registry,
but
they
shouldn't
they
don't
manage
them.
We
manage
them
on
behalf.
So
what
I
would
like
to
do
is
project
these
special
set
of
images
into
a
customer's
registry
that
a
customer
can't
push
to
because
they
have
a
special
character
that
block
that
is
blocked
on
push,
but
it's
a
reserved
namespace
for
the
registry
to
provide
content.
B
H
Quote-Unquote
well-known
directory
path
for
servers
that
can
be
used
for
things
like,
let's
encrypt,
if
you,
if
you
want,
let's
encrypt,
to
do
verification
based
on,
can
I
fetch
a
file
over
http?
That's
the
directory
path
where
that
file
gets
fetched
from
by
the
remote
service
or
for
verifying
yourself
on
google's
silly
webmaster
tools.
Thing
like
you,
there's
a
file
that
you
place
in
that
well-known
directory
that
it
then
fetches
to
see
that
you
own
that
that
domain
or
that.
B
Host
gotcha
yeah,
so
it
is
that
same
kind
of
scenario.
The
problem
is:
how
do
I
know
of
the
millions
of
registries
that
people
have
across
all
of
us
today
that
well
known
that
directory
named
well
known,
is
not
already
used,
so
the
thought
process
was.
Can
we
use
one
of
the
characters?
That's
already
reserved,
because
it
says
it's
not
supported
and
just
say
yeah,
it's
still
not
supportive
for
everybody
else,
except
the
registry
itself,
so
that
we
can
help
customers
with
a
set
of
system
images.
H
H
G
C
C
C
C
Wait
can
anybody
how
do
you
you
can't
push,
you
can
only
push
to
stuff
under
you
slash,
so
we
could
make
if
we
wanted
to
host
helm,
charts
or
something
we
could
have
helm
slash
right.
You
know
so
that
we
we
had
thought
about
that
as
like.
We
don't
want
people
to
squat
on
these
system
or,
like
official.
A
B
B
It
basically
the
relaxation
of
the
regex
for,
but
it
I
didn't.
I
think
it
was
tianon
mentioned
the
point.
We
have
to
check
the
clients
I
haven't
checked.
The
client
is
a
great
one.
I
I
assumed
people
check
on
push.
I
didn't
even
think
that
they
might
check
on
pole,
but
it
makes
perfect
sense
that
invalid.
H
D
D
B
B
Derek
did
have
something
for
next
week,
but
I
don't
I
don't
remember
being
time
sensitive,
so
jocker
has
been
working
on
some
delete
apis
that
they're
going
to
ship
quickly
for
the
thing
that
we've
been
all
watching
and
I
was
asking
him
hey.
This
sounds
like
a
great
conversation
for
us
to
have
across
all
registries,
but
it
doesn't
have
to
be
next
week
so
yeah,
I'm
all
in
vote
for
for
that
anybody
object.
F
B
C
Thank
you
and
thank
everybody
for
this
great
discussion,
so
we're
gonna
keep
chugging
at
this
rc2
and
and
yeah.
If
we
can
get
some
help
with
the
optional
language
and
a
review
on
the
two
open
pr's
that
would
be
great
and
we'll
track
down
that
whole
content
range
thing
as
well.
We'll
do
it
thanks.
Thank
you
yeah.
I.