►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
OCI BoF - Alban Crequy, Kinvolk & Chris Aniszczyk, CNCF (Any Skill Level)
About Chris Aniszczyk
Chris Aniszczyk is an engineer by trade with a passion for open source and building communities. At Twitter, he created their open source program and led their open source efforts. For many years he served on the Eclipse Foundation's Board of Directors representing the committer community and the Java Community Process Executive Committee. In a previous life, he bootstrapped a consulting company, made many mistakes, lead and hacked on many eclipse.org and Linux related projects. He is now the COO of the Cloud Native Computing Foundation and VP of Developer Programs at The Linux Foundation.
About Alban Crequy
Originally from France, Alban currently lives in Berlin where he is a CTO & co-founder at Kinvolk, a software engineering team focused on building foundational Linux technologies for the cloud. He is a contributor to rkt, a container runtime for Linux, Weave Scope, a container visualization & monitoring tool, and is actively working on BPF-related projects. Before falling into containers, Alban worked on various projects core to modern Linux; kernel IPC and storage, dbus performance and security, etc. His current technical interests revolve around networking, security, systemd and containers at the lower-levels of the system. Alban previously gave talks at several conferences including FOSDEM, Linux Plumbers, IO Visor Summit, Kubecon and LinuxCons/OSSummit.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
F
H
J
B
N
A
People
are
late,
you
could
wait
so
before
we
have
all
been
kind
of
give
us
an
update
on
OCS
certification.
So
what
what
happened?
Initially
when
we
started
o
CI
was
our
initial
goals
of
getting
one
point
about
the
door
happened
and
then
you
know
we
took
a
few
steps
back
and
kind
of
delayed
our
work
on
certification
work.
So
now
that
one
o
is
out
the
door,
we
also
recently
added
the
distribution
spec,
which
should
help
with
kind
of
house
certification
is
done
on
the
image
front.
A
So
they're
gonna
get
dive
in
a
little
bit
on
kind
of
their
research,
and
then
it
would
be
kind
of
good
to
hear
from
the
room
of
what
the
thoughts
are
and
how
we
kind
of
move
forward
on
this,
and
then
it
looks
like
there's
also
some
like
kind
of
I
guess,
container
end-users
in
a
room
that
are
just
interested
in
just
general
questions
will
allow
you
to
ask
them
as
it
makes
sense.
Yes,
yes,
Dean.
Yes,.
A
O
O
So
it's
a
snapshot
screenshot
of
the
github
page.
It
showed
on
the
spec
some
modification
one-time
tools
as
well
and
on
the
image
side
right,
no,
nothing
in
the
last
month
that
was
done
obviously,
and
named
image
test
no
charge
either
on
under
the
distribution.
That's
really
recent
so
that
the
initial
work
today.
O
O
Okay,
so
that
commits
taken
over
from
the
degrees
of
a
study
on
distribution
truth
that
does
not
exist
when
they
think
so
now,
we'll
talk
about
OCI
in
one
time,
so
there
is
one
repository
which
contain
the
specs,
so
that's
mostly
text
files
with
respect
description
on
the
spec
itself
does
not
mandate
any
weight.
It
does
not
mandate
any
CLI
flags
or
Jia
PC
interface
or
anything
like
that.
It
defines
different
actions
with
parameters,
but
it
does
not
mandate
any
CLI.
O
So
in
order
to
be
able
to
run
tests,
the
tests
need
to
have
a
way
to
execute
the
runtime.
So
in
the
repository
of
the
test,
there
is
the
additional
CLI
spec
that
explain
how
it
will
execute
the
test.
So
this
sale
is
back
in
the
test.
History
is
actually
the
how
one
see
does
it
so
when
we
run
the
test
we
can
specify
which
one
time
we
want
to
test.
In
this
case
we
want
to
test
Quincy
and
we
can
either
run
other
tests
or
execute
one
specific
test
that
we
want
to
try.
I.
O
I
did
the
same
in
Seiran
so
that
that
will
always
what
Mary
but
then
removed,
but
you
can
have
a
look
at
that
on
four
bubble-wrap
OCIO,
which
is
a
vapor
one
bubble
wrap
at
the
moment.
I
cannot
run
any
tests
because
it
doesn't
support
right
now.
The
two
action
create
on
start
continuous,
so
I
I
cannot
contest.
O
This
is
a
kind
of
summary
data.
We
don't
know
where
I
go
about
test
on
Nancy,
so
some
of
the
whenever
other
tests
give
a
failure.
It
could
be
either
because
a
bug
in
one
see
that
it
doesn't
follow
the
spec.
So
there
is
a
couple
of
issue
file
you
for
that.
This
does
Avenue
Tantra
V,
so
it
could
be
a
limitation
of
the
Travis
CI
platform.
For
example,
it
doesn't
allow
any
single
modification
for
a
block.
O
O
Yes,
so
one
of
them
about
the
delete,
I
think
there's
a
discrepancy
between
the
speck
on
the
implementation.
I,
don't
remember
the
exact
details
about
this
one
on
the
other
one
is
about
setting
the
Mon
propagation
on
the
OT,
FS
I
think
some
options,
don't
work
on
1c
I.
Think
if
I
remember
call
he
used
to
work,
but
maybe
it's
a
regression
and
I'm
not
quite
sure
so.
Yeah
I
put
the
links
to
their
issues.
O
O
Okay,
so
this
is
a
non-si
I,
give
it
a
try
on
different
runtime
implementation.
So
once
he
as
I
said,
there
is
a
couple
of
issues
filed
about
a
couple
of
issues.
Seven,
there
was
a
minor
issues
about
the
common
line,
parameter
which
is
no
fixed.
So
now
I
can
run
the
test,
but
well
wrapper.
Ci
I
cannot
run
the
test
because
it
does
not
support
the
two
steps
create
on
start
that
are
specified
in
a
spec.
O
O
O
Spawn
or
CRE
that's
not
a
project
that
exists
yet,
but
so
CMT
and
spawn
can
start
containers
and
there
is
some
interest
to
make
it
more
aligned
to
the
OC
respect.
So
when
it
exists,
we
can
wait
and
then
docker
or
continuity
was
here.
Oh
that's
more
high-level
container
on
time,
so
it
doesn't
deserve
directly
expose
the
OCI
bundle
interface.
Oh,
it
doesn't.
F
O
E
Sorry
for
interrupting
your
you're
doing
a
great
talk
with
apologies
for
interrupting,
so
a
container
d
actually
exposes
the
the
runtime
spec
directly,
so
you
can
inspect
it
and
then
actually
inspect
the
on
disk
bundle
through
the
runtime.
So
but
the
issue
we
have
with
certification
is:
if
we
just
if
we
certify
on
the
on
the
command
line
interface,
which
actually
isn't
a
standard,
then
we're
unable
to
certify
things
like
cryo
and
docker
and
container
D.
So
that's
where
the
main
issue
with
certification
was
historically.
O
O
So
for
content
on,
you
can
check
that
ok
on
the
status
and
orchid,
so
there
is
no
support
at
the
moment,
neither
for
dossier
avantime
or
the
image
spec.
There
is
a
few
issues
feel
about
that.
One
github.
What
about
supporting
the
OCIO
on
time
on
supporting
the
image
spec
on
another
issue
which
is
about
using
runs
internally,
so
our
cat
has
a
different
stage
system.
O
O
I
I
O
O
O
Well,
otherwise,
on
this
issue
there
was
different.
Ids
talked
about
about
her
different
way
to
do
that,
like
exposing
the
OCI
interface
that
was
talked
about
I
think
we
mentioned.
If
we
use
fancy
unmodified,
then
we
can
consider
that
the
higher
level
or
die
be
certified
or
run
tests
with
them,
Mach,
1,
C
and
C,
whether
it's
called
there
are
ones.
Oh,
she
opened
an
interface
correctly,
so
Safari
not
work.
We
are
focused
only
on
the
one
see
like
one
time
on
I.
Think
we'll
continue
on
that
to
finish
the
test.
E
F
N
C
O
A
So
so
you
know
when
we
had
the
certification
working
group
initially
formed
and
tasked
with
coming
up
with
scope
for
the
program.
The
initial
ideas
is
a
lot
of
us
thought
what
what
the
end
users
want
to
see
right.
You
know
they
want
to
see
if
they
use
I,
don't
know
ECR
or
any
other
registries
out
there
or
you
know
any
of
the.
You
know
things
that
run
containers.
A
G
If
that's,
the
intent
is,
as
a
customer
I
want
to
buy
or
use
an
OC
ice
certified
runtime
if
I
step
up
to
gke
or
aks
doc.
Do
I
want
to
see
that
brand
on
those
services,
because
if
the
answer
to
that
is
yes,
then
the
testing
infrastructure
that
will
support
a
certification
program
would
need
to
support
somehow
running
that
test
environment
to
demonstrate.
You
know
just
if
we
can,
if
the
only
thing
that
we
can
run
the
testing
harness
against,
is
the
reference
implementation.
G
Well,
that
that
better
work
I
mean
they've,
done
good
work
and
demonstrated
that
yes,
the
the
spec
and
the
reference
implementation
are
drifting.
Okay.
We
we
knew.
That
would
happen
sooner
or
later.
But
if,
if
I
say,
okay,
we've
got
run
C.
So
how
do
I
demonstrate
in
a
KS
using
Microsoft
as
an
example
that
I'm
using
that
run,
see
that
was
certified
and
I'm
gonna?
G
Tell
you
right
now
that
if
my
customers
are
demanding
a
high-quality
solution
and
I
have
to
change
Runcie
after
it's
been
certified,
I
will
do
the
right
thing
for
my
customer.
So
that's
why
I'm
trying
to
say
where?
Where
is
the
reality
for
me
as
a
vendor,
providing
a
product
that
will
have
a
run,
see
that's
certified,
sorry
a
run
time
that
is
certified.
How
do
I
use
that
to
solve
that
problem
for
the
customer
who
wants
to
so
that
that's
the
problem
I'm
trying
to
bridge.
J
I,
it
is
likely
that
you
will
have
vendors
who
don't
comply,
and
so
it's
it's,
it's
critical.
Whatever
I
mean
just
my
personal
experience,
it's
critical
to
give
to
make
sure
that
you
can
test,
if
not
a
hundred
percent
as
much
of
the
specification
as
you
can
from
user
space,
so
to
be
able
to
show
up
drop
a
container
into
a
system
and
test
as
many
capabilities
as
you
can,
and
not
assume
that
you
have
to
have
privileged
access
to
check
everything.
J
E
F
E
Think
I
think
going
off
those
requirements.
If
you
take
number
three
and
turn
that
into
like
a
proxy-
or
you
can
say,
alright
run
this
thing
and
then
call
in
to
this
runtime
and
then
it
basically
passes
everything
through
and
checks
the
results
and
then
and
it
works
and
then
combine
it
with
number
four
that
would
work
with
every
like
high
level.
Runtime
like
docker
in
container
D
would
work
with
that
and
cryo
would
be
able
to
work
with
that
out
of
the
box,
and
so
I
basically
like
modify
the
suggestion.
G
Because
what
little
playing
and
I
haven't
touched,
the
test
suite
for
eighteen
months
now,
but
what
little
playing
I
did
at
the
time
there's
there's
two
levels:
there's
there's
a
the
way
that
a
lot
of
the
test
sweetest
was
structured.
Was
you
build
a
container
full
of
the
test
cases
and
that
allows
you
to
test
an
enormous
amount
and
that
that
would
be
something
you
could
hand
off
to
IKS
or
anything
else.
This
small
piece
of
the
runtime
that
you
run
into
where
you
can't
easily
test
it.
G
That
way
goes
back
to
the
idea
that
Stephen
was
talking
about
a
moment
ago,
because
there's
not
a
command-line
interface
I
can't
test
the
actual
life
cycle
on
a
higher
level
construct.
But
if
that's
the
only
thing,
that's
messing,
we've
still
come
a
long
way
in
being
able
to
say
here
is
a
container
a
collection
of
containers
full
of
tests.
G
If
I'm
understanding
number
two
well
the
the
problem
with
it
is
right.
Well,
if,
if
I've
I'm
gonna
build
the
right
thing
out
of
this
open
source
project
into
my
product,
I
will
make
changes,
and
so
I
will
not
verify
that
it
was
those
bits
that
I
downloaded.
So
those
bits
are
irrelevant
to
me,
except
you
know
I
because
I
might
have
to
fix
a
bug,
and
even
if
I
contribute
that
bug
fix
back,
it
may
get
modified
in
getting
reemerged,
and
so
the
bits
are
never
the
same.
E
F
O
Next
class,
it's
just
view
of
what
changes
are
no
history.
In
the
last
two
months,
sorry
chose
contributors
on
newer
files,
changed
and
there's
a
few
progress
in
progress,
so
it
doesn't
show
everything
and
then
I
have
a
maybe
four
slides
about
a
different
kind
of
change.
That
happened.
There
was
refactoring
in
a
tab,
so
tap
is
destiny,
test
anywhere
framework
or
protocol
on
it
showed
the
result
of
each
test
in
a
specific
format
that
is
described
below
at
this
title.
It
just
print
okay
or
not.
Okay,
if
the
tester
has
succeed
or
fail.
O
So
there
was
a
number
of
fix
about
that.
There
was
some
general
fixes,
so
good
part
of
the
test
run
specific
binary
in
the
container
on
this
check.
If
everything
is
fine,
according
to
the
JSON
config
Jason
on
some
other
test
test
model
life
cycle,
but
most
of
the
tests
I
think
in
the
in
the
first
category,
where
it
just
executes
a
binary
in
the
container
on
check
that
is
in
the
correct
environment.
So
there
was
some
fix
about
that
about
the
base
file
system
that
exists
in
that
container
alignment
for
the
test.
O
There
was
some
test
about
with
writer.
We
don't
need
that.
We
have
fixed
some
test
about
propagation
months
on
other
tests,
second,
etc.
There
was
some
improvement
about
checking
to
run
the
test
on
the
correct
platform.
Basically,
there
was
some
if
platform
is
Linux.
Also
Larissa
windows
do
different
things.
O
There
was
some
test
updates
on
air
limits
on
test
ability
to
use
our
namespace
fix
on
we'd,
only
weed
white
on
some
new
tests.
I
did
about
capabilities
about
the
process
user,
whether
it
run
in
a
correct,
UID,
etc.
Test
about
hooks
tests
about
when
changing
the
configuration
after
we
look
at
container
has
been
started.
He
does
not
actually
change
the
container
as
the
spec
require
on
test
about
delete
on
annotations.
O
That's
all
for
my
slide
about
the
OCI
runtime
on
I.
Have
a
similar
question
slide
about
the
scope
of
the
OCI
image
certification.
So
this
is
two
issues,
so
basically
what
I'll
be
satisfying?
Do
we
want
to
certify
specific
images
or
specific
or
see
on
time
that
wait,
the
image
correctly
or
certifier
registries
or
image
builder.
G
So
I've
been
pushing
in
this
discussion
for
a
long
time
now
that
well
we
want
to
certify
runtimes.
We
wanted
to
simply
validate
images.
I,
don't
believe
you
want
to
mislead
customers
by
certifying
images,
because
the
implication
of
a
certified
image
is
that
it's
gonna
run
on
a
certified
runtime
and
while
that
sounds
great,
I
can
tell
you
as
an
ISV
I'm,
not
gonna,
promise
that
I
run
on
Joe's
runtime,
just
because
it
was
certified.
G
I'm
only
gonna
promise,
my
customers
that
I
run
on
things
that
I
have
tested,
so
it
doesn't
provide
the
promise
that
folks
think
it
provides.
I
absolutely
want
to
know,
though,
that
as
an
ISV,
the
container
that
I've
built
to
distribute
my
app
is
a
valid
container
and
should
on
everybody's
sorry.
Thank
you
a
valid
image.
Thank
you.
J
E
Kind
of
thinking
from
a
technical
perspective,
I
agree
with
mr.
Walley
it
well
yeah.
You
can't
really
certify
that
an
image
is
gonna
run.
You
know
on
a
certain
place,
you
can
certify
or
you
can
validate
it
so
like
focus
on
validation
and
then
but
separate.
We
need
to
separate
the
behavior
of
the
registry
from
like
the
kind
of
abstract
notion
of
certifying
the
components
of
an
image
right
so
or
sorry,
validating
the
components
of
the
image
and
I
think
the
the
problem
with
run
time.
E
There
are
sorry
image
tools
thus
far
as
they
focused
around
validating
the
the
image
layout,
which
and
not
focused
on
the
abstract,
validation
of
the
components
as
referenced
by
the
like
image.
Digests.
Does
that
make
sense
so
like
if
you,
if
you
say
I,
have
image
with
this
digest
and
then
you
pull
that
out
and
you
get
a
manifest
list.
E
You
should
then
validate
that
manifest
list,
and
then
you
should
walk
down
and
grab
each
image
for
each
platform
and
or
each
you
know,
that's
in
that
manifest
list
and
then
validate
that
those
components
are
supported
and
then
also
to
help
with
with
with
transition.
We
should
probably
also
like
grandfather
in
the
docker
media
types
into
that
validation,
as
well
I
mean,
and
they
are
part
of
the
specification
just
so
that
people
don't
need
to
rebuild
everything,
to
get
valid.
Oci
images
in
that
validation.
O
A
A
G
A
A
K
I
A
Mean
I
think
it's
hard
to
commit
to
a
date
like
I.
Think
we've
made
some
progress
on
in
terms
of
what
work
needs
to
be
done,
at
least
on
the
run
time
and
distribution
side
like
this
distribution,
spec
hasn't
shipped,
you
know
a1,
no,
so
like
we
can't
certify
something
that
is
not
finished.
So,
on
the
run
time
bit,
you
know
that
has
a
lot
more
progress,
so
we
could
probably
do
something
there
but
like
we,
which
is
impossible
to
commit
the
timelines
I.
A
Would
love
something
by
the
end
of
this
year,
but
you
know
that's
I'm,
not
gonna
hold
anyone
to
to
a
specific
date,
but
for
me,
I
have
enough
feedback.
Then
I'm
gonna
go
go
work
with
the
the
kinfoke
folks
and
see
if
we
can
make
a
little
bit
more
progress.
So
I
got
some
ideas,
especially
from
the
runtime
side.