►
From YouTube: CNCF SIG Storage Meeting 2019-10-09
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
CNCF SIG Storage Meeting 2019-10-09
B
A
A
A
Okay,
I
think
we
can
start
so
we
have
two
documents
that
we
wanted
to
that.
We
wanted
to
review
this
time
around.
The
first
is
the
database
paper
that
subbu
has
been
working
on,
and
the
second
is
the
project
review
process
that
the
Theron
has
been
working
on
subbu.
Do
you
want
to
just
give
an
update
as
to
where
we
are
on
the
on
the
database?
Doc
of
I
know
that
Quinton
has
put
some
feedback
into
the
doc
and
I've
just
written
up
some
some
notes
that
I
would
like
to
go
through
as
well
sure.
C
C
So
that
is
one
that's
I
believe
that's
the
main
change
I
had
made
in
the
document
understood.
Okay,
and
there
was
also
you
problem.
You
were
not
there
in
our
last
discussion.
No
I
wasn't
understand
sorry
yeah.
There
was
a
discussion
about
what
is
a
database
in
general,
like
Cassandra,
was
considered
as
one
whether
it
should
be
a
database
or
not
I
think
it
was
borderline,
so
we
decided
to
include
it,
but
we
already
have
a
key
value
store
section
and
so
maybe
maybe
I'm
thinking.
A
So
I
think
that's
that's
that's
a
fair
point.
So
so
I
wrote
some
notes
at
the
at
the
end
of
the
document.
Just
because
I
couldn't
find
the
right
place
to
add
comments
for
heads
yeah,
so
so
I
think
I.
Think
one
of
the
things
you
know
that
we
were
discussing
in
the
past
was
in
the
rest
of
the
white
paper.
A
C
C
D
A
So
so
I
mean
in
the
previous
in
in
sort
of
previous
sections,
where
we
found
these
sort
of
things,
I
mean
we
even
make
just
like
a
little
table,
which
kind
of
just
said.
You
know
for
these
three
types
of
topologies.
These
are
the
relevant
attributes
that
you
should
expect
and
it
kind
of
helps
to
select
sorts
of
different
usage
patterns.
Or
you
know,
different
types
or
classes
of
database
for
different
use.
Cases
sounds.
A
D
I'm
in
favor
the
table
too,
and
you
know
in
terms
of
a
table
I
think
maybe
you
have
to
there
are
just
so
many
potential
databases
that
I
don't
think
you
could
cover
all
the
dozens
or
maybe
even
hundreds
that
are
out
there.
So
first
pigeonhole
them
with
some
popular
examples
in
each
category
and
then
cover
maybe
in
the
table
the
topology
differences,
the
factors
involving
wanting
to
split.
B
D
B
D
B
D
I
agree
with
that:
it's
just
that,
having
you
know,
sometimes
you
can
have
a
bunch
of
text
and
somewhere
in
there
throwing
a
popular
example,
might
solidify
it
in
somebody's
mind
if
they're
familiar
with
something
I,
don't
want
to
be
kingmakers
here
and
nominate.
Whatever
examples
we
give
is
you
know
the
foremost
examples
in
the
category,
though
so.
A
A
We
should
include
references
to
some
popular
examples
that
allow
people
to
apply.
You
know
context
to
what
they
already
know,
because
that
helps
them
understand
the
documents
so,
for
example,
it's
kind
of
nuts
to
describe
an
object
store
without
mentioning
mystery
and
it's
kind
of
nuts
to
talk
about
the
key
value
store
without
talking
about
that
CD,
for
example,
especially
where's.
A
Maybe
some
of
those
projects
are
our
CN
CF
projects
as
well
so
I
think
have
a
handful
of
examples
is
is
fine
as
because,
especially
if
they're
sort
of
you
know,
generic
household
names
but
I
agree
in
general.
We're
we're
not
aiming
to
be
kingmakers
here,
but
we're
an
example
serves
the
purpose
of
clarifying
the
document.
I
think
that's
fine.
C
C
A
There
is
a
question
mark
as
to
you
know,
do
you
assume
this
is
a
service?
You
do
you
consider.
Do
you
build
this?
You
know
and
similarly,
for
example,
we
kind
of
said
when
we
were
discussing
topologies
in
the
white
paper.
We
said
you
know.
Charlotte
systems
are
great
at
balancing
out
the
load,
but
one
of
the
disadvantages
is
you
know
you
have
to.
You
might
have
to
have
operational
requirements
to
to
rebalance
workloads
if
you
kind
of
get
the
shards
wrong
in
the
first
place.
A
You
know,
and
those
are
like
some
of
the
pros
and
cons
for
each
of
the
different
topologies,
so
I
think
it's
it's
completely
fair
to
say
that
if
you
want
a
really
big
distributed,
scalable
database
and
you
want
strong
consistency
and
not
eventual
consistency,
then
you
know
things
like
strict
timekeeping
are
our
complexity
factor
and
if
you're
considering
it,
you
know
this
isn't
just
like
something
you
can.
You
can
ignore.
C
D
A
D
Really
smooth
definitely
counts,
I
mean
it
can
be
used
as
a
cache,
but
you
certainly
have
the
option
of
putting
backing
storage
on
it
in
it.
I've
encountered
many
instances
where
it's
done
so
there's
no
doubt
to
me
that
Redis
is
in
the
database
category
I
think
this
is
more
a
key
value,
though
it
is
you've
now
user,
a
form
of
database
I
mean
FCT,
is
a
key
value.
Yeah.
C
So
that's
the
thing
which
I
mean
because
we
have
already
have
a
separate
section
for
key
value
stores
and
wondering
may
I'm
even
I
thought.
Maybe
we
should
merge
the
two
you
know
like,
because
many
of
them
are
evolving
into
databases
and
database
is
a
some
databases
now
start
to
give
key
value.
Api's
I
mean.
A
A
A
C
C
I
think
what
I
will
do
is
I
will
I
will
definitely
mention
that
these
lines
are
blurring
and
and
that
sometimes
things
can
come
in
both
categories.
I
think
that's
important
to
mention,
and
then
maybe
we
can
do
another
shot
at
putting
putting
the
two
together
and
see
how
that
looks
as
a
separate
attempt
and
then
yeah.
A
C
A
C
A
Right
well,
I,
I,
know,
I,
know
that,
for
example,
you
know
things
like
envoi,
for
example,
are
actually
adding
database
protocol
level
sharding
and
things
like
that
to
the
proxy
layer.
So,
for
example,
I
know
that
they
added
support
for
my
sequel
and
they
haven't
supports
for
Redis
and
they
actually
do
a
bit
of
sharding
themselves.
Oh
No.
C
C
B
C
C
Let's
go
to
your
comments,
make
sure
that
they
are
all
covered
consistency
and
eventual.
We
are
going
to
cover
that.
Do
we
meet
yes,
the
second
and
the
first
and
second,
are
a
combined
topic.
Yep,
no
sequel
and
document
databases
for
now
we'll
choose
a
category
and
put
them
there
for
now
and
then
in
which
you
look
at
merging.
C
Cassandra
I
think
last
time
we
agreed
that
it
should
be
in
databases,
I
think
it's
a
clear
example
of
a
borderline
case,
yep
cockroach,
strong
consistency
that
goes
back
to
the
first
end.
First
yep
database
is
based
on
an
underlying
underlying
key
value,
store,
yeah,
I.
Think
cool
I
will
I
think
that's
a
good
good
point.
We
should
fold
that
into
the
new
sequel
categories,
because
that's
where
they
are
most
relevant
databases,
and/or
caching
layers,
so
that
we
I
think
maybe
I
will
add
an
edit
for
the
for
section
line.
To
mention.
C
E
C
C
B
B
B
How
the
cigs
interact
with
the
the
TOC
long
term,
so
the
it's
still
pretty
rough,
but
I
wanted
people
to
weigh
a
and
I
didn't
intend
this
to
be
a
polished
document
by
any
means,
but
just
to
solicit
feedback
and
come
up
with
a
better
process.
So
the
main
points
it
to
see
that
the
TOC
agreed
on
was
time
boxing
that
you
know
there
should
be
a
responsibility
on
the
TOC
to
review
things
within
a
timely
manner
and
provide
a
response
back.
There
should
be
a
way
that
projects
understand
if
they
are
rejected.
B
If
these
things
are
fixed-
or
it's
not
cloud
native,
you
know
by
design
and
therefore
it's
rejected
so
I
think
they
have
a
problem
of
not
saying
no
and
and
or
just
letting
things
well,
because
they
don't
want
to
say
no
and
I
think
that
that
has
to
stop
so
and
they
also
agreed.
We
don't
have
a
good
process
now
for
what
that
this
responsibility
is
because
I
told
them
I
feel
like
we
end
up
with
duplication.
B
Now
now
we
have
cigs,
we
review
things,
we
give
them
a
recommendation
and
then
the
projects
still
end
up
presenting
to
the
TOC
and
we
start
over
from
scratch.
So
how
do
we
also
make
it?
A
more
efficient
process
makes
sense
to
have
the
subject
matter.
Experts
review
the
projects
and
do
the
due
diligence
and
give
a
recommendation.
So
how
do
we
do
that?
Better?
A
Yeah,
definitely,
we
can
I
think
we
all
should
I
think
we
should
all
review
this.
So
if
I'm,
if
I'm,
just
looking
at
this
in
terms
of
in
terms
of
sections,
we're
kind
of
defining
what
we
expect
out
of
the
out
of
the
TOC
and
the
process
and
the
timeline,
and
what
also
what
the
process
in
the
sig
itself
should
be
right
in
terms
of
when
they
hand
it
over
to
us.
B
B
So
I
just
wanted
to
point
that
out
it's
under
your
the
project
rejection
recommendation
project
marinate
in
the
Linux
Foundation
public
group,
we're
trying
to
find
out
what
that
level
was.
There
was
no
decision
made
on
it,
but
then
they
just
talked
about
well,
maybe
we
we
need
somewhere
that
it
just
goes
and
and
gets
more
contributions
or
fix.
You
know
fixes
governance
or
et
cetera,
and
to
me
I
always
thought
that's.
What's
the
intention
of
sandbox
was
so
I
think
there's
definitely
still
some.
B
A
Having
sort
of
there's
this
perception
that
the
goal
posts
were
changing
is
maybe
different
criteria,
we're
getting
applied
to
two
different
projects
and
I
and
I.
Think
having
having
this
having
this
process,
formalized
will
hopefully
remove
that
that
issue
I'm
not
entirely
convinced
that
we
need
something
more
than
a
sandbox
honestly
or
something
less
than
a
sound
box.
Personally,
because
I
think
the
sandbox
is
kind
of
very
intentionally
a
broad
I
and.
B
I
was
a
bit
surprised
by
the
suggestion,
but
just
hoping
that
this
helps
because
I
I
told
them.
My
concern
is
one
there's
no
time
around
any
of
these
things.
He
cloak
that
we
proposed
is
been
in
over
a
year
waiting
to
be
given
a
decision
and
to
me
that's
not
only
has
the
entire
TOC
changed,
but
it
seems
like
the
criteria
by
which
they're
judged
has
changed
right.
So
things
have
to
be
time.
B
Boxed
and
people
have
to
understand
the
criteria
which
they're
getting
judged
against
because
though
I
know
they
have
good
intentions,
then
I
think
I
hear
these
rumblings
of
unfairness.
Right
Mike
will
hop
him.
This
project
got
in,
but
my
project
didn't
get
in
and
why
was
it
rejected
and
in
and
I
think
they
also
haven't
been
doing
that
in
the
public.
B
They
they
do
it
quietly
in
the
background,
but
that
doesn't
help
other
projects
learn
what
they
should
be
doing
so
I
think
that's
I,
think
it's
okay
to
say
the
project
doesn't
fit
based
on
this
criteria
and
how'd
that
be
public
information.
I,
don't
think
that
needs
to
be
done
in
private,
so
I'm
hoping
there
is
more
transparency
that
comes
out
of
this.
F
B
Yes,
not
that
Jo
beta
brought
that
up
like
he
doesn't
want
to
have
like
a
criteria,
and
they
say
well
I
met
all
these,
so
then
you
have
to
accept
me
and
I
tried
to
make
the
language
in
there
address
things
like
that,
like
these
are
the
minimum
viable
criteria.
These
are
not
the
completeness
of
what
it
means
to
to
be.
You
know,
I
mean
we.
It
just
needs
to
be
worded
in
a
way
that
gives
the
TOC
the
flexibility,
but
it
also
gives
a
good
enough
direction
for
these
projects.
A
I
think
it's
definitely
a
step
in
the
right
direction.
I
mean
for
for
what
it's
worth.
My
my
two
cents
is
that
the
sandbox
is
a
great
place
where
a
project
can
mature
and
get
and
gain
its
its
its
first
few
steps
under
the
foundation
right
and
I.
Think
a
lot
of
the
challenge-
and
you
know
especially
the
comments
about
the
gaming
rights-
is
because
the
sandbox
shouldn't
be
about.
A
Think
the
the
key
thing
that's
missing
here
is
that
you
know
the
guidelines
around
not
marketing
and
keeping
the
sandbox
projects
as
a
separate
category
are
really
really
important,
because
a
lot
of
the
question
marks
that
we
kind
of
keep
on
keep
keep
on
hitting
around
removing
all
those
are
because
the
sandbox
projects,
then
you
know,
directly,
do
get
marketed,
and
things
like
that,
so
people
do
see
the
sandbox
projects
as
getting
again
and
I.
Think
that's
that's
a
challenge
here.
E
A
B
Well
and
I
agree
and
I
I.
It
was
unsettling
to
hear
such
diverse
comments
around
sandbox
in
in
from
the
TOC
board
of
what
people
thought
it
should
be.
You
know
what
I
mean
like
I,
think
some
people
have
really
high
expectations
of
what
they
think
a
sandbox
project
should
be,
whereas
I
have
I
feel
like
a
long
time
ago,
we
removed
like
the
due
diligence
for
sandbox,
for
the
exact
reason
that
it
could
it
could
grow
and
flourish
and
expand
the
community
there.
So
I
mean
things
like
that
have
to
be.
B
C
The
the
fact
that,
like
I,
think
when
they
were
discussing
sandbox
projects,
they
were
talking
about
like
having
like
a
hundred
like
accepting
them
in
the
hundreds
which
I
have
which
probably
won't
scale
for
these
cube.
Con
sig
talks
right.
You
suddenly,
like
hundred
of
them,
want
to
present
that's
probably
not
going
to
work
out
eventually.
A
B
Feel
free
to
add
comments,
suggestions.
You
can
put
it
directly
in
the
docker
out
as
a
comment.
I
mean
I,
don't
I
want
it
to
be
a
community
driven
document.
I,
don't
feel
like
you
necessarily
need
ownership
of
any
of
this
I
just
would
like
to
include
for
everyone
and
I.
Think
we've
certainly
ran
into
some
of
these
things.
You
know
just
as
one
of
being
one
of
the
new
SIG's
reviewing
projects,
so
your
input
is
desired.
B
A
Cool,
did
you
did
you
to
having
this
sort
of
done
by
any
particular
date
or
having
any
times
it's
off
to
the
next
sick,
but
by
any
particular
dates?
No.
B
They
just
it
was
like
a
last
minute
thing:
hey
can
you
join
and
talk
about
your
doc
and
I
said
sure
and
then
I
didn't
commit
to
dates
or
finalization.
They
they
wanted
some
time
to
review.
I
can
bring
that
up
on
the
next
public
call
and
we
can
figure
out
a
date
that
we
could
ride.
Ideally,
I
think
we
would
want
it
done
by
Q
Khan.
We
would
want
to
have
this
criteria
set
forth
published
and
you
know
so.
New
projects
can
look
at
it.
Hearing
to
that,
yeah.
A
A
Okay,
so
what
I
wanted
to
do
next,
then,
is
the
the
the
last
thing
on
the
agenda
is
to
discuss
the
the
benchmarking
and
performance
paper
which
I've
only
just
started,
putting
together
and
I
kind
of
want
to
apologize
for
letting
this
slip.
I
was
meant
to
set
up
a
call
a
couple
of
weeks
back
and
then
life
happened
and
it
didn't
quite
happen
as
I
planned.
So
what
I'd
like
to
do
just
now
is
discuss
some
of
the
ideas
and
perhaps
have
a
little
bit
of
a
brainstorm.
A
So
the
things
that
we
absolutely
don't
want
to
touch
is
we're
not
going
to
be
publishing,
benchmark
numbers
and
we're
not
going
to
be
providing
sort
of
our
own
vendor
or
product
or
project
comparisons.
It's
it's.
It's
all
about
sort
of
providing
the
end-user
with
the
ability
to
run
their
own
tests,
thoughts,
comments,
questions.
A
Where
you
know
different
people
might
want
to
publish
different
benchmarks
and
they
tweak
everything
for
a
particular
use
case
and
I.
Don't
really
want
to
get
into
that
into
that
arena.
Where
we're
having
to
argue
the
pros
and
cons
or
the
Howard.
Do
you
compare
apples
to
apples
between
different
benchmarks,
different
numbers,
so
what
I'd
really
like
to
focus
on
is
to
give
people
the
ability
to
run
their
own
tests
on
their
own
environment.
A
So
if
they're,
if
they're
looking
to
test
two
projects
in
there
or
two
tools
in
there
or
two
providers
or
service
providers
or
two
storage
vendors
in
their
equipment,
ethics
cluster,
they
can
use,
they
can
use
the
tools
to
sort
of
compare
them
in
their
own
environment
as
opposed
to
and
I
know.
Obviously
what
it
allows
them
to
do
is
for
the
end
users
to
then
actually
publish
their
own
numbers,
but
that
would
be
their
numbers
for
their
environment
as
opposed
to
our
numbers
and
some
hypothetical
environment.
C
A
Well,
yeah
I
mean-
and
this
is
why
I
said
you
know
I
kind
of
wanted
documents,
common
pitfalls.
So,
for
example,
you
know,
storage
systems
will
go
faster
if
they're
replicating
with
loose
consistency
or
asynchronously
rather
than
synchronously,
and
you
know
they
will
perform
amazingly
if
the
entire
data
sets
exists
in
cache
and
isn't
actually
hitting.
You
know
physical
media,
for
example,
and
things
like
that,
so
these
are
things
we
can.
We
can
actually,
you
know,
have
a
few
paragraphs
to
actually
document
these
things.
A
So
people
know
what
they're
comparing
but
I,
don't
really
want
to
get
into
the
into
the
complex
scenarios
of
trying
to
justify
why
a
particular
system
has
a
particular
number,
because
I
think
that's.
If,
if
you
know,
if
promoting
a
particular
project
is
a
can
of
worms
describing
the
performance
of
a
particular
project
is
a
gigantic
kind
of
worms.
I'd.
D
A
This
is
this
is
more
a
case
of
we've
written
a
paper
and
people
understand
the
different
aspects
and
different
attributes
of
a
storage
system,
and
what
we're
trying
to
do
here
is
give
them
the
capability
of
measuring
one
of
the
attributes,
which
happens
to
be
performance,
and
we
might
you
know
the
next
thing
might
well
be
something
like
consistency.
For
example,
then
we
might
suggest
different
tools
to
test
those
kind
of
conditions,
but
I
don't
actually
be
in
the
market
of
publishing
the
marketing
numbers
so
to
speak.
Yeah.
D
A
B
And
so
do
we
need
to
have
a
disclaimer
that
they
can't
also
use
those
numbers
to
feed
their
own?
That,
like
I,
don't
at
all
disagree
with
the
reasoning
behind
it,
but
I
also
don't
want
it
to
be
used
as
a
weapon
against
other
people
saying
using
the
benchmarks
for
their
own
purpose.
Then
I
mean
do.
How
will
we
prevent
the
other
side
of
it?
Even
though
we
don't
publish
it?
How
do
we
prevent
other
people
from
taking
those
numbers
and
doing
comparisons
are.
B
D
B
F
B
F
A
So
so,
first
off
so
a
couple
of
things
in
in
the
first
instance
we're
not
building
a
tool
or
a
framework
we're
describing
tools
which
are
publicly
available
anyway,
and
most
of
those
have
some
sorts
of
disclaimers
anyway
of
their
own,
but
either
way
you
know
we're
not
saying
we're
not
building
a
tool.
That's
somebody
who's
going
to
use
the
cnc
of
storage
tool
or
whatever
right,
but
also.
Secondly,
I
think
the
CNC
F
is
fairly
well
documented
things
around
trademarks
and
things
like
that.
A
D
I
agree,
and-
and
the
other
thing
in
terms
of
stopping
them
from
a
legal
perspective,
in
the
sense
that
you
know
we're
pretty
much
on
an
open-source
license
with
that
allows
people
to
fork.
It
will
I,
don't
see
how,
since
anything,
we
produce
would
be
under
the
open-source
license
that
people
couldn't
take
whatever
it
is
and
declare
that
they
had
forked
it.
Therefore
they
can
do
whatever
they
want.
A
B
C
We
should
talk
about
how
to
configure
the
tools
and
basically
not
how
to
configure
the
database
that
they
are
testing
against
right.
That's
what
it
amounts
to
yeah,
exactly
and
mention
that
this
benchmark
tests,
this
type
of
workload,
so
make
sure
that
your
the
workload
that
you
intend
to
run
in
your
production
matches
what
the
benchmark
is
trying
to
do.
A
A
A
So
so
initially,
when
I
was
what
I
was
thinking
of,
doing
was
focusing
on
volumes
and
databases
as
to
things
to
to
measure.
I
know
that
we
could
also
potentially
do
key
value
stores,
but
I
don't
have
a
ton
of
experience
in
that
space
unless
somebody
wants
to
help
with
that
area.
But
certainly
you
know
in
the
in
the
volume
space
there
are.
A
There
are
a
number
of
good
open-source
tools,
including
you
know,
like
the
obvious
ones
like
FIO,
where
we
can
sort
of
document
the
different
types
of
different
types
of
sort
of
benchmarking
criteria
and
block
sizes
and
random
versus
sequential
and
read/write
ratios,
and
caching
versus
non
caching
and
compressed
versus
uncompressed.
Indeed
view
versus
on
these.
You
can
you
know
all
of
those.
You
know
obvious
things
which
are
which
are
fairly
well
understood
and
I.
Think
with
with
databases,
there's
you
know,
certainly
quite
a
bit.
A
We
can
do
with
things
like
you
know,
sis
ventra,
or
something
like
that
with
key
value
stores.
Perhaps
there's
the
wire
CP
benchmark
suite,
which,
which
is
quite
popular
there,
but
I
would
probably
need
a
bit
of
help
to
to
structure
that
bit
of
the
document.
So
what
do
you
guys
think
about
sort
of
focusing
on
volumes
and
databases
as
a
first
step.
C
Yeah,
so
we
have
a
via
ourselves
lon,
both
suspension,
TPCC
benchmarks,
and
when
I
was
at
YouTube,
we
actually
ran
YC
us
be
against
her
with
us,
but
those
are
kind
of
I.
Don't
know
how
much
why
CSP
has
evolved.
Since
then,
yeah
I
mentioned
that
I
I
could
have
the
person
who
ran
the
benchmarks
document
about
how
it
should
be
run,
since
bench
is
fairly
straightforward.
C
A
C
A
A
G
G
A
I
mean
so
I
mean
that's.
That
would
be
the
SSD
right.
Cliffs
would
be
one
of
those
things
where
I
would
suggest
it
would
come
under
the
common
pitfalls.
So
you
know
just
because
people
run
these
sorts
of
tests
and
and
if
they
don't
run
them
for
long
enough,
for
example,
they
they
they
kind
of
get
to
see
the
cached
version
of
the
SSD
and
and
then
it
slows
down
over
time.
D
A
So
if
we,
if
we're
kind
of
agreed
on
on
some
of
these
concepts,
I
could
put
a
quick
outline
together
and
then
it
would
be
really
awesome
if
we
could
have
maybe
just
a
separate
call
for
the
people
who
are
really
interested
in
helping
write
some
of
the
content
to
get
together,
and
we
could
kind
of
split
up
the
work.
If
that
makes
sense,.