►
From YouTube: OCI Weekly Discussion - 2020-09-16
Description
OCI Weekly developers call recording from 16 Sept 2020; notes/agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#September-16-2020
A
A
C
B
Yeah
it
was,
there
was
one
one
aspect
of
just
like
not,
I
think
the
only
thing
that
would
be
interesting
in
that
is
that,
thankfully
they
haven't
been
doing
it,
but
lasker
was
saying:
oh.
That
would
be
interesting
if
we
annotated
in
the
notes
around
what
minute
marker
that
something
happened
in
the
conversation.
B
A
Yeah
yeah,
it's
kind
of
a
bummer
when
the
recordings
were
like
kind
of
perfectly
timed
with
start
and
end.
I
was
uploading
the
vtt
file,
which
is
zoom's,
pretty
good
translation
of
the
the
commentary
and
and
youtube
supports
them.
But
anyway,
once
you
take
off
any
number
of
seconds
at
the
beginning,
the
vtt
file
becomes
useless.
So.
A
A
A
A
A
E
B
E
A
B
F
B
B
B
B
I
I
Okay,
so
yes,
so
this
is
about
a
new
feature
in
sec
comp
so
a
while
ago,
as
a
comp
kind
of
you
could
kind
of
say
hello
or
deny
on
the
system
call.
But
now
there
is
this
new
canal
feature
on
the
comp
that
you
can
send
a
notification
to
an
external
agent
and
that
external
engine
can
take
decisions
and
then
write
on
a
reply
to
the
kernel
to
say
to
this
or
not
block
it,
but
on
an
error
or
something
like
that.
I
I
I
I
I
did
one
about
cyclop
so
that
he
can
take
the
valley,
scripture,
4k
on
exec
nausea
hook
about
sec
comp
with
to
keep
that
valley
descriptor,
and
then
this
hook
can
do
whatever
he
wants
in
this
example
opposite
via
a
unique
socket
to
a
second
agent.
That
can
then
do
act
on
that
second
notifying
file
descriptor
to
act
on
the
container.
I
I
That
is
the
rca
state,
the
same
rci
state.
It
gets
from
other
hook
like
the
container
id
pid
and
some
other
information
like
annotations,
but
in
this
case
it
gets
additionally
file
descriptors
of
the
site
comp
right
there
and
then,
as
a
comp
adjunct
will
have
different
behavior.
There
could
be
different
implementations
like
some
information
implementation,
that
act
on
the
empanada
system
call
or
other
that
act
on
bpf
in
this
example
or
other
things.
I
He
could
also
decide
to
look
at
the
annotations,
the
annotation
in
the
conflict.json
to
behave
differently.
Based
on
that.
So
here
I
put
an
example
of
ocr
hook
of
type.
Second,
in
the
same
way
that
all
the
lco
can
execute
a
command.
Here
I
execute
a
command
and
I
can
pass
parameter
if
we
want
to,
and
then
this
ocr
hook
here
will
be
given
on
the
sdn,
the
oci
state
that
already
is
already
defined
by
uci.
I
Yeah,
I
don't
know
if
you
have
thought
about
that,
and
here
I
added
the
p
of
the
process
that
is
attached
to
the
second
policy
open.
So
the
thing
to
understand
is
we
get
a
file
descriptor
every
time
we
run
a
second,
but
that's
not
only
at
the
fancy
init
stage,
but
every
time
you
do
a
command
like
cuba,
city
exec
or
the
car
exec.
When
you
do
run
c
exec
you
introduce
a
new
process
inside
the
container
and
that
new
process
will
be
attached
a
new
second
file
descriptor.
I
It
went
through
that
the
same
policy
that
the
policy
coming
from
the
config.json
yeah.
The
second
is
not
attached
to
the
spacer
signal,
but
it's
attached
to
process.
So
it
means
when
we
add
a
new
process
in
the
container.
You
get
a
new
second
file
discretor
that
will
need
to
be
passed
to
the
ocr
hook
in
the
same
way.
I
No
in
this
proposal,
it's
just
one
policy,
the
one
defining
config.json
so
yeah.
If
here
I'll
say
that
the
ppf
system
call
is
notified,
then
to
be
the
same
well
yeah.
I
didn't
see
a
use
case
to
have
different
policy
technically.
That
would
be
possible,
but
it
seems
to
be
complicating
to
me
here.
I
mentioned
lifecycle
so
yeah.
How
does
the
second
page
knows
when
the
container
is
gone
and
there
is
no
need
anymore
to
do
anything
on
the
second
valley
scripture,
two
possibilities?
You
could
use
weight
id.
I
With
this
pdf
d
that
just
wait
on
the
on
the
pid
one
of
the
container
to
terminate
and
then
it
knows,
the
container
is
gone
or
we
could.
We
could
later
use
a
oci
first
stop
hook.
So
that's
here
hook
that
already
exists
in
the
spec
to
know
that
okay,
the
controller
is
no
longer
there
yeah.
That's
a
implementation
detail.
I
guess,
although
in
the
when
we
receive
the.
I
I
Yeah,
I
have
a
branch
here
that
is
not
ready
for
review.
It's
just
my
experimentation.
So
far
on
one
c,
so
I
get
proof
of
proof
of
concept
to
show
that
it
can
work-
and
here
I
added
in
this
branch
this
in
the
contract
directory
a
second
agent
that
just
under
the
system
call
and
let
addon
minus
42
just
as
a
test
and
see
that
it
works
on
the
when
the
container
runs
the
system
call
it
received
the
server.
I
I
I
That's
a
bit
different,
because
I
can
configure
namespace
or
c
group,
but
it's
not
running
in
line
in
a
process
hierarchy,
so
it
will
not
allow
to
configure
second,
because
second
cannot
be
configured
from
an
external
process.
It
needs
to
be
the
process.
The
balance
process
of
the
process
that
execute
the
second
system
count
to
configure
the
cop.
I
B
I
J
I
J
I
B
J
B
Yeah,
there's
probably
going
to
be
some
amount
of
like
host
policy
versus
cluster
policy
question
there
and
even
giuseppes,
and
I
know
you're
on
the
call
there
was.
There
was
some
proof
of
concept
work
about
even
like
potentially
shipping
a
container
with
its
or
shipping
an
image
with
its
like
minimal
set
comp
pieces
in
it.
I
don't
know
how
we're
going
to
reconcile
that
probably
yeah.
K
K
J
If
I'm
not
allowing
this
the
amount
cisco
in
a
container,
it's
not
because
I
don't
want
them
to
be
able
to
think
that
they've
mounted
something
it's
just,
because
I
don't
want
them
to
maybe
par
use
a
super
block
parser
in
the
kernel
on
something
that
they
provide
right,
so
that
that
one
of
the
one
of
the
major
reasons
for
the
kernel
inclusion
of
this
in
the
first
place
was
to
provide
that
kind
of
thing.
So
in
that
case,
I
don't
think
it
needs
to
be
a
host
decision
of
this.
J
Kind
of
I
mean
it,
it's
it's
analogous
to
the
question
I
had
for
ociv2
as
well,
where
we
we
had
the
question
of
how
do
how
do
we
handle
binding
in
devices?
One
container
might
just
say.
I
just
want
some
kind
of
graphical
some
kind
of
gpu
to
do
some
computations
another
one
might
say.
I
must
have
this
one
is
that
up
to
the
image
spec
is
that
up
to
the
one
time
spec?
Is
that
up
to
the
host?
J
I
I
I
C
F
I
F
I
I
For
this
proposal
and
to
specify
a
bit
more
okay,
what
happened,
for
example,
if,
if
the
set
comp
policy
as
this
notify,
but
there
is
no
ocr
hook
for
the
comp
yeah,
I
think,
for
example,
in
this
case
I
will
just
yeah
see-
I
should
not
care
about
that.
So
the
file
descriptor
will
be
closed
when
nobody
has
a
reference
to
it
anymore.
So
the
system
call
that
I
fail
to
notify
will
just
return
the
error
for
that.
According
to
the
kernel
rules,.
I
B
It's
probably
it's
probably
worth
I
mean
like
at
least
ensuring
that
it
I
mean
you've
got
a
proof
of
concept
to
some
extent,
I'm
sure,
but
to
have
a
pull
request
worthy
but
yeah
having
a
pull
request
to
the
runtimes
pack,
even
even
with
having
shared
conversation
on
that
prior
one.
Like
you
mentioned
it,
the
benefits
and
drawbacks
to
either
one
of
those
it
not
having
annotations
or
metadata
possible
with
it.
K
Yeah,
well,
I
think
the
two
implementations
can
co-exist
like
both
of
them
have
advantages
and
disadvantages
like
for.
I
think
one
with
the
advantage
here
is
to
require
yet
another
process
for
just
moving
our
file
descriptor
around
but
yeah.
In
some
cases
it
can
be,
it
can
be
used
yeah,
I
I
think.
Well,
maybe
we
can
look
at
both
of
them
like
I,
I
was
playing
with
the
with
the
other
proposal
and
implemented
in
syria
and
well.
The
implementation
is
quite
simple,
so
I
think
even
exciting
does.
I
K
Well,
well,
I
don't
think
the
ocra
time
can
have
both
methods
to
move
the
second
file,
descriptor
like
in
your
case,
you're,
showing
like
it's.
It
moves
more
metadata
together
with
for
descriptor.
So
if
you
need
that,
you
can
go
this
way.
Otherwise,
if
you
just
need
to
find
the
descriptor,
you
can
specify
where
it
should
be,
where
it
should
be
certain
yeah.
B
K
K
L
Oh,
I
feel
like
I,
I
understand
the
technical
details
of
the
proposal.
What
I
feel
like
is
lacking
here
are
use
cases.
What's
what's
this
going
to
be
used
for,
like
I
understand
that
it's
possible
and
that
it
should
be
implemented,
but
what's
what's
the
end
goal?
What
are
we
trying
to
accomplish
with
it.
I
I've
read
the
use
case
about
people
running
system
t
inside
the
container
and
system
e
needs
to
run
mk,
node
or
bpf
system
call,
and
sometimes
we
don't
want
to
give
the
container
enough
privilege
for
that
because
it
could
be
done,
shows
to
give
a
cap
and
cannot
or
whatever,
but
we
still
want
the
thing
to
work
so
by
using
that
we
can
have
the
second
pageant
doing
the
privileged
system
call
on
the
contents
payoff
after
checking
that
it's
something
allowed
buy.
The
policy.
D
Yeah
I
mean
we
can
give
our
use
case
of
why
we
did
this
work,
which
was
for
certain
systems
like
perf
event
open
the
extended
syscall
attributes
can't
be
inspected
by
a
pure
second
policy.
In
addition
to
that,
the
sophistication
of
the
syscall
attributes
is
like
ever
expanding.
Since
it's
an
extended
attribute
syscall.
What
we
would
like
to
do
is
we'd
like
to
take
the
ea
arguments
and
pass
those
to
an
external
agent,
specifically
in
this
case
the
open
policy
agent
and
validate
those
syscalls.
D
So
we
can
do
cisco
filtering
using
opa
as
opposed
to
having
to
do
cisco
filtering
using
setcomp
or
se,
linux
or
whatever,
because
it's
like
on
a
person
by
person
or
a
team
by
team
basis
of
what
we
want
to
allow
and
therefore
having
this.
This
set,
notifier
and
add
a
fee
capability
opens
that
up
versus
having
to
have
all
the
policy
in
kernel.
M
B
H
M
Long-Winded
argument
with
the
kernel
maintainers
about,
we
should
relax
this
and
here's
how
we
should
specify
this
policy.
But
this
this
comp
mechanism
serves
as
a
way
to
relax
those
kind
of
policies
in
specific
instances
where
you,
the
container
operator
guy,
know
that
it's
safe.
So
just
generally,
it
serves
as
a
sort
of
a
safety
policy.
K
B
Good,
I
think
it
was
a
good
discussion,
so
I
think
that
to
answer
steve's
question,
it
sounds
like
the
next
step
is
at
least
a
runtime
spec
pr,
and
then
you
know,
people
working
through
the
what
what
it
means
for
the
runtimes
run,
cdc
run
otherwise
and
yeah.
I
think
that's
good,
and
then
we
can
share
this
video
in
at
least
the
most
first
30
minutes
for
folks
who
weren't
here
to
be
able
to
catch
up
on
this,
and
the
document
document
probably
mostly
suffices,
but
still
all
right.
B
E
Awesome
so
so
maybe
I
will
show
my
screen
if
it's
okay,
yeah,
okay,
fantastic,
so
I
mean
I'm
I'm.
I
feel
that
before
we
kind
of
like
talking
about
why
this
spec
is
needed,
maybe
we
need
to
kind
of
I
don't
know
you
will
tell
me
if
it
makes
sense
or
not,
but
basically
talk
about
webassembly,
one.
Second,
what
it
is
and
why
we,
for
instance,
did
what
we
did
or
do
you
feel
that
this
is
unnecessary.
E
I
would
like
that:
okay,
fantastic,
so,
let's,
let's
do
it
real
quick!
So
again
I
will
talk
about
it
on
as
part
of
my
use,
our
use
case,
but
I
think
there
is
way
bigger,
regular
game
here.
So
so,
first
of
all,
I
will
explain
a
little
bit
about
the
stuff
that
we're
doing.
We
are
at
solo
working
a
lot
in
the
network,
so
the
stuff
that
we're
doing
is
stuff
like
api
gateway
on
top
of
envoy.
E
Now
we
can
actually
extend
it
and
one
of
the
way
to
extend
it
is
with
web
assembly.
So
that's
covering
the
nutshells,
but
we're
working
about
it,
but
we're
explaining
what
is
the
use
case
and
why
so
real
quick?
I
will
kind
of
like
giving
you
two
examples
that
are
very
famous
in
the
ecosystem.
For
us,
which
is
basically
and
generally,
there
is
project
like
sto,
which
is
a
service
mesh
and
glue
and
the
naturals
they
all
build.
The
same
way
right
glue
is
focusing
on
the
edge.
E
E
It
can
do
a
lot
of
stuff,
but
you
need
to
give
in
the
configuration
and
that's
responsibility
of
the
data
of
the
control
plane,
so
it
could
be
st
or
it
could
be
glue
right
in
that
case
and
the
control
plane
we're
going
to
go
and
grab
a
lot
of
stuff
figure
out.
What
is
your
environment
watch?
Your
your
you
know
your
services
and
watch
your
your
security.
E
Basically,
so
that's
in
the
naturals,
it's
exactly
the
same
thing
in
glue
and
in
sdm,
so
kind
of,
like
kind
of
like
double
click
on
how
it's
actually
working
in
sto
in
invoice.
Sorry,
so
in
the
nutshells,
when
a
request
coming
for
something
like
glue,
the
user
configure,
for
instance,
something
like
virtual
service
glue
responsibility
is
to
go
and
configure
first
of
all,
some
of
the
external
services
like,
for
instance,
external
audit
or
rate
limiting,
as
well
as
configure
envoy,
and
then
when
the
requests
come,
it's
basically
going
to
a
chain
of
filter.
E
So
the
first
one
can
be
external,
odd
and
then
rate
limiting
and
grpc
and
so
on
and
so
on.
It
will
go
all
the
way
you
know,
as
you
can
see,
kind
of
like
pipe
down
eventually
we'll
go
to
the
upstream,
and
then
it
will
go
all
the
way
back
right
and
return
to
the
user.
So
this
is
architecture
is
actually
extremely
powerful
and
the
reason
it's
powerful
because
you
can
actually
put
your
own
custom
filter
in
the
way
right
and
therefore
you
can
actually
say
that
on
the
required
spot
I
want
to
do
like.
E
For
instance,
we
build
a
waff
filter
right
or
we
build
a
transformation
filter.
So
you
can
do
a
lot
of
stuff
and
again,
you
know
trust
like
talking
to
all
our
customers.
I
can
tell
you
that
all
of
them
need
their
need
is
differently
and
and
by
having
this
architecture,
it's
very
very
easy
to
basically
extend
and
void
the
data
plan
so
yeah.
So
this
is
kind
of
like
in
the
notches.
You
can
put
a
custom
filter
inside
envoy.
E
Now
it's
very
very
powerful
because,
as
I
said,
it's
basically
giving
you
the
ability
to
customize
it
to
your
own
it,
but
also
it
will
be
very,
very
useful
if
we
will
be
able
to
write
those
filter
in
any
language.
It
would
be
very
useful
if
it
will
be.
You
know
very.
We
need
to
make
sure
that
you
know
it's
not
going
to
slow
down
the
request,
because
it's
extremely
important
latency
it's
need
to
be
safe.
E
We
don't
want
it
to
take
the
proxy
down
there
is
we
hope
that
there's
no
way
need
to
con
to
compile
it,
because
the
case
today-
and
this
is
very
important-
is
that
you
can
write
your
own
custom
filter,
but
right
now
it's
have
to
be
in
c
plus
class
async
and
you
need
to
recompile
envoy.
So,
basically,
that's
pretty
complex
thing
to
do
so.
We
will
hope
that
we
will
not
need
to
compile
and
we
want
to
make
it
as
easy
as
we
can.
E
So
this
will
be
a
wish,
but
actually,
as
I
said,
it's
not
working
like
this,
so
you
know
so
we
and
and
seo
took
a
different
approach
for
how
to
solve
those
problems
and,
for
instance,
for
us
what
we
did.
We
said
you
know
what
it's
very
important,
that
it
will
be
very
fast
and
therefore
we
are
going
to
write
our
own
customer
for
the
customer
filter
for
the
for
our
user.
We
are
going
to
compile
it.
E
We
are
going
to
make
sure
to
ship
that
so
that's
mean
that
it's
very
fast
and
very
safe,
but
you
know
the
hard
work.
This
is
something
that
solo
doing
right.
We
have
to
have
c
plus,
plus
we
have
to
compile
it.
You
know,
there's
nothing
easy
about
it.
Right,
sdo
tried
to
do
it
a
little
bit
different.
They
said
what,
if,
instead
of
it
every
time
that
they
request
coming
to
proxy
to
envoy,
so
we
are
going
to
basically
send
it
to
a
go,
a
grpc
server
that
basically
will
know
with
that.
E
You
will
be
able
to
extend
it
with
adapter
and,
if
you
ask
yourself
why
ssto
felt
so
or
what
is
in
trouble
so
far,
it's
mainly
because
of
this
piece,
because
when
you
are
on
the
request,
pat,
you
really
definitely
do
not
want
to
go
to
an
external
server
or
less
as
much
as
you
can,
and
definitely
if
all
you
need
to
do
is
to
modify
a
little
thing
on
the
other.
You
definitely
don't
want
to
send
all
the
requests
through
the
wire.
It's
just
really
really
not
safe
and
stis.
E
This
problem
dramatically,
because,
if
you're
thinking
about
what
happened
every
time
that
people
started
with
sto
and
just
use
pilot,
it
wasn't
that
bad,
but
when
they're
actually
adding
this
mixer
functionality,
that's
where
all
the
problem
starts.
So
so,
basically,
they
took
a
different
approach
right,
they
said.
Look
that
way
you
theoretically
can
use
any
language
to
be
fair.
Go
is
the
only
one
that
you
can
actually
use.
It's
not
fast,
it's
not
more
safe
than
what
we're
doing.
E
E
It
needs
to
be
extremely
secure,
because
I
want
to
make
sure
that
if
someone
wrote
a
more,
it
was
a
model
that
is
not
safe.
It's
not
going
to
take
my
browsing
down.
It's
need
to
be
is
the
hope
is
that
it
will
be
faster
if
you're
writing
something
in
javascript.
There
is
a
lot
of
involvement
in
the
language
versus
with
webassembly
is
relatively
you
know,
less
less
interpretation
should
become
again.
E
E
You
know
to
communicate
with
the
wasp
model,
and
now
wassum
itself,
as
I
said,
is
basically
the
way
it's
secure
is
by
using
a
vfvm.
So
basically,
in
that
case,
we
took
v8
and
basically
what
we
did.
We
said,
okay,
so
we're
going
to
take
this
model.
This
was
a
model.
It's
a
virtual
machine
like
v8,
we
will
put
the
user
code
on
top
of
it
and
then
the
communication
between
the
filter
that
we're
writing
the
wasa
and
envoy
and
the
model
will
be
what
we
call
abi.
E
This
is
like
api
with
binary
right,
so
that's
basically
will
be
the
interface.
So
basically,
we
did
all
this
work
and
brought
the
ability
and
build
this
filter
and
everything
that
we
need
to
make
sure
that
we
will
be
able
to
bring
wasm
to
envoy
now.
Abi
is
still
pretty
low
level
right.
So
you
will
prefer
that
your
user
is
not
going
to
need
to
use
this,
and
therefore
you
need
to
write
sdk.
E
So
google
write
the
c
plus
plus
one
rewrote
the
assembly
script.
One.
The
community
wrote
the
rust
one,
there
is
go
tiny
gold
coming
up
and
the
idea
is
just
to
create
those
environment.
This
sdk
that
will
help
the
user
to.
You
know
to
basically
minimize
that
you
know
the
code
that
they
need
to
use
and
make
it
simpler
for
them.
So
now
this
is
basically
how
it's
going
to
work.
So
this
is
very
interesting
right,
because
now
you
can
write
potentially
any
language
that
will
write
sdk,
for
it
will
be
fast.
E
You
know
it's
almost
native,
it's
not
it's
not
native
native,
but
the
performance
is
close
to
native
it's
safe
right,
because
it's
inside
the
vm
there
is
no.
There
is
no
need
to
compile,
because
that's
all
the
id
with
wasm,
but
it's
not
easy
right,
I
mean
you
still
need
somehow
to
build
those
wasn't
with
the
co.
It's
it's
pretty
complex
still,
and
this
is
where
we
basically
solo
came
to
to
the
the
picture.
E
So
that
was
very,
very
interesting
to
me
right
and
therefore
I
said
look,
this
is
true.
Like
I
mean
bringing
wasn't
to
android,
for
instance,
is
great,
but
we
need
somehow
to
make
the
experience
like
you
know
like
if
we're
looking
kind
of
like
back.
We
know
that
elle,
you
know
the
linux
conte,
the
linux
content
was
there
way
before
docker
make
them
accessible
for
the
all
of
us.
E
So,
but
what
I
wanted
to
to
figure
out
basically,
is
how
how
can
I
build
a
tool
that
is
like
what
docker
did
to
linux
container
to
the
wasom
in
envoy,
and
we
came
with
webassembly
hub
and
it's
pretty
simple
right.
It's
a
command
line
very
like
talking
you're,
writing
was
me
in
it.
It's
creating
you,
the
library
that
you
need,
then.
Basically
you
everything
like
it's
basically
you're
telling
which
language
you
want
and
to
which
platform
right
now
we're
supporting
glue,
sto
and
envoy
local.
E
It
will
create
you,
a
library
and
all
the
resources
that
you
need.
You
don't
need
to
do
anything
and
then
basically
your
cd
to
the
open
the
project.
You
need
to
put
only
the
logic,
the
business
logic
code,
then
you're
doing
wasme
build.
Then
you
can
pull
and
push
to
a
registry
or
ci
and
then,
basically
after
it,
you
can
actually
deploy.
So
you
can
run
deploy
blue
yours.
E
There
was
some
data
model
that
I
want
and,
and
and
I
wanted
you
know,
this
is
the
configuration
that
I
want
to
give
them
and
that's
pretty
pretty,
really
really
interesting
and
and
after
we
release
it,
for
because
we
need
it
for
our
customer,
google
basically
reached
out
to
us
immediately
and
said
we
are
interested
in
this.
We
need
it
for
the
sdo,
so
the
sdo
community
basically
decided
that
that
will
be
the
official
way
to
to
extend
sdo
with
wasan,
so
that's
kind
of
like
in
the
naturals.
E
What
we
are,
what
are
we
doing?
Why
are
we
doing
it
and
again?
I
personally
think
that
this
is
only
the
beginning.
I
mean
we
needed
it.
This
is
something
that
we
are
running
with
our
customer
in
production.
This
is
why
we
needed
it,
but
I
wanted
to
say
that,
in
my
opinion,
this
would
be
the
future
of
the
of
of
cloud
native
extending
stuff.
So
I
know
that
oppa
open
policy
agent
is
looking
to
to
use
it.
E
I
know
that
that
a
nuts
as
well
from
the
cncf
project
and
trying
to
to
use
it
and
we
personally
building
our
own
project
that
is
not
proxy
relevant
that
we
are
extending
with
with
a
wasm.
So
in
general,
I
think
that
we
are.
You
know
that
this
is
the
future
of
extension
for
for
a
wessem
for
cloud
native.
Is
there
any
questions
so
far
before
we're
moving
to
the
spec
and
again.
B
E
B
E
E
Maybe
that's
the
word
that
I'm
looking
for
and-
and
it
was
very
important-
and
I
think
that
misalignment
is
destroying
innovation
in
my
opinion
and
therefore
it
was
very
important
to
me
not
to
to
drug
the
community
to
another
form
like
that.
So
you
know
we
had
it
with
the
container
management
and
we
had
it
with
now
with
service
mesh.
I
really
don't
feel
that
this
is
healthy.
E
So
by
doing
this
we
learn
a
lot.
We
don't
know
why
how
we
feel
that
wasn't
need
to
be
distributed,
and,
of
course
we
didn't
want
to
invent
the
wheel.
So
we'll
look
at
you
guys
right,
because
it
just
makes
sense,
you
already
done
it,
but
what
we
did
wanted
to
make
sure
is
to
be
a
little
bit
more
specific.
So
this
is
this
is
solo.
E
This
is
our
company
right
and
basically
everything
that
we're
doing
with
us
and
we
put
in
one
repository,
and
what
you
can
see
is
that
there
is,
you
know
stuff
like
sdk,
that
we
build,
and
you
know
the
tooling
like
was
me
that
I
described
and
so
on
and
there's
also
the
spec
and
again
the
idea
with
the
spec
is
just
I
really
really
hoping
that
the
community
is.
You
know,
I
believe
that
that
would
be
a
big
thing.
I
believe
the
people
who
want
to
use
it.
E
I
think
the
technology
is
solid
and
I
wanted
to
make
sure
that
there
is
not
again
kind
of
like
you
know,
bad
interaction
of
about.
You
know
how
how
something
like
that
should
work.
So
what
we
hope
is
basically
to
propose
one
based
on
our
experience
running
it
in
production.
This
is
kind
of
like
again,
it's
a
very
new
market,
so
the
idea
with
this
is
mainly
to
it's.
Mainly,
it's
mainly
just
basically
suggest
and
say
look
guys.
We
are
a
little
bit
ahead
of
the
market.
So
here's
what
we
learned.
E
N
N
F
Well,
I
think
it's
super
interesting
and
I
know
there's
this
other
wasm
group
and
that's
been
working
on
some
stuff
and
I'm
assuming
you
guys,
are
kind
of
talking
yeah
amongst
yourselves,
which
is
awesome,
like
you
know,
part
of
what
we've
been
trying
to
do
for
a
while.
Now,
obviously,
is
take
this
ability
to
have
content
distributed
into
this.
You
know
production
oriented
world
from
dev
through
prod
being
open
to
lots
of
different
format
types,
so
you
certainly
kind
of
nailed
the
elements
of
that
to
make
it
simpler
and
especially
in
the
seo
world.
F
That
is
the
way
we
do
docker,
run
and
so
forth
that
you
can
store
in
a
registry
and
there's
these
things
that
def
that
allow
us
to
persist
a
runtime
image
in
a
registry
with
this
manifest
in
this
index
schema
thing
that
we
found
that
was
fairly
generic,
that
we
could
use
to
store
other
things,
and
you
can
store
a
vm
image.
You
can
store,
you
know,
which
is
obviously
huge.
You
can
store
a
helm
chart
which
is
nothing
more
than
some
text
and
everything
in
between.
F
So
I
think
part
of
the
feedback
would
from
from
us,
would
be
like
hey
we'd
love
to
see.
You
know
this
evolve
from
a
name
collision
kind
of
thing,
we'd
like
to
just
kind
of
avoid
calling
it
an
oci
image
and
calling
it.
You
know
something
else
and
then
of
course,
there's.
The
thing
is:
if
it's
actually
branded
oci,
then
there's
a
bunch
of
people
here
that
kind
of
are
very
interested.
In
being
part
of
that
conversation,
sure
we
would
love
you.
E
F
Is
hard,
I
I
don't
think
you're
getting
I'm
sure.
There's
a
bunch
of
people
have
feedback
on
the
specifics
of
what
you
guys
are
building
part
of
what
we
were
talking
about
here
was
just.
Is
we
like
to
get
in
front
of
everybody,
so
they
can
see
it,
but
it
is
it's
actually
literally
just
the
naming
that
we
wanted
to
try
to
work
through.
E
Okay,
so
you
tell
us,
you
know
we
can
totally
talk
about
it.
I
mean,
as
I
said,
this
is,
was
very
you
know,
intuitive
name
for
us.
That's
why
we
use
it,
but
I
mean
totally
fine
to
change.
There's
no
problem
at
all
and
again,
if
we
can
work
on
this,
if
you
have
any
thing
that
you
wanted
to
do
to
help
us
to
do
to
whatever
so
it's
kind
of
like
join
co
joins
forces
to
help
with
the
spec
or
change
the
spec
or
anything,
but
we
would
love
that.
F
Yeah,
the
way
we've
been
kind
of
doing
it
is
we've
become
saying:
look
there's
this
general
artifact
approach.
That
said,
you
can
store
anything
in
the
registry
and
there's
two
mediums
by
which
to
store
things.
There's
this
manifest,
which
is
what
most
images
are
they're,
not
multi-arc,
the
singular
architecture.
Images
are
sort
of
manifest
helm.
F
Charts
are
in
a
manifest
oppas
a
whole
bunch
of
our
singularity,
and
this
warmth
thing
that
I
just
saw
the
hardware
folks
promote,
there's
cnabs,
which
are
actually
based
on
index,
which
we're
working
on
getting
that
to
be
more
supportive
of
what
we
think
of
as
an
artifact.
Basically,
the
way
you
can
know
that
it's
an
index
is
a
cmav
versus
a
multi-arc
index.
F
So
at
that
point
the
spec
actually
isn't
even
in
oci
like
the
helm,
spec
doesn't
go
in
oci.
We
just
we
say
that
helm
can
be
pushed
to
our
registry
as
an
oci
artifact,
and
so
we're
kind
of
saying
the
same
thing
here
as
wasms
these
you
know
pleasant
assemblies
can
be
pushed
to
a
registry
as
well,
as
quote
an
oci
artifact,
and
that's
awesome.
F
So
I
think,
there's
a
very
minor
detail
of
hey,
we'll
work
with
you
on
the
specific
media
type,
because
we've
been
trying
to
make
sure
that
there's
a
clean,
unique
name,
space,
everybody
and
then,
as
far
as
the
spec
I
mean
I
I'm
not
like.
I
think,
there's
an
interesting
question:
does
oci
want
to
adopt
a
wasm
spec
or
is
it
cncf,
but
regardless
of
where
the
spec
lands,
you
can
still
have
it
sorted
in
a
quote
oci
registry,
the
way
you're
doing
it?
G
E
It's
also
a
little
bit
more
complex
because
I
don't
know
if
you're
aware,
but
there's
no
foundation
per
se
to
to
wasan.
There
is
the
bike
alliance,
which
are
there's
a
lot
of
politics
behind
the
scene.
We
are
just
waiting
patiently
until
we
will
have
a
place
to
land
it
if
it
makes
sense
to
you
guys.
F
E
F
Well,
I
think
that's
part
of
the
question
that
joshua's
touching
on
is
if
this
is
there's
two
ways
to
think
about
the
oci
brand.
If
you
will
anybody
can
start
something
in
an
ocr
registry,
we
refer
to
that
as
it's
an
oci
artifact
like.
If
you
want
to
store
something
on
a
file
system,
you
can
change
the
extension
to
whatever
you
want
and
the
file
system
will
store
it.
The
idea
that
you
have
a
file
extension
and
allows
you
to
know
what
the
type
is
is
the
thing
that
file
systems
support.
F
What
we've
done
is
effectively
done.
The
same
thing
with
registries
is
that
media
type
that
we
were
talking
is
how
you
say
that
this
thing
is
a
wasm
as
opposed
to
everything's
a
zip
file
right.
So
now
you
can
actually
say
this
thing
is
a
wasm
now,
whether
it's
an
istio,
that's
also
perfectly
fine
right.
The
the
thing
is
is
that
we
wouldn't
call
that
a
quote
oci
image.
That's
where
I
think,
where
the
little
bit
of
the
branding
and
trademark
stuff
kind
of
gets
a
little
confusing
so
totally
fine.
It's
a.
E
Good
feedback,
so
again
you
know
our
bed,
we
can
easily
fix
it,
though,
and
and
I
think
that
eric
asks
something
regarding
the
specifically.
So
I
don't
know
if
you
take
a
look
at
what
we
did,
but
basically
the
idea
is
that
it's
unhanded
like
for
wasabi
at
least
we
did
it
as
a
kind
of
like
there
is
a
configuration
part
that
you
can
extend
it
to
different
types.
So
it's
not
only.
It
doesn't
have
to
be
on
the
enboy.
E
We
specifically
just
put
the
envelope
because
it
makes
a
lot
of
sense,
but
the
idea
was
to
extend
it
to
different,
because
you
know,
as
I
said,
wassum
is
going
to
use
for
way
more
stuff,
specifically
specifically
for
for
a
full
cloud
native
technology.
So
I
just
wanted
to
say
that
yeah.
So
I
actually
don't
know
you
guys
know
better
than
us,
because
you're
already
running
those
specs,
so
any
feedback
will
be
really
really
good.
F
I
just
see
that
was
me
so
just
mistaken
time,
because
we
try
to
be
good
about
everybody's
meeting
times
and
I'm
actually
late
to
something
as
well.
I
I
don't
know
what
time
zone
you're
in
like
where
I'm
happy
to
follow
up
directly.
We
can
follow
up
next
week
at
the
same
time
in
this
meeting,
and
I
think
I'm
I'm
guessing
a
lot
of
other
people
are
interested
as
well.
So
if
the
time
zone
works,
the
time
works
for
various
time
zones
next
week.
H
Yeah,
I'm
interested
in
this
topic
too.
I'm
sorry.
I
had
to
jump
out
for
a
little
bit
but
yeah
I
played
around
a
little
bit
with
it
on
the
container
d
side.
I
definitely
have
like
some
thoughts
about
like
what
I'd
like
to
see
be
possible
as
not
just
like
the
general
wasn't
case,
but
for
oci
images,
and
I
should
be
able
to
run
the
containers,
but
that's
a
little
different
than
like
the
envoys
stuff.
H
So
I
just
want
to
make
sure
that,
like
we
can
separate
the
two
and
not
not
have
them
be
like
confused,
because
there
is
an
idea
of
just
being
able
to
run
wasm
onesie,
like
general
containers
yeah
like
application
containers,
but
yeah.
You
know
that's
different
from
the
the
envoy
case.
So
that's
mainly
what
I
want
to
make
sure
separated,
but
I'd
be
interested
in
participating
in
that.
E
F
E
Yeah
and
as
I
said,
we
actually
personally
doing
other
stuff
right
now
with
watson
that
is
not
related
to
envoy.
So
we
definitely
like
we,
we
game
with
you
like
we
agree
and
also
I
know
that
we're
working
with
microsoft
and
with
the
capital
ones,
and
they
trying
to
do
basically
to
be
able
to
run
a
wasm
instead
of
docker
in
a
in
a
in
kubernetes.