►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: CNCF Storage WG - Alex Chircop, StorageOS & Quinton Hoole, Huawei
The CNCF Storage Working Group has been exploring how different storage technologies are used in cloud-native environments, and has published a draft white paper on our findings. In this deep dive session we'll present our work thus far, and host detailed discussions and feedback covering topics including block stores, file systems, object stores, key-value stores and databases, amongst others. Common understandings of terminology, classifications and use cases will be discussed. Different architectural approaches and designs will be brainstormed and compared in terms of key attributes like availability, scalability, performance, data consistency, durability, fault tolerance, ease of development and operational complexity. We seek to align the community on common understanding, terminology, classifications and use cases.
To learn more: https://sched.co/GreV
A
Thanks
for
sticking
around
this
long
and
I'm
acutely
aware
of
the
fact
that
I'm,
probably
the
last
thing
between
you
and
a
beer
and
I,
take
this
responsibility
very
seriously.
So
with
no
further
ado,
let's
get
going
we're
going
to
be
taking
on
a
little
bit
of
a
deeper
dive
into
the
storage
working
group
in
the
CNC
F.
Today,
give
you
an
idea
of
particularly
a
white
paper
that
we've
been
writing.
A
Aleks
myself
and
several
others,
some
of
whom
were
in
the
room,
have
tried
to
put
together
some
information
that
we
hope
will
be
useful
to
consumers
of
cloud
native
storage
to
kind
of
standardize
and
help
everyone
use
the
same
language
when
discussing
this
stuff
and
get
a
sort
of
a
higher
level
overview
which
will
hopefully
help
you
categorize
the
different.
The
myriad
of
different
storage
options
that
seem
to
be
available
today,
we'll
have
a
Q&A
session
at
the
end
and
between
Alex
and
I.
A
A
So
what
we
try
to
do
is
a
combination
of
things,
as
I
said
that
the
overall
aim
was
to
educate
people
and
provide
a
common
platform
of
language
for
people
to
have
conversations
about
what
the
most
appropriate
forms
of
storage
are
for
various
different
use
cases
in
the
cloud
native
environment.
We
try
to
define
the
attributes
of
storage
systems
and,
particularly
as
they
pertain
to
cloud
native
storage,
which
in
many
cases
is
distributed,
and
that
adds
various
interesting
properties
and
attributes.
A
We
also
try
to
give
you
know
clearer
definitions
of
the
different
layers
that
constitute
storage
systems.
So
many
of
you
might
be
familiar
with
the
fact
that
you
obviously
have
a
data
access
interface,
you,
you
know
you
need
to
be
able
to
read
and
write
the
data,
but
you
typically
also
need
to
be
able
to
provision
volumes
back
them
up
and
then
in
many
cases
you
also
need
other
forms
of
of
api's,
which
are
things
for
like
managing
distributed
storage
systems.
A
In
many
cases,
the
actual
operations
of
of
some
of
these
big
distributed
storage
systems
are
big
enough.
That
you
need
a
whole
nother
system
to
manage
them
for
you,
so
just
understanding
where
the
interfaces
between
those
pieces
are
and
and
what
the
vocabulary
around
them
is.
We
decided
was
a
useful
thing
to
agree
upon.
A
Then
again,
you
know
within
any
one
of
those
sets
of
interfaces.
You
have
a
variety
of
different
options
available.
So
volumes
are
one
example,
but
there
are
many
other
ways
that
you
can
access,
storage
and
we'll
have
a
look
at
those
and
and
the
various
different
interfaces
for
managing
things.
These
are
the
people
who
were
the
primary
authors
of
the
document.
You
might
recognize
some
of
the
names
there
in
fact
we're
fairly
proud
of
the
fact
that
we
got
some
pretty
serious
experts
involved
here.
A
A
You
know
pretty
knowledgeable
people
to
distill
the
vast
amount
of
information-
that's
out
there
into
into
something
so
hopefully
useful,
so
as
I
mentioned,
they're
they're,
very
different,
many
different
layers
interfaces
etc
in
in
a
complete
storage
system,
rather
than
you
know,
focus
too
much
on
the
the
architecture
initially
I
think
what's.
What's
perhaps
a
better
starting
point
is
to
understand
what
the
attributes
of
a
storage
system
are
and
in
particular
those
are
the
things
that
you
usually
need
to
match
to
your
application.
A
So
if
your
application
needs,
you
know
strong
consistency,
then
you
need
to
go
and
look
for
strongly
consistent
systems
and
then
the
rest
of
the
solution,
kind
of
falls
out
of
that,
rather
than
the
other
way
around,
rather
than
say,
I
want
to
use.
You
know
system
XYZ,
because
everybody
says
it's
cool
and
then
try
and
force
my
application
to
use
that
thing,
which
may
not
actually
be
the
right
match,
or
vice
versa.
So
we
identified
what
we
thought
were
a
very
useful
set
of
attributes.
A
There
are
more
than
this,
but
but
we
focused
on
what
we
thought
were
the
most
important
ones:
availability,
scalability
performance,
consistency
and
durability.
Now
these
are
all
you
know,
fairly
short
words,
I
think
most
people
think
they
understand
what
all
of
the
mean
turns
out.
Some
of
them
are
more
complex
than
one
might
otherwise
believe
and
I
won't
reuse,
I'm
sure
some
of
you
have
were
in
the
intro
section
this
morning
and
perhaps
in
the
storage
day
on
Monday,
so
I
went
the
labor.
A
My
consistency
example,
but
I
think
it's
fairly
commonly
understood
that
the
C-
and
you
know,
cap
and
the
C
and
acid
are
not
actually
the
same
kind
of
consistency.
There
are
different
kinds
of
consistency
and
the
same
goes
for
durability
and
performance.
There
are
various
different
flavors
of
performance
and
scalability,
so
we
dived
into
that
in
quite
a
bit
of
detail
in
the
white
paper.
Just
to
you
know,
try
and
tear
these
these
terms
apart
and
make
sure
that
we're
all
talking
about
the
same
thing
when
we
use
these
words.
A
There
are
actually
a
few
other
attributes
that
are
pretty
important
as
well.
In
the
real
world,
perhaps
less
technical,
the
one
is
is
the
operational
complexity
of
whatever
the
solution
is
that
you
choose
in
some
cases,
this
can
be
as
simple
as
a
as
a
managed
service
that
you
subscribe
to
in
a
public
cloud
provider,
in
which
case
you,
for
the
most
part,
have
nothing
to
do
and
on
the
other
extreme
that
there
could
be.
A
You
know,
open
source
software,
that
you
need
to
download
install
figure
out
all
the
bugs
in
deploy
on
your
production
environment
and
then,
in
many
cases,
write
additional
software
to
actually
make
that
stuff
work
properly
and
there's
a
whole
spectrum
of
difficulty.
In
that,
depending
on
which
options
you
you
decide
to
take
the
other
obvious
one,
which
is
perhaps
one
of
the
things
that
that
sort
of
triggered
cloud
native
in
the
first
place
is
cost.
A
A
There
are
many
other
factors
that
came
into
it:
convenience,
etc,
etc,
but
at
the
end
of
the
day,
if
you,
if
you
have
to,
if
you
can
just
get
as
much
compute
and
storage
capacity
as
you
want
immediately,
and
for
only
during
the
minutes
that
you
need
it,
everybody
ten
turns
out
to
be
much
happier
than
if
you
have
to
spend
months.
You
know
pre-ordering,
stuff
and
planning
and
I'm
sure
you
all
intimately
familiar
with
the
arguments
behind
why
cloud
computing
has
been
successful,
but
a
lot
of
it
is
custom.
A
I'm
not
gonna,
go
into
too
much
more
detail
on
this
slide,
but
just
to
say
that
in
achieving
some
of
these
fundamental
properties
or
attributes,
we
often
you
know,
come
across
a
lot
of
other
terms.
So
how
does
a
veil?
How
does
failover
work?
How
does
redundancy
work?
How
does
data
protection
work?
These
are
not
really
attributes.
These
are
more
features
of
the
system
that
are
used
to
achieve
some
of
these
attributes,
which
is
what
we're
often
after
does.
The
slide
is
a
little
bit
mixed
up
in
that
it
has.
A
Combination
of
these
tools,
as
well
as
some
you
know,
breakdown
of
some
of
the
properties.
So
when
we
think
about
scalability,
it's
important
to
realize
that
they're
their
various
different
axes
of
scalability,
so
you
might
want
to
understand
how
much
data
you
can
actually
store
in
a
system
like
how
big
does
it
get
before
it
becomes
unusable?
And
that
may
be
very
important,
for
you
have
enormous
amounts
of
data
to
store.
A
You
should
make
sure
that
whatever
solution
you
choose
can
can
accommodate
that
data
and
if
you
get
the,
if
your
estimates
are
wrong,
then
you
know
you
should
know
whether
you
have
any
way
out
of
that
and
often
people
talk
about
horizontal
scalability
versus
vertical
scalability
etc.
Do
you
want
to
scale
the
number
of
clients
that
can
access
it,
which
is
a
completely
different
axis
of
scalability,
and
you
should
never
confuse
the
two?
Do
you
want
and
do
you
want
to
scale
the
performance
of
the
thing?
A
Do
you
want
to
be
able
to
do
more,
I,
ops,
etc,
and,
and
if
you
need,
if
you're
number
of
customers
grows
or
you're
number
of
users
of
your
application
grows,
is
there
a
ceiling
to
how
fast
you
can
read
and
write
to
this
data
store
and
and
if
not
or
if
there
is,
what
what
avenues
do
you
have
out
of
it?
Can
you
scale
up,
or
are
you
stuck
and
need
to
go
and
buy
bigger
boxes,
etc
and
there's
some
overlap
between
scalability
and
performance,
etc.
A
Consistency,
as
I
mentioned,
is,
is
probably
one
of
the
more
interesting
attributes
in,
in
the
sense
that
I
think.
In
the
early
days,
people
were
mostly
familiar
with
fairly
consistent
stores,
be
those
databases,
local
file
systems,
even
remote
file
systems
and
block
stores.
They
were,
for
the
most
part,
a
highly
consistent
and
fairly
fairly
performant,
but
they
they
ran
into
you,
know,
issues
related
to
scalability
and
and
and
and
availability
for
the
most
part.
A
So
that's
where
big
distributed
systems
started
becoming
more
popular
things
like
EBS
and
s3
and
alternative
ways
of
storing
things,
and
this
led
to
you
know
implicit
consistency,
challenges
which,
unless
you
understand
them
clearly,
can
cause
your
applications
to
get
very
complicated
and
not
work.
To
be
perfectly
blunt,
so
that's
that's
an
area
that
we
kind
of
dived
into
in
quite
a
bit
of
detail
and
yeah.
Hopefully,
that's
useful
in
terms
of
durability.
This
is
perhaps
a
a
good
place
to
sort
of
take
a
little
diversion.
A
So
one
thing
we
made
a
point
of
doing
in
the
paper
in
the
description
was
not
to
confuse
access
interfaces
with
the
actual
attributes
of
the
storage.
So
a
good
example
might
be
object,
stores
so
I'm
sure
many
of
you
have
come
across
object
stores.
They
tend
to
have
HTTP
interfaces,
they
tend
to.
You
know:
support
operations
like
put
and
get
had
fairly
granular
levels
to
be
designed
for
big
pieces
of
data
like
images
or
videos
or
backups
or
whatever,
but
you
know
s3
I
guess
was
the
grandparent
of
many
of
these
object
stores.
A
Dropbox
came
out
of
that
and
various
other
things
after
that,
but
s3
provides
you
know
more
than
just
an
interface
definition.
It
provides
a
whole
bunch
of
guarantees
around
durability
and
implicit
performance
implications
of
some
of
those
durability
guarantees
so
I'm
not
sure
what
the
architecture
actually
is
these
days,
but
certainly
back
in
the
day
it
was
three
copies
in
different
availability
zones.
Different
data
centers
essentially,
and
basically
your
data
would
never
disappear.
A
That
was
kind
of
part
of
the
the
value
offering
of
s3
and
I
think
today,
still
there's
advertisements
of
like
eleven
nines
durability,
or
something
like
that
that
your
data
will
basically
never
go
away,
but
there's
a
cost
to
that.
There's
a
cost
in
terms
of
performance.
There's
a
cost
in
terms
of
the
redundancy
that
you
have
to
have,
and
so
some
people
have
actually
built
things
that
have
exactly
the
same
interface.
A
There
have
precisely
the
s3
interface,
but
they
don't
have
all
of
those
durability
guarantees
and
they
don't
put
your
data
in
multiple
data,
centers,
etc.
So
just
you
know
make
sure
that
when
you
talk
about
an
object
story,
you're
talking
about
the
one
that
copies
your
data
into
lots
of
different
locations
and
gives
you
11
nines
durability.
Or
are
you
talking
about
the
one
that
actually
stores
it
on
a
file
somewhere
in
the
file
server
and
doesn't
give
you
any
of
those
guarantees.
A
As
I
mentioned,
in
addition
to
the
sort
of
primary
properties,
it's
pretty
important
to
understand
the
instantiation
and
deployment
aspects
of
whatever
storage
system.
It
is
that
you
choose-
and
you
know,
I
think
most
of
this
is
fairly
familiar
to
people,
so
I'm
not
going
to
go
into
too
much
detail,
but
some
of
them
are
tend
to
be
more
Hardware
focused.
So
you
have,
you
know.
A
Typically,
smaller
amounts,
smaller
numbers
of
more
dedicated
hardware,
and
you
tie
a
few
of
them
together
with
fairly
consistent
state,
often
with
proprietary
Hardware,
interconnects
networks,
etc,
and
then
there's
the
category
which
are
tend
to
be
more.
Software
related,
often
open
source
projects,
and
you
can,
you
know,
deploy
these
yourselves
either
on-premise
or
in
a
public
cloud,
and
these
tend
to
be
more
distributed.
A
They
come
with
a
lot
more
management
overhead
because
you
have
to
you
know,
run
the
software
yourself
in
some
cases
and
then
in
other
cases
you
can
obviously
subscribe
to
either
instances
of
open
source
services
or
proprietary
storage
services
like
in
many
of
the
public
clouds
and
I.
Think
at
this
point,
I'm
gonna
hand
over
to
my
esteemed
colleague,
Alex
who's,
going
to
take
you
a
little
deeper
into
the
interfaces
and
also
the
topologies
of
the
storage
systems
available
today.
Thank.
B
C
When
it
comes
to
cloud
native
storage,
we
we
kind
of
bucketed
two
general
categories
of
storage,
the
first
one
being
volumes
which
is
which
is
I,
guess
the
the
more
maturely
orchestrated
interface
in
in
orchestrators,
like
kubernetes
and
and
and
that
covers
things
like
block
interfaces
and
file
interfaces,
as
well
as
shared
file
interfaces
where
those
interfaces
where
file
systems
can
be
shared
by
multiple
hosts
on
different
nodes.
At
the
same
time,
in
in
in
the
general
case,
block
interfaces
in
the
most
simplistic
fashion
start
off
with
a
local
disk
right.
C
C
This
is
an
interface
whereby
the
workloads
are
being
are
accessing
the
storage
system,
typically
through
a
network
interface
rather
than
an
operating
system
interface,
and
that's,
it
can
be
the
most
popular
ones
being
obviously
an
object
store,
but
also
much
more
much
more
common
nowadays
are
things
like
key
value
stores,
but
obviously
all
the
other
databases
you
know
so
a
database
is
of
is
a
valid
storage
medium
and
it's
it's.
It's.
It's
I,
guess
a
traditional
medium
for
a
lot
of
applications
to
to
store
their
data.
C
This
life
is
a
little
contentious,
so
we
tried
to
do
a
comparison
of
the
different,
the
different
volume
access
interfaces
because,
as
I
said,
typically
there's
a
kind
of
general
expectation
that
different
interfaces
have
certain
properties.
So
very
often
block
interfaces,
for
example,
are
particularly
good
for
low
latency
and
individual
workloads
on
on
individual
hosts,
for
example,
but
perhaps
they're
less
suited
for
for
sharing
or
scaling
from
a
capacity
point
of
view.
File
systems,
on
the
other
hand,
are
really
good
for
sharing
or
often
shared
shared
file
systems.
C
Arounds,
locking
and
consistency
when,
when
used
by
complex
transactional
systems,
for
example,
and
as
quitman
was
mentioning,
object,
stores
often
have
availability
and
durability
as
one
of
their
as
one
of
their
key
aspects,
assuming
obviously
that's
those
those
object,
stores,
half
that
was
came
those
attributes
and
they're
and
they're
great
for
sharing
throughput
across
lots
of
workloads,
but
because
of
the
way,
but
the
distribution
and
the
protocol
implies
a
higher
level
of
latency.
For
example.
C
So,
at
the
end
of
the
day,
the
attributes
of
that
particular
storage
system
become
a
combination
of
the
attributes
at
each
layer
in
the
in
the
stack
so
orchestrators
and
host
an
operating
system.
Layer,
which
kind
of
is,
is
how
the
application
is
consuming,
that
that
storage
system
can
have
quite
an
effect
on
things
like
availability
or
scalability,
or
even
performance.
C
So
in
in
volumes,
you
see
folio
managers
playing
playing
an
aspect
here,
but
also
things
like
in
container
runtimes
appointments
and
overlay
file
systems,
for
example,
and
when
you're
accessing
storage
systems
through
the
network,
we
often
we
often
have
a
variety
of
layers
and
tools
which
are
which
are
interjected
as
part
of
the
system.
Perhaps
load
balancers,
perhaps
meshes
and
discovery
mechanisms,
a
big
aspect
of
the
of
how
a
storage
system
performs
and
and
is,
and
the
availability
and
scalability
of
that
system
is
fundamentally
going
to
be
down
to
the
topology
of
the
storage
system.
C
So
initially,
as
a
scranton
mentioned,
a
lot
of
a
lot
of
storage
systems
have
a
centralized
kind
of
a
centralized
topology.
Where
you
had
a
small
number
of
components.
They
were
often
hardware
based.
They
were
often
using
some
sort
of
proprietary
interconnects
to
maintain
a
high
level
of
stakes
between
between
the
different
components
in
the
system
and
they
provided
remote
storage
to
to
to
a
number
of
nodes
or
a
number
of
node
spirits
connected
to
that
centralized
to
that
centralized
storage
system.
So
this
was
an
environment
where
he
primarily
scaled.
C
C
Very
often
charting
is
used
within
databases,
and-
and
this
is-
and
this
is
the
most
typically
use
case,
but
shardene
also
comes
with
shark
charting-
is
MIT
perhaps
simpler
to
implement
in
some
distributed
systems,
because
you
have
say
lots
of
individual
database
nodes
which
which
handle
individual
splits
of
the
data.
But
the
way
you
splits,
the
data
can
often
change
as
the
data
grows
and
the
original
use
cases.
Don't
often
apply
so
you
end
up
having
some
shards,
which
might
run
really
hot,
and
it's
really
complicated.
C
This
has
proved-
and
this
is
proved
to
be
quite
popular
in
in
cloud
negative
environments,
and
we
can
we
see
this.
We
see
this
patter
and
growing
quite
quickly.
However,
there
often
are
again
operational
complexity
issues
here,
because
the
storage
environments
and
the
compute
environments
now
get
managed
as
a
single
entity.
So
changes
to
the
compute
environment
affect
the
storage
environment
and
changes
to
the
storage
environment,
affect
the
compute
environment.
C
C
Solar
systems
would
also
provides
typically
provides
a
range
of
data
services,
so
things
like
things
like
replication,
where,
where
once
or
system
can
replicate
to
another
source
system,
is
obviously
the
most
common
use
case.
Snapshots
and
clones
are
key
to
backups
and
point
in
time
copies
of
the
data
and
are
more
and
more
common,
especially
in
client
services
and
service
provider.
Environments
is,
is
encryption
where
more
and
more
storage
providers
are
providing
an
encryption
capability
to
keep
data
safe
within
within
those
environments.
C
Probably
one
of
the
most
well
developed
and
constantly
developed
technologies
at
the
moment
is
how
the
storage
systems
or
integrate
with
orchestrators
through
a
variety
of
management
interfaces.
So
we
already
talked
about
the
workloads
and
how
they
access
the
the
data
access
interfaces
in
the
data
plane
of
a
storage
system.
C
But
likewise
another
key
aspect
is:
how
can
you
make
your
storage,
declarative
and
composable
so
in
much
the
same
way
as
I
know,
you
can
ask
an
Orchestrator
to
run
a
container
in
a
pod
for
you
and
you
can
specify
things
like
network
requirements
and
CPU
and
memory
requirements.
You
can
now
also
ask
an
Orchestrator
to
supply
storage
interfaces
for
you
and
supply
a
set
of
parameters.
That's
that
an
Orchestrator
can
interact
with
a
storage
system
with
the
there
are
a
number
of
different
interfaces
in
use.
C
Today,
the
there
are
a
number
of
native
interfaces
which
are
built
into
some
orchestrators,
so,
for
example,
kubernetes
has
I
believe
16
or
17
native
drivers
in
in
in
built
mainlined
into
the
crew
Bonetti
source.
We
also
have
things
like
the
VDI,
which
is
a
docker,
a
runtime
interface
to
volume,
drivers
which,
which
can
interface
with
storage
systems,
and
we
also
have
the
Flex
interface
in
kubernetes,
which
I
guess
is
the
first
generation
of
an
external
storage
driver
to
kubernetes,
followed
rapidly
on
with
the
CSI
interface,
which
is
now
the
new.
C
A
C
Fantastic
and
and
what
we'd
really
like,
is
your
feedback
and
your
interact
and
and
your
your
comments
on
on
the
white
paper,
anything
to
to
help
us
make
it
better
and
we're
also,
as
a
next
step,
going
to
be
looking
to
investigate
and
publish
real-life
case
studies
on
people's
use
of
different
storage
systems.
To
kind
of
take
some
of
these,
some
of
the
terminology
and
some
of
the
workers
we've
done
in
the
white
paper
and
transform
that
to
kind
of
real-life
use
cases
and
real-life
scenarios.
C
C
So
so
the
question
was:
what's
the
scope
of
storage
in
in
in
terms
of
urine
at
least
I
think
I
think?
What's
what
we're
seeing
now
is
that
more
and
more
different
application
patterns
and
different
workloads
that
are
moving
to
orchestrated
environments
have
some
component
of
a
stateful
nature
right
at
the
end
of
the
day,
every
architecture
in
every
application
has
a
has
a
stateful
requirement,
whether
that's
storing
sister,
storing
day
for
themselves
or
consuming
data
from
say,
databases
or
perhaps
missus
buses
or
instrumentation
or
observability
systems
which
require
store,
States
somewhere.
C
C
It
depends
on
the
solution,
it's
the
right
answer.
So
the
question
is
where
the
sort,
the
role
of
the
storage
solution
and
in
terms
of
their
the
the
data
management
cycle-
well,
a
source
or
solution-
can
have
a
lot
of
complex
functionality
whose
remember
storage
system
can
be
a
database
and
can
have
a
variety
of
functionality
there,
but
also
storage
solution
can
be
responsible
for
taking
care
of
things
like
data
retention
and
and
and
other
functionality.
C
So
so
that's
a
very
good
question.
So
the
question
is:
if
we're
doing
big
data
and
and
we're
considering
things
like
data
locality,
has
that
influences?
The
answer
is
that
data
locality
and
and
is,
is
something
that
is
actually
covered
in
some
of
the
CSI
spec
and
we're
looking
at
things
where
the
topology
of
the
of
the
storage
system
and
the
topology
of
the
compute
nodes
come
together
in
a
schema.
D
C
The
first
thing
is
that
storage
systems
have
traditionally
presented
storage
to
operating
systems
or
VMs,
and
now
what
we're
looking
to
do
is
we're
looking
to
present
storage
to
applications
right
so
fundamentally,
you've
containerized
the
application
you've
made
it
portable
and
the
orchestrator
can
place
the
application
wherever
it
once
and
you
needs
to
have
a
system
now
where
storage
can
be
presented
to
the
application
and
move
with
the
application.
So
support
abilities
is
a
big
thing.
C
The
other
big
thing
is
that
the
whole
point
of
having
an
orchestrated
storage
system
is
that
it's
declarative
and
composable,
so
in
much
the
same
way
that
you
declare
say
CPU
and
memory
and
network
ports,
and
things
like
that.
You
should
also
be
able
to
declare
the
storage
requirements
and
have
the
orchestrator
votes
dynamically
provision
and
consume
that
storage,
so
having
those
those
interfaces
and
an
API
is
where
the
orchestrator
can
can
it
can
use
a
driver
can
hook
into
into
a
storage
system
to
allow
the
storage
systems
do
that
is
key.
E
Just
to
pick
up
on
what
you
were
talking
about
about
the
the
movement
to
bind
data
to
applications
and
the
model
by
which
storage
systems
can
be
told
to
do
this,
the
white
paper
seems
to
talk
about.
Well,
it's
a
taxonomy
of
current
storage
systems,
perhaps,
and
those
that
will
be-
you
know
forthcoming
in
some
short
horizon,
but
it
would
seem
to
be
much
further
to
go
to
get
closer
to
a
to
a
model
that
binds
data
to
applications
more
tightly
and
I.
Wonder
what
do
you
see
how
double
the
CN
CF?
A
A
F
B
E
They'll
serve
to
a
nice
cozy
initiator,
for
example,
and
though
there
was
a
declaration
somewhere
that
that
initiator
at
that
IQ
n
can
talk
to
this
target
and
report.
Lunz
will
say
lund
to
you
can
see
that
now.
The
question
is,
you
know
how
what
you're
really
doing
there
is
to
what
you're
trying
to
accomplish
is
there's
an
application
running
somewhere
on
that
host
and
it
could
be
a
VM
and
the
hypervisor.
E
It
could
be
just
an
application
running
on
the
host
no
hypervisor
and
you
are
accomplishing
the
delivery
of
data
access
to
that
application,
which
is
there
it's
all
implied.
None
of
that
is
explicit
in
the
mapping
model
that
you've
just
that
you
just
expressed
same
fiber
channel
and
it
seems
still
largely
true,
it's
a
little
bit
different
right,
but
you
basically
deliver
a
volume
and
then
there
are
simple
instance:
it
into
a
container,
and
so
it's
it's
an
evolution,
but
still
very
it's
an
increment
toward
something.
E
A
Unfortunately,
we're
we're
gonna
get
kicked
out
of
this
room
five
minutes
ago,
so
what
I
can
encourage
you
to
do?
Thank
you
very
much
for
your
participation.
This
is
a
lot
of
audience
feedback
which
was
valuable.
Can
we
just
take
it
out
into
the
area
outside
the
room
here
and
carry
on
the
discussions?
I
think
it'd
be
super
cool,
yeah,
yeah,
no
fistfights,
please.