►
From YouTube: CNCF SIG-Storage Meeting - 2019-09-11
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
So
Alex
had
something
that
came
up.
You
can't
join,
so
thank
you
for
having
everyone
add
their
notes.
The
agenda
I
think
what
we
wanted
to
cover
today
was
to
go
over
the
template
that
Lewis
was
working
on
if
he
happens,
to
join
and
then
also
the
database
paper,
the
so
Lou
was
working
on
and
and
if
there
are
other
agenda
items
that
people
want
to
add.
Please
go
ahead
and
add
them
here.
A
A
A
B
A
If
you
want
to
put
it
in
the
agenda,
you
have
edit
permissions
that'd
be
great,
if
not
just
put
it
in
the
chat
and
I'll.
Add
it
there.
Oh,
where.
A
A
B
B
A
D
C
A
A
B
You
had
the
one
thing
I
did
was
because
key
value
stores
and
databases
have
similarities.
Those
parts
I'm
not
covering
I
just
said,
look
at
key
value
stores
for
the
trade
offs,
so
I've
only
so
it's
kind
of
additives,
the
stuff
that
I
added
here
is
things
to
consider
beyond
what
you
would
otherwise
think
about
when
moving
a
key
value
store
into
cloud
storage.
B
A
B
B
D
D
The
scope
of
coverage,
because
there
are
people
who
choose
to
put
even
commercial
software
in
containers-
you
know
yeah
I
I,
don't
think
the
CNC
F
is
going
to
accept
a
non
open-source
as
a
project
or
promoted
aggressively,
but
still
the
user
community
sometimes
is
in
search
of
help
in
terms
of
how
to
do
them,
even
if
it's
only
to
support
a
legacy.
Application.
F
D
B
A
B
F
If
that
is
the
case,
and
definitely
you
know,
cockroach
DB
is,
is
you
know
verging
on
a
household
name
and
I?
Don't
know
whether
the
debate
was
whether
or
not
that
is
open
source,
but
irrespective
of
whether
it
is,
it
should
be
mentioned
on
the
basis
that
it's
not,
that
it
is
a
household
name
in
that
category
or.
B
F
I,
wouldn't
get
too
hung
up
about
the
definition
of
open
source
I
think
that
is,
as
you
say,
a
topic
for
a
different
discussion,
and
we
can
put
a
reference
if
there
is
a
sort
of
reasonably
good
reference
to
the
debate.
We
can
put
a
link
in
there
and
say
that
you
know,
depending
on
what
definition
of
open
source
you
use,
some
of
these
may
or
may
not
be
considered
open
source.
Something
long,
I
think.
C
B
F
F
D
F
D
F
A
B
B
B
G
One
thing
is
that
I
trying
to
understand
as
the
cloud
native
foundation,
parallel
Linux,
Foundation
and
then
again,
I'm
looking
at
this
for
the
big
picture
and
I
think
I'm
not
going
to
say
it
icon
anyway,
so
I'm
trying
to
think
that
we
should
be
very
open
source,
friendly
and
I'm
thinking
in
that
model.
We
should
not
even
have
my
opinion.
It
shouldn't
probably
have
at
all
anything
with
that
closed
source
at
all
in
the
paper,
because
then
that
becomes
a
marketing
thing.
Since
then,.
G
So
I
think
we
should
focus
very
very
clearly
on
something
as
open
source
and
anything
that's
closed.
Search
is
just
not
in
the
paper
and
paper
are
no
again
I
feel
that
way,
because
we
are
part
of
the
Linux
Foundation.
Now,
if
we
were
some
other
type
of
foundation
that
dealt
with
both
closed
and
open
source
projects,
then.
F
G
A
F
Yeah,
but
regarding
we
had
this
whole
debate
in
the
in
the
white
paper,
I
know
he
said:
I,
don't
know
if
you
remember
it
that
the
problem
with
your
approach
so
firstly
to
be
clear:
we
do
not
intend
to
be
exhausted
about
listing
all
non
open
source,
all
open
source
databases
and
we
decided
to
list
a
few
closed
source
ones
in
particular
where
they
provide
useful
information
to
contextualize
people's
brain.
So
when
you
talking
about
object
stores-
and
is
we
people
understand
what
s3
is
they
understand?
It's
it's
the
definitive
object
store.
F
It
was
the
first
one
and
it
sort
of
defines
the
category,
and
so
we
mentioned
it
explicitly
and
I
think
there
are
other
categories
that
have
similar
things.
We
did
not
exhaustively
mention
every
single
possible
closed
source
object
store,
but
we
did
mention
s3
and
Ana,
maybe
another
one
I,
don't
remember
and
I
think
we
should
be
consistent.
I
think,
personally,
that
that
principle
is
sound
and
I
think
we
should
continue
with
that.
Well,.
F
F
It
happens
not
to
be
a
open
source
as
far
as
I'm
aware-
and
it's
now
actually
I
believe
you
know
available
on
Google
cloud
as
a
commercial
offering,
but
I
think
it
should
definitely
be
here.
I
mean
everybody
just
about
everybody
has
heard
of
spanner
and,
and
it
helps
contextualize
what
the
other
things
are
and
which
what
the
categories
are
yeah
just
my
opinion,
yeah
I.
G
F
Think
we
do
need
to
have
a
principle
on
which
the
judgment
is
made
and
the
principle
I'm
proposing.
Is
there
where
it
is
a
name
of
a
commercial
product
which
is
reasonably
well
known
and
helps
to
contextualize
people's
thinking?
Then
we
should
mention
it.
You
should
not
try
to
be
comprehensive,
oh
yeah,
so
that's
the
basic
principle
place
yeah.
F
F
F
A
A
F
F
B
F
G
C
B
G
F
So
any
any
other
sections
of
the
white
paper
we
kind
of
broken
into
categories,
and
then
we
discussed
along
various
axes.
This
is
just
from
memory.
I've
just
read
your
document
now
sorry,
so
this
one
we
had,
you
know
the
distributed
versus
centralized,
etc,
and,
secondly,
we
had
the
relative
properties,
availability,
scalability,
performance,
etc.
B
Yes,
if
you
look
at
the
paragraph
after
after
the
mention
of
the
databases,
value
stores
and
databases
share
similar
usage
of
how
they
similar
way,
you
storage,
similar
in
similar
ways,
all
the
trade-offs
that
apply
to
key
value
stores
applied
to
databases.
Also
so
I
just
said.
Look
at
the
section
nine
point,
four
for
that:
okay,.
F
B
A
good
point
I:
we
could
get
into
that,
because
different
systems
offer
different
trade-offs
based
on
the
type
of
transactions
they
support,
but
I
even
I
am
not
too
sure
about
you.
You
will
require
the.
We
can
say
that
these
provide
these
days.
The
systems
provide
a
spectrum
of
trade-offs
between
consistency
and
availability,
but
there
are
like
very
strange
nuances
about,
for
example,
the
spanner
has
one
very
different
transaction
model.
I
believe
cockroach
is
very,
very
strict
acid,
yeah
and
then
tidy
be
may
offer
trade-offs.
B
B
G
I
completely
agree:
if
we
start
getting
too
deep
into
details,
we're
gonna
start
creating
white
papers
for
each
one
of
these
companies,
so
yeah
I
think
with
I.
Think
the
goal
really
is
to
create
enough
information
for
the
user.
To
then
read
those
white
papers
understand
them
right
and
not
really
to
describe
each
one.
It
really
tight.
We
need
to
kind
of
give
them
like
if
we
were
creating.
G
If
this
is
an
engineering
school,
we
did
this,
be
the
one
on
one
of
databases
right
and
they
will
read
it
and
it
would
be
a
true
document
that
would
live
a
long
lifetime
because
it
kind
of
describes
what
are
they
use
for
what
you
know,
what
are
some
of
the
models
and
then
from
there?
They
can
then
understand
the
specific
product
right.
C
F
B
F
C
F
Think
it's
ambiguous
as
to
whether
it's
a
database
or
a
key
value
store
and
I
certainly
think
a
lot
of
people
have
in
their
heads
that
it's
a
no
sequel
database.
Yes,
that's
a
common
understanding,
so
at
the
very
least
we
can
just
put
a
reference
in
both
sections.
We
can
say
we
put
it
in
here.
If
people
don't
see
it
in
here,
they'll
say
why
the
hell
they're
not
mention
Cassandra
and
the
databases-
hello,
hello,
hello,.
B
F
F
We
actually
noticed
you
getting
disconnected
and
we
waited
for
you.
I'm
just
gonna
respond
to
suga's
point
about
not
getting
into
the
details
of
the
specific
project
and
I
agree
100%.
We
can't
we
can't
go
into
detail
about
every
one
of
the
projects.
What
we
definitely
want
to
do
is
I
mean
I.
Think
the
crux
of
of
the
whole
issue
is
this:
trade-off
between
essentially
strict
acid
and
isolation,
their
various
other
things
and
I.
F
Think
we
have
to
deal
with
that
in
a
reasonable
amount
of
detail
in
its
generality
that
there
are
these
fundamental
trade-offs
that
all
of
these
databases
make
and
what
the
spectrum
of
trade-offs
is,
and
we
could
even
just
taking
the
CN
CF
databases
as
an
example
TI
DB
and
the
tests.
We
could
point
out
where
those
for
you
know
on
the
spectrum,
and
they
do
you
know
they're
both
configurable
and
they
both
have.
You
know
configurable
trade-offs,
but
in
general
they
fall
somewhere
on
that
spectrum.
I
think
that
would
be
very
useful.
Yeah.
F
Then,
as
for
the
Cassandra
mine,
my
personal
feeling
is
that
it
is
you
right,
it
is
ambiguously
a
key
value
store.
A
database
is
definitely
a
lot
of
people
who
think
of
it
and
or
have
read
about
it
as
a
no
sequel
database.
So
I
think
we
should
mention
it
here,
even
if
it's
just
to
say
we
dealt
with
a
in
a
key
value,
store
section
C
there
we
didn't
forget
about
it
here.
F
That's
a
good
idea
and
maybe
just
make
it
very
clear
where
we
drew
the
line
in
our
paper.
You
know
we're
dealing
with
some
things
and
calling
them
databases
and
some
things
and
calling
on
key
value
stores
and,
as
you
say,
there's
a
bit
of
a
blurry
line
between
the
two.
So
maybe
we
just
need
to
make
a
statement
as
to
where
we
artificially
drew
that
line
for
the
purposes
of
this
paper.
So.
B
F
G
F
B
G
B
F
Relational
databases
absolutely
and
I
think
relational
databases
are
one
kind
of
database.
You
know
that
you
know
all
the
contention
around
distributed
and
no
sequel
and
all
of
that
stuff
that
that
distinction
existed
a
long
time
ago,
yeah
yeah
nineties,
we
had,
you
know,
object,
relational
mapping,
z'
ir
M's
and
all
these
kind
of
things,
and
they
they
in
fact
don't
even
explicitly
support
an
SQL
right.
They
provide
an
object
interface,
not
in
the
sense
of
blob
stores
or
yeah.
B
People's
minds
cool
so
in
my
notes,
I
have
I,
will
add
Cassandra,
maybe
with
an
asterisk,
with
saying
that
there
are
systems
like
there
are
some
key
value
stores
that
are
beginning
to
look
more
like
databases,
Cassandra
is
one
such
example.
I
think
I'll,
add
that
sounds
good
and
then
I
will
cover
add
a
paragraph
that
covers
the
trade-offs
that
databases
make
about
acid
versus
availability.
F
B
F
Yeah,
even
that's
debatable
at
the
risk
of
dragging
us
out
too
much,
but
I
mean
one
of
if
you
just
zoom
out
of
the
detail.
I
think
our
one
of
our
responsibilities
here
is
to
educate
people
as
to
the
spectrum
and
differences
between
all
these
things,
that
people
call
databases
yeah
and
focus
on
the
important
ones.
So
so,
obviously
you
know
consistency
all
of
that
stuff.
F
They
don't
exactly
advertise
what
they're
missing,
and
so
people
really
have
to
go
and
dig
around
and
figure
this
stuff
out
for
themselves.
So
so
what
we're
trying
to
do
is
help
people
not
have
to
do
all
that
homework
yeah
and
in
one
place
say
these
are
the
you
know.
These
are
the
properties
that
can
be
present
in
a
cloud
database.
If
you,
if
you
choose
these
properties,
you
typically
can't
get
these
other
properties,
because
they're
inconsistent
we've
got
the
current.
F
F
I
mean
every
one
of
these
fields
is
actually
a
whole
nightmare
in
itself.
There
are
some
sections
on
these
things
in
the
rest
of
the
white
paper
and
you
can
refer
to
them
where
possible.
There's,
for
example,
I
wrote
a
specific
section
on
consistency,
I
think,
and
we
can
expand
that
if
you,
if
you
have
some
more
thoughts
on
it,
oh
yeah.
B
I,
can
that
may
be
actually
a
good
idea,
because
that's
a
because
some
of
those
things
apply
to
other
systems
too
I
think
the
way
I
would
do
it
is
do
the
read
after
write
consistency
as
a
generic
section,
because
that
applies
to
multiple
other
data
stores
but
acid,
specifically
to
data
bases
because
they
are
kind
of
you.
Don't
talk
about
acid
if
you
are
not
talking
about
a
database,
yes,.
F
F
It's
not
very
comprehensive,
I
wrote
it
in
a
rush,
and
the
main
aim
was
just
to
tell
people
that
consistency
means
a
whole
lot
of
things.
So
don't
don't
believe
that
you
understand
it
until
you've
read
all
of
these
various
papers
about
consistency,
but
if
you
want
to,
if
you
want
to
add
some
detailed
stuff
there
or
also
more
stuff
about
read
after
write,
I
think
that
could
be
valuable
sounds.
F
Okay,
so
I
think
we
have
two
more
items
on
the
other
than
I'm
aware
of
and
sorry
I
dropped
in
late,
so
I
hope
this
is
up-to-date,
so
Lewis
has
been
doing
some
work
on
various
papers,
which
will
ask
him
to
give
us
a
sort
of
an
update
next
time.
The
other
thing
we
have
been
doing
and
Aaron
in
particular,
has
been
there's
been
a
little
bit
of
concern,
I,
think
about
inconsistency
of
dealing
with
projects
that
apply
to
the
CNC,
F
and
I.
Think,
particularly
at
the
sandbox
level.
F
F
You
know
you
will
get
and
accept
or
reject,
within
a
certain
bound,
the
timeframe
etc
rather
than
some
of
these
projects,
which
kind
of
drag
on
and
drag
on
and
on
find
sponsors
and
this
and
that
so
it
the
documents
not
ready
for
broad
review,
but
hopefully
it
will
be
within
the
next
week
and
we'll
send
it
out
to
the
mailing
list.
But
it
is.
There
is
a
first
draft
of
it
out
there,
but
Aaron's
just
tidying
up
for
general
consumption.