►
From YouTube: CNCF Storage WG Meeting - 2018-09-26
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
Quit
I
think
we're
ready
to
get
it
kicked
off
whenever
you
are
I
feel,
like
you
know,
we've
missed
to
a
handful
meetings
and
I.
Think
the
participants
at
this
point
are
those
that
are
focused
on
being
a
part
of
the
white
paper,
so
I
think
until
we
make
more
noise
about
it,
a
little
working
on
it
like
I,
think
this
group
is
probably
what
we
can
expect
to
to
show
up
at
the
meeting
right
now.
A
B
C
So
it's
a
first
off,
as
you
can
see,
there
hasn't
been
the
range
of
progressive
thought
Health's
there.
Everything
I
was
just
explaining
the
clint's
of
a
low
reading
busy
couple
of
months
and
not
had
enough
opportunity
to
puts
the
focus
on
if
needed.
But
what
I've
done
so
far
is
a
restructured
book
based
on
what
we
had
agreed
previously,
so
I've
created
placeholders
and
the
the
sections
that
I
think
we
need
to
write
up.
C
Otherwise,
I
guess,
Xena
and
I
will
continue
to
work
on
this.
Now
that
there's
a
bit
of
structure
in
there
and
we'll
see
where
we
take
this
over
the
next
couple
of
weeks,
but
I
think
we
probably
need
to
hydrate
a
little
faster
though
I
would
suggest
if
we
have
two
or
three
volunteers
that
will
work
together.
Maybe
we
could
have
a
call
for
half
an
hour
every
couple
of
days
and
just
keep
the
progress
going.
Is.
A
A
Maybe
we
could
get
people
to
I
mean
what
maybe
we
could
have
someone
going
and
actually
a
highlight
sessions
and
say
like
here's,
where
we're
looking
for
a
volunteer
and
have
a
good
comment,
you
get
people
to
sign
up
that
way
or
do
you
want
people
to
sign
up,
and
just
you
know,
take
sections
of
it
and
say
I
want
to
work
on
this
I,
don't
know
sorry
kind
of
another.
One
follow-up
is:
are
we
think
we're
ready
to
actually
like
pare
it
down
at
all
like
is
it?
C
C
One
of
one
of
the
things
I
was
going
to
propose
is
in
the
end
of
examples
of
file
system
and
block
device,
etc.
I
was
going
to
take
a
first
class,
it's
putting
down
some
of
those,
some
of
some
of
the
examples,
whether
it's
file
systems
or
block
devices
or
object
stores
or
whatever
else,
and
even
some
of
the
databases
and
then
maybe
reaching
out
to
a
broader
group
to
kind
of
say,
hey.
You
know
for
this
as
a
project.
It's
a
list
of
database.
C
You
want
to
supply
two
paragraphs
to
explain
with
Vanessa's
and
how
it
compares
that
Vigneron
and
howitzer
crates
to
the
rest
of
the
terminology
that
we've
talked
about
or
hands.
You
know
data
protection
and
consistency
and
reliability,
and
all
of
those
sorts
of
things
and
and
kind
of
just
crowdsourcing
to
the
examples
by
asking
the
maintainer
of
those
examples
to
actually
add
that
they
do.
A
C
The
first
the
first
space,
so
the
attributes
of
the
storage
system
that
they
can
access
interface
and
the
storage
second
layers.
I,
do
have
a
bunch
of
rough
notes,
which
will
mean
I
can
probably
get
this
done
in
a
few
days
or
maybe
we
cursor
and
then
the
thing
I
don't
know.
Are
you
still
comfortable
picking
up
the
orchestration
in
the
management
interfaces
section?
Yes,.
D
B
A
A
C
Crazy
yep.
C
E
A
A
B
Think-
and
this
is
a
question
to
the
group-
and
my
thinking
was
that
it
would
be
very
useful
to
have
generic
statements
about
fundamental
properties
of
local
block
stores.
You
know
remote
block
stores,
etc
and
not
just
have
a
sort
of
laundry
list
of
products.
I
think
it's
great
to
add
to
add
the
products
there
as
examples
of
whatever
category
of
store,
we're
talking
about,
but
I
think
it's
as
important
or
more
important,
perhaps
to
have
the
fundamental
generic
statements
about
these
classes
of
store,
yeah.
E
Actually
I
completely
I
was
thinking
the
same
thing
just
a
few
minutes
ago
and
I'm
glad
you
mentioned
that
because
sometimes
what
my
concern
is
is
as
we
continue
forward,
and
this
document
becomes
a
live
document
for
every
new
company
that
comes
in
and
adds
a
little
section
to
it.
So
it
becomes
like
a
the
sections
with
the
companies
become
larger
than
the
generic
session
that
which
is
showing
the
reader.
What
you
know
trying
to
teach
them
what
what
storage
is?
So
that's
my
concern.
So
maybe
we
can.
E
C
Completely
completely
agree
and
I
think
you
know
this
is
what
I
opted
to
have
to
document
the
store
stock
in
the
layers
and
yes,
interfaces
up
front
today.
This
is
what
the
block.
This
is,
what
the
attributes
of
the
block
access
interface
are.
These
were
the
attributes
of
actors,
interface,
our
and
the
sheriff
system,
etc.
But
then
also
it's
a
different
layer.
Isn't
that
and
part
of
that
is
about
you
know
having
local
and
remote
and
the
difference?
Apologies
and
whether
its
charges
or
low
pilots
or
all
of
those
things?
C
So
that's
so
that's
when
we
and
we
then
come
to
the
block
section,
and
we
say
this
is
local
block.
We
can.
We
can
quickly
make
a
reference
back
and
say:
local
black
bullet
local
block.
Has
these
attributes
around
availability,
scalability
performance,
consistency,
durability,
etc.
Agarose
block
has
these
things
of
this
tributed
block?
Has
these
things
and
then
we
can
give
some
examples,
but
we
don't
have
to
we
don't
have
to.
C
B
Yeah
sounds
great,
so
I
guess
the
question
is:
how
do
we
flesh
out
these
remaining
sections
as
quickly
and
I?
Really
really
like
the
the
stuff?
That's
in
the
block
already
I
think
it's
it's
the
right
approach
to
presenting
all
of
this
information
I'm,
just
as
I
mentioned
the
email
to
a
couple
of
you
and
I'm
concerned
that
that
we're
not
going
to
get
it
done
in
the
next.
Let's
call
it
four
weeks,
five
weeks
and
so
yeah
I
guess.
B
The
question
is:
how
do
we
fill
in
the
missing
bits
too,
particularly
towards
the
end
of
the
document
which
are
arguably
I?
Think
the
groundwork
has
been
layered
on
terminology
and
the
approach
to
analyzing
and
presenting
these
things
is
very
valuable.
But
ultimately
it's
the
end
of
the
dock
that
that
that
benefits
from
all
of
that-
and
so
you
know,
one
approach
is
to
take
to
find
volunteers
who
have
specific
expertise
in
these
particular
areas.
You
know,
possum
is
perhaps
a
good
example
for
block
stores.
B
I
think
rook
was
originally
designed
for
safe
and
and
now
is
support
other
things,
but
that
find
people
who
who
can
talk
to
the
generic
sections
before
they
perhaps
go
into
any
particular
products
or
power
projects.
It
obviously
has
the
risk
that
people
who
have
a
specific
block,
store
product
or
project
will
perhaps
be
a
little
biased
in
how
they
present
the
generic
information.
B
A
Figuring
out
how
to
delegate
and
get
other
folks
involved
to
help
fill
us
out,
it's
gonna
be
important.
You
know.
The
other
point
to
bring
up
is
the
things
that
have
been
assigned
to
Alex
me
and
Shang.
Those
relating
to
you
know
the
lower
level
like
unstructured
block,
and
you
know,
file
systems
below
that
that
we
don't
have
assigned
is
more
structured,
so
object,
stores
and
key
value
stores
and
databases,
and
you
know
if
we're
gonna
try
to
pare
this
down
to
actually
get
it
done.
A
D
B
E
A
B
Great
and
and
I
would
personally
be
comfortable
if
we
deferred
databases,
I
mean
it's
a
big
enough
area
and
we
specialized
and
most
people
know
what
a
database
is
and
roughly
what
it
looks
like
and
so
I
don't
think
that
area
will
be
as
valuable
as
some
of
the
other.
The
other
two
you
mentioned
for
completeness.
We
want
to
do
it
eventually,
but
I
think
it's
arguably
less
well,
which
people
are
much
more
vague
about
how
I
mean
what
these
things
are
here.
E
B
C
C
C
This
document
kind
of
fell
apart
this
time
last
year
as
soon
as
we
started,
trying
to
work
on
who's
in
and
who's
out
and
all
of
that
sort
of
rare
the
base.
So
I,
you
know,
listen
learnt.
We
don't
want
to
do
that
again
and-
and
you
know,
I'm
happy
if
say
between
Clint
you
me
and
seeing
more
movies.
You
know
we
keep
like
editorial
control
over
documenting
it.
B
I
think
once
once
the
guts
of
it
is
there,
you
know
we
should
definitely
open
it
up
for
comments
and
and
I'm
hoping
that
we'll
get
some
valuable
input
and
many
of
those
will
result
in
changes
to
the
document
I'm
sure
and
but
but
it
needs
to
keep
the
general
flow
and
structure
saying.
Otherwise.
It
can
be
a
bit
of
a
throwing
stuff
against
the
wall,
cool,
excellent,
I'm,
very
comfortable
with
the
way
things
are
moving.
B
C
A
C
C
C
B
Appendix
was
something
I
threw
in
there
and
it
was
really
just
generic
algorithms,
technologies,
etc
that
apply
across
many
of
the
areas.
So
it
was
really
a
grab
bag
for
stuff
that
didn't
fit
cleanly
into
any
other
section.
It
may
be
that
it's
already
covered
elsewhere
or
again.
Perhaps
we
can
defer
some
of
that
stuff.
E
C
B
Know
I
know
a
fair
amount
about
all
of
those,
and
I
can
do
it
very
I
mean
I'm
not
going
to
go.
You
know
into
great
detail:
I
might
put
a
reference
to
the
paxos
paper
and
the
raft
paper
and
basically
just
have
a
you-
know
three
line
item
for
each
one
of
those
to
explain
the
essence
of
them
and
how
they
differ.
C
B
A
From
everybody
you're
in
colic,
as
we're
filling
in
these
sections,
that
we
don't
need
to
rewrite,
what's
already
written
in
detail
like
abusive
sentences,
something
meaningful
and
a
link
to
established
and
a
credible
source
that
describes
a
tech
is
better
than
trying
to
rewrite
it
from
scratch.
Oh
completely
yeah.
A
C
B
I
think
that
the
one
part
that
is
pretty
important
is
being
able
to
sensibly
compare
some
of
these
things
against
the
properties
that
we've
mentioned,
and
you
know
there
may
be
links
to
some
subsets
of
those
comparisons,
but
I
think
at
the
end
of
the
day,
having
a
consistent
those
tables
that
we
provisionally
put
in
there
I,
don't
know
what
it
was
Alex.
Does
it
make
sense
to
continue
to
plan
to
film
for
those?
Oh,
yes,.
C
C
C
Yeah
I
was
I,
was
kind
of
pretty
to
think
about
this.
Maybe
it's
slightly
differently.
I
had
another
table
which
I
haven't
copied
in
yet
to
say
to
make
a
table
based
on
the
layers
rather
than
the
attributes,
because
the
layers
actually
define
the
attributes
in
most
cases,
so
so
as
as
I'm
as
I'm
writing
down
the
layers.
You'll
see
I've
kind
of
set,
for
example,
sorry
for
all
this
getting
around
but
like.
C
It's
like
a
axes
interface.
It
defines
how
we
access
the
storage
system,
but
it
also
influences
availability
to
performance
with
scalability
in
different
ways
and
therefore
fine
saying
the
local
fastest
whereabouts
file
system
implements
the
data
access
layer.
This
way
it
gives
you
a
better
way
of
showing
how
to
find
those
those
specific
attributes,
rather
than
listening
at
those
attributes
every
single
time,
because
otherwise
they
become
too
painful
for
for
the
various
examples.
C
So
so,
for
example,
if
we
just
say
a
local
file
system,
does
this,
we
don't
take
into
consideration
some
of
the
other
properties
which
affects
those
attributes,
because
many
of
these
systems
are
layered.
So,
for
example,
you
know
you
look
at
an
RPC
device
from
self
which
is
a
block
device,
and
it's
an
you
can
argue,
it's
a
distributive
block
device,
but
it's
actually
based
on
the
Ceph
object,
store
mechanism
and
the
availability
and
the
data
recovery
of
the
data
protection
is
all
that
to
the
layers
of
self
as
opposed
to
the
block
device
itself.
C
For
example,
the
block
devices
a
data
access
interface
does
affect
availability
in
terms
of
how
you
move
that
block
of
ice
between
nodes
and
the
management
interface
for
that
block
device.
So
I
was
thinking
fine,
even
those
terms,
as
opposed
to
just
just
a
row
table
of
the
attributes
so
kind
of
saying,
with
with
a
local
classes
that
these
are
the
layers.
This
is
how
it
affects
the
attributes,
because
each
one
of
those
layers
changes
the
attributes.
B
Yeah
yeah
I
think
that's
fair,
the
one
thing
which
I
thought
when
I
knocked
this
thing
together
and
to
be
clear,
those
tables
I
bashed
out
in
five
minutes,
so
I
didn't
give
any
deep
thought
to
them.
But
what
I
thought
was
valuable
is
you
know,
I,
think
it's
more
about
distributed
versus
shard
adverse
local,
that
there
has
pretty
fundamental
effects
on
those
properties
which
ever
lay
you're
talking
about
and
you're
absolutely
right.
B
B
C
A
A
C
Apply
equally,
whether
it's
a
fan
system
or
a
block
device
or
an
object
store,
and
then
on
top
of
that
you
have,
for
example,
the
actual
interface
which
also
defines
you
can
availability
in
terms
of
failover
or
something
like
that.
So,
for
example,
if
it's
a
because
it's
a
shared
bond
system
interface
on
top
of
a
distributed
store,
then
just
have
to
move
them
out.
A
B
C
I
mean
we
should.
We
should
probably
aim
to
have
drafts
to
the
working
group
for
the
for
the
Wednesday
26
for
over
obsession
right.
A
B
Yeah
I'm
a
little
hesitant
to
fall
foul
of
not
giving
people
enough
time
to
review
and
comment
and
presenting
it
as
final
before
everyone's
had
that
opportunity,
so
I
would
be
slightly
more
comfortable
saying
this
is
our
draft.
It's
currently
under
review.
Please,
you
know,
give
it
some
thought
and
look
at
it
and
maybe
present
the
final
one
in
Seattle
month
later.
A
C
Know
if
this
helps
I
know
you're
preparing
a
presentation
for
for
the
cubic
on
China
I,
actually
sort
of
presented
the
rough
outline
of
this
document
to
meet
up
a
couple
of
weeks
back
and
put
some
sort
of
presentation
with
a
handful
of
slides
together.
So
I
can
I
can
share
that
with
this
group,
and
you
know
we
can
maybe
use
that
as
a
starting
document
for
the
presentation
to
take
on
China.
If
you
think
that
helps
that
sounds
fantastic.
B
B
One
other
comment
ahead
about
the
document
in
general.
Is
that
I
think
a
level
of
detail
in
the
doc
is
very
good
at
the
moment.
I'd
only
get
this
a
lot
of
kind
of
meta
discussion,
around
options
we
considered
etc,
which
is
valuable
but
I,
think
we're
gonna
have
to
condense
this
thing
into
something
much
more
consumable,
because
the
vast
majority
of
the
audience
consuming
this
I
think
is
not
gonna.
B
Have
the
attention
span
to
be
able
to
read,
you
know
what
looks
like
it
might
become
a
50
or
60
page
document,
so
I'm
thinking
that
we
need
either
a
slide
deck
which
the
majority
of
people
can
consume
and
I'm
thinking.
20
slides
is
something
like
that
that
distills
the
essence
of
this
stuff
and
then
says,
if
you
want
more
detail,
go
to
the
document
because
I
think
the
document,
in
the
shape
that
it's
currently
panning
out
is
too
big
for
the
vast
majority
of
people
to
consume.
Well,.
E
B
A
B
Can
can
I
ask
you
Clint
to
perhaps
just
send
a
summary
of
what
we
just
decided
to
the
mailing
list,
yep,
so
that
those
who
not
here
know
that
there's
progress
being
made
and
and
who's
doing
what
and
what
the
timeline
is
and
then
maybe,
if
they
have,
the
bandwidth
could
volunteer
as
well.
So
you
can
solicit
volunteers,
it
seems
like
we
have
enough
people
right
now,
yeah,
so.
A
B
A
One
things
that
also
challenged
this
in
the
last
round
of
the
document
just
to
think
about
last
year
was
people
jumping
in
kind
of
last
minute
when
things
were
baked
and
I
know
that
I
would
say
we
want
to
have
more
of
a
pictorial
control
of
this
document.
So
as
I
write
that
email
and
I
say
they
like
get
involved,
is
it
fair
to
say
like
now?
Is
the
time
to
to
step
up
and
like?
What's
the
what's
the
friendly
language
to
basically
say
like.
B
Well,
I
think
they're
different
ways
of
going
about
I'm,
quite
in
favor,
of
having
a
very
limited
number
of
people
with
edit
control
over
the
document,
and
it
sounds
like
that
number
is
is
like
four
or
so
at
the
moment
and
then
commentary.
We
can
allow
people
to
comment,
and
then
you
know
their
comments
may
or
may
not
make
it
into
the
document
and
that's
at
the
discretion
of
the
primary
editor,
but
they
have
that
you
know
transparent
and
out
there.
So
people
can
make
comments
and
the
primary
editor
can
say.
B
A
C
B
I
would
I'm
not
sure
what
you're
thinking
is
a
Alex
but
I
I
think
the
document
is
too
premature
for
commentary
at
this
point.
I
think
there's
just
two
guys
missing,
so
I
would
I
would
say
we
close.
It's
not
open
for
comments,
but
if
you,
if
you
want
to
volunteer
to
write
one
of
the
sections,
please
contact
Alex,
that's
something
like
that.
Yeah.