►
From YouTube: CNCF Storage Working Group Meeting 9/20/17
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
A
Should
add
a
little
feature
to
a
zoom
that
shows
you
when
the
rated
participants
joining
has
decreased
to
us.
A
All
right
thanks,
everyone
for
joining
I've,
been
on
the
tears
you've
been
in.
A
Helping
to
chair
the
storage
working
group,
so
we've
had
a
couple
of
sessions
now
I
think
they've
been
great
sessions.
We've
talked
about
some
good
stuff.
Clint
and
Steve
gave
a
great
presentation
to
the
TSC
weeks
back
about
some
of
the
conversations
and
we've
also
had
some
mailing
look
threads.
Where
there's
been
questions
raised
about,
you
know.
What's
the
fundamental
charter
of
the
storage
working
group,
if
we
consider
or
view
that,
should
we
take
online
and
what
artifacts?
A
If
any,
should
we
try
to
create
and
so
I
kind
of
wanted
to
devote,
rather
than
pull
in
another
person
to
come,
speak
in
today's
session?
There's
lots
of
folks
that
want
to
continue
to
talk
about
the
projects,
and
so
I
really
wanted
to
devote
today's
session
to
really
just
discussing
what
we
want
the
Charter
of
the
working
group
to
be
what
we
want.
A
Then
I'd
like
to
transition
after
we
get
more
clarification
and
what
we
do
want
to
work
in
I'd
like
to
transition
to
actually
talking
about
that
I'm
figuring
out
how
we'd
like
to
put
that
together
again
that
second
second
topic
is
assuming
that
the
group
is
supportive
to
index.
If
the
group
is
not
in
support
of
doing
that,
then
scratch
that
does
that
make
sense.
A
So
why
don't
I
take
a
quick
stab
at
the
idea
behind
the
storage
work
group
when
we
first
wanted
to
put
it
together
and
then
and
then
we'll
go
from
there.
So
after
there
was
a
lot
of
discussions
about
CSI
container
storage
interface,
it
became
really
clear
to
a
handful
of
folks,
especially
chatting
with
folks,
like
Chris
Chris
Anna
check
at
the
CN
CF
and
others
that
there
was
a
lot
of
other
things.
A
We
probably
want
to
talk
about
around
storage,
whether
it's
bringing
in
other
projects,
whether
it's
creating
artifacts,
like
a
storage
landscape
or
a
white
paper,
whether
it's
even
just
being
an
initial
vetting
mechanism
for
the
COC.
So
we
can
discuss
and
do
due
diligence
around
projects
that
that
we
might
want
to
bring
into
the
TSC
that
that
could
sort
of
be
the
function
of
the
storage
workgroup
and
it
was
separate
from
CSI
in
a
CSI.
A
We
wanted
to
still
be
able
to
be
its
own
independent
project
that
could
really
mature
and
get
to
a
place
where
that
community
felt.
You
know
they
were
ready
to
bring
it
up
for
a
vote
in
CF,
but
the
storage
workgroup
would
be
would
really
be
separate
from
from
CSI.
From
the
perspective
of,
there
were
a
lot
of
other
work
streams
that
that
the
storage
room
could
focus
on.
So
you
know
I
think
when
we
first
kicked
off
the
you
know
really
I
would
say
the
first
project
that
we
we
looked
at
and
talked
with.
A
You
know,
we've
also
had
some
some
other
folks
come
on
and
talk
about
open,
SDS
and-
and
you
know,
that's
that's
really
as
far
we
says
we've
got,
you
know
this
is
really
very
early
still
right.
This
is
I,
think
meeting
for
maybe
of
the
worker.
So
so
that
was
the
initial
goal.
That's
what
we
wanted
to
do
now.
A
You
know
we
sort
of
started
that
discussion
really
with
the
presentation
that
he
gave
to
the
group
a
couple
weeks
ago
and
I
would
love
to
continue
that
assume
that
other
people
are
keen
as
well.
You
know
I
think.
The
goal
here
is
really
just
to
provide
some
clarification
and
and
remove
ambiguity
around,
what's
happening
in
the
storage
space
versus
really
trying
to
claim
who
who's
the
winner
in
any
way
what
components.
A
So
anyway,
that
was
sort
of
the
background,
and
now
why
don't
I
pause
for
a
sec?
So
I
can
answer
any
questions
that
folks
generally
have
and
then
really
I'd
like
to
transition
this
into
just
a
discussion
around
making
sure
that
the
community
was
one
of
the
ones
who
continued
for
in
that
direction,
as
well
as
hear
from
folks
about
other
things
that
they
believe
the
the
workgroup
can
be
focused
on.
So
I'll
pause
for
questions.
E
A
Exactly
right,
yeah
I
mean
my
expectation
here
in
Steve.
I.
Think
you
put
this
well
to
the
TOC,
is
I
still
think.
There's
gonna
continue
to
be
some
really
interesting
innovation
in
their
own
storage.
I.
Don't
think
this
will
just
be
a
hey.
We,
we
wrote
a
white
paper,
we
have
a
landscape
and,
and
a
year
from
now,
there's
gonna
be
nothing
different.
It's
just
gonna
be
that
right.
A
So,
and
so
that
was
again,
the
idea
why
we
also
wanted
to
make
CSI
and
storage
working
group
deliberately
separate
was
that
you
know
that
will
remain
its
own
project,
even
if
it's
brought
into
CN
CF
with
all
the
other
things
that
we
can
take
on
from
a
storage
recruit
perspective,
so
yeah
great
question,
great
clarification.
The
idea
is
that
this
would
be
a
long-running
worker.
E
Okay,
so
it's
a
bit
of
an
orthogonal
one,
but
I
know
this.
Is
you
know
when
I
look
at
the
the
CN
CF
structure
and
I?
Look
at
you
know
like
so
CN
CF
projects
or
open
source
and
then
there's
certain
you
know,
projects
I
would
say
that
are
kind
of
being
incubated
by
the
CN
CF
like
CSI,
that
vendors
are
strongly
incentivized
to
participate
in
because
that's
kind
of
like
a
spec
or
a
standards,
type
thing
right.
E
So
there
is
like
a
natural
incentive
for
for
proprietary
vendors
to
participate
in
that
versus
folks
working
on
open
source
projects,
but
I
think
you
know
I
think
we've
got
some
clarification
on
this
of
the
TRC,
but,
unlike
the
there
doesn't
seem
to
be
a
whole
lot
of
incentive
for
proprietary
vendors
to
stick
around
and
participate
outside
of
projects
like
the
CSI.
Unless
we
have
things
like
landscapes
that
reflect
proprietary
solutions
and
white
papers.
That
mention
those
proprietary
vendors.
E
So
is
this
more
just
anecdotal
but
I
think
it's
like
there's
a
big
if
you're
I'm,
just
looking
at
the
the
participants
here
and
there's
this
huge
storage,
brain
trust
that
I'm
looking
at
and
and
black
half
of
them
or
proprietary
vendors,
and
we
want
them
to
stick
around
because
they
have
good
idea.
So
I
think
this
is
something
that
it's
just
another
reason
why
I
think
like
the
landscape
and
the
white
paper
is
important.
E
F
Right
missus
go
I,
agree
with
that
and
I
think
you
know
from
my
interaction
with
customers.
I
think
what
would
be
very
valuable
to
them
to
keep
putting
the
putting
the
customers
in
line
first
would
be
they're.
Looking
for
some
sort
of
industry
endorsement
on
what
a
cloud
native
storage
architecture
would
look
like
and
I
think
it
would
be
really
valuable
as
an
output
from
this
working
group
to
help
clarify
what
what
is
happening
in
the
storage
industry.
What
is
inherently
different
about
cloud
native
application
and
what
does?
F
How
do
cloud
native
storage
products
fit
within
the
CMC
of
landscape?
So
I
think
it's
not
just
white
papers
but
I
think
it's
around
helping
them
understand
not
the
day
one
deployment,
but
the
day
two
production
scenarios
that
they
may
run
into
the
type
of
things
that
they
need
to
worry
about,
and
the
type
of
tools
that
I
think
this
working
group
would
either
produce
or
incubate
as
projects
or
provide
guidelines
around
how
to
handle
day.
2
scenarios
I
think
that
would
be
very
useful.
B
Yeah,
just
just
filling
in
on
that
I
was
kind
of
doing
a
little
bit
of
thinking
from
the
different
emails
that
we're
seeing
and
some
of
the
previous
discussions,
and
it
kind
of
feels
like
there's,
probably
five
specific
things
that
the
working
group
has
maybe
an
immediate
focus
for
I
think
base.
You
know,
based
on
just
some
of
the
things,
that's
really
from
customers
that
we
talk
to,
but
also
just
community
events
and
the
sort
of
thing.
B
So
so
an
educational
focus
being
the
first
one
as
the
the
second
thing
I
was
thinking
is
clarifying
the
taxonomy
and
the
landscape,
which
we've
already
talked
about
that
making.
It
really
clear
and
and
creating
some
really
clear
groupings
as
to
you
know,
differences
between
API
frameworks
versus
storage,
States
planes
versus
storage,
orchestrators
and
and
all
of
these
sort
of
things,
and
then
the
third
thing
is
patterns
and
use
cases.
B
So
you
know
what
is
our
involvement
in
say
things
like
the
CSI
process
and
do
we
get
involved
in
community
specs,
either
in
terms
of
contributing,
officially
or
or
contributing,
unofficially
or
or
maybe
providing
some
stewardship
or
potentially
direction
in
that
space?
I
think
those
were
sort
of
the
five
things
that
kind
of
keep
on
coming
up
multiple
times.
D
D
D
Sorry
other
than
having
in
a
committee
right,
so
what
I'm?
What
I'm
wondering
about
is
you
know,
for
example,
the
the
interface
and
the
proposals
for
the
API
is
I
thought
that
was,
that
was
a
great
direction
than
a
great
start.
You
know
in
moving
that
direction
with
folks
like
docker
and
core
OS
and
the
kubernetes
team
community
and
stuff
like
that.
I
think.
That's,
that's
a
great
idea
and
that's
a
great
way
to
go,
but
I
think
it
needs
to
be
very
clear
that
that's
the
goal.
D
A
So
these
are
all
these
are
all
been
great
great
points
and
and
great
great
discussion
topics
I'm
taking
notes.
Just
so
you
know
on
little
white
paper
little
some
paper
as
well
as
trying
to
transfer
those
notes
into
our
running
meeting
minutes
and
I'm
writing
them
in
blue
and
if
anyone
looks
at
the
doc,
they'll
see
that
I'm
horribly
behind,
but
I'm
also
scribbling
on
the
paper
as
well.
A
You
know
I
guess
starting
backwards.
John,
no
I,
don't
think
that
we
want
to
have
an
organization
for
the
sake
of
an
organization.
I
think
we
all
probably
have
way
better
things.
We
can
take
our
time.
I
I
do
think
that
there
are
some
potential
real
things
that
we
could
produce,
though.
So
let's
talk
about
those
in
just
a
second,
the
point
on
on
sort
of
the
the
API
and
the
specs
and
and
again
this
was
raised
just
before
that
by.
A
Let's
see
it,
wasn't
you
Steve
those
dude?
Was
it
you,
okay,
so
so
yeah
just
before
that
we
with
respect
to
CS
III,
want
to
be
deliberate
again
that
all
CSI
related
things
we
really
want
to
funnel
into
the
CSI
meetings.
There's
separate
CSI
meetings.
There's
you
can
be
creating
pull
requests.
You
can
be
discussing
with
that
community.
A
So,
yes,
I,
do
think
that
that's
an
important
part
of
storage
but
I
do
want
to
be
clear
about
the
distinctions
between
the
two
and
then
so,
and
then
there
may
be
future
ones
that
there
may
be
future
aspects
of
specs
or
api's.
That
does
come
out
of
this
group.
I
think
that's
great,
but
as
it
stands
right
now,
it's
doesn't
leave
a
CSI.
We
should
keep
separate.
So
what
I
captured
was
from
goo
I'd
gotten
some
good
stuff.
A
Here
you
know
on
top
of
just
thinking
about
a
cloud
native
storage,
landscape,
a
cloud
native
storage
architecture.
It
is
beneficial
and
really
I
think
the
way
you
said
it
in
goo
was
you
know
how
storage
fits
into
the
cloud
native,
architectures
and
I
I.
Think
that
that's
sort
of
a
more
general
point
that
was
also
brought
up
just
around
you
know
of
the
five
things
we
could
be
doing.
One
of
them
could
be
education,
and
you
know
some
of
the
points
around
education
to
be
focusing
on
I
heard
patterns
in
places.
A
A
We
can
capture
patterns
and
use
cases.
This
again
could
be
beyond
a
white
paper.
She
could
just
be
collection
of
these
things
that
were
trying
to
share
with
the
community
better
taxonomy
x',
and
you
know,
glossary
x'
definitions
of
some
of
the
different
components
of
the
stack
you
know
I'm
all
for
it,
I'm
all
for
the
working
group
trying
to
take
these
on
and
sort
of
producing
our
view
of
these
things
in
our
definitions
anyway.
A
So
these
are
some
of
the
things
that
I'm
really
hearing
come
out
and
again
I'll
capture
as
much
of
those
I
can
in
the
doc,
but
but
I
think
to
answer
John
your
question,
and
this
is
what
I
think
we
would
be
working
on
this.
This
would
be
that
the
Charter
would
be
to
work
on
some
of
these
things.
So
literally,
the
outcome
of
the
group
would
be
that
we'd
have
say
a
page
of
a
doc
in
github
or
something
else
that
captures
hey.
A
These
are
patterns,
we're
seeing
these
are
use
cases
we're
seeing
this
is
our
glossary
around
the
different
components
when
it
comes
to
storage
in
the
cloud
native
ecosystem.
Here's
how
we
see
you
know
here's
an
entire
tire
collection
of
information
around
how
we
see
how
storage
fits
into
the
cloud
native
storage
are
sorry,
the
cloud
native
architecture
so
forth,
and
so
on.
D
A
It
feels
like
low-hanging,
fruit
and
Wow
and
again
that
that's
that's
why
I
said
I,
it's
quite
possible
that,
amongst
these
discussions
and
this
this
exercise,
we
actually
say
hey.
You
know
what
there
is.
Maybe
another
standard
or
API
or
or
other
thing
that
we
do
want
to
figure
out
and
that
emerges
from
the
the.
D
Yeah,
so
here's
this
not
to
cut
you
off
right,
so
the
the
challenge
that
I
see
with
with
that
with
that
idea
in
that
direction
and
and
I
think
it's
it's
definitely
something
it'd
be
great.
It'd,
be
an
awesome
thing
to
work
on,
but
the
challenge
that
I
see
is
you
know,
let's,
let's
start
with
kubernetes,
for
example,
you've
got
flex
volume,
you've
got
internal
cloud
providers,
you've
got
internal,
other
storage
drivers
and
you've
got
external
storage
drivers
and
external
providers.
There
is
no
there's
no
Koki
City
to
talk
about
there.
D
You
know,
look
at
the
rook
guys
in
the
in
the
presentation
that
we
had
with
them
on
trying
to
figure
out
what
to
do
with
the
stuff
that
they're
working
on
right.
The
problem
is,
is
there's
it's
just
there's
no,
in
my
opinion,
there's
no
good
message
to
really
go
and
talk
about
unless
something
changes
in
terms
of
how
the
API
is
architected,
how
things
work
where
at
least
a
decision
is
made
that
says
hey.
This
is
the
way
we
do
it
right.
D
That
being
said,
then,
if
you
throw
in
you,
know,
docker
and,
and
you
know,
DC
OS
by
itself,
without
running
kubernetes
or
swarm
or
some
of
these
other
technologies
there
I
think
are
still
perfectly
valid
and
useful.
Then
the
discussion
changes
yet
again
for
each
one
of
those,
maybe
I'm.
Just
you
know,
I
said
I
want
to
come
across.
As
being
you
know,
negative
or
critical,
or
anything
like
that.
D
I'm
just
trying
to
be
realistic
in
terms
of
you
know,
conversations
I
have
with
people
that
are
trying
to
get
their
head
wrapped
around
some
of
this
stuff.
The
challenges
they're
having
is
there
are
too
many
options
and
everything
is
vastly
different
for
them
and
they
do
and
that's
not
a
good
experience
for
them
at
all,
especially
considering
the
pace
of
change
these
days
with
with
technologies
and
what
they're
adopted
so.
E
Hey
John,
so
lately
there's
sort
of
two
things
I
wanted
to
respond
to.
One
is
the
the
landscape
comment
you
made
and
then
I
wanted
to
follow
that
on
with
a
response,
my
question
sort
of
to
further
what
you
said
about
process
sort
of
phobia,
but
so
I'll
take
the
first
one,
which
is
I,
think
what
you're
describing
as
a
granularity
thing.
E
So
right
now,
if
you
look
at
the
CN,
CF
storage
landscape,
it's
like
seven
alerts,
kind
of
right
like
it's,
just
like
everyone
and
their
dog,
that's
like
somewhat
cloud
native
Jim
right
and
so
the
there
are
some
like
very
high-level
ways
that
we
could
segment
them
that
are
meaningful,
right
and
I.
Think
like
folks,
are
and
like
one
is
like
storage
adapters
or
cloud
native
platforms
like
there's
a
whole,
you
can
talk
about
docker
volume
plugins.
E
You
can
talk
about
that
that
whole
smorgasbord
of
stuff,
but
but
frankly,
there's
like
a
whole
lot
of
solutions
that
don't
fit
in
there.
So
just
calling
out
the
fact
that
there
are,
you,
know,
adapters
and
there's
a
variety
of
different
kinds
of
adapters,
some
that
are
in
tree,
some
that
are
out
of
tree.
There's
a
spec,
that's
being
worked
on,
like
I,
think
that's
useful
in
itself,
and
there
is
also
you
know:
storage
platforms
that
run
inside
kubernetes
may
sauce.
You
know
swarm,
etc,
like
the
capability
for
that.
E
Think,
like
the
fact
that
you
know,
storage
platforms
need
a
service
interface
to
be
cloud
me,
you
know,
and
so
it's
like
you
know,
those
are
like
three
very,
like
high-level
big
blocks,
that
we
could
have
me
at
least
thought
sorting
stuff
into
and
talking
about
those
patterns
without
having
to
get
into
the
nitty-gritty
of
sure,
like
ease
flex
volume
or
should
I
wait
for
CSI.
Okay,.
E
E
Besides
the
TOC
in
deciding
what
the
CNC
F
produces
and
exits
and
there's
a
governing
board
that
sits
above
the
TOC,
but
the
governing
board
doesn't
tell
the
TOC
what
to
do,
and
so
the
TOC
are
the
ones
that
decide
what
to
do
and
the
TOC
members
can
spin
up
working
groups
to
help
them
with
due
diligence
to
help
inform
them,
etc,
but
essentially,
like
the
the
working
groups,
exist
to
inform
the
TOC
members.
And
it's
literally
that,
like
that's.
That
simple
is
that
correct
incorrect
pin
all.
A
Right
so
I
think
it's
correct,
yeah
I
think
it's
in
a
good
assessment.
I
mean
we
spun
up
their
working
groups
effectively
exactly
to
help.
Do
the
due
diligence
to
help
determine
what
projects
we
may
or
may
not
want
to
bring
in.
I
I
think
that
the
only
point
that
I'll
make
is
I
wouldn't
underestimate
the
power,
however,
of
the
voice
that
will
work,
groups
can
have
coming
back
to
the
TSC.
A
C
If
I,
if
I
may
add
one
thing,
I,
think
one
of
the
things
that
I
think
of
this
working
group
is
as
actually
doing
that
we
really
helpful
is
things
that
are
horizontal
in
nature,
but
they
span
multiple
vendors
or
they
span
the
entire
landscape
and
trying
to
come
up
with
either.
You
know,
documentation
white
paper
is
all
our
stuff
that
we
talked
about
then,
but
also
I
mean
CSI
is
an
example
of
a
horizontal
project.
C
There
could
be
others,
I
mean
Steve
was
hinting
at
a
storage
platform
interface
of
some
kind,
and
maybe
that's
a
discussion
point
that
you
know
you
have
a
you.
Have
a
working
group
here
full
of
like
I,
said
the
brain
trust
around
storage,
some
open,
some
commercial
I
think
will
be
a
really
good
use
of
people's
time
here.
If
we
were
to
work
on
things
that
are,
you
know,
horizontally
spanning
a
nature
can
bring
together
all
the
different
pieces
rather
than
focus
on
one
specific
vendor
or
one
specific
project.
C
E
E
I
look
at
the
landscape
thing
right,
so
I
go
back
to
the
fact
that
the
way
like
storage
in
the
landscape
right
now
is
not
super
useful
and
if
you
just
simply
have
categories
and
talk
about
the
properties
or
the
category
so
basically
to
fit
into
a
category
like
the
categories
reflect
patterns
like
so
we're
seeing
in
cognitive.
That
folks,
are
you
know
using
storage
adapters
from
their
CEOs
to
talk
to
adjacent
storage
platforms.
That's
a
pattern
that
that
exists
across
daugher.
You
know
Mazeroski,
etc.
E
Right,
you
know
and
and
talk
about
the
properties
in
the
pattern
and
then
list
you
know
some
some
commercial
vendors,
some
open
source
projects
that
meet
that
pattern
right
and
that's
not
king-making
and
that's
very
different
landscape
and
and
white
paper
is
explaining.
Lampe
landscapes
are
very
different
to
the
cnc.
If
accepting
a
project
to
becoming
a
CNC
F
project,
right
that
those
are
two
very
different
things,
what
do
you
think
about
that?
Yeah.
F
You
know
IIIi
like
that
idea.
I,
also
like
what
Alex
said,
which
is
I,
think
this
working
group
focusing
on
more
horizontal
projects,
is
more
useful
and
valuable
than
a
specific
point
solution
and
I.
Think
if
you
look
at
a
project
like
Prometheus,
which
I
consider
to
be
horizontal
and
I,
think
it
really
did
benefit
the
ecosystem,
benefited
the
customers
benefit
of
the
community
and
benefited
all
vendors
too,
and
so
I
think
focusing
more
along
those
kind
of
lines
and
I
think
there's
areas
where
this
working
group
can
contribute
horizontally.
F
Like
Prometheus
I
mean
I,
don't
know
exactly
the
specifics
right
now,
but
you
know
just
around
metrics
around
storage
and
those
kind
of
things
that
every
vendor
could
contribute
to
would
benefit
both
the
customer
and
all
of
the
vendors
I
think
that
are
in
this
working
group.
So
I
think
you
know
again
really
I
like
the
horizontal
concept
that
Alex
talked
about
and
I
think
see,
and
when
you
presented
the
storage,
orchestrators
I
mentally,
have
parsed
it
somewhat.
You
know
horizontal,
be
benefiting
multiple
vendors,
I.
E
Yeah
and
then
it's
like
tricky
like
as
we
go
through
right,
like
how,
like
you
know,
it's
kind
of
funny,
because
it's
like
I
look
through
the
you
know
the
or
the
participant
list,
like
the
the
average
like
title,
is
CTO
or
like
senior.
Take
you
for
something.
E
It's
like
they're
the
capacity
for
us
to
spend
a
huge
amount
of
time
like
producing
stuff
like
this
is
probably
quite
small
and
so
I
think
we
should
be
like
super
careful
about
how
much
we
sign
up
for,
and
you
know
initially
take
small
like
look
for
what's
urgent
and
important,
you
know
that's
that's
like.
As
being
said,
low-hanging
fruit
like
go
tackle
those
things
that
sort
of
line
up
with
what
the
last
three
people
say.
A
A
Good
thing
where
you
can
turn
on
and
off
layers,
and
you
can
see
the
proprietary
ones
the
opens
responds
so
I
suppose
I
should
really
know
the
answer
to
this,
but
I
think
the
official
position
is
that
from
the
CN
CF
is
that
incorporating
things
like
proprietary
projects
is
very
much
in
scope,
but
I
would
just
like
to
hear
from
others.
Maybe
there's
aspects
I'm
missing,
so
I
wanted
to
open
up
that
up.
Briefly,
thanks
for
bringing
that
up
at
the
very
beginning,
Steve
I.
D
C
Is
a
definition
for
cloud
native?
You
know
it's
currently
on
the
on
the
CN
CF
website.
It
says
it's
container
package
can
be
managed
and
micro
services
oriented
so
I
think
if
we
use
that
definition,
I
I'd
say
that
you
know,
storage
projects.
Propriety
are
open,
should
somehow
meet
that
criteria
to
beyond
that
in
the
landscape,
I.
D
C
C
B
Think
we
should
probably
define
some
well.
This
probably
comes
into
some
of
the
things
that
we
were
talking
about
earlier
around
taxonomy
right.
We
we
can
probably
define
some
of
the
attributes
like
is
it
containerized?
Is
it
open
source
or
closed
source
doesn't
have
an
open
API
all
of
these
sort
of
things,
as
part
of
that
as
part
of
our
classification,
but
John
I?
Think
you're
completely
right,
I'd
be
very
surprised.
B
If
you
know
the
things
of
customers
are
deploying,
don't
include
some
mix
of
different
components:
some
open
some
clothes,
some
containerized,
some
not,
but
we
should.
We
should
probably
aim
to
say
these
are
the
things
that
that
that
we
think
are
important
in
cloud
native
storage,
but
also,
then
specifies
why
we
think
they're
important,
because
they
enable
specific
patterns
or
specific
use
cases
or
they.
You
know
they
enable
other
things
like
orchestrate,
the
storage
or
or
or
other
things
or
other
goals
that
we
want
out
of
the
out
of
the
environments.
A
That's
a
great
great
transition,
so
what
I've
done
is
I've
I've
captured
possible
actionable
next
steps,
the
low-hanging
fruit,
if
you
will
in
the
doc
I've
still
got
a
lot
of
notes
to
add
Alex
I
believe
you're,
the
one
that
had
given
us,
the
five
possible
things.
I
think
I
captured
three
of
them.
If
you
wouldn't
mind
filling
in
the
others
in
the
doc.
That
would
be.
That
would
be
very
helpful.
A
So
what
I
don't
know
is
I've
told
out
the
the
the
the
possible
actionable
next
steps
that
it
sounds
like
there's
at
least
some
consensus.
We
could
move
forward
on
and
I've
tried
to
do
it
in
maybe
a
way
that
would
be
foundational
for
all
the
other
things
we
want
to
do
so,
starting
with
glossary
in
taxonomy.
A
Then
you
know
maybe
maybe
moving
to
cloud
native
storage,
landscape
and
or
patterns
and
use
cases.
It's
a
toss-up,
ultimately
capturing
patterns
and
use
cases,
I
think
hurmat
will
be
able
to
transition
to
cleanly
describing
how
cloud
native
storage
fits
in
the
cloud
native
architectures
and
then
finally,
the
you
know
what
is
a
cloud
native
storage
architecture.
A
I
feel
there'll
be
a
lot
of
great
discussion
and
debate
about
that
one,
so
I
figure
if
we
can
all
be
speaking
the
same
language
with
the
glossary
and
a
taxonomy.
We
all
know
what's
out
there
with
the
cloud
native
storage
landscape,
we
understand
from
one
another.
What
are
the
patterns
and
use
cases
that
we're
seeing?
We
can
really
then
start
to
dive
into
details
on
that
on
what
cloud
native
storage
architecture
really
is.
So
that's
the
thought
this
is
a
this
is
this
is
a
I
think
John
said
it,
that's
a
lot
of
stuff.
A
Actually,
so
you
know
one
of
the
things
I
would
like
to
do
if,
if
folks
are
keen
to
move
in
this
direction,
is
to
talk
about
how
we
want
to
collaborate
on
this.
If
there
are
specific
people
that
would
like
to
take
point
for
any
of
these
things
and
we'll
make
sure
that
we
keep
a
big
chunk
of
this
meeting
for
being
able
to
review
these
so
that
we
can
also
ultimately
publish
them
from
the
working
group.
F
Think
the
list
is
great
Ben,
you
know
I
definitely
be
willing
to
wall
in
volunteer
I.
Think
Steve
had
also
in
as
I
think
in
the
last
presentation
had
some
thoughts
around
orchestrated
storage,
orchestrated
solutions
and
so
I
think.
Maybe
that
could
be
a
starting
point
to
start
defining
what
a
cloud
native
storage
architecture,
or
maybe
at
a
high
level
or
horizontally,
would
look
like
without
specifically
zooming
in
on
one
specific
implementation,
or
anything
like
that.
Yeah.
E
I
think
I'd
be
happy
to
do
that
and
volunteer.
You
know
I
thought,
maybe
so
I
thought
maybe
what
I
could
do
is
take
a
stab
at
a
particular
like
granularity
for
these
different
categories
and
the
properties,
and
then
we
could
set
up
a
cadence
of
meetings
like
the
CSI
folks
have.
But
but
this
is
more
like
a
landscape
cadence
meeting
and
then
we
can
sort
of
iterate
and
refine
and
improve
on
it.
That.
C
E
C
Right
so
that
that's
the
taxonomy
and
you
know
definition,
part
yes,
great
I
think
I'd
be
happy
to
explain
to
you,
I
think,
Steven
and
Clinton
that
you
guys
have
a
good
start.
So
we
should,
if
nothing
else,
I'd
say
let's
iterate,
on
what
you
guys
have
and
see.
If
we
can
put
in
you
know
a
white
paper,
that's
consumable
by
others.
A
That's
right
so
I
I
think
that
the
question
we
have
to
ask
is:
we
have
30
people
on
the
call
right
now
how
many
of
those
30
want
to
participate
in
this
logistically,
if
you
know
25
of
them
do
or
20
of
them
do
or
whatever,
whatever
you
know,
the
number
is,
if
it's
a
large
number,
then
I
think
probably
we
focus
some
of
the
existing
slots
for
the
storage
working
group.
To
actually
do
that.
A
You
know
I'm
not
saying
that
if
people
that
I
really
want
to
spearhead
this
one,
a
smaller
group
wants
to
jump
on
the
side
and
have
some
quick
discussions
by
all
I
mean
that's
great,
but
but
you
know
I
since
I
do
think
this
is
going
to
be
an
important
part
of
the
function
of
the
group.
I
just
want
to
make
sure
that
people
don't
feel
like
they're
playing
musical
chairs
going
from
meeting
to
meeting.
A
B
Think
it
occurs
to
me:
that's
some
of
the
some
of
the
first
steps
like
the
glossary,
taxonomy
and
underlying
scape
stuff
is
something
that
probably
affects
us
all
and
we
probably
all
have
a
certain
amount
of
input
or
or
opinion
on
it,
and
we
probably
should
have
two
or
three
calls
to
to
thrash
this
out.
I
think
once
we
get
a
little
bit
of
structure
after
a
call
or
two,
we
can
probably
see
some
natural
I
guess.
B
Natural
sections
that
might
a
marriage
where
we
can
focus
on
you
know
particular
use
cases
or
particular
topics
that
perhaps
you
know,
individuals
or
smaller
groups
can
might
choose
to
focus
on
and
have
specific
deliverables
at
that
stage.
But
I
think
we
probably
do
needs
a
couple
of
whole
group
sessions
to
trash
out
some
of
the
first
things,
and
it
would
probably
be
helpful
if
we
met
more
regularly
than
once
a
month.
E
Don't
want
to
dominate
the
discussions
here
but,
like
you
know,
put
the
TOC
thread
on
the
landscape
in
general,
like
every
product
manager
of
every
storage
company
is
going
to
want
their
product
ticked
off
in
every
single
category,
and
we
have
to
basically
figure
out
and
think
about
how
to
create
a
reasonable
process
that
we
don't
just
end
up.
Getting
all
these
spurious
requests
that
we're
constantly
having
to
do
with
that.
We
have
no
time
for
and
so
I
have
some
ideas
around.
E
D
A
Thanks
John,
that's
great
all
right,
so
here's
what
I
think
I
think
we
I
think
green
increase
the
cadence
at
least
for
the
next
couple
meetings.
Just
so
we
can
hammer
some
of
this
stuff
out
I
like
I,
like
Alex's
suggestion
of
let's
start
with
the
group
that
can
then
go
funnel
into
I.
Guess
the
polish
of
what
we're
trying
to
do.
A
What
do
we
think
in
here?
I
mean
the
working
groups
they've,
they
vary
dramatically.
You
know
the
is
the
networking
work
group
for
a
little
while
was
once
a
week.
It
bounces
back
and
forth,
and
I
expect
the
same
thing
to
happen
for
the
storage
or
akin
group,
depending
on
what
we're
working
on.
But
let
me
just
get
an
understanding
from
from
folks
here.
C
I
highly
recommend
that
I
mean
there
are
only
two
documents
on
this
cleanse
presentation.
Steve
has
a
couple
of
heart
attacks
on
this.
If
we
can
try
to
put
it
all
and
do
a
bunch
of
lot
of
fine
work
in
Google,
Docs
or
slides
or
whatever
and
then
come
to
the
meeting
to
review
and
discuss
issues
as
opposed
to
brainstorm
or
just
brainstorm,
I
think
that
would
be
a
lot
more
efficient.
C
A
E
I
think
Clinton
I
can
like
put
put
put
like
you
know,
appear
what
Bassam
said
like
take
put
put
an
initial
like
proposal
with
some
content
and
structure
around
it
together
for
the
first
meeting,
and
then
we
can
see
if
everyone
feels
like
we're
on
track.
I
agree
like
you
know,
collaborate
or
flying,
and
then
we
were
on
line
like
we
just
funky.
A
The
second
part,
which
is
cloud
native
storage,
landscape,
I,
think
instead
I
just
want
to
want
to
in
the
floor
to
any
other
burning
questions,
desires,
uncomfortableness
whatever
it
is,
let's
just
open
that
up.
If
there's
not
a
ton,
I
feel
like
we
got
a
good
thread
to
pull
on
a
good
trajectory
to
go
down,
and
we
can
even
we
can
even
just
end
early
I.
F
E
A
Abreast.
Storage
working
group
is
not
the
governing
chart
of
CSI
and
so
I'm.
You
know
what
we're
trying
to
focus
on
right
now
in
the
storage
working
group.
Is
these
other
things
this
low-hanging
fruits,
but
CSI
is
very,
very
very
much
from
the
perspective
of
storage
working
group
and
the
CSI
the
direction
that
that
we're
interested
in
seeing
seeing
folks
take.
So
if
you're,
if,
if
John,
if
you
want
to
have
more
involvement
in
CSI,
please
join
those
meetings.
A
E
A
second
that
right,
like
the
the
CSI,
is
part
of
the
you
know.
If
you
look
at
the
landscape,
category
right
and
I
talked
about
adaptive
frameworks
for
CEOs
right
like
to
see
it.
Csi
fits
perfectly
into
that
category,
but
like
what
we've
been
talking
about
here
is
there
are
other
categories
right,
and
so
we
just
want
to,
like
you
know,
expand
our
scope
and
articulate
the
rest
of
the
stuff
as
well,
but
like
definitely
keep
going
on
CSI.
If.
H
I,
let
me
just
add
a
few
words
here,
because
I
type,
some
things
on
a
chat
and
so
I
just
want
to
expand
on
that,
because
I
am
myself
I'm
confused
too
I
think
before
we
start
going
forward
on
directions,
we
need
to
first
define
what
the
team
over
the
community
or
this
forum
is
supposed
to
accomplish,
and
output
I.
Think
that
will
help
a
lot.
I
think
one
we
have
as
a
foundation.
H
A
Thankfully,
so
so
I've
just
added
to
the
actual
next
steps.
Let
me
capture
what
we've
captured
in
the
discussion
here
today
in
text
as
really
you
know
that
the
storage
working
groups
Charter
I'll,
take
that
one
I'll
put
that
together,
I'll
put
it
up
in
a
doc,
put
it
on
the
website.
Probably
we
can
review
that
and
make
sure
that,
based
on
everything
we
talked
about
today,
that
folks
agree
with
that
III,
it's
a
good,
important
step.
You're
right,
we
talked
about
it
today.
I
think
there
was.