►
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).
Container Storage Interface: Present and Future - Jie Yu, Mesosphere, Inc. (Intermediate Skill Level)
The goal of Container Storage Interface (CSI) is to provide a standard API allowing a storage provider to write just one plugin that will work for all major container orchestration systems: Kubernetes, Mesos, Docker and Cloud Foundry. As the original co-author of the spec, Jie will give you an overview about CSI, and talk about many of the design decisions that were made earlier in the process and the rationales behind those design decisions. As an Apache Mesos PMC and committer, Jie will further discuss CSI from a container orchestrator's perspective and talk about why this interface makes the container orchestrator's life much easier. Finally, he will talk about the CSI support recently introduced in Mesos, and show you how seamless the integration is, and how easy it is to deploy a CSI plugin in Mesos.
About Jie
Jie Yu is a Tech Lead at Mesosphere, Inc, focused on containerization, storage and networking. Jie is an Apache Mesos PMC member and committer, and is the co-author and maintainer of the Container Storage Interface (CSI) spec. Before joining Mesosphere, Jie was a software engineer at Twitter. Jie obtained his PhD in Computer Science and Engineering from the University of Michigan. Jie has spoken at various academic and industry conferences like OSS Summit, QCon, MesosCon, OOPSLA, MICRO, etc.
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
Let's
get
started:
I'm
gonna
talk
about
containers,
storage,
interface
today,
present
and
future.
Just
give
you
a
bit
of
intro
about
me,
so
I'm
attack
the
atmosphere
right
now,
the
co-author
of
the
CS
ice
pack
and
I'm
also
the
approaching
mesas
PMC
and
commuter
and
I
received
my
PhD
from
University
of
Michigan
in
us
and
I'm
a
former
Twitter
engineer.
A
So
this
is
kind
of
the
outline
of
the
talk.
I'm
gonna
first
give
you
some
motivation
why
we
wants
to
introduce
CSI
and
what
are
the
goals
that
we
want
to
achieve
and
to
achieve
those
goals,
we
made
a
few
design
choices
early
on
in
the
process
and
I'm
gonna
talk
about
those
design
choices
that
we
made
to
help.
A
You
better
understand
the
spirit
of
the
CSI
spec
spec
and
then
give
you
an
overview
about
on
the
spec
itself
and
talk
about
some
of
the
container
orchestration
system
integrations
that
we
have
so
far
and
then
finally
talk
about
the
future
of
where
the
spec
is
gonna
go.
So
first
question:
is
why
CSI?
So
if
you
look
at
storage
supporting
a
cognitive
environment,
you
have
container
orchestration
system
like
kubernetes,
mazes,
darker,
color
foundry,
and
you
have
vendors
storage,
vendors,
a
bunch
of
storage,
vendors
and
the
typically
still
continuing
orchestration
systems.
A
I'm
gonna
refer
to
on
the
continuous
trader
as
CEO.
So
typically
all
the
CEO
exposed
and
sort
of
pluggable
storage
interface,
allowing
storage
vendors
to
plug
it
into
on
those
systems
and
those
pluggable
storage
interface,
usually
define
those
control
plane
operations.
Allow
kind
of
like
allow
CEO
to
invoke
on
during
the
lifecycle
of
the
volume
things
like,
for
example,
like
crazy
volume,
attach
detach
volume,
mount
and
mount
format,
Chris
snapshot
cetera
alright.
A
So
if
you
look
at
those
storage
interfaces,
so
far
at
the
time
and
like
they're,
like
popular
container
orchestration
systems
or
middleware,
have
independently
evolved.
So
many
storage
interfaces,
for
example,
docker
has
this
darker
volume,
plugging
and
criminalise?
Has
both
in
free
volume,
plugins
and
flex
volume,
and
some
middleware,
like
lift
storage
or
open
SDS,
has
their
own
definition
of
volume
drivers
from
the
perspective
of
a
storage
provider.
This
is
a.
A
This
is
a
disaster
situation,
because
a
good
analogy
of
this
problem
is
you:
have
you
try
to
build
yours
like
electrical
appliance
and
you
have
to
build
those
on
different
type
of
electrical
electrical
plug
and
to
adapt
to
those
outlets?
And,
for
example,
like
I
came
from
us
and
I
bring
my
Apple
chargers.
It
doesn't
work
here
because
the
standard
is
different.
It
just
cost
paying
for
our
storage
providers
because
they
have
to
build
those
different
type
of
interface,
for
different
CEOs
and
and
also
it's
it's
bad
for
cluster
operators.
A
Then
the
question
is:
why
not
just
pick
one
and
make
that
the
standard,
but
we
kind
of
look
into
different
interfaces
and
they
have
all
have
their
issues.
For
example,
some
interfaces
CLI
based
and
I'm
gonna
talk
about
that
later.
Yc.
Our
base
interface
is
not
ideal
for
storage
interface
and
and
some
of
the
interface
that
we
saw
lack
of
idempotency
on
their
API
is,
for
example,
the
darker
volume
driver
interface
and
some
of
the
interface
is
kind
of
entry
and
I'm.
A
Gonna
talk
about
that
later,
why
entry
is
not
ideal
and
most
simple,
and
also
we
look
at
some
in
the
middle
wares
and
kind
of,
and
we
find
out
that
many
of
the
implementing
of
those
middle
words
or
like
those
kind
of
specification
kind
of
tightly
coupled
in
the
implementation-
and
it's
too
heavy
way-
it's
not
just
a
specification.
It's
a
specification,
plus
implementation
plus
a
bunch
of
unnecessary
pieces.
That's
not
relevant
to
this
problem,
so
so
that's
the
reason
we
kind
of
trying
to
introduce
container
storage
interface
and
we
have
a
bunch
of
goals.
A
These
are
like
that.
The
the
kind
of
defi
high
level
goals
that
we
want
to
achieve
at
the
very
least
it
has
to
be
interoperable.
What
that
means
is
the
storage
vendor
can
just
build
one
single
plugging
and
that
plug-in
can
be
used
by
all
the
container
orchestration
systems
that
support
si
si
and
it
has
to
be
vendor
neutral
what
that
means.
It
should
not
be
dominated
by
any
of
the
seal
or
provider,
and
we
want
to
focus
on
just
specification.
We
don't
want
to
do
any
of
the
implementation
of
the
specification.
A
A
A
We
discussed
the
first
iteration
on
the
drafts
back
and
actually
we
shared
that
in
a
Google
Doc
on
to
the
community
and
then
on
in
May
we
kind
of
poured
the
the
Google
version
of
the
spec
to
get
help
repo
and
and
all
the
discussion
are
moved
to
Tokyo
hub
repo
in
May
and
then
on
in
December.
After
a
lot
of
discussions,
CSI
3.1
it's
being
released
and
like
earlier
this
year,
we
have
different
CEO
support
CSI,
for
example,
come
and
support
CSI
from
1.9
and
May,
so
support
CSI
from
1.5
and
March.
A
We
have
sir
CSI
0.2
release
and
CEO
is
trying
to
adopt
in
the
new
version
and
now
I'm
going
to
talk
about
some
of
the
design
choices
that
are
we
made
during
the
process
of
designing
the
spec.
So
the
first
decision
we
trying
to
make
is
whether
this
plug-in
model
should
be
in
three
versus
out
of
three.
So
what
entry
means
is?
Essentially,
you
have
a
single
repository
contain
the
code
of
different
drivers
and
different
drivers
from
different
vendors.
A
A
typical
example,
for
that
is
the
Korean
entry
volume
flowing
model
right
now
and
usually,
like
entry
implied
that
the
volume
code
itself
will
be
running
in
the
same
OS
process
as
the
container
orchestration
system.
It's
possible
that
I
have
entry
but
other
process
solution,
but
that's
just
complicated
because
then
you
have
to
define
both
northbound
API
and
the
southbound
API
northbound.
You
talk
to
CEO
and
southbound
talk
to
drivers
so
complicated.
A
So
when
we
say
entry
here
is
actually
intriguing
process,
so
so
that's
one
option:
we
can
go
with
that
option
and,
and
the
other
option
is
out
of
tree
what
that
means
is
there's
no
single
repository
contained
the
code
for
all
the
drivers
and
driver,
so
storage
vendor
maintained
your
own
repository
for
their
plugins
and
they
have
their
own
release
cycles
and,
and
the
current
CEO
will
talk
to
those
storage
plugging
through
either
a
CR
interface
or
service
interface.
A
typical
example
of
this
model
is
flex
volume.
A
So
usually,
when
you
mentioned
out
of
tree,
it
means
out
of
process.
So
out
of
tree
in
process
is
kind
of
it's
possible
like
through
dynamic
library,
loading,
but
it's
complicated
and
it's
not
gonna
be
working.
If
you
have
different
cou
written
in
different
languages
and
we
do
have
Co
between
different
languages,
so
so
so
so
the
decision
for
that
is
pretty
straightforward,
I,
don't
think
we
have
too
many
discussion
on
that
and
just
say
we
wouldn't
go
with
out
of
tree.
The
drawback
of
entry,
plug-in
model
is
pretty
obvious.
A
It
has
a
cup
holder
release
cycle.
So
imagine
that
you
have
a
single
repository
for
all
the
plugins.
Every
plugin
has
their
own
release
process,
and
then
you
want
to
coordinate
all
these
release
into
one
single
release
cycle.
It
just
make
it
so
hard
and
also
put
a
burden
of
the
testing
to
the
the
maintainer
of
the
repo.
A
We
yeah.
We
go
through
some
debate
on
this
I
said,
especially
because
that,
on
the
other
interface
for
networking
cause,
CNI
is
a
CLI
based
interface
and
initially
we
thought
that
maybe
we
should
go
with
the
same
model
and
also
flexlearning
your
CLI
based
interface.
So
what
does
that
mean
for
CRI
base
interface,
so
basically
Vanderwall?
Some
binary
on
the
hosts
and
seal
will
invoke
binary
during
the
lifecycle
of
the
the
volume
and
with
some
arguments
to
to
undo
like
create
volume.
Volume
attach
bowing
things
like
this.
A
So
what
we
end
up
deciding
is
which
would
go
with
service
instead
of
CI,
on
that.
The
reasoning
for
that
is,
services
are
actually
much
easier
to
deploy.
Think
about
I
mean
you're,
running
accounting,
your
environment,
you
have
kubernetes
or
mesas
doing
scheduling
for
you
running
a
container
ism
and
Iranian
container
is
much
easier
than
on.
The
point
see
are
binaries
because
the
Paseo
binary
means
you
have
to
use
some
other
tooling,
like
puppet
chef
or
ansible
to
to
to
make
sure
the
binary
shows
up
on
the
hosts.
A
I'm,
not
sure
how
many
of
you
are
using
puppet
or
instable
before,
but
it's
a
painful
and
and
deploy
see
our
binary
dependency
is
not
easy
as
well,
because
dependency
changes
all
the
time
with
the
library
the
CI
depends
on
is
comforting
with
some
other
library
diets
used
by
some
host
services.
The
finally
I
think
the
one.
The
other
reason
that
we
go
with
services
like
fulfils
back
for
some
of
the
few
space
backend
I,
require
a
long-running
service
anyway,
so
and
make
a
service
to
make
it
easy
to
on
to
to
unify
them.
A
So
yeah,
the
decision
is
just
go
away:
service
define
a
service
API,
and
the
next
decision
is
kind
of
related
to
like
controller
and
no
service.
You
might
see
this
if
you
read
the
spec,
so
we
identified
two
set
of
operations
on
controlling
operations
that
have
different
characteristics,
so
some
operations
has
has
to
be
executed
on
the
node
things
like
OS
mount
and
mount
or
some
of
the
ice
cuts.
A
The
initiator
thing
that
has
to
be
run
on
the
know
that
the
volume
will
be
used
and
some
operation
things
like
volume
attached,
detached
or
a
deletion
in
the
cloud
environment.
You
don't
have
to
run
that
on
that
that
the
operation
on
the
note
that
you
want
to
use
the
volume
you
can
run
that
anywhere
as
long
as
you
know,
the
no
ID
and
just
cut
an
API
provided
by
the
cloud
provider.
A
So
you
have
these
two
type
of
operations
and
they
require
different
things
like
things
like
OS
privileges,
for
example,
for
our
OS
mount
and
mount.
You
need
some
certain
privilege
to
do
that
and
for
attach
and
detach
for
I
need
some
special
credential
to
be
able
to
do
those
operations.
So
the
decision
for
that
is
actually
we
introduced.
Two
sets
of
ap
is
called
controller
service
and
no
service,
and
and
the
only
requirement
for
that
is
no
service
has
to
be
run.
A
I,
don't
know
where
the
volume
will
be
used
and
the
controller
service
can
be
running
anywhere
in
the
cluster,
so
you
have
different
way
of
deployed
controlling
those
services.
So
that's
option
number
one
for
some
CEO
that
has
this
matter
agent
notion
that
you
can
deploy
a
controller
service
anywhere
in
the
cluster
in
the
CIO's
master
will
talk
to
controller
service,
and
then
you
deploy
the
no
service
on
every
single
agent
and
the
CIO's
agent
will
talk
to
the
no
service.
So
that's
option
number
one:
that's
not
the
only
option.
A
The
other
option
is,
you
have
had
less
deployments,
so
some
of
the
CEO
actually
don't
have
this
master
agent
notion
and
everything
is
just
node
and
you
can
actually
deploy
both
the
controller
service
and
no
service
in
a
single
container
and
the
CEO
will
just
talk
to
that,
for
both
control
serves
and
no
services.
So
that's
also
possible
and
it's
a
lot
by
the
spec.
A
A
If
the
API
is
not
idempotent
and
the
CEO
will
actually
freeze
AMPA
like
one
on
the
creative
onion
I
issued
a
career,
volunteer,
storage,
plugging
and
and
the
storge
plugin
create
a
volume
in
the
backend
and
then
try
to
return
a
response
contain
the
ID
of
the
volume
to
the
CEO
and
imagine
that
this
response
never
reached
the
CEO.
What
that
means
is
CEO
has
no
way
to
know
on
the
idea
of
that
volume
and
have
no
handle
on
that.
A
What
that
means
is
see
almost
like,
we
will
retry
and
the
retrial
will
create
a
new
volume
because
Co
don't
know
about
the
previous
idea
of
the
volume
and
the
previous
volume,
the
idea
of
the
previous
volume.
So
it
will
create
a
new
volume,
be
here
and
the
volume
V
will
be
returned
to
Co.
But
the
problem
is
volume,
a
will
be
leaked
and
no
one
will
be
the
co
won't
see
you
don't
have
a
handle
on
the
volume
any.
So
it
won't
try
to
delete
on
you.
A
So
that's
problematic,
so
so
a
better
way
to
solve
that
issue
for
failure.
Recovery
is
make
the
call
idempotent.
So
when
you
create
volume,
you
also
specify
some
identifier
like
a
say:
hey
I
want
to
create
a
volume,
I
want
to
call
it
a
and
the
storage
plugin
will
just
crave
on
your
a
and
the
volley.
If
the
volume
a
already
exists,
the
storage
plug-in
will
just
even
basically
return.
Okay,
say
hellevang.
Is
there
I'm
gonna
return
that
to
you
so
imagine
the
same
scenario
on
the
response:
gag
dropped
and
seal.
A
A
So
now
next,
we
need
to
decide
what's
the
wild
protocol
for
that
and
we
decided
to
go
with
G,
RPC
I
think
that's
a
pretty
natural
decision
and
we
don't
go
through
any
debate
on
this
because
I
don't
really
see
in
a
better
alternative
to
that
and
JRPG
provides
a
nice.
Probably
like
it's
language,
agnostic.
You
can
write
in
using
any
language
and
it's
really
to
write
specification.
You
just
need
to
write
your
portable
file
and
define
all
these
fields
and
that'll.
A
Be
it
it's
very
easy
to
communicate
the
specification
and
there's
a
lot
of
community
there's
a
lot
of
tooling
behind
G
RPC
and
a
big
community,
and
it's
also
part
of
the
CCF
and
has
real
production
users.
Ok,
so
another
thing
we
we
kind
of
have
we
gone
through.
A
bunch
of
debate
is
whether
the
API
should
be
async
versus
sync
by
async.
What
I
mean
is
when
the
CEO
is
your
request
to
the
the
plug-in.
A
The
plug-in
won't
return
immediately,
maybe
like
return
202
accepted
or
something
like
this
and
and
the
volume
will
be
happening
asynchronously
in
the
in
the
background
and
when
the
volume
operation
finishes
on
the
the
plugin
will
send
a
message
back
to
the
co
indicating
that
the
operation
has
been
finished.
The
motivation
for
that
is
some.
A
If
you
have
a
super
long
running
operation,
the
CEO
has
to
do
has
to
be
defensive
and
timeout
anyway.
So
in
the
key
of
that
to
address
that
thing
is
trying
to
make
the
call
item
potent
for
battle
failure
recovery,
so
we
decide
to
go
with
synchronous
and
because
it's
simple
and
and
we
still
have
the
same
problem
for
long
running
operations,
no
matter
which
async
or
simple
you
choose
and
also
our
more
importantly,
the
plugin
implementation
itself
can
be
acing.
It
does
not
have
to
be
synchronous.
A
A
The
only
requirement
is
the
plug-in
has
to
provide
a
gr
PCM
end
point
through
domain
socket
and
the
reason
we
want
to
go
with
domain
lock
is
for
security
reasons,
because
if
you
go
with
arbitrary
socket,
then
you
have
to
define
like
whether
it
has
to
be
secure.
Do
you
use
TLS
or
something
else?
We
don't
go
through
those
who
just
say:
hey
everything.
A
Just
the
plugin
needs
to
have
closed
that
domain
socket
and
then
you
can
put
a
proxy
in
front
of
that
and
do
all
these
authentication
authorization
stuff
in
a
possible
way
of
deploying
plugging,
for
example,
on
a
plugin
can
be
deployed
by
co.
Using
daemon
sets
great
and
some
other
CEO
might
decide
say
hey
on.
You
have
some
running
system
these
services
already
using
popular
ansible
and
I'll
just
connect
to
that.
That's
also
possible.
It's
not
disallowed
by
the
on
the
spec
right.
So
I'll
give
you
some
overview
now.
A
I'm
gonna
give
you
some
overview
about
the
API
itself.
The
spec
itself
on
there
are
three
G
RPC
services
that
the
plug-in
is
to
implement
the
identity
controller
in
the
node,
so
the
identity
service
basically
give
you
some
basic
information
about
the
plugin
like.
What's
your
name
and
what
are
your
capabilities
and
we're
gonna
probe
you
and
to
see
if
you
are
healthy
or
not,
and
and
if
every
single
plug-in
needs
to
implement
these
three
costs?
It's
very
basic
cost
and
the
second
service
is
called
controller
service.
A
As
I
mentioned,
it
can
be
run
on
any
node
in
the
cluster
and
create
volumes
in
the
livonian
as
a
stand
by
its
name.
Just
like
provisioning
and
de-provisioning,
a
volume
controller
published
volume,
control,
unpublished,
warning
is
used
to
make
volume
available
on
a
given
node
it's
like
attached,
but
we
don't
call
it
attached
because
there
might
be
something
else
more
than
just
attached,
so
we
call
it
publish
trying
to
use
a
different
work.
A
A
Actually
many
of
those
calls
are
optional,
so
van
vendor
don't
have
to
implement
those
calls
if
it's
not
all
needed,
for
example,
for
some
certain
plugins
there's
no
dynamic
provisioning
support,
so
you
don't
have
to
implement
crave
or
delete
volume
for
some
plugins
does
not
require
on,
like
a
controller
publish
what
that
means.
Is
there's
no
remote
attached,
for
example,
so
you
just
leave
that
call
empty
or
just
don't
implement
that
call
and
get
capacity
and
listening
are
optional
to
you.
The
rest
are
mandatory.
A
Okay,
now
on
the
search
service
is
called
no
service.
No
service
has
to
be
running
on
the
note.
Ceo
has
to
guarantee
that
the
no
service
is
deployed
on
a
note
that
ammonia
will
be
used
and
on
their
life,
or
course
for
calls
related
to
I,
published
a
volume
on
a
note
stage
and
stage
and
stage,
publish
and
publish
the
difference
between
stage
and
publish
is
so
both
of
them
trying
to
make
the
volume
ready
to
be
consumed
by
the
container.
But
the
difference
is
stage.
A
Volume
should
be
called
only
once
for
a
volume
on
a
given
note
and
publish
may
be
called
multiple
times,
one
for
each
workload,
for
example,
and
with
different
credentials.
So
if
you
have
some
operation
in
your
plugin
that
you
want
to
perform
once
for
every
volume,
on
a
note,
you
should
increment
the
stuff
inside
stage
volume.
Otherwise
you
put
your
logic
in
to
publish
warning
and
actually
stage
volume
is
optional.
So
you
don't
have
to
implement
that.
A
If
you
don't
have
certain
operation
that
you
need
to
perform
once
per
volume
note
and
also
understand,
the
code
called
get
no
ID.
The
reason
we
need
that
is
because
different
storage
vendor
have
different
way
to
represent
on
the
notion
of
note.
For
example,
some
storage
vendor
will
use
the
host
names
and
we'll
use
IPS
and
will
use
some
special
label
whatever,
and
we
don't
want
to
dictate
how
people
are
how
vendors
will
expose
those,
no
information.
So
basically
we
ask
the
vendors
they
hate
you
increment.
A
This
call
tell
me
what
no
ID
is
and
then,
when
the
co
does
controller
publish,
it
will
pass
the
same
ID
that
you
returned
to
that's
returned
by
the
storage
provider.
So
so
we
bypass
this
issue
by
introduces
get
new
ID
call
alright.
So
this
is
kind
of
the
life
cycle
kind
of
a
very
simple
life
cycle
for
for
a
volume.
So
initially
volume
is
not
created.
A
Co
will
dynamically
provision
the
volume
by
using
crave
volume
and
the
volume
is
in
created
estate
and
then
before
the
the
volume
can
be
used
by
a
container
on
a
node.
It's
the
CEO
will
call
controller
published
first
trying
to
make
the
ready
on
a
node
from
the
controller
service
on
things
like
attach
will
be
part
of
that,
and
then,
once
the
controller
publish
is
successful,
the
CEO,
the
agent
or
cubelet
on
the
net
will
actually
call
no
stage
volume
on
to
which
is
the
operation.
A
That's
one
time
for
each
volume
on
a
note
and
then
count
no
published
volume
for
each
part,
and
the
reverse
is
the
the
the
unpublish
and
delete
or
fill.
So
it's
pretty
straightforward.
So
give
you
some
example
how
plugin
should
be
implemented.
For
example,
if
you
want
to
implement
an
NFS
plugging,
you
don't
have
to
implement
controller
service.
A
Similarly,
that
the
reason
you
need
instance
get
is
because
you
want
the
publish
wanting
to
be
idempotent,
and
then
you
can
perform
the
on
the
formatting
and
the
mountain
warning
in
the
no
stage
volume
and
perform
a
by
now
in
the
no
published
volume
and
there's
a
reference
implementation
for
that
in
Google
cloud
platform.
Github
repo
one
thing
to
mention
here
is
the
CSR
plug-in
itself
can't
not
just
for
our
external
volume
like
cloud
native
storage
providers
is
also
for
local
volumes.
A
Things
like
LVM,
you
can
be
in
a
VM
CSI
plug
into
what
that
means.
You
need
to
deploy
a
controller
and
no
service
on
the
same
note
and-
and
you
can
create
your
logical
volume
using
LV-
create
in
crave
on
you
and
there's
no
need
to
do
on
controller
published
volume,
because
no
plugging
and
controller
plugging
are
on
the
same
node
and
since
because
it's
local
and
you
can
formatting
an
amount
of
all,
you
know
published
phone.
Actually,
there
is
a
one
reference
implementation,
mrs.
A
A
So
basically,
you
have
two
parts,
two
type
of
parts:
one
is
what
I
call
a
controller
part
basically
are
running
the
the
controller
service
of
the
plugin
and
there's
some
sidecar
provided
by
kubernetes,
trying
to
talk
to
the
API
server
to
do
things
like
dynamic
provisioning
and
attach
and
detach,
and
also
talking
to
the
controller
service.
Stop
plugging
and
there's.
A
Also,
a
note
pot
basically
deployed
as
a
daemon
set
on
every
single
note
and
and
running
no
services
of
the
plug-in
and
there's
a
sidecar
for
that
on
trying
to
trying
to
inform
on
the
new
ID,
for
example,
on
to
the
kubernetes
system.
That's
how
kubernetes
integrate
CSI
and
invasives
kind
of
similar.
That
missus
has
this
notion
called
resource
provider,
which
is
essentially
a
way
to
customize
the
resource.
Providing
part
of
mesos
stack
that
you
can
customize
the
resource.
Providing
I
mean
it's
not
real.
A
Missus
agent
will
actually
talk
to
those
CSI
plug-in
to
may
actually
made
the
Vong
available
to
the
container
so
very
similar
architecture
and-
and
this
u.s.
actually
is
our
product
where
we
build
some
Astra
like
additional
abstraction
on
top
of
mesos,
and
we
call
this
TCO
storage
servers
to
provide
additional
abstraction.
So
we
call
plug-in
provider
and
profiles.
So
plugging
is
basic.
Si
si
plugins.
You
can
register
with
the
co
storage
service
about
any
CSI
plugins
and
then
provided
just
an
instance
of
a
plugin.
A
Basically,
for
example,
you
have
EBS
plug-in,
but
you
have
multiple
providers
that
use
the
EBS
plug-in
will
manage
each
zone.
For
example,
that's
one
way,
and
so
provider
is
just
instance
about
plugging
and
then
profile
is
similar
to
storage
classes,
trying
to
provide
an
interaction
from
the
the
name.
The
kind
of
the
class
of
the
storage
versus
the
detailed
parameter
of
those
storage
depends
on
the
vendor,
and
then
we
can
run
a
bunch
of
application
on
top
of
the
entire
platform.
Some
of
them
are
warning.
A
Consumers
like
Cassandra
Kafka,
using
local
disk
marathon,
might
be
using
external
disk,
and
some
of
them
are
actually
volume
providers,
I
mean
they're,
both
provider
and
consumer,
for
example,
like
take
SEF
as
an
example
that
you
can
run
SEF
staff,
you
will
use
local
disk,
so
you
will
try
to
consume
local,
just
provided
by
l
vm,
for
example,
or
provide
by
red
block
devices,
and
then
it
provide
external
storage
to
other
framework
that
once
you
consume
those
volumes,
so
it's
both
consumer
and
the
resource
provider
all
right.
So
that's
the
co
integration.
A
If
you
have
more,
questions
feel
free
to
ask-
and
we
can
talk
about
that
later
and
the
government's
model
of
this
back,
we
have
some
girls
trying
to
achieve.
Of
course
we
want
to
be
inclusive
and
open,
and-
and
more
importantly,
we
want
to.
We
want
that
to
be
independent
of
any
CEO
or
storage
provider.
We
want
to
try
to
avoid
a
storage
vendor
war
on
this
spec.
So
so
that's
the
reason
we
want
to
keep
it
simple
start
from
the
lowest
common
denominator
first
and
then
gradually
adding
those
new
features.
A
That's
not
very
Universal
to
every
single
vendors
and
and
given
that
giving
those
go
in
mind,
we
have
this
government's
model
where
it's
similar
to
kubernetes
governance
model.
We
have
member
reviewer
approver
janitor
on
the
only
difference
is
the
approver
has
to
be
a
core
group
of
CEO
representative.
So
we
want
to.
We
want
to
use
this
mikedolan
to
try
to
avoid
a
storage
vendor
war.
A
Alright,
so
there's
some
future
work
CSI.
What
I'm
doing
is
topology
aware,
and
that
has
to
be
part
of
the
spec.
The
reason
for
that
is,
the
co
scheduling
needs
to
know
about
the
topology
information
to
decide
whether
a
volume
can
be
used
in
a
given
zone
or
not
a
given
topology
or
not.
So
there
has
to
be
part
of
spec
and
has
to
be
first
class
because
Co
needs
to
know
about
that
information.
It's
not
opaque
to
Co
snapshot,
support,
bonding
resizing
and
plugging
registration.
A
The
reason
I
mentioned
plugging
registration
is
because
there's
some
other
spec
like
ink
ribbon
is
called
device,
plugging
which
use
this
plugin
registration,
also
docker
a
new
plugin
model
using
this
registration
flow,
which
I
really
like
and
I,
think
we
should
purchase,
unify
them
into
a
single
way
of
registration
so
that
Co
don't
have
to
use
conventions.
You
find
out
where
the
socket
is
domains.
Okay
is,
and
also
we
want
to
add
this
small
test
suite
so
that
vendors
can
easily
use
that
to
kind
of
at
least
provide
some
minimal
validation
of
their
plugins.
A
A
B
I
have
a
couple
questions.
First
of
all,
when
container
runtime
interface
was
added
to
queue.
Burnet
is
the
entry
container
runtime
implementations,
for
example,
for
docker
and
for
rocket
got
replaced
by
the
G
RPC
interface
based,
so
is
there
any
plan
to
replace
some
of
all
entry
storage
volume
drivers
with
out
of
three
CSI
based
ones,
yeah.
A
C
Yeah
there
is
a
plan
to
move
the
entry
volume
plugins
out
of
tree,
so
we're
working
on
that
design.
This
quarter.
The
idea
is
going
to
be
to
maintain
the
existing
interface
for
the
entry
volume
plugins,
because
the
deprecation
policy
for
the
kubernetes
api
is
very
strong
and
we
can't
just
rip
those
out.
So
what
we
plan
to
do
is
modify
the
internal
logic
of
the
kubernetes
entry
binaries
to
proxy
out
to
the
CSI
volume
plugins
and
keep
an
eye
out
for
that
design
and.
B
Kill
so
another
question:
is
you
know
this?
Some
CRI
implementations
in
kubernetes
that
make
use
of
virtualization,
for
example,
cutter
containers
and
there's
also
vert
lit
that
I'm
working
on
and
what's
important
for
them
is
to
be
able
to
access
block
volumes
as
block
devices
and
not
have
them
mounted,
because
we
need
to
accept
them
from
inside
the
VM.
Are
there
any
possibilities
for
this
with
new
CSI
yeah.
A
Yeah
so
great
questions
on
so
yeah
I
mean,
as
a
start,
I
mean
when
we
initially
start
si
si
I
didn't
mention
here,
but
one
of
the
goal
is
trying
to
support
block
device
as
well
so
and
depends
on
the
block
device,
the
blood
devices
for
volume.
It's
part
of
the
CSI
scope,
the
block,
if
the
device
we
are
talking
about
is
not
actually
a
kind
of
volume
like
block
device
for
other
devices.
D
A
C
So
a
question
is:
what
is
the
future
of
flex
in
kubernetes,
so
flex
already
has
some
production
drivers
out
there
and
we
don't
want
to
break
support
so
we're
going
to
keep
it
in
maintenance
mode.
What
that
means
is
that
will
continue
to
support
it,
but
we're
not
going
to
expand
that
API
and
you
further
and
with
CSI.
That's
what
we
consider
the
future
we're
going
to
continue
to
invest
and
expand
the
API
there.
E
Am
so
I
wanted
to
voice
a
question
that
I
also
asked
earliness
yes
I
process
and
also
Western
in
in
the
communities
context,
which
is
the
topic
of
file
system
users,
so
we
use
POSIX
file
systems
that
we
map
into
the
containers
in
order
to
add
to
access
control,
we
need
a
POSIX
user,
probably
POSIX
group
on
Windows
as
ID
or
username,
and
currently
there's
no
story
for
that.
I
understand
that
the
container
systems
don't
have
a
straight
abstraction,
available,
I
think
in
the
kubernetes
context,
we
ruled
out
somehow
the
service
account
to
be
used.
E
A
I
think
yeah
I
think
I
saw
that
you
have
issues
a
long
time
ago.
Yeah
I
think
the
reason
we
delay.
That
is
because
we
want
to
start
from
the
simple
things:
first
start
from
the
lowest
common
denominator:
first,
trying
to
finish
those
and
make
it
rocky
solid
and
then
go
beyond
those
things
on
to
add
things
like
file
system
users
on
and
which
is
kind
of
important
for
some,
the
production,
workload
and
yeah.
We
do.
A
We
do
have
plan
to
address
that
I
think
the
difficulty
is,
we
don't
have
a
standard
way
to
represent
what
user
means
in
the
Inc
account
have
CSI
I
mean
sometimes
like
me,
people
mention
user,
it's
file,
assistant,
user
or
different
kind
of
a
user,
and
they
have
different
identity
systems
in
their
environment.
So
it's
hard
to
standardize
on
that.
That's
the
reason
we
can't
delay
that
decision.
After
all,
these
lowest
common
denominator
has
been
addressed,
but
yeah.
It's
part
of
the
thing
that
we
want
to
address
in
the
future.
E
There
some
conversation
going
on,
but
the
let's,
let's
say
more,
like
security
access,
control,
kind
of
guys
and
interest
action,
because
that's
something
that
you
that
will
just
get
handed
down.
I
guess
why
an
LDAP,
wires
and
kubernetes
mechanism
down
to
the
couplet
and
then
in
the
end
and
in
the
most
common
case
for
a
Linux
processes.
It
will
be
just
a
string
right.
It's
a
really
a
trivial
piece
of
information
that
we
need
to
get
through,
and
this
will
enable
so
many
use
cases
but
yeah
yeah.
A
I
believe
it's
an
important
problem
and
just
the
reason
we
don't
look
into
that
is
that
the
seal,
don't
have
immediate
plan
to
address
that,
and
we
don't
have
a
clear
room.
I
mean
clear
view
of
the
what
the
problem
is.
I
wish
like.
We
have
a
clear
definition
what
the
problem
is
and
then
we
start
to
attack
all
those
issues
and
also
we
it's
kind
of
early
to
other
security
related
issues
on
that
that
people
wants
to
do
for
identity
management
and
security.