►
From YouTube: CNCF Storage WG Call 2017-11-09
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
B
C
E
F
B
Officially,
at
poor
personalities,
you're
like
in
the
in
the
conference
trims.
F
B
C
C
No
problem
at
all
just
a
lot
you
guys
could
make
it
I
know
I'm
just
kind
of
a
last
minute
meeting,
and
you
know
I
think
that
having
our
storage
working
group
meetings
for
your,
what
about
with
that
six
or
seven
of
them
I'm
thinking
three
we've
been
stuck
on
this
concept
of
getting
past.
What
is
cloud
made?
Storage,
so
I
figure?
It
takes
some
some
attack,
some
meetings
outside
of
the
normal
cycle
just
to
hammer
some
of
this
out
get
some
agreement
move
forward.
D
Yeah,
it's
a
good
question:
I
mean
the
definitional.
Things
are
hard
because
everybody
has
their
own
perspective
and
I.
Think
Tim's
perspective
is,
you
know
a
valid
one.
It
much
different
from
I
think
the
perspective
of
a
lot
of
people
in
this
room
coming
from
coming
from
a
different
background,
so
I,
honestly
I,
don't
I,
don't
know
where
to
start
Clint
because
it's
it's.
D
B
B
B
D
B
B
Cloud
native
to
write
a
plug-in
storage
from
all
the
way
up
from
cloud
native
computer,
which
I
think
is
that
is
not
controversial,
and
this
came
out
of
directly
out
of
the
charter
documents
right.
So
so,
let's
start
there
cool
so
so
fly
native
computing
is,
you
know
essentially
distributed
systems
that
have
the
following
properties:
they're
packaged
in
containers,
they're
dynamically
managed
and
they're
micro
serve
service-oriented.
That's
the
definition,
that's
on
the
CN
CF
charter.
So
let's
start
with
that
and
then
now,
let's
introduce
state
stateful
stateless.
A
B
But
you
know
it's
it's
so
so
so
again,
starting
from
cloud
native
computing
and
the
notion
of
micro
services
and
the
notion
of
dynamically
managing
container
packaged
I'm
introducing
one
definition
here.
It
says:
you're,
stateless
you're,
a
stateless
micro
service.
If
you
don't
manage
stayed
beyond
a
request
session
or
transaction
the
word,
we
can
wordsmith
all
of
all
of
this,
but
let
me
walk
through
it
and
then
and
then
we
could
talk
through
so
so.
Therefore,
stateful
is
services
that
state
beyond
what
is.
A
F
B
B
G
B
Then
then,
you
could
look
at
this
and
say:
I
can
you
know
I
have
stateless
services,
one
that
don't
have
state
and
one
that
are
stateful
this
like
this
diagram
and
they
can
both
run
on
the
same
cloud
native
environments
or
there
is
a
class
of
stateful
services
that
could
also
run
outside
of
the
cloud
native
environment.
So
let's
just
call
those
external
stateful
services
and
some
of
these
external
suitable
services
could
be
consumed
by
other
stateless
services
or
consumed
by
the
cloud
native
environment
itself,
their
external
they
manage
state.
C
B
B
C
Can
I
be
the
devil's
advocate?
Yes,
you
know
if
you,
if
you
do
something
pretty
easy,
you
go
to
GCE
storage
yeah,
not
or
cloud
storage,
or
something
like
that
like
it
doesn't
refer
to
volumes
or
block
storage.
If
you
do
the
same
thing
in
AWS
and
you
look
at
how
they
classify
the
different
services
other
ec2,
you
know
it
doesn't
refer,
ABS,
isn't
the
only
storage.
C
C
One
of
the
big
things
we've
been
kind
of
dealing
with
is
the
plot
of
native
storage.
I've
got
very
high
level
and
I
think
that
some
people
are
gonna,
say
yeah,
it's
falling,
it's
like.
If
you
have
a
storage
background
like
I,
do
I
have
a
heavy
storage
background
in
my
tendency
is
to
set
a
personal
net
worth
compute
or
storage
like
that
little
level
cinetic
like
that's
just
what
we
know
it
by,
but
I
think
the
devil's
advocate,
or
at
least
the
progressive
side
would
say:
hey
storage,
just
captures
more
stuff
nowadays
and.
B
C
B
D
B
Yeah
exactly
right
and,
and
you
know
there
is
no
science
behind
us
honestly,
it's
some
level,
it's
it's.
What
would
resonate
with
people
and
how
we
define
it.
I
realize
that
you
know
with
every
definition,
every
terminology
terms.
You
know
there
are
many
ways
you
can
look
at
it,
but
but
the
idea
is
to
put
something
together
that
we
could
maybe
a
review
with
others.
If
we
can,
if
we
can
arrive
at
consensus
and
I,
think
we
have
a
chance
of
getting
others
to
mind.
B
I
think
if
I
can
soften
him
up
with
you
like
before
before
the
discussion
next
week,
okay,
so
it's
just
moving
on
so
you
know,
storage
services
are
essentially
stateful
services
that
expose
volumes
and
volumes
come
in
different
shapes
and
sizes
and
I
won't
even
get
into
you
know.
Shared
volumes,
snapshots
and
I
mean
they.
They
vary
a
lot,
but
let's
just
start
with
story
services
that
are
one
that
exposed
volumes
sure.
So
then
the
next
definition
would
be
well.
Imagine
now
we're
going
to
talk
about
storage
interfaces.
B
Yeah
and
then
it
let's
talk
about
local
volumes,
local
volumes
are
volumes
and
they're,
but
there
was
attached
to
a
node
and
are
not
provided
by
a
storage
service.
So
I
think
there
there
is
no
service
behind
a
local
volume
in
this
definition,
and
we
should
I
know,
there's
a
lot
of
discussion
about
local
volumes
and
storage.
So,
even
though
that
they
are
they're
typically
orchestrated
and
exposed
by
it
and
container
a
cloud
native
environment,
they
are
not
provided
by
a
storage
service
using
this
definition,
okay,
and
so
somehow
we
have
to
make
that
clearer.
B
So
now
we
arrive
at
what
is
cloud
native
storage,
so
I'd
argue
giving
that
definitions
here.
The
chain
of
definitions,
that
cloud
native
storage
is
a
class
of
storage
services
that
have
the
following
properties:
they
expose
standard
storage
interfaces.
This
is
the
interoperable
beam
there.
It
can
be
dynamically
provisioned.
The
volume
suite
dynamically
provisioned
and
obviously
they're
scalable
and
reliable.
B
They
all
defer,
they
all
vary,
but
they
are
all
storage
services
and
that
will
talk
common
interfaces
to
and
commit
and
can
dynamically
provisioned
volumes
now,
that's,
not
the
it's,
not
the
universe
of
all
stateful
applications
or
services.
This
is
doesn't
include
key
value
stores,
everything
but
I
think
that's
actually,
quite
honestly,
one
beyond
the
scope
of
this
group
and
to
these
services
here
are
foundational
for
the
other
services
to
build
other
services.
C
D
C
C
Yeah
I
mean
so
I
think
that,
like
you're
telling
me.
D
C
D
One
question
I
have
is
so
obviously
there
are
differences
between
compute
and
storage,
but
if
I
look
at
kind
of
so
I
think
we
all
understand
that
this
is
not
an
academic
exercise
where
truth
is
the
ultimate
arbiter,
but
rather
a
political
exercise
right,
so
something
that
enough
people
can
agree
with
that
it
becomes.
D
You
know
cloud
native
storage
being
packaged
at
itself
as
containers
and
being
able
to
be
managed
with
the
same
management
tool
chain
as
the
rest
of
the
application.
So
so
I
I'll
pick
a
little
bit
on
EMC
on
plan,
and
this
is
now
me
channeling
tone,
so
so
yo
Rex
ray
has
a
driver
for
D
max
D
max
is,
you
know
very
may
or
may
be
it
doesn't
I,
let's
assume
that
it
does
so
so
there
is
a
very
like
unquestionably
enterprise-class,
reliable,
highly
performant
storage
system
that
people
are
running
mission-critical
workflows
on
today.
D
You
know
if
you
can
dynamically
provision
a
volume
on
top
of
that,
and
you
know
it's
scalable
and
reliable
and
has
a
standard
storage,
interface,
I.
Think
I,
think
one
thing
that
Tim
would
say
is:
does
that
make
it
cloud
native
storage
and
so
I
I?
Don't
I,
don't
know
that
it
does
certainly
being
able
to
run
your
advantage
or
application
via
kubernetes.
It
feels
like
and
you're
consuming
underlying
resources
that
certainly
feels
cloud
native,
but
is
that
cloud
native
storage
I?
So
there's
something
about
like
the
container
packaging
mechanism.
That
seems
important.
D
B
We've
talked
about
this
one
before,
and
so
it's
this
cloud
native
is
that
a
property
of
the
storage
system
itself
or
is
cloud
native
refer
to
the
fact
that
you
can
consume
storage
from
a
cloud
native
service
or
app
yeah?
That's
a
good
way,
that's
what
it
might
have,
though
so
and
I
think
I.
Think
wife,
remember
correctly
when
we
talked
about
this
last,
the
most
common
definition
is
that
it's
storage
consumable
by
other
cloud
native
applications
and
so
I
try
to
avoid
this
here
and
I
said
there
are
some
external
services.
B
That's
why
the
external
piece
came
into
this
external
services,
yeah
that
and
we
can
play
on
that,
one
right
we
can.
We
can,
you
know,
figure
out
how
to
you
know,
define
that
more
clearly,
but
there
are
external
storage
services
and
there
are
ones
that
run
on
the
continent.
Compartment
they're,
both
storage
services,
yeah.
C
I
think,
like
a
great
example,
Michael
like
I
mean
obviously
you
work
for
port
works
right
and
you
guys
have
a
containerized
storage
solution.
Yeah
again.
Obviously
the
max
is,
you
know
adult
thing:
we
don't
sell
much
B
max
with
containers,
so
I
don't
really
care,
but
you
know
I
think
the
the
point
is
that
you
know
if
you
take
an
example
and
you
look
at
the
existing
system
of
stuff
that
could
be
cloud
native
storage.
You
start
to
like
characterize
it.
Existing
platforms
like
AWS
like
EBS
volumes
right.
It's.
C
Nobody
should
really
care
that
it
CVS,
that's
the
interface
it
works,
and
then
you
go
through
like
the
class
of
the
capabilities
or
classifications,
and
you
kind
of
determine
like
how
cloud
mated
is
this
thing.
So
I
feel
like
the
the
check
boxes
to
say,
you're
cloud
native.
Aren't
that
your
as
yourself
like
containerized
to
dynamically,
manage
it's
just
feeling
that
you're
interoperable
with
a
certain
you
know
base
set
of
expectations
that
enable
someone
to
be
successful
with
kubernetes
I?
C
D
Know
what
you
think,
Michael
yeah,
no
it's
fair,
I
mean
and
I
think
you
know
these
are
the
types
of
things
we
just
need
to
bring
up
and
discuss,
discuss
you
know
in
so
EBS
is
just
a
sand
operated
by
AWS,
so
in
in
a
lot
of
ways.
Yes,
you
kind
of
by
extension,
if
we
agree
that
you
know
a
cloud,
a
cloud
block
store
can
be
cloud
native
and
because
it's
cloud
then
having
some
other
storage
substrate
doesn't
doesn't
preclude
yeah.
B
Yeah-
and
you
know
just
to
be
frank
here-
I
think
we
should
to
the
extent
possible
we
should
try
to
avoid
defining
climate
of
storage
as
a
way
to
differentiate
storage,
vendors
and
their
implementations,
but
but
rather
to
be
a
little
more
functional,
a
functional
definition.
Any
definition
that
excludes
EBS
and
Google
persistent
disk
from
the
picture,
I
think
would
be
wrong
because
arguably
EBS
is
actually
the
most
used
cloud
native
storage
system
today,
given
the
number
of
people
that
run
kubernetes
in
in
Amazon
today
and
they're,
all
using
EBS,
directly
or
indirectly.
B
C
C
And
then
you
know
fitting
different
platforms
underneath
there
like
feel
it's
all
possible
and
I
guess
where
I'm
getting
is
yeah
so
I
like
the
story,
I
think
there's
some
key
things
to
just
get.
Everybody
agree
on
I
think
the
next
step
is
like
practically
applying
some
of
those
ideas
and
actually
like
looking
at
the
platform,
so
I
put
together
something
that
we
could
take
a
look
at
if
you
guys
wanted
to
go
through
that
exercise.
Real,
quick
and
I
think
the
terminology
can
be
changed,
but
we
could
at
least
look
at
it.
C
B
B
B
A
B
B
C
Step
back
right,
the
storage
working
group
was
formed
because
the
UFC
was
evaluating
projects
and
the
people
on
the
TOC
didn't
background
in
storage.
Some
of
them
were
very
a
lot
of
more
in
just
very
microservices.
Focused
and
I
went
down
the
12
factor
app
like
religion
and
basically
helped
understand
it,
and
so
the
ethical
review
is
formed
to
help
provide
some
guidance
and
help
sort
through
the
smoke
of
what
was
going
on.
B
So,
and
so
you
know-
maybe
I'll
ask
this
differently.
Let's
assume
we
use
the
word.
Let's
take
the
alternative.
Let's
use,
let's
use
the
word
storage
to
refer
to
everything.
That's
persistent
search
right,
not
so
now
that
includes
literally
storage
service
equals
stateful
service
in
my
definition
here
all
right.
B
What
is
this
group
going
to
do
with
that
like
what?
What
are
we
hoping
to
achieve?
If
that
was
the
definition
first
of
all,
the
cloud
native
environment,
kubernetes
or
others
will
not
be
consuming
all
stateful
services
there,
like
I'm
gonna,
use
that
CD,
but
that's
not
a
common
interface.
That's
an
implementation
choice.
C
D
C
We're
talking
different
points
like
I've
got:
I've
got
a
service
that's
long
ago
right
and
I'm
gonna
run
myself.
Obviously,
that's
gonna
use
the
volume
services,
because
it's
stores,
files
and
etc
right
if
I've
got
a
micro
service
right
that
needs
to
consume
from
how
do
I
actually
get
that
micro
service
plumbed
up
to
be
able
to
talk
to
this
mom
but
database,
and
maybe
it's
creating
a
new
space
in
with
tables
like
maybe
it's
doing.
C
C
B
You
can
use
brokers,
you
can
use
catalogs
all
the
different
catalogs
you
can
argue
helm
is
already
in
that
you
know
category
for
doing
some
of
these
stuff
right.
My
question
is:
would
you
would
people
classify
that
all
as
storage?
This
is
all
part
of
a
storage.
You
know
cloud
native
storage
and
cloud
native
storage
working
under
the
plan
native
storage
group,
Charter,
yeah,
I.
A
A
A
That's
fine
and
I
think
that
CSI
of
an
example
yep
well
standardized
being
provisioning
right
and
mounting,
and
usually
both
volumes
right
point
specifically,
but
they're
going
to
be
another
project
that
standardizes
the
key
values
in
the
base
and
behind
it
are
large
key
value
stores,
and
that
could
be
another
ciencia
target
right.
We
agree
with
you
and
would.
A
Well,
that's
what
I'm
saying
that
were
key
category
but
doesn't
mean
that
it's
always
written
who
could
be
an
umbrella
many
of
different
categories
and
what
we
are
describing
is
a
huge
category
right.
It's
there's!
No
other
teams,
we
can
say,
look
guys
I'll
get
your
teams
and
your
awesome.
Oh,
go
over
there
to
your
own
I'm
graphing
on
section
called
you
know,
CNCs
storage
optic
store
and
then
define
a
standardized
value
13
to
send
the
data
base
team
model.
Tv
and
everything
saying
you
guys-
are
all
something
preventing
the
services.
Maybe
in.
C
Services
and
all
you
can
tell
you
like
the
song
from
a
product
perspective.
This
is
also
interesting
and
I
speak
for
port
works,
but
if
you're,
if
you're
a
storage
company
and
all
you
do
is
provide
blog
services,
you're
kind
of
a
dinosaur
yeah,
if
you're
a
storage
company
that
provides
block
services,
object,
services,
key
value
store
services
like
all
these
other
services,
that
cloud
native
applications
need
then
you're
actually
kind
of
interesting
moving
forward.
So
I'm.
B
B
F
B
C
B
I'm,
looking
at
the
Amazon
products
and
services
page
and
under
stories,
they
have
s3
glacier,
snowball,
EBS,
Storage,
Gateway
and
EFS
databases.
They
have
Aurora,
Amazon,
RDS,
dynamo,
redshift,
elastic
cache,
etc.
Right
I
under
analytics
I
bet
use
where
their
time
series
stuff
shows
and
then
obviously
monitoring
time
series
under
cloud
watch.
B
B
B
C
B
C
B
A
C
Yeah
so
I
I'm
on
that
side,
I
think
you
know
it
if
I
was
a
storage
guy,
you
know
and
I
came
from
20
years
ago
and
I've
been
doing
it.
My
whole
life
which
I
have
it,
should
just
be
storage
right,
it's
just
bits
and
blocks,
and
you
know
we're
doing
a
core
service
to
serve
applications,
but
I
feel
like
the
progressive
side
is
to
say
you
know,
there's
less
and
less
of
people
doing
it
that
way
and
the
new
way
to
store
information
and
data.
C
C
C
Think
the
other
honest
feedback
and
I
was
playing
Tim
for
a
reason,
because,
like
seriously,
he
he's
gonna
weigh
whether
this
gets
to
conclusion
or
not
very
heavily,
and
you
know
he's
obviously
very
opinionated
about
it.
Like
he's
he's
someone
that
you
know,
we
should
be
using
as
we
make
these
decisions
like
what
would
Tim
say,
because
you
know
he
will
be
an
important
factor
and
like
either
being
behind
the
group
and
what
we
defined
things
that
as
or
not
I
said.
B
This
sentence
doc
and
asked
for
feet,
but
I
can
explain
this
issue
so
we'll
see
I'll
see
what
he
says.
I
think
we'll
get
some
early
feedback.
I'll
try
to
do
the
same
with
Ben,
I,
I
think
I
think
we're.
Definitely
there
and
I
feel
clearer
now
about
what
the
crux
of
the
issue
is,
which
is
that's
thirst.
Clady
up
storage
should
be
more
than
volumes
or
not.
That
seems
to
be
the
core
issue.
Yeah
exactly.
B
C
C
Think
Tim
was
pretty
hooked
on
decoupled,
but
I
think
that
what
he
really
was
trying
to
get
out
was
that
it's
interoperable
or
self-service
and
on-demand
you've
got
the
other
pattern,
which
is
the
scalability
of
it,
which
tends
to
just
be
a
kind
of
a
cloud
based
pattern
and
being
elastic
and
then
autonomous
and
dynamic
is
how
was
capturing.
You
know.
C
Different
platforms,
like
port
works,
different
platforms
that
containerize
and
self-managed
I
thought
that
that's
one
way
that
you
could
do
that
under
the
classification,
so
those
are
the
high-level
patterns
and
then,
under
those
patterns,
you've
essentially
got
different
different
capabilities,
a
more
detailed
level,
so
under
the
decoupled,
interoperable
you've
got
dynamically
consumed,
which
means
that
you
know
it's
orchestrated
the
next
one
you've
got
or
it
means
that
the
application
is
able
to
dynamically
consume.
The
the
volumes
are
dynamically.
Orchestrate
to
make
them
available
store
data.
C
C
So
it's
another
important
one
as
being
part
of
self-service
and
then
you've
got
the
elastic
side
which
breaks
out
whether
it's
elastic
from
a
capacity
and
performance
perspective
and
whether
that
is
actually
metered
to
actually
limit
and
be
able
to
bill
and
charge
and
impact
the
the
consumption
model
or
how
people
actually
consume
that
that
resource
and
then
that
far
one
is
self
managed
for
you
know,
living
on
top
of
crew,
net
kubernetes,
etc.
So,
okay,.
B
C
Have
you
know
in
this
in
the
platform's
I've
got
different
types,
so,
just
like
you
said,
Louis
II,
a
cloud
data
storage
type,
essentially
the
first
one
EBS
is
a
volumes
type.
The
second
one
is
a
data
services
type
and
that
provides
no
block
and
then
no
sequel,
and
then
it's
kind
of
interesting,
because
you
can
then
classify
these
types,
even
though
they're
like
far
different,
but
I
think
that
all
of
these
different
categories
are
all
things
that
you
could
validate
like
that
service
by.
A
C
A
B
Yeah,
if
you
and
given
the
discussion
having
earlier
if
you
said
cloud
native
storage,
is
volumes
only
than
you
get
rid
of
all
the
lines
that
sink
data
services
yeah,
you
leave
the
ones
that
say
volumes.
You
still
have
lock
or
file,
that's
still
in
there
yeah
different
kinds
of
volumes,
and
you
still
all
these
attributes
for
differentiating
our
properties
of
these
systems
that
we
should
consider
when.
F
C
B
C
C
Let's
see
what
comes
back,
I
mean
I,
wouldn't
think
the
readout
to
the
TOC
will.
Let
then
spin
it
and
decide
what
he
wants
to
stay
there,
or
we
should
at
least
that
should
be
somewhat
lucky
besides.
I
would
hope
to
have
this
thing,
at
least
in
some
kind
of
form,
so
that
we
can
actually
like
talk
about
some
of
that
cute
calm,
hey
here's.
B
G
B
C
Think
that
it's
got
to
be
resolved
before
Q,
calm,
like
you
do,
I
I
mean
I
I
would
love
it
to
like.
Okay,
we've
got
CSI
coming
up,
that's
gonna
be
proposed,
probably
soon
after
okay
I,
don't
know
that
so
I
mean
if
we
sit
here
in
a
room.
You
know
for
four
hours
and
we've
got
30
people
that
express
their
ideas
about
it,
like
I,
think
at
the
end
of
the
day,
it's
just
gonna
be
a
benevolent
dictator
who
just
says
here's
what
happened.
Yeah.
E
G
C
It's
Ben
who's
gonna,
basically
make
that
decision.
So
I
don't
know
III,
don't
I,
don't
want
to
recommend
that
we
put
on
the
brakes
and
say
wait
for
a
face-to-face
is
I.
Just
don't
feel
like
that's
gonna
be
where
it
gets
resolved.
No
okay,
so
yeah.
Let's
just
wait.
Let's
eat
I'll
see
if
there's
any
more
takers
on
that
email
thread
to
give
their
opinion.
Let's
see
what
Tim
says
and
then
we
can
wrap
back
to
to
been
with
and
one
status
isn't
what
we
talked
about
and
give
them
an
update.