►
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: CNCF Storage WG - Alex Chircop, StorageOS & Quinton Hoole, Huawei
The CNCF Storage Working Group 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. We seek to align the community on common understanding, terminology, classifications and use cases. In this intro session 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.
To learn more: https://sched.co/GrcZ
A
So
this
session
is
all
about
the
the
CNC
f
storage
working
group,
so
the
CNC
F
has
a
number
of
different
working
groups
which
cover
different
technology
areas,
things
like
security
and
C,
ICD
and
server
list
etc,
and
this
is
about
the
the
storage
working
group
and
we're
going
to
talk
a
little
bit
about
the
things
that
we
that
we
cover
in
a
storage
working
group
and,
if
you're
interested
in
participating,
how
to
participate
and
and
how
to
get
involved.
Because
we
could.
A
A
A
So
the
reason
we're
doing
this
is
because
storage
is
is
critical
to
a
lot
of
use
cases.
When
we're
discussing
native
I'm
going
to
come
out
and
say
this,
there
is
no
such
thing
as
a
stateless
architecture.
At
some
point,
every
application
historian
state
somewhere,
whether
that's
a
file
system
or
whether
that's
an
external
service
that
that
it's
depending
on
we
had
a
we
had
a
very
good.
A
A
So
a
lot
of
the
technologies
that
that
have
been
deployed
in
Clara
natives,
such
as
containers,
are
all
about
making
workloads,
portable
and
making
them
easier
to
run
in
platform
agnostic
right
and
in
order
for
containers
and
workloads
to
be
portable.
They
also
needs
the
storage
environments
to
be
portable
and
they
also
need
access
to
their
data.
A
The
global
storage
in
the
CN
CF
is
to
enable
striving
a
thriving
ecosystem
right,
so
whether
that
whether
this
is
open
source
projects,
whether
it's
discussion
of
services,
whether
it's
discussion
of
interactions
and
integrations
between
different
systems-
these
are
all
key.
So
we
aim
to
be
both
vendor
and
platform
neutral,
and
this
is
why
you'll
sort
of
see
client
providers
as
well
as
storage
vendors,
as
well
as
individual
maintainer
zuv
particular
projects
attend
these
meetings
and
this
is
all
and
to
ensure
interoperability
with
with
a
broader
set
of
applications.
A
So
so
the
mandates
for
the
storage
working
group
is
primarily
to
clarify
the
terminology
and
the
landscape,
because
storage
is
quite
a
complex
environment,
there
are
lots
of
moving
parts.
We
look
at
storage
in
two
primary
buckets.
There
are
there's,
there's
a
storage,
that's
related
to
volumes,
which
is
which
is
possibly
a
little
bit
more
maturity,
understood,
but
there's
obviously,
storage
which
is
accessible
through
api's,
so
things
like
object,
stores,
key
value.
Storage
databases
are
all
are
all
catalyst
storage.
As
far
as
the
storage
working
group
is
concerned.
A
So
we're
looking
to
understand
these
terminologies
we're
looking
to
understand
how
the
automation
works,
how
things
are
integrated
in
the
various
landscapes
and
understand
how
the
different
implementations
of
these
solutions
actually
affect,
how
the
storage
is
consumed
in
your
applications.
So
one
of
the
we've
been
working
on
a
we've,
been
working
on
a
white
paper
and
we've
been
trying
to
capture
a
lot
of
this
information
to
cover
the
different
attributes
and
the
different
and
the
different
types
of
systems
and
the
different
types
of
capabilities
out
there.
The
other
thing
we
do
is
we've.
A
Instead,
things
like
rook,
which
which
got
accepted
as
a
sandbox
project
earlier
on
in
the
year
and
got
voted
to
to
be
promoted
as
an
incubation
project
for
for
the
CNC
F
a
couple
of
months
now,
back
and
rook
provides
a
framework
and
a
set
of
tools
to
old
and
to
help
abstract
different
storage
system,
starting
with
SEF.
But
it's
adding
support
for
other
things.
A
Like,
like
mini
oh
and
a
number
of
other
projects,
projects
like
like
Vitesse,
which
talks
with
which
is
a
very
large-scale,
sharded,
sequel
implementation,
which
which
again
there's
a
number
of
Stein's
in
the
in
the
sponsor
boots,
which
can
which
can
talk
about
that
and
other
projects
like
I,
never
know
how
to
pronounce
this
ti.
Kv,
which
is,
which
is
a
I,
think
titanium
key
value
store,
which
is
which
is
a
distributed.
A
Key-Value
store
and
provides
extreme
scalability
and
is
an
is
an
alternative
to
to
an
alternative,
key
value
store
which
can
be
integrated
into
into
databases.
And,
apart
from
that
things
like
open,
EBS
and
open
STS,
which
which
are
which
are
which
are
very
interesting
projects
and
help
shape
the
contents
that
were
that
we're
providing,
as
well
as
providing
inputs
to
the
broader
CN
CF
community.
A
A
So
the
storage
sake,
as
it
stands
days
is
cribben.
Eighties
is
a
criminai
things
sake
and
they're,
and
they
work
on
criminate.
These
specific
projects,
the
CN
CF
storage
working
group
is
is,
is
a
CN
CF
initiative
and
it's
and
it's
and
it's
broader
than
just
kubernetes.
It
covers
technologies
which
which
are
generically
cloud
native
and
maybe
storage
systems.
That's
that's
Orient's
specifically
related
to
kubernetes.
B
B
One
and
I
also
ran
a
lot
of
the
big
systems
at
Google
before
that
and
started
easy
to
at
Amazon
way
back
in
the
mid-2000s
I
guess
so
I'm
currently
on
the
technical,
Oversight
Committee
of
the
CN
CF,
and
one
of
the
things
we
identified
fairly
early
on
was
that
you
know
storage
is
a
vast
landscape
and
there
are
many
complicated
and
competing
ways
of
solving
these
problems
related
to
storing
things,
particularly
in
cloud
native,
and
we
really
wanted
to
just
get.
Everyone
together.
B
Agree
on
a
common
set
of
terminology
agree
on
a
common
set
of
understandings
of
how
these
things
plug
together
in
in
a
way
that
we
could
communicate
to
the
public
so
that
it
looked
less
like
a
spaghetti
mesh
of
competing
storage,
vendors
and
more,
like
some
coherent
ecosystem,
that
we
could
then
start
having
meaningful
and
sensible
discussions
about.
So
that
was
you
know
how
I
got
involved
in
storage
working
group
I'm.
A
B
Person's
not
not
wise
enough.
Ok,
so
anyway,
I'll
stop
rambling.
Now,
basically,
this
is
just
a
prelude
to
the
next
part
of
the
talk,
which
is
so
we
said
about
writing
a
white
paper
and
what
we
wanted
to
do
was
essentially
present
people
with
something
digestible
that
they
could
use
to
understand.
So,
given
a
product,
you
know,
where
is
what
is
this
product
and
can
we,
you
know
at
least
slotted
into
a
diagram
and
how
do
I
figure
out
the
pros
and
cons
of
this
product
versus
some
other
product?
Is
it
in
the
same
space?
B
And
if
so,
how
does
it
differ?
And
what
are
the
metrics
that
we
can
use
to
understand
where
those
differences
might
lie,
so
so
yeah
definition
of
attributes
of
a
storage
system?
So
what
does
it
mean
to
be
highly
available?
What
does
it
mean
to
be
highly
scalable?
What
does
it
mean
to
be
highly
durable?
You
know.
B
Sometimes
these
words
are
assumed
to
have
particular
meanings,
but
often
when
you
dive
under
the
hood,
this
there's
way
more
detail
there
than
one
might
think
and
in
some
cases
a
lot
of
misunderstanding
about
even
basic
terms
and
the
one
I
often
pull
out
is
consistency
and
I'll
use
my
little
audience.
Interaction
trick
that
I
used
on
Monday
apologies
to
those
of
you
with
storage
day.
So
how
many
of
you
have
heard
of
the
cap
theorem?
Does
anyone
know
what
the
cap
theorem
is?
B
Okay,
excellent,
so
everybody
knows
about
the
cap
theorem
give
or
take,
and
what
is
the
C
and
cap
stand
for
consistency,
excellence,
everyone's
nodding
and
saying
consistency,
and
how
many
of
you
have
heard
of
acid
databases,
lots
of
hands?
Everyone
knows
about
acid
is
and
what
is
the
C
and
acid
stand
for
consistency
right
and
others
the
same
consistency
in
cap
and
acid?
B
So
there
are
some
shaking
heads
I
guess
it
was
a
leading
question,
they're
completely
different
kinds
of
consistency,
and
so
people
who
kind
of
think
they
know
what
consistency
means
and-
and
this
is
not
a
criticism.
I
was
in
this
camp
not
very
long
ago.
Someone
pointed
out
to
me
that,
in
fact,
this
there's
like
a
whole
menagerie
of
consistency,
and
if
you
think
that
you
get
to
choose
between
consistent
or
available
or
partition,
tolerant,
it's
it's
way
more
complicated
than
that.
So
just
a
you
know
to
illustrate
why
it's
useful
to
have
common
terminology.
B
The
other
thing
that
is
somewhat
not
always
understood
and
and
I
think
we
can
perhaps
blame
some
of
the
overzealous
marketing
and
sales
people
around
exactly
what
various
different
projects
and
products
do.
So
you
know
this
concept
of
a
storage
system
and
you
buy
one
and
it
stores
your
stuff,
for
you
turns
out
that
there's
a
whole
variety
of
pieces
that
you
have
to
fit
together
before
you
actually
have
a
useful
thing,
and,
and
not
all
of
the
projects
provide
all
of
those
pieces.
B
So
it's
it's
important
to
to
just
be
able
to
understand
how
they
all
fit
together.
Data
access
interfaces.
You
know,
sometimes
people
talk
about
a
block,
store
or
a
file
system
or
a
object,
an
object,
store
or
a
key
value
store
to
some
extent.
Those
define
an
API
or
a
data
access
interface,
but
they
don't
actually
define
the
properties
of
the
system.
So
there
are
numerous
examples
where
you
know.
B
S3
is
an
object
store
and
it
has
a
particular
interface
and
implicit
in
s3's
product
offering
is
that
it's
very
highly
durable
and
that
your
data
gets
replicated
across
multiple
geographies
and
that
it
will
never
go
away
and
implicit,
perhaps
less
well
spoken
about,
is
that
the
latency
is
fairly
high.
It's
designed
specifically,
for
you,
know,
fairly
large
objects,
things
like
videos
and
backups
and
photographs,
and
things
and-
and
so
it
has
a
and
it
has
a
cost
model
associated
with
it.
B
So
it's
it's
worth
just
making
that
distinction,
and
then
we
can
yeah
we're
going
to
talk
more
about
some
of
the
other
areas
too
I'm
not
going
to
go
into
any
of
the
detail.
We
have
a
deep
dive
session.
Is
it
at
4:30
today,
Alex
I
think
so?
Ok,
3:45,
where
we
will
go
into
much
more
detail
about
the
contents
of
this
paper,
but
it's
we
just
thought.
We
would
tell
you
about
the
fact
that
it
is
one
of
the
things
we
working
on.
B
We
had
a
bunch
of
authors,
some
of
them
experts
in
particular
categories,
as
which
was
very
useful,
Kings,
been
very
involved
in
open,
STS
and
CSI
and
other
areas
you
may
or
may
not
recognize
young
Lee.
Who
actually
was
one
of
the
initial
implementers
of
Etsy
D.
He
was
on
stage
the
other
day,
so
we
figured
if
we
want
to
have
someone
tell
us
about
key
valleys
doors.
We
probably
do
worse
than
him
and
and
several
other
people
with
lots
and
lots
of
experience
in
various
areas.
So
hopefully
we
are
reasonable
coverage.
B
So
where
do
we
go
from
here?
So
this
white
paper
is
is
largely
done.
It's
been
out
and
available
for
comment
for
a
couple
of
months
now
since
before
Shanghai,
just
over
a
month,
so
I
think
we're
going
to
sort
of
declare
that
done.
Working
groups
in
the
CNC
F
world
have
a
finite
life
span
and
they
set
out
to
do
a
particular
thing,
and
this
particular
thing
has
mostly
been
accomplished.
So
the
question
is:
do
we
reformulate?
You
know
since
essentially
set
another
set
of
things.
B
This
working
group
should
do
next
or
do
we
dissolve
and
say
the
job
is
done.
We've
had
a
few
suggestions
as
to
what
the
next
goal
should
be.
One
of
them
would
be
to
get
a
deep
understanding
of
a
set
of
particular
use
cases
so
great
to
dive
into
understanding.
You
know
where
Netflix
doors,
all
its
videos
and
how
they
all
work
and
and
where
you
know
how
various
you
know,
high-profile
big
storage
solution,
big
storage
implementations
have
actually
be
done
pros
and
cons
problems
they
faced.
B
You
know
things
that
were
successful,
so
I
think
that
would
be
useful.
The
CN
CF
has
also
identified
that
the
the
technical
Oversight
Committee
on
which
I
serve
it's
only
nine
people.
Most
of
them
are,
you
know,
very
experienced
and
and
fairly
senior
people
in
in
big
companies,
not
while
not
all
big
companies,
but
they're,
certainly
busy
people,
and
they
don't
necessarily
have
the
band
with
to
spend
as
much
time
as
was
required
with
all
of
the
project
as
they
expand.
We
currently
have
more
than
30
CNCs
projects,
I
think
all
together
and
that's
growing.
B
You
know
rapidly,
it's
not
unimaginable
that
we
might
have
a
hundred
in
a
year's
time,
and
nine
people
spread
across
a
hundred
projects
is
just
too
thin.
So
that's
the
one
area.
The
other
area
is
that
you
know
there
are
specific
I
mean
that
this
landscape
is
pretty
broad,
and
this
goes
beyond
storage,
but
there
are
many
many
very
specialized
areas
and
and
nine
people
cannot
be
experts
and
highly
specialized
experts
on
on
all
of
those
areas.
B
So
we're
looking
at
transforming
what
is
currently
a
working
group
into
a
special
interest
group
and
that
would
be
responsible
for
all
of
the
projects.
Storage,
related
projects
in
the
CN
CF,
as
well
as
evaluating
and
advising
the
TRC
on
future
storage
related
projects.
So
that
might
be
something
people
might
want
to
get
involved
in.
B
B
Also,
a
bunch
of
other
presentations
still
coming
up
that
you
might
be
interested
in
Alex
and
I
are
doing
another
one
of
these
in
much
more
detail
later
today
and
then
I
went
to
read
through
all
of
them,
but
there
are
several
interesting
talks
you
might
want
to
attend.
You
can
look
them
up
in
the
schedule
and
with
no
further
ado,
let's
open
up
the
floor
to
questions
discussions.
We
have
a
good
few
minutes,
left,
I,
guess
ten,
so
far
away.
D
D
B
That's
a
very
good
question
and
I
think
there
are
I
definitely
think
there
are
cases
for
backups
and
restores
I've
seen
enough
of
them,
even
in
in
cloud
native
storage,
where,
depending
on
your
level
of
paranoia
or
your
cost
structure,
they
make
sense.
So
so
I
can
give
you
a
good
example.
I,
don't
think
any
of
this
is
proprietary
knowledge,
so
hopefully
it's
okay,
but
you
can
imagine
behind
us
something
like
EBS
you,
you
write
to
a
block
store.
There
are
multiple
copies
of
that
block,
store
that
block
written
across
different
physical
machines.
B
If
any
physical
machine
or
drive
dies,
you
still
have
copies,
they
get
re,
replicated
everything.
However,
all
of
those
are
in
a
single
data
center.
So
if
that
data
center
burns
to
the
ground,
your
data
is
gone
and,
secondly,
to
you
know,
multiple
drives
failing
at
the
same
time
is
not
unheard
of.
You
know,
especially
if
they're
the
same
manufacturer
drive
installed
at
the
same
time.
Guess
what
if
you
have
a
mean
time
to
failure
of
two
years?
B
There's
a
there's
a
big
bump
at
about
two
years
and
if,
if
you
fail
one
drive
and
before
you've
managed
to
copy
all
the
contents
to
another
drive
that
one
it
fails,
you
also
are
not
in
a
good
place
and
besides
that
software
rollouts
fail.
So
I
was
at
Amazon
when
we
managed
to
corrupt
a
large
number
of
disks
through
a
software
error.
And
so
the
answer
was
go
back
to
your
backups.
Please
we
gave
you
a
very
good
snapshot
facility
for
snapshot
into
s3
back
in
the
day,
and
this
is
ten
years
ago.
B
So
please
excuse
me
if
any
of
this
data
is
out
of
date,
but
but
there's
a
good
example.
Etsy
D
is
another
example
where
you
have
multiple
Etsy
de
replicas.
Each
one
of
them
has
a
disk
behind
it
and
in
theory,
they're
all
replicated
and
redundant,
and
you
can't
lose
your
HDD
store.
But
you
do
you
know
people
upgraded
CD
and
the
store
gets
corrupted.
You
have
to
restore
from
backups
I
think
there
are
use
cases
for
both
yeah.
A
And
and
just
to
to
sort
of
add
to
dance,
it's
a
lot
of
the
storage
systems
provides
capabilities
to
protect
your
data,
whether
it's
you
know
through
penalties
or
copies
of
the
data
or
snapshots
or
replicas,
etc,
but
that
doesn't
protect
you
from
human
error
when
somebody
deletes
something
by
mistake
or
from
a
software
park
when
it
goes
and
corrupts
off
your
records
in
your
system,
or
indeed
say
a
database
corruption
or
something
like
that.
So
there
are
always
going
to
be
things
where,
where
a
backup
is
still
it's
still
critical,
a.
B
B
F
Right
so
for
in
kubernetes
right
now
we
actually
we
are.
We
just
added
a
snapshot,
support
in
kubernetes
and
CSI.
So
with
that
you
can
based
on
that
and
a
beauty
or
a
backup
and
restore
solutions.
So
right
now
we
have
just
added
the
basic
building
block
volume
snapshot,
support
right.
So
next
step
is,
we
are
going
to
add
the
execution
hook
so
to
make
sure
that
the
snapshot
is
a
consistent.
F
So
that's
the
something
then
other
applications
can
be
with.
On
top
of
that,
so
one
thing
we
have
not
made
decision.
Yes,
whether
we
should
do
this
work
within
six
storage
or
we
should
do
part
of
this
work
like
I'd,
like
the
ecosystem
beaut.
Those
applications
like
the
something
we
are
discussing,
yes,
Group
snapshot
set.
Allow
you
to
actually
create
a
snapshot
of
a
group
of
volumes
that
belongs
to
a
application.
So
we
did
discuss
about
that.
F
G
H
B
B
H
Okay
and
on
that,
with
that
white
paper
and
with
the
focus
of
the
work
group
and
the
sig
is
the
is
like
the
primary
goals
of
taking
of
the
different
storage
solutions
that
are
going
to
be
available
and
just
trying
to
categorize
them
and
the
different
types
like
you
were
saying.
We
have
your
key
value
store.
You
have
your
optic
stores
stuff
like
that,
and
then
kind
of
building
a
an
acceptance
criteria
within
that
group
is
that
what
the
goal
is
I.
B
Don't
think
we're
really
in
the
business
of
developing
acceptance
criteria,
I
think
what
we
really
are
in
the
business
of
is
explaining
things
to
people
and
making
it
possible
to
actually
have
reasonable
discussions.
So
I
think
saying
that
you
can't
call
yourself
a
key
value
store
if
you
don't
provide
consensus,
it's
maybe
not
a
useful
thing
to
do.
What
what
we
would
prefer
to
do
is
say
that
there
are
key
value
stores,
some
of
them
provide
consensus.
B
And
usually
its
pros
and
cons,
you
know
these
consensus
is
very
useful
if
you
need
high
availability
and
you
don't
want
to
lose
your
data,
but
it's
high
latency
and
it
has
bottlenecks
through
the
master.
So
don't
be
surprised
when
you
run
into
those
things
when
you
use
those
kind
of
key
value
stores
and
use
them
for
things
that
they're
designed
to
be
used
for
not
for
something
else.
Yeah
I.
C
A
G
A
Various
layers
in
a
storage
system,
like
things
like
a
thinks
of
protection
and
the
topologies
of
the
different
storage
systems
and
that
sort
of
thing,
as
well
as
the
orchestration
and
the
management
interfaces.
So
things
like
CSI
the
different
interfaces,
whether
it's
native
drivers
or
say
that
the
the
docker
driver
and
other
similar
technologies,
as
well
as
other
frameworks
for
example,
which
are
which
are
cropping
up
like
the
rook
project,
which
which
helps,
for
example,
the
automation
of
deployment
of
different
storage
systems.
For
example.
E
A
B
B
Is
but
there's
actually
quite
a
lot
of
it's?
It's
not
really
40
pages,
it's
more
like
25,
because
there's
a
lot
of
white
space
and
stuff,
but
but
I
think
we
tried
to
at
least
you
know,
structure
the
landscape
so
that
you
could
understand
where
these
different
things
fit
in
and
that
they
exist
and
provide
links
to
further
detail.
You
know
we
certainly
don't
go
into
every
single
erasure,
coding,
algorithm
and
all
of
the
detail
there,
but
we
do
mention
that
it
exists.
B
That's
a
very
good
question,
so
we
have
bi-weekly
meetings.
I
think
we
have
the
detail
here
so
twice
a
month
on
Wednesday
we
have
a
meeting.
There
is
a
mailing
list
which
you
can
subscribe
to
send
messages
to
if
you
want
to
communicate
with
other
people,
similarly
interested
in
storage-
and
you
can
also
go
back
through
the
archived
minutes
and
videos
of
these
meetings.
B
D
A
So
that's,
rather
than
trying
to
shape
your
application
around
a
fixed
storage
solution.
You
can
actually
pick
a
storage
solution,
actually
is
appropriate
for
your
application
news
cases
and
discuss
how
you
can
interface
with
those
solutions
in
orchestrated
environments
like
with
kubernetes
or
say,
containerized
workloads,
for
example,.
B
Yeah,
it
just
had
one
one
more
comment:
to
add
that
it
was
quite
interesting
so
having
been
involved
right
from
the
beginning
of
cloud
computing.
Basically,
there's
been
this
kind
of
cycle
which
is
interesting
to
follow.
So
in
the
early
days
when
we
provided
people
of
virtual
machines,
we
said
you
can
pay
by
the
hour
and
they're,
not
very
reliable.
You
know
the
machines
crash,
it's
commodity
hardware.
B
You
have
contention,
because
you
have
more
than
one
virtual
machine
on
a
per
disk
or
per
machine,
and
so
they
are
useful
for
some
things,
but
they're,
not
the
same
local
disks
that
you
used
to
have
on
your
server
in
the
corner.
And
similarly,
if
you
have,
you
know
a
hundred
million
virtual
machines
in
a
public
cloud
service,
you
cannot
have
them
all
hit
your
NetApp
server
at
the
back
of
the
room
because
things
ain't,
gonna,
work
so
good.
So
therefore,
you
end
up
with
other
solutions
that
perhaps
address
some
of
those
issues.
B
So
so
we
had
to
take
people
from
where
they
were
at
the
time
to
just
educate
them
about
some
of
the
limitations
of
the
traditional
ways.
They
did
things
and
encouraged
them
to
look
at
alternatives.
I
think
the
pendulum
is
almost
swung.
The
other
way
now
and
now
you've
got
all
these.
You
know
cloud
native
stores
which
which
have
a
bunch
of
limitations
and
unbound
size
of
their
own,
but
everyone's
like
we
have
to
use
these
things
on
the
far
end
of
the
cloud
native
spectrum,
because
all
the
other
stuff
is
rubbish.
B
So
maybe
we
we
sort
of
did
our
job
too
well
in
the
early
days,
and
we
need
to
come
back
to
I
think
some
semblance
of
sensibility
in
the
middle
of
that
which
is,
we
have
now
many
more
options
than
we
had
15
years
ago.
They
all
have
use
cases
where
they
are
appropriate
and
use
cases
where
they're
not
and
have
people
able
to
make
those
decisions
themselves.
F
I
This
near
the
storage
networking
industry
association,
because
I
think
what
I'm
trying
to
understand
is
there
is
the
team
that
is
dealing
with
the
actual
development
of
the
standard,
like
the
storage
sig
in
the
CSI
team,
and
then
there
is
also
some
kind
of
an
industry-wide,
a
group
that
works
on
their
overall
storage
directions
and
ideas
within
sneer
and
and
and
this
group
is
kind
of
somewhere
in
the
bit
in
between
I'm
trying
to
understand
what
what's
the
goal.
Yeah.
B
B
We
have
members
who
are
build
projects
and
those
projects
want
to
know
some
of
this
information
and
want
to
be
able
to
work
together,
and
then
we
have
consumers
and
consumers
basically
want
to
know
how
to
use
cloud
native
software
provided
by
the
CN
CF,
and
so
those
are
our
two
customers
and
you
know,
there's
obviously
interactions
our
customers
want
to
know
how
to
plug
their.
You
know
vendor
XYZ
storage
into
their
application.