►
From YouTube: CNCF Storage WG - 2018-06-27
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
A
All
right:
well,
let's
kick
it
off
and
get
going
I'm,
not
sure
if
we're
gonna
get
too
much
more
than
this
today,
a
lot
of
huge
audience.
Nice
cozy
little
group.
Thank
you
all
for
joining
this
morning
on
the
agenda,
we've
got
a
couple
things
and
if
anybody
had
any
extra
topics
to
bring
up
that,
they
want
to
chat
about,
or
just
trying
to
literally
discuss,
feel
free
to
add
it
to
the
agenda.
A
I
asked
saw
a
few
weeks
ago
to
to
come
to
the
group
today
to
chat
about.
What's
going
on
with
with
CSI
I
think
we've
had
our
most
recent
release
is
0.3
and
looks
like
we're
chugging
steadily
forward
towards
getting
it
stabilized
in
kubernetes
and
possibly
a
1.0.
So
I
asked
sod
to
kind
of
chat
about
what's
the
latest
on
0.3,
so
hopefully
we'll
have
that
discussion,
and
hopefully
we
can
chat
about
other
things
after
that
that
people
may
have
questions
about
for
CSI.
A
B
For
those
who've
been
wondering.
Why
are
we
not
yet
1.0?
The
idea
was
that
we
get
the
spec
to
a
state
that
we're
happy
with
and
then
try
to
implement
it
and
that's
both,
as
you
know,
implement
CSI
drivers,
as
well
as
on
the
CEO
side
for
kubernetes
mezzo,
set
cetera
to
discover
any
issues
that
we
have
with
the
spec
used
that
to
revise
the
spec.
B
B
There
were
breaking
changes,
so
if
you
had
a
driver
written,
you
have
to
actually
go
in
and
update
it
between
0.2
and
0.3.
We've
tried
to
minimize
any
braking
changes
and
we've
basically
eliminated
them.
I
can
talk
about
some
of
the
changes
in
0.3,
so
the
big
things
that
went
in
were
one
was
the
snapshot
API.
B
The
snapshot
API
is
designed
to
basically
create
delete
and
list
snapshot
objects.
We
already
have
a
create
volume,
delete
volume,
and
this
was
following
very
similar
patterns.
You
can
take
a
look
at
the
PR
if
you're
curious
about
exactly
what
that
looks
like,
but
the
our
pcs
are
fairly
straightforward.
B
The
details
of
it,
of
course,
took
some
time
to
decide.
The
second
feature
was
topology
in
particular
availability
topology.
The
idea
here
is
that
a
particular
volume
may
not
be
equally
available
across
a
cluster
to
all
nodes,
and
we
want
some
way
to
be
able
to
express
that
when
we
provision
a
volume
to
be
able
to
influence
where
that
volume
is
going
to
be
available
as
well
as
after
the
volume
is
provisioned
be
able
to
be
able
to
understand
where
it
was
provisioned
and
use
that
information
to
do
intelligent
scheduling
on
the
CEO
side.
B
We
have
a
new
plug-in
capability,
called
accessibility
constraints.
If
you
support
it,
then
you
can
request
topology
or
you
can
have
optional
topology
requirements
on
the
create
volume.
Call.
These
topology
requirements
basically
act
as
constraints,
limiting
where
a
volume
can
be
accessed
from
note
that,
while
this
is
designed
to
allow
you
to
specify
things
like
region
zones
racks,
the
way
that
this
has
been
expressed
in
the
API
is
that
we
never
actually
refer
to
a
region
zone
rack.
B
Instead,
it's
an
opaque
key
value
where
the
key
can
be
whatever
you,
whatever
makes
sense
for
your
storage
system.
So
the
one
of
the
challenges
is:
how
does
the
co-discoverer,
what
the
keys
and
values
are
and
for
that?
What
we
did
is
extend
the
information
that
we
get
for
a
given
node
to
be
able
to
return
the
labels
that
should
be
applied
to
that
node.
So
if
you
look
for
get
node
get
info.
B
So
node
get
info
will
now
return
a
list
of
topology,
basically
labels
that
apply
to
the
node
and
then,
when
a
CEO
decides
that
it
wants
to
schedule
to
a
particular
node,
it
can
take
those
labels
and
send
them
back
in
on
the
create
volume
request
side
to
ensure
that
a
node
is
scheduled
there
and
then
on
the
response
for
create
volume.
You
will
get
the
list
of
topologies
that
that
volume
is
accessible
from
so
this
went
into
the
spec
in
0.3,
both
snapshots
and
topology.
B
On
the
kubernetes
side,
we
have
not
finished
integrating
with
this
behavior,
yet
we're
planning
to
do
that
for
this
coming
release
for
1.12
and
then
some
of
the
other
smaller
features
were
things
like.
We
have
no
get
ID,
which
allowed
us
to
retrieve
the
ID
of
a
node
as
understood
by
a
storage
system.
What
we
realized
with
the
topology
work
and
some
of
the
other
smaller
PRS
that
went
in,
was
that
there's
additional
information
for
a
node
that
we
want,
and
it's
not
just
ID,
so
we
expanded
this
call
to
note
get
info.
B
B
This
information
can
be
used
by
the
CEO
to
make
more
intelligent
scheduling
decisions
and
not
not
attached
to
many
workloads
to
a
given
node
that
of
a
given
volume
type.
So
those
were
the
big
changes
that
went
in
to
zero
point
three.
There
were
a
bunch
of
smaller
clarifications
and
corrections
that
we
did
for
the
most
part
again
between
zero
point,
two
and
zero
point.
Three
there
were
additive
changes,
nothing
breaking
so
your
zero
point
through
driver
should
be
compatible.
B
D
C
Because
I
think
that
that's
going
to
be
interesting
because
we're
seeing
we're
seeing
a
lot
more
people
deploy
larger
communities
clusters
but
kind
of
reserved
different
nodes
for
different
purposes.
And
is
that
kind
of
where
you're
you're
sort
of
seeing
the
topology
question
come
into
play
in
terms
of
sort
of
requests.
B
So
the
need
the
use
case
is
actually
vary
a
lot.
So
if
you
look
at
cloud
providers,
they're,
naturally
segmented
into
you-
know
generic
generally
zones
and
regions
and
the
storage
that
they
make
available
their
block
virtual
disk
storage
tends
to
not
be
available.
You
know
globally,
it's
usually
zonal,
and
today
we
have
no
way
to
be
able
to
express
that
in
the
CSI
spec,
so
that
was
a
big
gap
that
we
needed
to
fill.
So
that
was
a
big
driver
on
on-prem.
B
You
know
we
there's
all
sorts
of
different
segmentations
of
a
cluster
that
you
could
have
things
like
racks,
so
and
storage
systems
can
a
can
be
not
equally
available
to
all
the
notes
they
might
be
available
in
a
certain
rack,
a
certain
you
know,
subdivision
of
that
cluster.
That
was
another
driver
cluster
is
being
very
large.
B
B
Yeah,
so
we
want
to
get
to
1.0
right
around
when
the
CEOs
are
beginning
to
land,
their
GA
releases
of
CSI
for
kubernetes,
we're
targeting
q4,
possibly
slipping
into
q1,
so
based
just
on
that,
we
anticipate
CSI
going
1.0
by
end
of
year,
part
of
going
1.0
is
going
to
be
coming
up
with
things
like
certification
process
for
CSI
drivers.
That's
something
that
we
need
to
start
looking
into.
We
haven't.
B
We
have
a
sandy
testing
suite
that
you
know
if
you
have
a
CSI
driver,
you
can
run
this
test
set
of
unit
tests
against
your
driver
to
do
a
sanity
check
to
make
sure
that
it's
implementing
the
spec
correctly,
but
for
a
certification
suite,
we
want
to
expand
that
and
and
maybe
have
more
requirements
that
must
be
checked
off
beyond
that.
We
do
want
to
also
become
an
official
member
of
the
CMC
F.
Today
the
project
is
still
run
independently
and
not
officially
part
of
the
CNC
F.
B
We're
going
to
continue
to
expand
that
for
the
kubernetes
implementation,
for
example,
we're
going
to
try
to
implement
this
quarter,
support
for
ephemeral,
local
volume
so
so
far,
we've
supportive.
We
focused
mostly
on
remote
persistent
volumes,
and
we
also
want
to
use
the
aside
to
support
things
like
hey
I
want
to
inject.
You
know
some
identity
into
a
pod,
and
the
lifecycle
of
that
volume
is
the
lifecycle
of
the
pod.
I,
don't
have
an
attached
or
how
do
I
make
that
happen.
So
we're
gonna
focus
on
that
use
case.
B
B
Basically,
what
they
said
was
they're,
not
certain
yet
based
on
where
their
product
is
going
so
I
believe
docker
is
trying
to
be
a
Orchestrator
of
orchestrators
and
kubernetes
is
one
of
the
orchestrators
that
it
supports.
So
the
indication
they
gave
me
was
if
the
support
for
CSI
and
these
underlying
orchestrators,
like
kubernetes,
etc,
are
solid.
Then
they
don't
need
to
actually
go
and
implement
it
at
their
lair.
So
they're
doing
a
wait-and-see
kind
of
approach
to
see
if
they
actually
need
to
re-implement
this
at
their
lair
or
not,
is
do.
B
A
Excellent
updates,
thanks
so
much
for
jumping
on
I,
really
appreciate
that.
Thank
you.
Thank
you
very
much
for
your
attention
and
and
what
you
guys
have
done
for
the
CSI
project.
I
think
it's
very
important
for
all
SEOs
and
very
important
for
their
customers
using
cloud
natives.
So
it's
excellent
stuff.
Thank.
B
A
C
So,
just
to
recap,
the
white
paper:
that's
what
we're
trying
to
put
together
is
designed
to
or
the
goals
are
to
to
clarify
terminology
and
provide
some
examples
and
and
how
we
can.
How
provide
information
where,
realistically
an
end
user
would
be
able
to
compare
and
contrast,
two
different
technology
areas
which
regards
to
some
specific
attributes
of
the
system
like
availability
and
scalability,
and
consistency
and
performance
and
durability
in
those
sorts
of
things
and
I
spend
a
bit
of
time.
C
Well,
then,
the
more
I
thought
about
it,
the
more
I
realize
it.
Actually,
it's
it's
it's
less
about
the
data
interfaces
that
define
the
attributes
but
more
the
underlying
layers
within
that
storage
system
or
the
storage
service,
so
I'm
kind
of
proposing
that
we
that
we
break
this
down
into
into
an
unlike
with
some
of
this
into
the
into
the
document
at
the
moment,
do
you
guys
have
access
to
the
documents.
C
The
consistency
of
the
data
after
a
writer
and
update
or
delete
operation,
or
the
delays
that
that
can
happen
between
performing
those
operations
and
actually
getting
committed
to
the
to
the
volatile
menthol
of
that
store
and
then
also
things
like
durability
in
which,
which
includes
some
of
the
functions
of
data
protection
independency,
but
also
covers
areas
like
checksums
and
bit
rot
and
all
these
more
advanced
areas
which
which
probably
need
a
bit
more
defining
and
then
follow
that's
on.
If
we
look
in
at
the
next
page
with
the
data
access
interface.
C
So
the
interface
is
what
I've
tried
to
do
is
put
each
put
a
couple
of
sections
together
and
say
what
our
section
defines
and
what
the
influence
is.
So,
for
example,
that
they've
access
interface,
the
vines
have
the
data
is
stored
and
consumed
by
applications,
and
that
influences
the
interfaces
that
you
used
to
manage
a
provision
that
stuff
it
influences
things
like:
availability
in
terms
of
moving
at
the
advances
interface
or
getting
access
to
the
data
access
interface
between
nerds.
C
If
the
influences
certain
things
like
performance,
because
you
know
protocols
and
things
like
that-
affect
that-
and
it
doesn't
ruin
scalability
and
I've
kind
of
tried
to
group
these
into
two
sets
one
around
volumes
and
one
around
storage
services
that
you
access
through
some
sort
of
API
layer
and
so
volumes
covers
things
like
block
file
systems
and
shared
file
systems
and
application.
Aps
covers
things
like
object,
stores
and
key
value
stores
of
databases,
and
obviously
these
are
including,
but
not
limited,
to
kind
of
discussions
right
and
then,
after
that,
I
was
kind
of
thinking.
C
C
That's
actually
defined
by
the
backend
object
store,
and
then
you
get
into
even
more
complex
scenarios
where,
for
example,
you
know
you
could
have
and
you
could
have
a
file
system
like
cluster,
that's
providing
a
block
interface
which
which
you
know,
which
then
is
consumed
by
the
front,
end
file
system
interface
on
top
of
that
block
interface.
So
with
all
of
those
layers
in
place,
I
kind
of
try
to
limits
the
the
layers
that
we
kind
of
seen
in
normal
use,
so
starting
at
the
very
top
level.
C
There's
like
what
does
the
container
or
the
application
see
and
that
defines
how
the
data
at
the
interface
is
actually
consumed
by
the
container.
So
things
like
you
know,
it's
volume
namespace
in
the
networking
requires
there
is
an
Orchestrator
and
a
host
and
operating
system
level.
So
things
that's
defying.
C
And
there's
the
actual
storage
topology,
which
defines
the
architecture
of
the
actual
storage
system,
is
running,
so
we've
got
sort
of
a
couple
of
options.
There
we've
got
things
like
centralized
systems
or
distributed
systems
or
maybe
shy
these
systems
like
like
the
tests,
for
example,
and
then
there
are
there's
potentially
another
layer
which
happens
at
the
virtualization
or
or
or
hypervisor
or
perhaps
client
provider
layer
where
resources
are
either
accessed
directly
or
the
virtualization
layer,
provides
some
sort
of
mapping
or
pooling
or
chronic
disease
management
or
fail
over.
C
And
then
there
are
the
next
layers
sort
of
happens.
The
actual
things
are
protected
within
the
storage
system,
so
things
like
you
know
some
of
the
obvious
stuff
like
like
raids
and
marrying
and
replicas
and
erasure
coding,
but
we
can
sort
of
beef
that
up
as
well
and
then
there
are
probably
things
like
the
echo
services
which
get
applied.
That's
different
levels
within
the
stack
and
that
can
do
you
know
the
most
obvious
ones.
Are
things
like
replication
or
snapshots
which
again
can
happen
at
the
application
layer?
C
C
So
I
think
it's
worth
defining
what
what
those
kind
of
options
are
and
then
just
to
just
to
sort
of
completely
solve
where
the
date
actually
ends
up
sitting,
then
in
some
sort
of
physical
or
non-volatile
layer.
So
and
the
main
reason
for
including
this
is
because
it's
often
used
in
service
definitions
from
trying
providers
or
or
or
you
know,
products
which,
which
are
available
from
commercial
companies
or
Overton's
line
act,
where
you
know
we're
talking
about
in-memory,
caches
or
non-volatile
memory
or
SSD
layers
disk
and
those
sort
of
things
to
give.
C
A
A
In
the
document,
I
think
it
provides
some
information
about
just
a
general
storage
service
and
what
capabilities
or
how
you
expect
it
to
act,
and
what
you've
laid
out
here
is
that
it's
more
of
a
top-down
vision
that
you
know
you've
got
a
storage
service,
but
you
don't
know
what's
backing
it,
and
you
know
the
storage
services
capabilities
are
all
going
to
be
changed.
Based
on
how
the
storage
service
is
actually
I.
A
C
There
are
often
myths
about
oh
well
file
systems
are
slower
than
block
or
or
object
stores,
so
hurry
are
here
prior
latency
or
whatever
else,
but
but
actually
it
kind
of
does
depend
on
how
how
you're
accessing
an
object
or
what
its
protection
or
innovation
occurring.
It's
what
services
are
based
on
it,
whether
there's
a
little
balancers
with
it
is
you
know,
and
all
of
those
sorts
of
things.
C
A
Also
I
guess
tied
to
my
comment
and
like
what
you're
saying
here
too
as
well.
You
know
the
more
details
that
are
exposed
about
how
the
service
is
built,
like
think
of
the
less
cloudy
it
is
at
the
end
of
the
day,
because
you
don't
go
to
a
public
cloud
and
get
the
information
about
how
they're
there
sequel
services
built
in
the
backend.
A
A
That's
so
on
one
end,
I
think
it's
like
the
more
information
we
expose,
maybe
the
less
relevant
it
is
to
the
the
general
audience
who's
looking
to
go,
stand
up
an
applicator
build
an
application
that
relies
on
Cloud
Data
Services,
because
they
just
will
never
get
that
information
that
helps
them
understand
like
how
that
service
was
built.
But,
on
the
other
hand,
someone
who
is,
you
know,
looking
to
be
highly
dynamic
and
how
they
imagine
applications
and
they
do
have
their
own
storage
team.
A
C
So
I
kind
of
talked
about
that
too.
So,
if,
if
we're
limiting
the
landscape
to
just
cloud
services,
that's
probably
less
exciting
to
most
people,
because
a
number
of
people
are
are
coming
to
this
discussion
in
terms
of
you
know
different
projects,
for
example,
that
there
that
the
roles
are
looking
to
consume.
You
know
whether
it's
something
like
work
or
cluster
or
staff,
or
you
know,
perhaps
something
like
mini
or
the
tasks
or
corporally,
video,
or
course,
or
any
number
of
key
values
of
developing
sort
of
propose
to
the
chunk.
C
And
if,
if
we
need
to
kind
of
define
okay,
so
you
know
if
it
s
is
charted,
what
does
actually
sharded
mean?
Or
if
we
say
you
know
many
uses
the
ratio,
everything
will.
What
does
that
actually
mean?
And
why
would
you
want
to
use
it
so
so
kind
of
I
kind
of
came
at
this
room?
That's
the
finer
terminology,
and
then
we
can
use
that
to
define
the
products
and
services
without
having
to
sort
of
explodes
that
information
into
each
and
every
example.
I.
D
Sorry,
it
took
me
a
while
to
mute,
but
I
had
one
thought
that
you
prompted
me
to
think
of
Clint
when
you
got
into
the
idea
that
some
characteristics
mean
they're,
less
cloudy
and
in
a
way,
to
some
extent,
I
think
people
tend
to
pigeonhole
these
stateful
storage
solutions
into
just
categories
that
existed
in
the
legacy
pre
cloud
world,
you
know
putting
them
in
categories
of
relational
database
or
whatever,
but
I
think
it
might
be
valuable.
Since
you've
made
the
point
that
people
buy
these
by
service
level.
D
Agreements
to
just
inventory
the
potential
service
level
agreement
characteristics
that
you
ought
to
use
to
evaluate
a
solution.
You
know
like
how
many
iOS
can
it
do
per
second,
what
is
the
actual
guarantee
for
resiliency
in
terms
of
fault
tolerance
within
a
failure
domain?
The
backing
storage
is
ability
to
manage
replication
across
failure,
domains
including
geo
regions,
and
just
give
people
a
clue
as
to
what
the
different
accesses
are,
that
they
should
potentially
evaluate
a
cloud
storage
system.
C
Yeah,
absolutely
because
you
know
when
we
need
to
find
those
attributes,
then
there
are
all
sorts
of
things
that
kind
of
come
into
play
like,
for
example,
you
know
if
you're,
if
you're
using
say
an
active
active
database,
for
example
as
your
way
of
storing
systems,
then
perhaps
you
know
your
your
way
of
doing.
Availability
is
influenced
by
some
of
the
upper
layers
like
perhaps
there
might
be
a
load
balance,
it
might
be
an
ingress
controller.
A
Alex
I,
like
I,
don't
think
it's
a
good
update
and
a
good
direction.
I
know
that
we,
we
haven't
gotten
a
response
from
couple
weeks,
but
I've
been
worth
payin
and
going
off
the
back
end
and
or
just
really
gets
back
to
to
get
some
more
direction
before
we
dive
into
it
further.
But
I
I
think
it's
gonna.
A
It's
if
we
approach
this
from
the
top-down
perspective,
I
think
that
its
value,
it's
more
modern
and
more
valuable
and
more
oriented
towards
cloud
and
I,
think
that
you
know
if
the
white
paper
is
able
to
be
succinctly.
Pro
Qing
it
from
top
down
like
I
like
that
direction,
but
I'm
what
I'm
worried
about
is
like
just
having
too
much
information
and
too
much
to
discuss
in
the
white
paper
where
it
gets
watered
down,
or
it's
just
not
possible
to
to
get
it
done
in
a
reasonable
timeframe.
A
C
A
C
C
That's
just
a
way
of
defining
the
terminology
perhapses
and
it
could
be,
you
know
structured
like
a
glossary
or
an
appendix
or
something
if
we
needs
to
sort
of
show
the
the
product
examples.
First
I
was
just
kind
of
getting
really
confused
when
trying
to
work
through
the
product
examples
and
trying
to
figure
out
how
to
have
talked
about
them.
Without
talking
about
all
the
different
layers
can
influence.
What
that
thing
can
do.
A
C
A
Does
anybody
have
anything
else
they
wanted
to
chat
about
I'm,
also
interested
in
an
other
topics
that
folks
may
want
to
hear
about.
I
did
have
the
estimate
sni
a
group
reach
out
I
think
that
they
possibly
wanted
to
to
get
a
spot
to
chat
about
redfish.
So
that
might
be
one.
That's
interesting!
That's
coming
up
I
know,
do
I,
see
you
out
there
I,
don't
know
if
port
works,
sir
or
Alex
likes
or
Joe
s.
A
E
A
I
think
there's
a
few
things.
One
I
think
you
know
we're
all
concerned
working
together
on
other
si,
si
updates
and
implementations
and
things
to
help
si
si.
So
I
might
be
interesting
for
the
storage
group,
but
I
think
another
thing
is,
you
know
where's
where
support
works
at
we're
storage
is
at
you
know.
What
are
we
seeing
in
the
industry?
What
are
what
are
your
customers
actually
really
interesting
point
was
storage
and
cloud
native.