►
From YouTube: CNCF SIG-Storage Meeting - 2019-08-14
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
A
We've
put
information
packs
together,
based
on
sort
of
questionnaire
that
that
we
that
we
drafted
for
reviewing
these
sort
of
projects,
and
we
have
that
and
presentations
which,
which
I
think
we
are
ready
to
submit
to
the
TOC
I
believe
all
the
other.
Questions
and
sort
of
queries
have
been
answered
at
this
point.
So
unless
anybody
has
any
other
queries
or
any
other
things
they
want
to
cover,
we
can
we
can.
We
can
forward
them
to
the
Tarkan's
and
they
can
be
candidates
for
the
for
the
project
presentation
next
week.
A
A
B
C
B
B
A
That
sounds
brilliant
yeah
we've
struggled
engaging
with
the
CNCs
end
user
forum
in
the
sense
that
we
we
got
an
invites
to
the
to
speak.
That's
one
of
their
meetings,
but
sort
of
it
was
poorly
attended
and
we
didn't
really
get
the
whole
of
the
feedback
from
that.
So
we're
we're
just
looking
for
a
way
forward.
If,
if
we
don't
get
responses,
you
know
we
probably
need
to
delay
it
and
maybe
launch
it
again
at
coupon
or
something
like
that,
but
there's
only
so
much
I
think
we
can.
A
A
Jing
was
was
going
to
put
a
little
framework
together
for
a
paper
that
compares
things
like
roblox
tours
and
ephemera
lists
and
local
disks
and
disks
from
storage
systems,
etc.
Just
to
just
to
clarify
some
of
the
options
and
terminology
there,
and
we
had
also
discussed
about
writing
a
database
section
for
the
white
paper.
E
A
So
the
block
storage
parts
that
the
the
block
bit
is
and
the
ephemeral
disk
etcetera.
That's
that's
something
that
Jing
was
going
to
be
putting
together
now:
okay,
god
yeah
yeah.
So
we
need
somebody
for
the
for
for
the
database,
because
the
original
CN
CF
landscape
white
paper,
we
kind
of
said
look.
There
are
key
value
stores
and
object
stores
and
databases,
and
we
had
sort
of
sufficient
content
and
sufficient
skills
to
cover
object,
stores
and
and
key
value
stores.
A
But
we
kind
of
puts
databases
as
active
scope
for
the
first
iteration
of
the
white
paper.
So
what
we're
looking
to
do
now
is
is
so
it's
taking
a
step
forward
and
actually
alter,
maybe
a
database
either
a
database
section
or
a
standalone
database
white
paper,
so
we'd
be
looking
for
a
bit
of
guidance.
There
I.
C
A
Okay,
so
so
so
there's
that
and
then
finally
there's
there's
that
there's
a
third
paper
that
that
we
were
that
we
wanted
to
work
on,
which
is
a
performance
performance
paper.
So
one
of
the
things
we
were
talking
about
was
there
seems
to
be
a
recurring
theme
with
other
recurring
set
of
questions
around.
A
How
do
I
handle
a
benchmark
and
how
do
I
run
performance
tests
and
in
cloud
native
storage
systems,
and
a
good
starting
point
would
probably
be
to
document
some
of
the
tools
and
some
of
the
easiest
usage
patterns
that
are
available
and
I.
You
know
I'm
putting
a
hand
up
and
volunteering
to
help,
write
that
and
I'm
really
interested
to
hear
if
there
are
any
other.
C
Alex
I'm
not
necessarily
signing
up
to
do
it
myself,
but
I'll
look
around
VMware
where
I
work
and
see
if
I
could
find
somebody.
Okay,
don't
worry
brilliance.
One
interesting
thing
is:
you
know
there
are
a
lot
of
these
benchmarking
to
fools,
but
I
think
to
do
this
right.
We
should
probably
approach
it
where
we
get
tools
in
the
categories
of
you
know
intended
for
block,
while
object,
etcetera.
C
A
And
there's
the
wire
CD,
which
would
do
key
value
workloads,
for
example,
but
but
what
I
wanted
to
do
was
kind
of
capture?
These
are
tools
you
can
run,
but
also
maybe
these
are
some
of
the
kind
of
gotchas.
That's
that
you
should
be
aware
of
when
comparing
different
systems.
So,
for
example,
you
know
things
like
the
effects
of
caching
and
compression
and
replication,
and
did
you
ban
variety
of
other
things
and
how
that
effects
the
benchmark
results.
So
people
can
kind
of
work
towards
an
apples
for
apples,
kind
of
comparison,
yeah.
C
The
the
other
thing
that
I
think
potentially
should
factor
into
somebody
making
decisions
is
even
something
to
measure
network
bandwidth
consumption,
because
some
solutions
vary
on
their
usage
patterns
of
the
network
and,
if
you're,
taking
your
storage,
that
related
networking
and
sharing
it
with
the
same
networking
backing
infrastructure
that
you
use
for
your
compute
workloads,
you
can
have
surprises
if
you
don't
really
understand.
What's
going
on.
That's.
A
A
very
good
point
as
well
so
yeah,
so
so
what
what
sort
of
what
sort
of
impacts
as
the
business
storage
system
have
on
the
on
the
environment?
So
we
are
measuring
CPU
memory,
utilization
and
network.
There
they're
all
important
things
to
keep
in
mind
yep,
so,
basically
that
that's
kind
of
the
general
scope
of
the
paper
I'm
going
to
try
and
have
a.
A
E
I
have
so
we
have
done
benchmarks
for
with
tests
both
using
sis
bench
and
TPCC
right,
but
they
are.
They
were
we
test
specifics
or
if
your
I
don't
know
if
that
that
counts
or
how
that
can
be
incorporated
into
a
generic
one,
especially
that
there
are
not
that
many
database
types
storage
for
kubernetes.
Yet.
E
C
A
So
yeah
just
to
be
completely
clear.
This
isn't
about
publishing
test
results.
This
is
about
publishing
a
how-to
guides.
So
if
you
want
to,
if
you,
if
you
have
two
systems
in
your
environments,
how
do
you
compare
them
and
what
tools
you
use
to
compare
them?
And
how
do
you
measure
things
so
so
I
think
I
think
so,
if
you
have
sort
of
a
bunch
of
backgrounds
on
on
systems,
for
example,
I
think
there
would
be
a
huge
amounts
of
value
in
describing
how
to
use
suspension
some
of
the
gotchas
behind
it.
A
E
I
will
actually
I
will
introduce
you
to
there's
two
people
who
ran
the
test
at
Planet
scale.
So
I
will
introduce
you
to
one
of
them.
They
can.
They
can
give
you
the
details
about
how
they
so
so
that
part
I
think
would
be
relevant
right.
That
would
be
fantastic.
That
would
be
an
absolutely
really
useful.
Any.
A
Okay,
I
think
I
think
we
can
start
with
that.
So
so
one
of
the
things
one
of
the
things
that
we
were
we
were
thinking,
is
we're
kind
of
falling
behind
on
some
of
the
deliverables
as
we
want
to
to
to
put
forward.
So
you
know
things
like
the
papers
that
we
have
just
discussed
now
and
I
was
I
was
hoping
that
we
could
agree
on
setting
up
a
bit
of
more
of
a
a
useful
agenda
to
move
forward
with
some
of
these
deliverables
effectively.
A
What
I'm
suggesting
is
that
we
have
more
regular
meetings,
perhaps
once
a
week
to
kind
of
get
a
bit
of
a
cadence
or
some
of
these
deliverables,
and
we
keep
to
two
of
the
meetings
to
be
the
you
know.
The
the
general
agenda
and
project
presentation
talk
me
things
as
we
have
today,
but
also
adds
you
know
another
two
meetings
which
can
be
more
focused
on
you
know,
discussing
the
papers
or
you
know
actively
working
on
the
papers
of
the
deliverables
that
we
want
that
we
want
to
move
forward.
A
F
A
Certainly,
for
the
next
two
or
three
months,
so
we
can
get
some
of
these
papers
out
of
the
way
and
have
some
good
deliverables
to
to
kind
of
publicize.
Certainly
before
cube
con,
you
know
we
we,
our
our
mission,
is
you
know,
apart
obviously
from
reviewing
the
projects
and
being
sort
of
an
extension
of
some
stuff
that
COC
does
is
also
to
kind
of
educate
and
to
help
the
declare
native
adoption.
So
some
of
these
some
of
these
things
are
equally
as
important.
That
I
think
we've
gotten.
A
You
know
quite
a
bit
of
quite
a
bit
of
publicity
from
things
like
the
white
paper,
so
trying
to
get
some
more
of
these
documents.
That
is
kind
of
important
in
my
books
anyway,
but
you
know
I
can't
frog-marched,
even
with
some
paintings,
but
we
do.
We
do
really
need
to
kind
of
keep
up
some
of
the
cadence,
but
we
can
play
it
by
ear.
So
if
things
are
moving,
if
things
are
moving
faster,
they're
owned
and
then
you
know
we
can,
we
can
slow
down
some
of
the
meetings.
That's
okay,
too,.
A
B
A
G
C
G
F
F
A
Wow,
okay,
yeah
I
kind
of
regret:
I
do
like
the
idea
of
having
some
sorts
of
animal.
Maybe
maybe
what
I'll
do
is
I'll
go
back
to
Amy
and
see
if
she
can
see
if
she
can
get
them
to
to
pick
up
some
sort
of
animal
thing.
I
noticed
the
Securities
sake
have
have
picked
a
logo
with
some
sorts
of
raccoon
or
something
that
acts
on
it.
So
there
you
go.
That
might
be
the
answer.
The
trend
is.
A
Yeah
and
to
be
completely
honest,
I
don't
know
that
we
want
to
sort
of
restrict
this
to
yes,
perfectly
containers
or
I.
Don't
know
you
know,
specifically
storage,
because
it's
supposed
to
cover
everything
from
databases
and
api's
and
all
sorts
of
other
things
too
so
yeah
all
right,
so
I'll
ask
them
to
do
some
other
stuff.
A
A
B
I
think
I'd
like
to
probably
start
doing
a
paper,
but
maybe
I
have
to
keep
Khan
on
us.
You
know
what
type
of
applications
should
use,
what
type
of
storage
you
know
things
like
that,
maybe
like
suggestions,
you
know
something
like
if
I
want
to
use
my
sequel.
These
are
the
storage
systems
and
why
things
like
that?
Sorry,
sorry.
H
B
Exactly
right,
I
just
feel
that
a
lot
of
you
know
I've
talked
to
a
few
customers,
and
you
know
the
noise
and
knowledgeable
about
storage
as
we
are,
so
they
don't
know
where
to
go.
They
know
that
they
need
my
seagull.
They
know
that
I
need
some
database
or
a
CD
or
something
say
what
do
I
put
behind
so
I
use
local
disk,
the
I
use
network
storage.
What
do
I
do
and
just
something
very
generic,
but
again.
I
C
A
B
A
G
H
B
H
H
I
B
E
A
A
No,
it's
it's
it's
to
sort
of
compare
the
different
types
of
different
types
of
database,
it's
kind
of
like
what
how
we,
you
know
have
a
few
pages
to
describe
the
sometimes
of
key-value
stores,
for
example,
or
different
types
of
objects.
Stories,
for
example,
know
about
it.
So
so
you
know
that
can
be
a
few
pages
to
kind
of
say:
look!
You
know
there
are
transactional
databases
and
there
are
distributed
databases
and
there
are
no
sequel
databases.
A
It
takes
the
white
paper
step
forward
in
the
white
paper
we
kind
of
describes
the
different
attributes
of
a
storage
system,
and
now
what
we're
saying
is
we
if
we
take
these
use
cases
or
these
specific
applications?
What
type
of
attributes
today
do
they
need
and
therefore,
that
kind
of
helps
you
select,
which
storage
system
to
use
yeah.
B
Exactly
and
I
feel
that
maybe,
unlike
the
white
paper,
that
this
will
probably
be
a
living
document
as
we
find
more
and
more
I,
don't
think
it'll
have
an
end.
We'll
just
have
ends
for
applications
that
will
do
one
application
and
then
we'll
add
more
and
more
as
we
go,
because
I
feel
that
there's
so
many
applications
right.
G
B
G
H
H
G
B
F
B
And
I
just
one
logistical
question:
the
that
we
have
a
a
github
location
and
the
documentation
that
we're
running
is
separate
from
the
github
location,
a
second
Google
and
it's
probably
under
somebody's
someone's
Google
Drive
a
when
we
write
the
paper.
Do
you
mind
if
we
write
as
a
markdown
format
in
github
the
way
it's
part
of
the
repo
and
it
stays
in
there
or
do
we
write
it
in
Google
Drive?
And
we
just
point
to
it:
I
think
if
you
write
to
him
lockdown
yeah
I'm,
suggesting
that
yeah
I
agree.
H
One
caveat
is
that
often
in
the
early
stages
of
the
document,
where
there
are
lots
of
comments
and
revisions
and
edits
and
changes
and
things,
people
generally
seem
to
think
that
Google
Docs
is
better
for
that
part
of
it
and
then
once
it
stabilizes
and
you
say:
okay,
this
is
you
know,
v10
or
whatever.
Then
then
we
dump
that
in
markdown
we
change
that.
You
know
at
the
header
of
the
document.
Usually
people
say
this
document
is
closed
for
comments.
H
C
A
H
I
might
have
missed
since
that
a
slightly
different
approach
to
what
I
think
you're
proposing
is
to
essentially
say
these
are
some
success
and
failure
stories
around
cloud
native
storage
and
try
and
kind
of
structure
it
in
such
a
way
that
people
can
kind
of
read
it
as
a
best
and
worst
practices.
I,
don't
know
if
that's
the
same,
what
you're,
proposing
or
different
or
whether
we
need
to
choose
one
or
the
other.
We
can
do
both
I'm,
not
sure
yeah,.
H
H
I
totally
agree
and
I
think
that's
with
some
degree
of
skepticism
people
view
some
of
these.
You
know
white
paper,
II
type
things
as
being
overly
theoretical,
or
else
you
know,
marketing
blur
by
vendors
and
I
say
think
people,
the
common
theme
I've
heard
from
what
people
want
is
actual
real
world
things
that
that
have
been
done
and
either
succeeded
or
failed.
People
seem
to
like
that.
G
It
can
be
I
say
we
use
that
information
as
a
starting
point.
At
least
these
are
the
applications
that
people
talk
about
and
we
can
use
those
as
a
starting
point
and
work
from
there.
Yes,.
H
A
So
I
mentioned
earlier:
I
shared
the
link
to
the
questionnaire
in
the
CNC,
have
slack
and
and
solder
Lewis
I
can't
remember
now
who's
going
to
share
it
with
the
community
sig
in
the
user
channel
for
kubernetes,
but
so
far
we've
only
got
about
15
responses,
so
it's
probably
not
super
useful.
It's
better
than
nothing.
I.
Guess,
though,.
H
A
A
But
I'm
a
sniff,
so
this
conversation
was
great
but
I'm,
not
sure
where
we
landed.
So
if
I'm
reading
this
right,
I
think
there
were
sort
of
two
separate
initiatives,
one
was
identify
some
use
cases
and
sort
of
go
through
some
of
the
pros
and
cons
about
which
storage
systems
to
use
for
those
use
cases
and
the
second
one
another
was
you
know
what
Louise
and
Simon
women
talking
about
and
then
Quintin
you
were
talking
about
something
more
along
the
lines
of
gave
documents,
some
real-life
success
stories
or
indeed,
failures
in
stats.
H
A
If
we
talked
what,
if
we,
what
if
we
don't
make
this,
you
know
a
big
thing
and
try
and
break
it
up
into
smaller
things.
So
if,
if
certainly
I
kind
of
like
the
idea
that
perhaps
if
we
have
a
bunch
of
use
cases,
we
could
have
a
bit
more
of
a
community
driven
effort
where
people
can
give
experiences,
but
also
you
know
the
pros
and
cons
of
different
storage
systems
for
each
of
those
use
cases.
A
A
H
Yes,
yes,
I,
agree,
I,
think
I,
think
breaking
up
into
small
pieces
like
that
is
a
good
strategy
for
getting
contributors.
I
still
think
we
will
need
an
overall
kind
of
a
driver
person
for
this
effort
who,
for
example,
you
know,
decides
what
those
areas
are,
that
we
want
to
publish
papers
on
and
then
finds
people
to
you
know
suitable
experts
to
to
write
the
necessary
stuff,
and
perhaps
has
it
has
an
overarching.
You
know
cover
document
that
says
you
know
these
are
the
areas
that
we're
interested
in
here.
H
A
B
H
Did
you
have
a?
Did?
You
have
a
specific
first
target?
Maybe
maybe
that's
a
good
way
to
start
is
tonic.
These
write
that
document
you
know
figure
out
what
the
structure
looks
like
how
long
it
is,
etc
and
then
say:
here's
a
template
for
all
the
other
ones,
and
these
are
the
other.
You
know
six
that
we'd
like
to
tackle
next.
My.
B
I
think
we
could
come
up
with
a
format.
You
know
trying
to
come
up
with
infrastructure
for
it
we
can
start
creating
these.
You
couldn't
even
start
with.
You
know,
creating
issues.
I
would
have
to
get
you
know.
So
we
can.
The
next
meeting
I
think
I'll
start
sending
out
emails,
but
we
can
start
coming
up
of
process
for
this,
so
that
everybody
follows
it.
Why.
F
B
We
just
that's
good
point
I'm,
trying
to
figure
out
how
to
answer
it,
but
I
think
that
you
know
I
feel
this.
This
is
a
a
not
a
one.
Stop
thing:
this
is
a
continuation.
We
will
continue
to
get
use
cases
for
for
and
we'll
continue
creating
suggestions.
So,
if
I
I'm
trying
to
view
this
instead
of
bottom-up
and
top-down,
if
I
am
NOT
a
storage
expert,
what
do
I
want
to
see?
I
would
like
to
see
a
location
where
it
gives
me
some
kind
of
help
for
the
application
I'm
looking
for
and
so
okay.
A
How
about
how
about
we
do
this,
because
I
I
guess
that's
that
feedback
that
there
and
said
we
should
pick
the
use
cases
with
a
purpose
right
and
certainly
it
would
be
useful
to
start
with
something
really
simple.
Like
you
know,
a
standalone,
my
sequel
or
a
standalone,
my
Postgres
and
the
focus
on
that
can
be
around
you
know.
A
How
do
we
do
performance
in
the?
How
do
we
do?
How
do
we
do?
You
know
various
other
things,
and
that
can
be
a
nice
simple
use
case,
but
then,
in
terms
of
use
cases
we
pick
can
actually
explore
one
or
more
of
the
different
attributes
as
we
define
them
in
the
white
paper.
So,
for
example,
if
we
pick
Kafka
that
can
be
all
about,
you
know
sequential
throughput
and-
and
you
know
me
perhaps
some
of
the
distributed
nature.
If
we
pick
a
no
sequel
database
like
Cassandra,
it
can
be
all
about.
E
H
H
A
F
H
The
other
thing
that
crossed
my
mind,
I
thought
I
just
mentioned-
is
that
many
of
these
I'll
call
them
storage
systems.
You
know,
depending
on
the
actual
application
running
on
top
of
them,
the
deployment
the
best
deployment
differs
substantially.
So
so
you
know
HCD
and
kubernetes
is
typically
backed
by
you
know:
persistent
remote,
persistent
disks,
which
have
you
know
poor
performance
and
various
other
characteristics,
but
for
that
specific
use
of
HDD,
it
kind
of
makes
some
sense
one
might
or
not,
but
anyway
it
is
the
way
it
is.
H
Whereas
if
you
want
a
very
high
throughput
one,
you
would,
you
know,
deploy
the
storage
part
of
it.
It
is
in
a
very
different
way
and
the
same
applies
sure
to
Kafka
and
cassandra
and
other
other
applications
or
other
storage
systems
that
there
is
no
one
good
way
to
deploy
a
given
storage
system.
It
depends
on
the
application.
That's
running
on
top
of
the
of
the
storage
system,
so
make
sense,
and
that's.
G
H
A
So
that's
that's
correct,
so
what
I
had
in
mind
was
if
we,
if
we
I,
want
to
avoid
trying
to
boil
the
ocean
here
right,
so
I
want
to
avoid
having
to
discuss
every
single
permutation
and
then
taking
6
months
to
come
up
with
every
Newsday's,
because
because
that
would
be
wrong
too,
there
is
value
in
getting
something
out
quickly
here.
So
it's
you
know
again
just
going
back
to
a
simple
example.
If
we
pick
something
like
Postgres,
for
example,
we
we
can.
A
This
is
another
way
of
doing
it
and
we
can
kind
of
grow
that
so
I
don't
think
we
need
to
have
every
single
permutation.
We
can
say
if
you
use
Cassandra
this
way
or
if
you
set
C
the
this
way
or
parameters
this
way,
then
this
is
one
way
of
doing,
but
if
this
kind
of
gets
traction
then
hopefully
some
of
the
people
in
those
communities
can
also
then
help
to
contribute
to
this
I.
Think.
H
The
only
reason
I
was
because
I
think
that
that
addresses
its
it
certainly
intended
to
address
the
high
level
overview
that
you've
mentioned.
Okay
I'll
go
read
it
different,
different
kinds
of
storage.
The
pros
and
cons
of
you
know
local
versus
remote,
distributed
versus,
not
etc,
and
then
so
what
what
I
think
we're
contemplating
now
is
the
next
step,
which
is
has.
G
F
G
I'm
not
saying
that
the
white
paper
should
only
be
about
patterns,
you
start
it
as
the
patterns
which
references
back
to
maybe
the
original
white
paper
in
a
more
succinct
way.
So
it's
not
as
long
as
that
white
paper
is
just
covered
in
a
couple
of
paragraphs
or
a
page
or
so
or
something,
and
then
you
delve
down
into
use
cases
yeah.
That
makes
sense.
H
Let's
take
you,
know
a
CD
as
an
example.
Paps
is
we
start
off
by
saying
you
know,
typically
or
often
one
either
optimizes
for
throughput
or
durability,
for
example,
and
and
here's
an
example
of
a
good
throughput,
optimized
deployment
and
here's?
Why
and
here's
a
good
example
of
a
durability,
optimized
deployment
in
here's?
Why,
hopefully,
that
does
I
totally
buy
your
argument,
Alex
that
we
should
not
try
and
boil
the
ocean
and
I?
H
A
Note
that
that
sounds
fine,
and-
and
actually
you
know,
there's
probably
no
harm
in
saying
if
there
are
maybe
five
or
six
things
as
we
can
think
of
actually
just
list
them
in
the
talk
and
kind
of
say
these
are.
These
are
other
alternatives.
That's
that
that's
you
know
are
coming
next
and
I'm
just
happy.
H
A
A
Okay,
so
what
I'll
do
is
then,
if
everybody's
is,
is
up
for
this
I'm
not
going
to
put
a
meeting
aggress
them
for
next
week,
because
next
week
is
kind
of
slightly
nuts,
because
we've
got
the
the
webinar
and
a
soft
project
presentation
all
on
the
in
the
same
week.
So
I'll
throw,
and
should
you
look
for
the
week
after,
but
we
I'll
put
in
the
agenda
for
the
things
we
want
to
cover
and
we
can
start.