►
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
Intro + Deep Dive: CNCF Storage WG - Alex Chircop, StorageOS
The CNCF Storage Working Group and SIG collaborates to explore and understand how different storage technologies are used in cloud-native environments. Topics include block stores, file systems, object stores, key-value stores and databases, amongst others. Different architectural approaches (centralized, distributed, sharded etc) are compared in terms of key attributes like availability, scalability, performance, data consistency, durability, fault tolerance, ease of development and operational complexity. In the intro we'll provide an overview of the work currently underway and on the roadmap. You'll get the meet the people leading these efforts, and find out how best to get involved and contribute. We also welcome any other input you might have related to cloud-native storage. Then we'll dive deeper! We'll present our work thus far, and host detailed discussions around the findings of our recent end-user surveys covering how cloud native storage is approached in the real world, including some representative successes and failures. Our hope is that others can learn from, and expand upon those experiences.
https://sched.co/MPlS
A
So,
first
off
before
we
begin
in
a
interesting
example
of
how
consistency
and
distributed
storage
is
a
challenge.
There
seems
to
have
been
some
logistical
issues
where
the
app
has
been
showing
that
our
session
is
in
g1
and
the
web
session
is
enjoying
that
we're
in
g2.
So
if
you're,
if
you're
here
for
the
open,
API
you're
in
the
wrong
place,
that's
in
g2
alright.
A
So
one
other
thing
that
you
might
notice
is
in
the
show
do
this
was
this
was
originally
supposed
to
be
around
the
CN
CF
storage
working
group,
but
just
hot
off
the
press.
The
storage
working
group
is
transitioning
to
the
CN
2.
It
was
sake,
so
I'm
going
to
spend
just
a
little
bit
of
time
talking
about
the
new
CN
CF
6,
which
are
which
have
just
which
have
sauce
which
are
just
being
formalized
and
give
you
a
little
bit
about
a
little
a
little
bit
of
background
in
this.
A
So
all
of
the
all
of
the
information
is
on
the
CN
CF
github,
but
for
background.
The
sync
is
here
to
help
scale
the
CN
CF.
So
over
the
last
year,
we
we
now
have
over
400
organizations
who
are
members
of
the
CN
CF
and
another
85
may
be
nicely.
Organized
and
user
organizations
have
also
joined,
and
the
number
of
projects
that
has
been
developing
added
to
the
CN
CF
and
meet
I
need
attention
and
help
and
coordination
has
been
growing.
A
So
so
the
idea
behind
the
sake
is
this
helps
the
the
TOC,
which
is
the
technical
oversight
committee
that
manages
the
projects
in
the
CNC
f.
It
allows
them
to
scale.
So
what
we're
looking?
What?
What
the
sake
is
is
here
to
do
is
to
meet
effectively
the
needs
of
European
users
right
and
figure
out
the
types
of
projects
that
are
going
to
be
that
they're
going
to
be
needed
in
a
cloud
native
environment
and
working
on
reviewing
and
providing
help
to
the
TOC
on
a
number
of
different
projects
which
fall
into
different
categories.
A
The
so
one
of
the
key
things
for
that.
The
stick
is
going
to
be
working
that
six
are
going
to
be
working
on,
are
handling
the
different
projects
so
working
with
the
projects
reviewing
the
projects,
Pro,
providing
feedback
for
the
COC,
but
also,
more
importantly,
actually
working
with
the
projects
to
help
them
present
and
get
ready
to
to
join
the
CNC
F.
A
We
also
have
a
responsibility
for
helping
the
end
users,
so
things
like
providing
up-to-date
information,
perhaps
white
papers
and
we'll
talk
a
little
bit
about
some
of
the
some
of
the
white.
Some
of
the
information
that
we've
generated
in
the
storage
there
in
a
minute
and
we're
also
here
to
look
at
gathering
information
from
the
end
users,
so
that
we
can
provide
the
the
right
feedback
in
the
talk
into
the
projects
to
help
to
help
guides
where,
where
these
projects
go
and
finally,
everything
that
the
sig
does
is
completely
open.
A
So
we
we
have
open
meetings
everybody's
free
to
join.
There
are
opening
open
meeting
notes,
open
mailing
lists,
etc
and
ice
trusted
advisors.
To
the
talk
we
have
a
number
of
technical,
leads
and
and
sub
projects
that
form
within
the
cig
to
perform
particular
functions.
To
help
the
talk
to
our
mandate.
A
Would
regard
to
the
storage?
Six
specifically,
our
mission
is
to
provide
all
of
the
all
of
this
information
to
the
talk,
but
also
to
help
them
in
saying
the
health
of
the
CNC
at
storage
projects
specifically
and
we'll
talk
a
little
bit
about
those
in
a
second
and
we're
constantly
looking
for
additional
projects
to
to
add
in
to
the
to
the
CNC
F.
A
Its
traditional
volume
based
systems
like
block
stores
and
file
systems,
but
also
API
driven
systems
like
like
object,
storage,
databases,
key
value
stores,
etc,
and,
fundamentally
just
in
order
to
sort
of
bracket
that
scope.
We're.
Looking
for
storage
systems
that
satisfy
the
the
CNC
have
cloud
native
definition
right.
So
we're
looking
at
four
storage
environments
and
storage
projects
that
work
with
micro
services
that
are
scalable
that
have
eight
the
eyes
that
are
declarative
and
that's
our
automatable
and
interact
with
orchestrators.
A
A
Obviously,
the
kubernetes
storage
sake
is
a
big
driver
in
this
area,
where
we'll
be
looking
to
work
very
closely
with
them
and
actually
what
the
the
leads
from
the
storage
thing
actually
works
with
with
the
CN
CF
storage.
Stick
very
well
we're
also
very
working
quite
closely
with
the
CSI
team.
So
the
CS
is
that
container
storage
interface-
and
this
is
the
son
Dyson
things
that
different
orchestrators
can
use
to
interact
with
storage
systems,
we'll
also
be
working
with
the
scenes.
They
have.
A
Storage,
sig,
asteroids
Ian's
have
security
sake
and
as
soon
as
it
assumes
forms
the
the
acts
sake
to
work
with.
In
terms
of
how
different
storage
systems
interact
with
different
applications
in
in
real
life,
so
in
terms
of
in
terms
of
the
operating
model,
the
sake
is
formed
with
a
number
of
chairs
and
a
number
of
techniques.
These
are
the
these
are
the
current
chairs
that
have
been
photos
in
and
exactly
so
that
being
voted
in
by
the
talk
today,
in
fact
that
the
vote
was
cleared.
So
this
is
half
of
the
press.
A
A
The
the
details
for
the
fort
for
everything
at
6
storage
does
for
the
CAF
are
available
in
that
github
repo
and
posted
some
links
there
to
cover
the
the
meeting
minutes
that
covered
some
of
the
things
we
discuss.
It's
probably
important
to
note
that
everything
that
the
the
Sikh
does
is
is
vendor-neutral.
We
have
a
number
a
lot
of
different
vendors
that
work
with
our
our
group,
including
some
of
the
names
listed
below,
but
we
also
have
a
number
of
individual
contributors
and
independent
contributors
that
that
helped
work
with
the
projects
that
we're
working
on.
A
Portable
orchestrators,
like
kubernetes,
help
you
to
abstract
away
the
infrastructure
and
give
you
the
ability
now
to
declare
how
your
application
needs
to
run,
but
it
kind
of
does
a
really
good
job
of
sort
of
playing
Tetris
with
your
workloads
right.
So
it
figures
out.
The
best
places
to
put
your
application
is
based
on
based
on
what
you
declare
in
your
application
in
terms
of
CPU
memory
and
say,
network
requirements,
but
just
as
important
is,
are
the
stateful
applications
right?
So
no
application
really
doesn't
know.
A
There's
no
such
thing
as
an
application
that
doesn't
store
state
somewhere.
Every
application
to
be
useful
is
story
and
state.
Now
that
can
be
something
that
can
be
a
service
that
lives
within
your
orchestrated
environment
or
even
in
this
environment,
but
it
could
also
be
service
with
also
be
using
services
that
live
outside
of
that
environment.
So
the
climax
of
storage
at
work
that
we're
talking
about
is
is
effectively
supporting
the
portability
as
right.
A
So,
during
the
life
of
the
working
group
previously
and
another
sake,
a
number
of
different
projects
have
have
presented,
including
you
know,
some
very
well-known
ones
like
like
CSI
and
rook,
for
example,
and
a
number-
and
you
know
with
through
with
collaboration
with
the
working
group
and
with
the
talk,
a
number
of
these
projects
have
been
accepted,
rook
initially
as
a
sandbox
project
and
which
is
now
graduated
to
to
an
incubating
project.
Vitesse
has
been
accepted
as
an
incubating
project.
Citv
was
a
sandbox
project
and
was
just
announced
as
an
incubation
project.
A
Today,
an
open
EBS
was
was
accepted
as
a
sandbox
project
and
just
a
bit
of
background
that
some
of
those
projects
after
looking
at
act
wrote,
provides
an
operator
and
an
framework
to
help
automate.
The
deployment
and
management
of
different
storage
systems,
but
primarily
SEF
Fitness,
is
a
distributed.
Database
project
which
originally
started
off
started
life
in
YouTube
TI
kV
is
as
a
distributed,
key-value
store
with
with
a
lot
of
advanced
functionalities,
and
it's
also
used
as
the
basis
of
TI
DB,
which
is,
which
is
a
database
that
sits
on
top
of
that.
A
The
the
white
paper
is:
is
there
not
to
recommend
any
specific
systems?
In
fact,
it
doesn't
specifically
grant
its
way
to
list
specific
storage
systems,
but
it's
there
so
that
people
can
understand
they
get
a
better
understanding
of
the
available
solutions
out
there
in
terms
and
the
attributes
and
the
layering
of
these
different
storage
systems-
and
this
is
important
because,
with
the
advent
of
cloud
native,
the
way
that
people
are
interoperable
storage
systems
is
is
changing.
A
You
know,
storage
systems
used
to
be
the
sole
domain
of
of
an
infrastructure
team,
but
but
more
and
more
sorry
so,
and
those
storage
systems
were
where
often
very
static
in
what
they
were
offering
to
application
team.
So
very
often
application,
architects
or
our
developers
had
to
develop
an
application
to
fit
around
the
storage
system
more
and
more
in
in
Incline
native
environments.
A
With
you
know
such
a
rich
offering
of
cloud
services
and
and
software
and
hardware
offerings
we
have-
we
have
a
new
paradigm
coming
where
developers
and
understand
the
attributes
of
their
of
their
of
their
environments
and
therefore
choose
a
storage
system
or
shape
the
storage
system
around
the
applications
of
the
requirements
so
effectively.
This
is
empowering
developers
to
make
some
of
these
decisions,
and
enough
was
the
objective
of
the
white
paper.
So
the
white
paper
hats
have
a
number
of
authors
from
the
from
the
CAF
source,
a
core
working
group.
A
A
lot
of
these
a
lot
of
these
names.
You
will
be
recognized
as
contributors
or
or
working
on
other
projects
like
like
CSI
or
or
or
at
CD,
for
example,
and
what
we
cover
in
the
white
paper
is
what's
effectively
inside
a
storage
solution.
So
we
wanted
to
look
at
the
different
interfaces:
that
storage,
that's
different
storage
systems,
how
and
looking
at
the
different
attributes
of
the
storage
system.
A
So
we
we
focused
on
on
five
main
attributes,
availabilities
scalability
performance,
consistency
and
durability,
because
these
are
the
things
that
and
all
those
people,
perhaps
don't
fully
understand
or
maybe
take
for
granted
in
some
cases.
So
the
storage
attributes,
the
storage
attributes
that
we
were
looking
at
kind
of
cover,
functionality
or
or
capabilities
of
different
sources.
So
when
we're
looking
at
things
like
availability,
we're
often
we're
often
thinking
about
it's,
perhaps
redundancy,
but
it
also
covers
aspects
like
how
does
think
the
failover.
A
How
does
a
pod
continue
to
access
the
data
as
during
viewing
failure
scenarios,
for
example
as
well?
As
you
know,
the
more
traditional
redundancy
and
data
protection
again
scalability
is
another.
One
of
those
is
another
one
of
those
topics
which
can
be
measured
on
a
number
of
different
accesses,
so
in
some
cases
it
might
be
important
to
have
a
storage
system
that
can
be
accessed
by
hundreds
or
thousands
of
clients.
A
In
other
cases,
it
might
be
about
the
capacity
of
a
storage
system
or
the
or
the
troopers
or
the
number
of
operations
that
the
storage
system
can
handle
and
then
obviously
performance
is
always
a
big
factor.
At
thatis,
that
has
something
which,
which
drives
a
lot
of
decisions,
and
again
sometimes
it's
it's
important
to
have
do
to
to
to
look
at
the
source
systems
from
from
a
latency
perspective
where
you
might
be
where
the
way
you
consume.
A
The
storage
is
is
a
very
big
factor
other
times
it
might
be
a
case
of
understanding
the
the
tardis
storage
and
provides
the
throughput
in
terms
of
you
know,
megabytes
per
second
or
iOS
per
second
and
those
sort
of
functionality.
It
translates
into
how
you
architect,
your
your
client,
environment
or
your
or
your
on-prem
environment,.
A
Consistency
is
a
thing
which
comes
up
very
often
in
storage
system
evaluations,
so
many
distributed.
Many
distributed
systems
take
a
number
of
different
compromises
in
terms
of
the
types
of
attributes
that
they
support.
So,
for
example,
some
systems
might
optimize
or
scale,
and
some
of
the
systems
might
optimize
for
performance.
Invariably
that
leads
to
compromises
on
the
types
of
consistency
that
those
other
systems
and
support.
A
So
the
more
moving
parts
you
have
in
a
system,
the
more
likely
you
might,
you
might
have
delays
to
consistency
and
those
delays
could
be
can
be
measured
across
two
accesses.
One
is
that
sort
of
the
time
it
takes
between
actually
permitting
data
to
a
storage
system
and
a
storage
system
actually
acknowledging
that.
That's
that
that
I
think
has
been
committed,
and
it
could
also
be
around
the
the
time
it
takes
between
data
being
committed
to
a
storage
system
and
the
correct
data
actually
being
returned
on
subsequent
reads.
A
The
other
and
then
finally,
the
other
important
thing
to
consider
when,
when
looking
at
cloud
native
environments,
especially
when
we're
looking
at
hybrid
plants
and
and
perhaps
different
managed
services,
it's
really
important
to
understand
the
durability
of
your
of
your
systems
right
so
having
redundancy
for
your
to
help
with
your
availability
is
is
one
aspect
but
the
where
your
data
is
protected,
which
geographies
of
data
is
copied
to?
How
many
failures
can
you
tolerate
before
the
data
is
lost,
etc?
A
And
then
also,
you
know
some
of
the
more
some
of
the
more
low-level
things,
so
things
like
bit
rot.
So
you
know
what
do
you
do
when
when
physical
media
starts
starts
to
fail?
So
these
are
all
things
that
there
are
considerations
when
you're
when
you're
considering
different
storage
systems.
Of
course,
planning
source
systems
come
in
all
shapes
and
sizes
and
can
be
instantiated
and
deployed
in
a
number
of
different
ways.
There
are
traditional
hardware
solutions
which
get
deployed
on
premises
in
your
datacenter.
A
There
are
software
options
which
provides
the
data
services
and
the
functionality
of
a
storage
system,
but
don't
actually
even
date,
specific
hardware
requirements
which,
which
obviously
mean
that
think
that
they're
probably
a
bit
more
portable
than
the
hardware
of
solutions
and
then
there's
there's
a
whole
plethora
of
client
services
that
can
be
consumed
from
from
private
implants
and
public
cloud
providers
covering.
You
know
everything
from
volumes
to
databases
to
other
services.
A
So
we'll
talk
a
little
bit
then
about
how
we
consume
the
storage
in
a
client
native
environments.
There
are
a
number
of
different
state
access
interfaces,
so
a
workload
can
can
be
talking
to
a
storage
system
and
in
in
what
we
defined
as
sort
of
two
major
buckets.
The
first
thing
volumes
and
the
second
being
which
we
build
API
is
so
volumes
are
perhaps
the
more
traditional
type
of
storage,
so
things
like
block
storage
file
system,
shared
file
systems,
etc.
A
It's
probably
fair
to
say
that
in
a
lot
of
the
orchestrated
environments,
volumes
are
have
more
mature
interfaces
and
the
more
mature
options
in
terms
of
in
terms
of
abstractions,
so
urban
Effy's
has,
for
example,
a
rich
set
of
drivers
and
interfaces
like
CSI,
which
we'll
discuss
in
a
minute.
That's
allow
native
native
interaction
with
with
a
whole
number
of
different
storage
systems,
and
there
are
a
number
of
projects
which
are
which
are
being
built
that
help
provide
abstractions
over
some
of
the
API
driven
storage
mechanisms.
A
So
one
of
the
one
of
the
a
couple
of
the
projects,
that's
that
we've
looked
at
recently
is
projects
like
baroque,
are
introducing
abstractions
to
help
automate
and
manage
things
like
databases
and
also
again,
the
it's
kind
of
the
early
days
for
them,
but
we're
also
seeing
a
lot
more
proven
at
these
operators.
So,
even
if
these
operators
are
effectively
pieces
of
code
that
help
automates
the
the
management
of
something
saiful
like
like
a
database
or
or
perhaps
a
sword
system
within
with
an
acrimonious
environment,.
A
So
different
volume
access
interfaces
traditionally
have
different
attributes
and
what
we'll
discuss
now
is
what
what
is
the
most
generally
accepted
attributes
of
these
of
these
different
environments.
But,
of
course,
one
thing:
that's
that
we'll
discuss
in
a
minute
is
the
difference.
How
the
different
storage
layers
in
an
asura
system
can
contribute
to
how
the
attributes
of
these
of
these
of
these
different
data
access
interfaces
can
be
affected.
A
So
in
many
cases
block-to-block
systems
are
most
suited
for
things
like
availability
and
low
latency,
but
they're
there
they're
less
suited,
for
example,
things
like
scaling,
and
they
really
don't
do
very
well.
It's
for
sharing.
They
come
with
multiple
workloads,
for
example,
whereas
file
systems
are
great
at
sharing
data
with
multiple
workloads
and
typically
very
much
optimized
for
for
true
put
object.
A
Source
tend
to
be
very
optimized
for
for
capacity
and
durability
and
availability,
so
so
object
stores,
work,
typically
objects
or
architectures
are
designed
with
to
have
lots
of
copies
or
or
support
features
like
a
racial
coding
to
to
provide
large
capacities
with
with
good
durability,
but
typically,
all
of
that,
all
of
that
architecture.
Concepts
comes
at
a
low
latency
performance
overhead.
So
so
we'll
talk
a
little
bit
now
about
some
of
the
storage
layers
within
a
storage
system.
A
So
we
we
said
before
that
some
of
the
different
data
access
interfaces
have
are
well
understood
in
terms
of
the
attributes
that
they
have.
But
one
thing:
that's
one
thing
that
one
thing
that
needs
to
be
understood
is
that
the
source
systems
have
lots
of
different
layers
in
there
in
their
environments
and
very
often
the
way
that
you
consume.
The
storage
doesn't
necessarily
determine
the
underlying
architecture
of
that
storage
and
more
and
more
with
automation
and
it's
cloud
native
environments.
A
It's
it's
often
we
often
come
across
scenarios
where
different
storage
systems
are
layered
on
top
of
each
other.
So,
for
example,
it's
it's
not
unusual
to
see
a
file
system
layered.
On
top
of
an
object
store,
in
which
case
it
will
have
the
sharing
capabilities
of
a
file
system,
but
the
latency
attributes
of
an
object
store.
Perhaps-
and-
and
there
are
you
know,
other
examples
where
perhaps
a
block
store
is
presented
from
a
distributed
file
system.
A
A
Starting
starting
at
the
very
top
of
that
layer,
we
have
a
number
of
abstractions
that
are
applied
by
the
orchestrator
and
the
operating
system,
and
indeed
some
of
these
things
can
indefinitely
affect
the
the
or
contribute
to
the
availability
or
scalability
or
performance
of
these
systems.
So,
in
the
case
of
in
the
case
of
volumes,
you
have
things
like
Raleigh
managers
and
which
can
balance
workload
across
a
number
of
devices,
but
also
in
the
API
side
of
the
world.
A
The
topology
of
the
actual
storage
system
is
also
important
to
to
consider
this.
Can
this
can
change
just
about
every
attribute
of
other
storage
system?
We
have
source
systems
that
are
more
traditional
where
they
are,
they
have
a
centralized
architecture
and
you
have
a
number
of
systems
that
that
connect
to
to
a
central
point.
These
sort
of
systems
tends
to
be
systems
that
that
scale
up,
but
as
opposed
to
scaling
out
so
they
tends
to
be.
They
tend
to
be
systems
that
perhaps
offer
lower
latency
capabilities,
but
not
necessarily
good
scaling
capabilities.
You
have.
A
On
the
other
hand,
you
have
distributed
source
systems
where
the
storage,
where
the
topology
of
the
source
systems
is
made
up
of
a
number
of
different
components,
the
direct
that
can
be
distributed
with
our
own
environment.
These
thing
to
have
better
scaling
and
better
capacity
attributes
are
typically
at
the
cost
of
some
of
the
performance
or
the
latency
capabilities.
A
So,
in
a
how
to
convert
topology,
which
is
which
is
perhaps
fairly
common
in
in
software
based
storage
systems,
when,
when
they're
automated
by
Orchestrator,
you
have
you
have
you
just
have
nodes
which,
in
your
cluster
and
those
those
can
be
used
both
to
to
consume
storage
as
well
as
provides
storage
as
provide
storage
services.
So
there
are,
there
are
some
advantages,
and
that
is
obviously,
as
you
know,
simplicity
elements
to
this,
but
of
but
then
there
are,
there
might
be
other
commercial
or
or
operational
challenges
to
do
that.
A
A
So
things
like
replication,
where
perhaps
a
source
system
might
give
you
protection
across
availability
zones
or
Geographic
different
geographic
areas,
things
like
snapshots
and
clones,
which
can
provide
data
management
and
data
copy
management
functionality
to
provide
you
with
the
with
the
ability
to
take
point
in
time,
copies
of
data
which
can
be
used
for
things
like
backups,
but
also
for
for
services,
like
you
know,
to
test
to
production,
promotion
and
data
lifecycle,
activity
and
then
finally
encryption.
So
we
were,
we
were
presenting.
A
We
have
a
replied
method
of
storage
day
on
on
Monday
and
we
had
a
number
of
end
users
contributing
different
different
in
different
advice
and
examples
of
their
use.
Cases
and
one
of
the
one
of
the
repeating
trends
was
that
you
know:
storage
systems
focused
on
performance
and
reliability,
initially
in
implied
negative
environments,
but
more
and
more
security
and
an
encryption
are
kind
of
becoming
the
facto
standards
that
that
need
to
be
enforced.
A
So
in
much
the
same
way
that
network
connectivity
is
always
encrypted
with
with
TLS
it's
getting
more
and
more
commonplace
to
have
to
have
encryption
and
storage
storage,
key
management
for
that
encryption
as
part
of
the
data
services,
a
storage
system
works
it
and
then
finally
and
I'm
not
going
to
talk
much
about
this
there's.
Obviously
I
didn't
at
the
end
of
every
store
system.
There
is
some
physical
store
somewhere
that
actually,
where
all
the
bits
actually
land.
A
Traditionally
that's
been
spinning
this,
but
more
and
more
we're
working
with
flash
storage
and
solid-state
storage,
but
we
should
also
consider
some
of
the
caching
capabilities
of
the
storage
systems,
provided
because
this
can
be
quite
important
in
terms
of
consistency,
discussions
within
within
a
storage
system,
so
that
was
all
about
the
data
access
interfaces.
I
want
to
talk
a
little
bit
now
about
the
management.
A
Within
storage
system,
so
the
management,
the
the
orchestrator,
can
have
a
number
of
different
ways
of
interacting
with
a
storage
system.
The
workloads
themselves
will
be
talking
to
detector
playing
in
a
storage
system,
whereas
the
orchestrator
will
be
interacting
with
the
control
plane.
There
are
a
number
of
different
control
playing
interfaces
which
have
standardized
over
time,
such
as
CSI,
which
is
the
container
storage
interface
there's
DB
di,
which
is
a
docker
volume
interface.
A
There
are
flex
drivers
and
criminals
as
well
as
well
as
native
drivers
and
with
all
of
this
there's
also
a
set
of
frameworks
and
tools
that
have
evolved
to
help
provide
additional
functionality
or
help
facilitate
interactions
between
a
B
is
between
orchestrators
and
the
storage
systems.
So
projects
like
open,
SDS
and
rope
fall
into
this
category.
A
For
example,
the
interfaces
that
are
available
in
kubernetes
primarily
today
are
the
native
volume
drivers,
which
are
drivers
that
are
that
are
sort
of
main
lines
into
into
the
main
urbanity
source,
but
the
but
the
standards
that
kubernetes
is
moving
towards
is
that
is
this:
si
si
si
si
sensor
or
container
storage
interface
and
in
much
the
same
way
that
we
had
CNI
for
networking
and
CRI
for
the
runtime.
Si
si
attempts
to
provide
an
abstraction
mechanism
between
urban
at
ease
and
the
storage
systems.
A
The
it's
probably
worth
pointing
out
that
that
si
si
isn't
a
grouping
at
these
specific
technology.
It
is
actually
container
Orchestrator
agnostic
and
another
orchestrators
like
mesosphere,
for
example
in
platformer.
You
also
have
si
si
interfaces,
but
I
guess
the
more
the
more
mature
well
known
ones
are
the
interfaces
between
si
si
and
I'm
CUBAN
at
ease
on
that
I
will
stop
here
for
a
second
and
ask
if
the
audience
has
any
other
questions
before
we
talk
a
little
bit
about
some
of
the
next
steps
that
the
si
si.
A
So
finally,
I
want
to
I
just
want
to
end
my
presentation
to
talk
a
little
bit
about
some
of
the
things
that
we're
going
to
be
working
on
next
with
the
with
the
storage
state.
So
we
have
launched
a
storage
survey
to
the
end
user
forums
for
tour
for
the
CN
CF,
but
would
also
encourage
any
of
you
that
have
the
time
to
provide
feedback
to
to
to
fit
in
the
to
fill
in.
A
A
The
the
C&C
have
six
storages
is
open
to
the
public
we'd
love
to
hear
your
thoughts
and
comments
in
our
weekly
meetings
and
we'd
love
to
help
you
get
involved
in
in
different
projects
and
different
different
papers,
and
if
any
one
of
you
would
would
like
to
get
in
touch
direct.
But
all
of
the
chairs
and
tech
leads
are
available
about
the
ciencia
fund,
the
kubernetes
slack
so
as
well
as
the
main
leanest
so
feel
free
to
get
in
faction
and
suggest
any
any
options.
B
I'll,
give
you
like
a
16
part
question
I.
So
can
you
kind
of
articulate
the
difference
between
a
sandbox
project
and
an
incubator
project
and
with
the
C
and
C
F
you
know,
I
does,
for
you
know
something:
that's
a
sandbox
or
an
incubator
and
at
which
point
it
graduates
to
become
indoor
spy
unit
against
EF.
C
Hi
I'm
Quinton
I
was
formerly
on
the
TOC
and
helped
formulate
some
of
that
stuff
around
sandbox.
So
the
answer
to
that
question
is
sandbox
is
explicitly
there
to
create
a
neutral
environment
where
multiple
companies
and
individuals
can
collaborate
in
a
safe
place,
and
in
that
way
it
does
not
actually
imply
that
the
technology
is
stable
or
usable
in
production
or
in
any
way
like
technically
endorsed
by
the
TRC.
In
many
cases,
some
of
these
projects
barely
exist
when
they
come
into
the
sandbox.
C
They
just
need
a
home
where
they
can
explore
ideas
or
develop
technology
collaboratively
between
companies.
So
that's
the
idea
of
the
sandbox
and
and
there's
a
variety
I
mean
there
are
some
projects
in
the
sandbox
that
are
fairly
mature,
but
but
we
don't
as
a
CNC
if
we
don't
actually
kind
of
tell
you
to
go
and
use
these
things.
C
However,
the
the
incubation
projects
go
through
a
pretty
easy,
substantial
technical,
due
diligence
by
the
TRC
and
the
and
the
six
they're,
not
necessarily
like
fully
production
ready
yet-
and
there
are
a
couple
of
caveats
around
incubation
projects
which
you
need
to
be
aware
of,
for
example,
they
may
still
have
one
major
contributor
company,
so
you
know
if
that
company
goes
out
of
business
or
or
in
some
way
decides
to
dump
that
project.
That
is
a
risk
that
still
exists
with
incubation.
So
this
is
typically
the
phase
where
those
projects
are
trying
to
get.
C
You
know
healthy
balance
of
collaborators
across
multiple
companies.
They
also
possibly
used
only
in
only
used
in
production.
In
you
know
relatively
small
number
of
companies.
They
are
used
in
production.
They
do
in
order
to
be
an
incubation
project.
Your
your
project
has
to
be
used
in
production
in
several
places,
but
it
may
not
be.
You
know
why
it's
spread.
They
used
what
in
in
a
widespread
way
and
then
obviously
graduation
is
one
step
above
incubation
again
and
that's
you
know,
kubernetes
is
the
kind
of
poster
child
for
that.
C
You
know
tons
of
people
use
it.
Tons
of
companies
contribute
if
any
one
of
the
companies
actually
pulled
out
at
Google.
Where
do
you
know
I'm
making
up
stories,
but
if
Google
were
to
go
bankrupt
tomorrow,
you
know
kubernetes
would
still
be
there.
There's
still
tons
of
other
people
who
understand
how
kubernetes
works
and
would
continue
to
maintain
it
into
the
future.
Does
that
answer
your
question.
D
A
A
So
you
contributing
to
the
sake,
helps
that
helps
with
the
work
that
the
sake
is
doing
in
terms
of
perhaps
reviewing
those
projects
or
working
on
some
of
the
white
papers
or
some
of
the
information
that
we're
working
on
if
you're,
obviously
contributing
to
a
project
directly.
Well,
then
you're
helping
a
specific
project
under
you
know.