►
From YouTube: Panel: The Open Container Initiative (OCI) and the Future of Container Standardization [I]
Description
Panel: The Open Container Initiative (OCI) and the Future of Container Standardization [I] - Moderated by Chris Aniszczyk, Linux Foundation
With the proliferation and rapid growth of container-based solutions over the past few years-- including container-based solutions from almost all major IT vendors and cloud providers as well as emerging start-ups-- the industry needed a standard on which to support container formats and runtime. Enter the Open Container Initiative (OCI), established to help promote a set of common, minimal open standards and specifications around container formats and runtime. Setting a baseline de facto standard, OCI will soon release version 1.0 of its runtime and image format specifications, now ready to look at what’s next for the future of container standardization and distribution. Hear from OCI members who are experts in container technology as they discuss the project’s progress at large with special focus on what’s coming next after the v1.0 release and certification program launch. Additional discussion topics will include:
How the runtime and image format specs are driving broader innovation
The impact the v1.0 release will have on the container landscape
Implementations and use cases
Value and benefits of the certification program and what that means for container standards
Future plans for the OCI
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 Vincent Batts
A mindful polyglot, Vincent Batts has spent the last 15 years participating in the Linux and open source community. Presently involved on the Open Containers Initiative as a maintainer and on the technical board. Still a current member of Slackware Core Team and has been a maintainer on the Docker project as well as the Go programming language for Fedora and Red Hat. He is currently working on all things container architecture in Red Hat's Office of Technology.
About Jeff Borek
Jeffrey Borek, WW Program Director, IBM - is a senior technology and communications executive with over twenty years of leadership and technical experience in the Software, Telecommunications, and Information Technology/Consulting industries. He is currently the ecosystem development lead for the Open Technologies and Partnerships team - working with clients, business partners, leading industry analysts, and various open source community initiatives including; the Cloud Native Computing Foundation (CNCF), co-chair of the Certification Committee of the Open Container Initiative, and the Open API Initiative (OAI).
About Saurya Das
Program Manager, Microsoft
About Brandon Philips
Brandon Philips is helping to build modern Linux server infrastructure at CoreOS as CTO. Prior to CoreOS, he worked at Rackspace hacking on cloud monitoring and was a Linux kernel developer at SUSE. As a graduate of Oregon State's Open Source Lab he is passionate about open source technologies.
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
Hello,
hello,
all
right,
perfect,
test
test
test
test,
one
two
three,
so
thank
you!
Everyone
for
coming
today
for
panel
around
the
open
container
initiative
in
the
future
of
container
standardization.
We
have
a
great
set
of
folks
today
to
talk
a
little
bit
about
their
involvement
in
OCI
and
kind
of
where
they
see
the
project
going
in
the
future.
For
those
of
you
that
are
in
the
room,
how
many
people
actually
know
of
the
open
container
initiative
OCI
with
show
of
hands?
A
That's
actually
a
lot
better
than
I
expected,
so
kind
of
flies
under
the
radar,
sometimes,
but
that's
great
so
to
kind
of
kick
things
off.
I'll
have
each
panelist
kind
of
intro
themselves
in
terms
of
their
background
and
how
they're
you
know
involved
with
the
project
not
only
themselves
but
their
company
and
we'll
kind
of
go
it
go
from
there
and
we'll
kind
of
be
laid
back
in
terms
of
questions
from
the
audience.
I
have
a
basically
handful
of
questions
to
ask
these
folks
and
then
we'll
kind
of
open
up
the
audience
for
any
questions.
B
D
My
name
is
Vincent:
batts
have
been
in
so
I
work
at
Red,
Hat
I've
been
in
and
around
this,
the
container
open-source
community
for
about
three
and
a
half
years
yeah,
and
particularly
with
with
the
open
containers
initiative
for
the
last
year
and
a
half
maintainer
of
various
projects
and
all
the
technical
oversight
board.
So
pretty
well
busted
there
I'm.
E
Brandon
phillips,
the
CTO
co-founder
of
core
OS
we
got
involved
in
SEI
is
one
of
the
project
co-founders
with
red
hat
and
docker,
and
a
lot
of
the
other
folks
on
stage
and
I
sit
on
the
technical
oversight
board
and
share
the
technical
oversight
board
of
the
OCI
and
yeah
and
along
with
vincent
and
everybody
else.
We've
written
a
large
bulk
of
the
specification.
F
A
So
to
kind
of
kick
things
off
in
my
first
question
so
this
morning,
I'm
sure
a
lot
of
folks
heard
the
announcement
that
container,
D
and
Rockets
are
coming
in
to
CN
CF
I
have
had
the
unfortunate
job
of
being
pinged
by
a
lot
of
folks
of
what
that
actually
means
for
the
OCI
and
how
that's
related,
so
I
will
properly
deflect
that
question
to
our
panelists,
to
kind
of
give
an
update
to
everyone
here
on
that
so
feel
free
to
kind
of
answer.
In
any
way
you
want
to.
So,
from
your
perspective,
sure.
E
E
On
the
other
side,
I'm
sympathetic
to
the
people
who
have
to
execute
the
container,
but
which
is
the
hard
work
that
is
done
inside
of
container
DNA
and
rocket,
but
primarily
I'm,
concerned
with
ensuring
that
we
have
these
specs
so
that
there's
confidence
that
building
a
container
today
means
that
it
will
work
into
the
future.
That's
kind
of
how
I
think
of
it,
and
then
the
responsibilities
are
that
really
rocketing
container
D
are
systems
that
make
different
trade-offs
in
order
to
execute
those
containers.
And
it's
really
up
to
the
users
and
I.
E
B
Yeah,
so
on
the
darker
side,
I
gave
our
perspective
this
morning.
Oci
is
the
spec
and
so
run.
C
is
the
reference
implementation
for
the
runtime
spec,
but
is
that
the
spec
level
and
then
container
D
is
an
implementation
of
that
spec
and
it
actually
includes
run
C
so
I'd
say
when
people
are
asking,
what
does
it
mean
for
OC?
I
is
just
one
more
implementation
of
OC
I
awesome.
C
Yeah
absolutely
well:
they
at
the
end
of
the
day,
quick
show
of
hands
how
many
out
in
the
audience
have
been
involved
in
SD,
O's
or
traditional
standards.
Development
organizations
in
the
past
yep.
Okay,
so
you
know
I
think
everyone's
obviously
seen
a
large
shift
over
the
last
decade
to
a
focus
from
a
kind
of
a
standards.
First
type
of
orientation
towards
the
rapid
activity.
That's
happening
in
open
source
communities
and
when
you
know
IBM
certainly
been
heavily
involved
with
open
source.
C
For
you
know,
over
15
years
now,
but
one
of
the
big
things
that
IBM
focuses
on
is
trying
to
make
sure
that,
when
something
takes
off
in
an
open
community
from
an
open-source
software
perspective,
it's
not
just
open
around
this
open-source
license.
But
it's
also
open
in
terms
of
the
way
the
project's
governed.
A
D
D
There
are
that's,
that's,
obviously
not
hard
and
fast,
because
run
see
is
over
there.
Even
though,
if
it's
a
it's
a
reference,
implementation,
OCI
now
has
libraries
for
how
to
handle
the
digestive
layers.
It
now
has
SELinux
libraries,
so
there
is
code
in
OCI
and
I.
Think
CNI
is
in
CN
CF
and
that
has
some
specifications
to
it
as
well.
Not
yet,
oh,
it's
not!
Oh
I
see
a
decision.
A
D
Fine
today,
but
still
so
there
there's
there's,
there
are
going
to
be
some
amount
of,
even
if
even
if
just
a
facto
standards
arising
out
of
CN
CF,
maybe
not
codified
specifications,
and
there
is
code
that
lives
in
OCI.
So
the
line
is
blurry
no
doubt,
but
as
far
as
the
scope,
the
because
of
all
the
folks
that
are
involved
and
I
think
to
some
people's
dismay,
we
wanted
OC
I
to
start
off
with
the
simplest
building
blocks,
because
some
of
this
has
been
moving
so
fast
and
we
are,
to
some
extent
a
trailing
specification.
D
We
wanted
those
basic
building
blocks
so
when
folks
say
why
is
this
not
being
done
a
no
CI
yet
or
blah
blah
blah?
Why
are
you
just
doing
runtime
and
image?
We
needed
that
conversation
first,
because
anything
that
builds
on
after
that
distribution
signing
so
and
so
forth.
Some
of
the
things
that
kind
of
challenge
what
is
in
scope?
D
It's
all,
let's
get
the
first
building
blocks
done
first,
and
then
we
can
move
on
and
have
these
other
conversations,
because,
even
though
simple
building
blocks
like
brandon,
said
the
tooling
that
builds
on
it
that
consumers
want
to
rely
on
for
an
indefinite
future.
All
this
comes
back
to
certain
building
blocks.
This
is
our.
This
is
the
scope
right
now,
as
you
get
higher
in
the
stack,
it
gets
a
little
blurry
whether
or
not
you're,
just
talking
about
a
de
facto
standard
or
a
specification.
E
So
juicy
a
concrete
when
OCI
started,
the
the
initial
scope
was
around
a
run
time,
so
actually
how
process
gets
executed
and
and
that
sort
of
stuff
it's
how
the
c
groups
could
set
up
the
environment
variables
below
and
then,
after
that,
we
had
a
vote
where
we
added
into
scope
the
image
format,
so
actually
how
all
these
files
get
clubbed
together
and
all
the
metadata
associated
with
the
image
and
then
some
things
that
people
have
wanted
to
discuss.
Post,
104
OCI
is
potentially
house
signing
and
signing
metadata
works
and
then
potentially
the
the
way.
E
B
Okay,
so
maybe
it's
a
wrong
example
and
just
on
on
the
on
the
standardization,
what
I
would
say
is
standards
are
really
good
to
get
an
agreement
by
everybody
in
an
industry
when
we
have
stopped
innovating
in
a
certain
area
where
everybody
agrees
on,
and
so
that's
why
you
see
I
had
should
I
say
very
opinionated
discussions
at
each
creation.
I
think
we
can
say
that
about
what
the
scope
should
be
until
we
just
agreed
on
an
intersection.
That
was
the
container
run
time,
and
then
we
expanded
that
to
the
image
format.
B
A
A
And,
and
so-
and
you
know
honestly,
first
and
yeah
and
my
response
is
generally
you
know
if,
for
a
standards
body
we're
actually
moving,
you
know
pretty
decently,
look
how
long
it
took
like
HTTP
to
oh
and
all
that
to
take
place.
So
you
know
geez,
look
how
fast
that
w3c
moves
for
things
so,
but
I
won't
answer
this
question.
I'll
have
someone
in
the
panel
talk
about
so
I
know
we're
close,
there's
rumors
on
the
street
that
we
may
be
shipping
one
Oh
soon,
I'll.
D
It
is
kind
of
funny
and
I
get
asked
this
often
enough
that
there
there
is
a
dichotomy
at
play
and
an
open
source
is
a
bizarre
and
wonderful
convergence,
and
you
see
the
the
San
Francisco
Bay
mindset
when
it's
like
we're
at
a
year
and
a
half
into
this,
and
people
are
like.
Oh
god
like.
Why
is
this
not
done
already
and
then
and
then
I
go
talk
to
folks
in
the
industry
and
they're
like
this
is
moving
very
fast.
D
Like
are
we
sure
I
mean
like
you're
comfortable
with
this,
like
less
than
two
years
and
you're
ready
for
a
one
dot
Oh
like,
and
so
we
are
in
a
bizarre
intersection,
but
the
the
testament
is
that
much
of
this
is
being
used
in
production
already
and,
and
there
are
plenty
of
tools,
projects
and
all
the
way
up,
the
stack
and
to
a
large
degree.
Some
of
this
is
an
implementation
detail
it.
D
It
is
almost
by
design,
boring
and
as
it
should
be,
but
that
that
that
same
Testament
means
that
this
stuff
is
being
used
in
production.
Some
of
it
even
pre-release,
like
there's,
already
been
folks,
implement
to
some
of
the
release
candidates
and
there
would
be
a
slight
change
and
they
had
to
retool.
That's
where
we
are
with
the
so.
Both
the
image
spec
and
the
runtime
spec
are
at
a
1.0
release
candidate
5
there's
no
in
there's
no
formal
cadence
to
say:
thou
shalt
have
well,
it
says
at
least
but
yeah,
it's
not
like
5.
D
You
know,
there's
a
there's,
no
patterns
like
even
on
the
Linux
kernel
that
you
have
about
7
or
8
release
candidates,
and
then
we
release
every
so
often
those
note
of
that.
It's
a
lot
of
folks
saying
how
much
they
vetted
it,
how
much
they
test
it.
How
much
they
feel
comfortable
that
any
changes
that
we
make
after
100
aren't
gonna
be
bolted
on.
We
feel
pretty
comfortable
with
that.
D
So
with
the
runtime,
we're
at
our
C
5
I
mean
I,
didn't
prepare
for
this,
but
we
could
like
put
up
the
vote
right
here
on
the
stage
for
that
for
the
window
and
it
would
likely
have
like
a
week
but
turn
around,
because
this
is
just
waiting
on.
Like
a
rebase
of
some
of
the
tools
that
are
consuming,
run,
C
so
run
C
being
on
the
this
updated
implementation,
you
know
green
flags
up
the
CI
CD
stack
that
are
consumers
of
this
implementation.
D
E
There's
been
a
couple
of
people
who
had
a
very
fair
criticism
about
not
having
implementations
of
some
of
the
release
candidates
and
so
we've
been
writing
this
line
of
writing
a
specification
and
then
trying
to
encourage
people
to
actually
build
software
against
the
specification
and
then
getting
feedback.
So
I
just
wanted
to
like
recognize.
Some
of
the
like
project
started.
Doing
that
hard
work,
so
Runcie
has
had
to
put
up
with
a
lot
of
changes,
so
lost
the
heart
of
everyone
on
that
team
and
then
on
the
image.
Spec
side.
E
E
And
so
there's
been
a
lot
of
other
projects,
there's
been
multiple
imitations,
the
runtime
spec
stuff,
like
container
D
and
rocket
etc
are
implementing
both
image,
spec
and
runtime
spec,
either
through
dependent
projects
or
independent
implementations.
There's
cipher
did
his
own
implementation,
the
runtimes
packets,
etc.
So
a
lot
of
the
credit
for
the
progress
also
goes
to
the
folks
that
are
actually
holding
us
accountable,
that
this
can
be
built
into
code.
A
E
Yeah
I'll
take
a
swing
at
it
as
one
of
the
people
responsible
if
you're
seeing
I
so
where
we're
at
there
is
that
we
we
have
a
bunch
of
implementations
of
CNI
both
on
the
people
consuming
it
so
projects
like
kubernetes
and
mazes
and
Cloud
Foundry,
I
believe
and
then
network
vendors
implementing
it.
So
you
have
flannel
and
weave
and
calico
and
Kanta,
'v
and
I'm
sure
I'm
missing
somebody.
Who's
gonna
be
mad
at
me
later
and
so
I
think
that
ecosystem
is
going
along
nicely
and
I.
A
G
B
So
I
can
add
to
that,
so
so
networking
definitely
was
not
out
of
scope
or
was
out
of
scope
of
OC
I
and
in
container
D.
So
the
goal
of
container
D
is
to
be
that
container
runtime
that
kubernetes
or
docker
could
use,
and
initially
we
had
networking
at
like
we
had
four
steps
into
our
roadmap
until
one
o.
Initially,
we
had
networking
in
there
with
a
nice
sentence
in
the
roadmap
saying
we
need
to
find
something:
that's
between
CNI,
which
is
pretty
low
level
and
CNM,
which
is
much
higher
level.
B
Something
in
between
that
would
work
for
both
very
quickly
after
some
discussions
we
just
decided
that
it's
out
of
scope
for
continuity
as
well
so
the
way
you're
doing
you're
doing
networking
is
that
the
higher-level
system,
like
kubernetes,
is
going
to
do
it's
in
a
business
for
networking
and
then
create
the
network.
Namespaces
and
inject
them
in
the
container
and
docker
will
do
the
same
for
cm.
B
E
Throw
something
out
controversial,
so
one
of
the
great
things
about
these
these
specifications
and
like
solving
this
is
largely
like
I'm,
not
super
sympathetic
to
network
vendors
like
if
they
have
to
write
two
whole
plugins
to
plug
into
this
entire
ecosystem.
Here,
I'm,
okay
with
them
wasting
a
little
bit
of
time
and
effort,
and
so
I
mean
it's
a
great
long-term
goal
to
reconcile
the
two
models.
But
largely
it's
not
an
unreasonable
amount
of
effort
to
have
like
a
gigantic
company
like
Cisco
write
to
plugins.
A
Nope
all
right
we'll
have
time
at
the
end.
So
a
couple
final
questions
to
the
panelists
we
have
about
ten
minutes,
so
we
talked
a
little
bit
about
scope
right.
So
you
know
she
has
very
limited
scope,
we're
getting
close
to
100.
What's
gonna
happen
after
we
declare
100
or
you
know,
redone,
are
we
gonna?
Do
a
201
one
like?
What's
what's
the
current
thoughts
within
the
OCI
TDC
of
essentially
either
expanding
expanding
scope,
or
you
know
what's
next?
A
D
Chris,
yes,
okay,
I,
you
know
by
two
pieces:
I,
don't
have
any
crystal
ball
to
say.
What's
next,
there
are
a
number
of
items
even
on
the
github
project
that
have
been
brought
up
or
viable
conversations.
Some
of
them
are
wildly
nuanced
I
mean
down
to
if
anybody
has
waded
into
looking
in
the
tar
archive
of
a
layer
that
gets
transmitted,
whether
or
not
the
white
out
file
should
be
in
an
order
or
not
like.
This
is.
D
Okay,
fine
we'll
say
it
this
way,
but
if
we
change
it,
it
is
a
breaking
operation.
That's
a
post,
one
dotto
conversation
will
punt
it.
So
they're
very
likely
could
be
Mena
versions
that
just
make
it
eration
Zahn.
This
I
would
not
imagine
nobody
wants
to
complicated
matrices
of
like
partially.
You
know
like
whether
it's
v11
or
v10,
but
likes
already
mentioned
signing,
has
come
up.
Distribution
has
come
up
possible.
Other
ways.
Besides
tartar
archives
at
all
has
come
up
these
kind
of
iterations.
D
D
No
there's
no
imminent
plans
for
a
lot
of
this,
and
some
of
those
like
iterations
on
improving
or
making
other
opportunities
would
largely
come
out
of
what
we
found
as
to
be
best
practice
or
like
we've,
improved
on
and
gotten
rid
of
white
outs
entirely,
and
this
is
a
non
conversation
anymore.
So
I,
don't
I,
don't
see
it
I,
don't
foresee
the
future
being
either
quitting
like
we're
done
and
I
also
don't
see
it
being
like
here's.
This
other
thing
that
we're
gonna
come
out
with
a
2.0
and
just
break
it
no
completely
at
all.
D
D
D
But
the
common
question
is:
what's
the
API
that
I
need
to
push
or
pull
these
these
objects,
because
when
you
go
look
at
particularly
for
like
the
image
spec
largely,
it
is
like
here's
how
you
pack
a
tar
archive
and
here's
the
Jaison
to
describe
it
and
here's
the
Jaison
to
describe
the
check
some
of
those
things.
It
is
wildly
simple
in
certain
ways
and
then
immediate.
The
immediate
intuitive
fault
is
cool.
How
do
I
train
you
know?
How
do
I
send
this?
What
do
I?
What
api
do?
D
I
push
these
objects
to
and
how
do
I
pull
them
back?
You
know
how
do
I
build
anything
higher
and
logically,
it
is
docker
registry
API.
It's
just
one.
One
of
the
things
as
we've
iterated
on
these
particular
mime
types
or
media
types
is
we'll
get
to
that
next
and
and
I
think.
To
some
extent
it's
not
any
concern
that
the
docker
registry
API
is
going
to
change
it's
just
we
want
to.
We
wanted
to
do
things
in
lockstep
fashion
of
like
we
solved
the
media
mime
type
for
a
foreseeable
future.
D
A
E
E
We
wanted
to
make
it
as
easy
for
them
without
much
disruption
to
convert
images
into
OCI,
and
one
of
the
early
compromises
was
ensuring
that
so
there's
two
pieces
of
an
image.
There's
the
metadata
that
describes
the
image
and
then
that
tarball,
that
has
all
the
files
in
it
and
we
didn't
really
want
to
disrupt
the
tarballs
if
we
could
avoid
it,
because
that
means
that
the
bulk
of
the
storage
we
could
avoid
touching.
E
You
know
the
gigabytes
and
gigabytes
of
data,
for
her
probably
have
this
petabytes
of
data
that
are
containing
her
images
in
the
world
today
may
be
really
nice.
If
we
didn't
have
to
touch
those
tar
balls-
and
we
can
just
have
JSON
metadata
outside
of
the
tar
ball
so
that
we
could
reach
reach
down
and
and
have
those
images
be
become.
Oci
images.
A
Question
4
for
Jeff,
since
you've
been
involved
kind
of
in
a
certification
efforts,
so
one
aspect
of
generally
a
standard
is
you
know
once
you
kind
of
build
out
specifications
generally,
there's
some
way
to
you
know
verify
that
implementations
are
compliant
or
conform
into
some
nature.
So,
what's
currently
our
thoughts
on
this
in
OCI
Jeff,
so.
C
There's
been
a
working
group
of
a
number
of
individuals
and
companies
in
the
industry
that
are
looking
at
this
issue
of
certification
and
they've.
Looked
at
different
past
examples
from
different
entities,
other
Foundation
Linux
Foundation
initiatives
around
IOT,
others
around
from
like
the
Eclipse
Foundation
and
ultimately,
what
we're
trying
to
do
is
strike
that
balance
between
you
know.
C
C
But
if
you
think
about
it,
I
think
it's
a
healthy
balance
in
the
ecosystem.
Right
I
think
it's
fortuitous.
It's
kind
of
turned
out
this
way.
I
know
it's
been
confusing
to
people
on
the
outside
or,
don't
you
know,
swim
in
the
fishbowl,
but
I.
Think
of
it
as
like,
the
Asian,
yin
and
yang
symbol
right
where
you've
got
folks
that
have
been
working
on
trying
to
fundamentally
nail
the
basic
building
blocks
and
then
you've
got
this
other
entity.
C
A
H
Think
we
already
had
a
discussion
earlier
on
so
I
wondering
the
cloud
native
computing
world
and
ecosystem.
You
have
chosen
the
OCI
being
the
standardized
level
and
the
standardized
abstraction
you
feel
this
is
the
right
abstraction
or
you
feel
there
is
other
interfaces,
other
things
which
are
more
important
to
standardize
than
the
OCI
part
yeah.
E
E
We
have
like
virtual
machine
stores
on
Amazon
and
virtual
machine
stores
on
all
the
other
cloud
providers
and
through
VMware,
etc,
but
the
missed
opportunity
there
was
workload,
mobility
and
largely
that
is
the
promise
of
cognitive
is
that
through
containers,
you're
able
to
move
workloads
across
different
environments,
different
compute
network
storage,
stacks
and
so
I
do
believe
that
container
images
are
the
abstraction
of
this
entire
movement.
Much
like
virtual
machines,
I've
been
the
abstraction
of
ayahs
for
the
last
ten
years.
C
Those
were
swimlanes
to
a
degree
in
that
it
was
pretty
clear
ten
years
ago
that
well
lightweight
applications.
You
want
you
could
run
over
here.
If
you
wanted
something
that
had
horsepower
in
the
UNIX
class
machines,
you
could
put
it
here
and
then,
if
you
wanted
a
really
trusted
environment,
you
could
put
it
up
on
the
mainframe,
but
over.
You
know
when
I
started
to
look
at
that,
and
you
looked
at
the
value
that
clients
saw
from
running
Linux
across
those
hardware
architectures.
C
My
next
logical
question
was
well:
what's
our
cross-platform
Linux
strategy
for
virtualization
and
we
didn't
have
one
because
IBM
you
know
have
been
doing
virtualization
on
the
mainframe
since
the
late
70s.
They
brought
that
technology
to
power
in
the
you
know,
90s
and
so
iBM
has
been
at
least
personally
from
my
perspective.
It's
something
that
I'm
just
thrilled
to
be
a
part
of,
because
I
was
looking
for
how
this
was
going
to
play
out
in
VMs
and
just
nailed
it
how
this
is
gonna
play
out
in
containers.