►
From YouTube: Kubernetes SIG Storage 20171109
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 09 November 2017
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.lfk4ptns0sye
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:06:25 From Saad Ali : https://docs.google.com/document/d/1-WmRYvqw1FREcD1jmZAOjC0jX6Gop8FMOzsdqXHFoT4/edit#heading=h.vun6eaytazit
09:42:40 From hekumar : volume is fine
09:42:48 From hekumar : yep, you sound fine
09:58:43 From stephenwatt : I agree with you Saad. Unfortunately I have to drop to run to my next meeting
09:58:53 From Saad Ali : Thanks steve
10:01:34 From Steve Wong : Kubecon Ask Me Anything link: http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america/program/schedule
A
A
C
We
are
desperate,
it's
an
only
good
word.
I
can
use
its
proper
here,
get
the
API
merged,
I've
been
pinging,
Clayton
I
mean
everything
should
be
ready
to
go
we're
starting
to
enter
the
rebase
health
and
conflicts.
So
it's
holding
everything
up.
We
have
a
lot
of
code,
that's
ready
to
roll
I.
Think
the
last
piece
is
the
plugins
I'm
working
on
those
this
week,
so
where
we
are
okay,.
A
A
Okay,
next
up
is
out
of
tree
volume,
plug-in
CSI.
This
is
a
work
in
progress.
We
have
a
lot
of
work
underway,
it's
a
very
tight
deadline,
but
I'm
optimistic
for
folks
who
are
interested
you
can
follow
along.
We
have
meetings
three
times
a
week
and
I'll
paste
that
link
into
the
chat
window
for
folks
who
are
interested
in
following
that.
I
can't
figure
out
how
to
get
into
the
chat
from
here.
We
go.
A
The
design
is
pretty
much
ready
to
be
merged
Tim,
as
I
have
a
meeting
with
him
after
this
to
go
over
any
last
open
issues,
and
hopefully
we
can
get
that
merged
soon.
Next
up
is
generic
storage.
Topology
I
have
not
started
working
on
that
I'm,
going
to
punt
that
until
after
code
freeze,
since
that's
primarily
design
work,
next
up
is
volume
resizing
how
mons
do
you
have
an
update
here?
Tell.
A
F
G
A
A
A
H
G
A
G
I
D
J
D
G
G
G
A
A
K
L
A
E
F
N
I
E
F
E
I
E
A
feature
this
thing
I
think
be
habit.
We
had
a
Google
document
where
discussed
all
the
right,
okay
and
there's
a
feature
request
and
there's
this
thing
also,
but
it's
a
I
I,
don't
know
if
I
will
have
I
I
can
do
some
matrix,
but
I
cannot
do
I.
Think
all
the
maybe
suppose
in
that
document
for
1.9
it's
just
not
to
do
in
and
I.
If
cemented,
some
people
have
volunteered,
but
it
requires
like
coordinating
all
that
effort.
A
E
Things
like
how
much
time
in
total
it
took
for
attach
operation
or
things
like
how
many
times
we
had
to
like
fix
of
volume
because
of
some
problem
happened
in
that
address,
control
or
or
things
like
how
many
times
deleting
a
PVC
field,
because
of
delayed
field,
or
something
on
that.
So
exposing
all
the
internal
state
at
they'll
be
really
really
useful
for
debugging
the
storage
problems
that
we
have
so.
A
E
A
O
A
P
So
last
lasting
storage
meeting
I
presented
an
initial
proposal.
I
think
he
missed
out
on
that
because
you're
on
a
PTO-
and
it's
know
it
seemed
generally
that
that
maybe
of
you
know
we
could
go
forward,
but
this
has
a
feature
to
try
it
out
so
I've
had
the
initial
that
proposal
did
the
design
document
shared
out
and
I
got
some
feedback
and
then
pushed
back
as
well
from
from
Jordan
Leggett.
P
So
you
know
we
haven't
really
converged
on
that
yet
or
I've
got
an
agreement
on
it,
but
if
anyone
else
from
this
sig
wants
to
take
a
look
at
that
doc,
you
know
they
provide
some
feedback,
her,
maybe
some
support
for
it.
That
would
be
definitely
helpful.
My
updated
dish
planning
sheet
last
night
with
the
link
to
it,
but
I
don't
see
it
in
here.
So
maybe
it.
A
P
A
A
E
So
the
I
think
the
the
bug
itself,
the
top
one
doesn't
have
much
the
thing
you
can
do
so
to
give
some
background,
we
have
like
at
least
I
right.
I
know
three
three
problems
that
can
cause
of
autumn
to
be
attached
to
a
node
like
one
that
I
found
was
like
the
the
controller
manager
crashes
between
starting,
attach
and
and
the
volume
getting
attached.
Second,
is
that
attach
finishing
outside
the
expiry
window
you
should
attach
attach
finishes
outside
the
time,
be
wait
for
a
to
finish.
E
Then
the
voluntad
is
outside
and
it
remains
permanently
attached.
Third
thing:
I
found
that
was
because
controller
manager
rebuilds
the
state
from
by
reading
the
known
information,
and
if
the
node
was
restarted,
if
the
node
was
shut
down
and
then
brought
back
and
in
between
controller
manager
was
restarted
or
controller
active
control
on
either
switch
happened,
then,
in
that
case
the
wall
of
information
is
permanently
lost.
So
there
are
three
cases,
for
example,
the
known
issues
where
like
volumes
are
attached
forever
and
they
don't
without
an
idle
intervention.
E
So
me
enging
and
anyon
we
had,
we
had
separate
calls
actually,
but
we
discussed
bunch
of
ideas.
We
discussed
tagging
and
we
discussed
some
other
thing,
but
two
solutions
can
came
up
that
looked
very
good
and
we
just
want
to
discuss
those
approaches.
One
was
that
first,
one
is
that
make
attack
errors,
carry
additional
context.
Currently,
when,
when
we
attach
fails,
all
it
returns
is
false,
an
error
these
these
two
return
values
it
returns.
E
The
only
so
best
approach,
one
it
seems
very
minimum
on
each
plane-
can
implement
this
editor
I
actually
already
opened
written
some
proof
of
concept
for
and
that
works.
So
that
and
but
there's
a
downside.
The
downside
is
like
it
will
not
fix
the
volume
until
user
tries
to
use
the
volume.
So
this
attached,
if
there
is
a
dangling
volume
and
when
user
tries
to
use
it,
then
only
it
will
do
this
detach
process
where,
if
the
volume
will
remain
attached
to
the
old
node
also
it
does
not
fix
us.
E
If,
if
the
user
tried
to
delete
such
a
dangling
wall
and
because
delete
operation
expects
the
wall
to
be
detached
and
till
it
will
not
work
so
and
yon
raise
the
point
that,
like
we
are
currently
performing
that
6-minute
ports
detached
regardless
of
volume,
is
mounted
or
not
mounted.
So
that's
a
separate
issue
covered
in
separate
bug,
but
basically
you
want
to
safeguard.
E
I
need
some
safeguards
against
that,
and
the
second
approach
was
that
the
zinc
was
resisting
was
like
pole
for
all
volumes
in
T
cell,
because
the
world
an
and
check
if
they
are
present
and
call
a
describe
volume,
call
and
check
if
it
is
attached
somewhere
and
if
it
is
attached,
add
it
to
the
actual
asset
of
the
world.
But.
A
E
E
X
X
will
be
a
problem,
but
Y
will
be
a
problem
and
X
could
be
also
problem,
but
it
depends.
But
Y
will
fire
will
be
a
problem.
So
that's
what
but
we
fall
for
volumes
and
P.
We
add
the
volume
in
the
actual
store
the
world
with
X
as
the
node
that
attached
it,
so
that
will
trigger
a
detach
from
the
old
node
and
valen
will
be
able
to
attach
to
the
new
node
where
it
is
actually
present
in
desired
State.
So
both
the
idea
is
similar
option.
E
So
this
is
the
code
that
returns
that
dangling
error.
So
if,
if
b-before
be
attached,
we
do
this
check,
we
check
if
the
volume
is
attached
somewhere-
and
here
we
are,
if
we
find
the
volume
is
attached.
This
only
happens
if
the
volume
is
not
attached
already
attached.
Okay,
so
so,
if
the
volume
is
attached,
then
we
return
this
volume.
It
will
not
new
dangling
error
with
no
name
and
your
ice
path.
You
can
see
your.
E
Yeah
we
are
yeah,
we
were,
we
were
checking
any
base
if
the
volume
is
attached
uh-huh,
but
now
we
are
rather
than
just
running
a
plain
error.
We
are
returning
this
new
type
of
error
banging
and
what
do
you
do
with
the
new
texture
so
in
same-same
permit?
If
you
go
down,
there's
a
change
in
operation
generated
code.
J
E
H
It
hey
AWS,
like
polling
the
cloud
everything
in
the
copywriter
guys
is
cheap,
what's
expensive
is
like
so,
in
other
words,
there's
no
difference,
you
know
fetch
everything
operation
and
a
fetch
one
operation,
so
I
would
I.
Would
my
knee-jerk
would
be
that
number
one
is
a
very
specific
fix.
Where's
number
two
is
generic
fix
and
will
solve
all
police
issues
by
typically
like,
if
isn't
since
you
like,
consolidates
with
the
actual
state
the.
E
L
G
Sorry
so,
basically,
when
an
volume
was
attached
to
some
node
right
and
battery,
you
don't
know
that
what
he
was
had
to
that
not
anymore
you're
trying
to
attached
to
some
other
node.
That's
the
the
issue
we
are
trying
to
fix
and
the
rarest
node
could
no
longer
in
the
system.
So
I
think
we
have
a
check.
If
the
node
is
not
belonging
to
the
state,
we
don't
escape
the
volume
or
something
so
that
might
cause
a
little
bitty
issue
better.
We
can
you
mask
it
a
little
bit
more.
A
If
I
mean
I
I
agree
with
that,
the
second
solution
would
be
a
little
bit
more
robust
because
it'll
catch
hey,
you
can
possibly
catch
other
errors,
whereas
number
one
is
more
targeted.
Both
will
fix
the
issue
as
we
currently
understand
it,
but
two
could
potentially
catch
other
issues
because
it
tries
to
fix
the
the
actual
state,
but
it
is
more
expensive
and
I.
Don't
know
if
all
cloud
providers
are
going
to
be
able
to
have
batch.
A
G
D
A
Okay,
I,
don't
have
a
strong
opinion
either
way
for
folks
who
do
I'd,
recommend
commenting
on
the
issue
and
then
I'll
leave
it
to
home
on
--then
Jing
to
to
make
the
actual
call
something
else.
I'd
like
to
point
out
is
for
CSI
we're
introducing
a
new
object,
a
volume
attachment
object
and
the
large
part
of
the
attached
logic
is
now
going
to
be
handled
an
external
attached
or
specific
to
each
volume.
E
E
I
A
E
E
I
E
We
had
a
couple
of
options.
One
option
is,
we
could
give
a
VM
a
specific
solution
or
we
thought
hey
well,
why
not
just
given
the
very
generic
solution
to
super
matters
and
that
we
can
so
that's
the
Peckham,
and
then
we
started
thinking
about
this.
Another
thing
that
came
up
is
the
meaning
of
snapshot.
Operation
looks
like
a
different
compared.
E
If
you
compare
like
public
cloud
providers
like
DCE
and
Amazon
or
here
in
these
kind
of
words,
a
snapshot
basically
means
you're,
actually
taking
a
contents
after
and
you
are
actually
doing
a
backup
to
some
other
story
right,
but
that
is
not
how
things
work
in
other
non
public
cloud.
Vendors
like
whether
it
is
any
story
is
human.
The
providers
or
we
OPM,
where
this
fear
or
any
of
these
guys.
So
in
other
words
of
which
Polish
word
a
snapshot
basically
means
we
just
take
a
snap
appointment
snapshot
of
the
world.
E
I
E
So
now
the
difference
in
order
that
would
be
involved
as
if
you,
if
the
customer
deploys
given
it,
is
cluster
in
a
fiber.
It
doesn't
enter
that
that
is
creating
volume
on
San
another
solar.
Whatever
story
you
have,
how
would
you
I
will
back
up
and
restore
that
that
one
use
case-
and
then
you
scale
that
we
were
thinking
is
even
if
cable
it
is
clustered,
it
will
actually
be
Pradhan
from
big
plot
windows
like,
in
other
words
your
on
GC.
E
There
may
be
use
cases
where
the
customer
may
think
I
do
want
to
take
back
up
toward
I
want
to
I
want
to
take
back
up
to
some
other
cloud
storage,
or
maybe
to
my
look
and
local
storage
that
I
have
weakened
my
data
center,
so
those
kind
of
use
cases
may
also
be
that
so
a
tiny
one.
This
was
collecting
that
we
just
wait
across
and
and
we
do
want
to
solve
it.
You
know
and.
E
They
will
give
up
coffee
and
the
coffee
could
involve
either
a
full
copy
of
the
hardness
is
no
option.
You
not
know
for
coffee,
and
the
mental
backups
can
actually
be
done
on
individual
data,
and
once
you
do
this
operation,
and
then
you
just
live
in
the
temple
in
snap-loc,
basically
utilizing
feedback
and-
and
the
restore
is
so
basically
if
the
customer
would
be
interested
in
doing
this
restores
only
when
something
goes
wrong
or
whatever.
Fine
next
thing
is
you
to
make
sure
that
this
is
not
here.
E
You
can
just
backup
software
to
talk
to
a
bit
from
the
backup
object
there
to
your
actual
this
and
I
just
look
around
a
lot
of
backup
vendors.
Who
does
this
couple
of
things
here,
but
when
I
just
get
up,
google
search
and
in
articles
there
are
more
than
25
vendors
were
actually
doing,
and
this
book
is
that
expose
it
windows.
So
this
is
so
I
just
want
to
like
stop
here
and
just
ask
like
you
guys,
have
any
and
into
the
comment
here
or
is
the
problem
here.
E
Okay,
so
to
summarize
all
we
are
trying
to
say
here:
the
problem
is
that,
depending
on
how
you
are
deployed,
what
Cobra
displeasure
and
be
any
or
different,
there
will
be
use
cases
where
that's
almost
want
to
do
backup
on
take
backup.
If
you
have
some
favorite
backup
windows,
probably
because
they
are
already
using
them,
how
can
we
solve
this
problem
will
require.
A
I
E
E
B
I
I,
don't
even
think
they
should
be
commingled
because
doing
a
snapshot
snapshots
can
be
valuable
for
purposes
other
than
backups,
and
when
you
do
one
of
these
backups,
it's
extremely
likely
that
you've
got
federated
separate
instances
of
kubernetes
involved
so
having
this
under
the
wrapper
of
one
just
is
problematic,
so
I
think.
Maybe
this
is
a
separate
layer
that
could
use
the
snapshotting
facility,
but
shouldn't
be
tightly
coupled,
but
just
my
personal
opinion.
B
Q
But
the
thing
is
an
Amazon
AWS.
What
happens
is
if,
whenever
you
take
snapshot
of
EBS
volume
internally,
they
create
is
three
object.
It
is
as
good
as
you
know,
taking
backup.
So
from
that
perspective,
Sandeep
is
saying
in
public
cloud
environment
like
Amazon.
Whenever
you
take
snapshot,
it
involves
copying
data
to
s3
object,
also,
which
is
not
true
in
on-premise
data
centers.
Like
me,.
R
But
I
mean
one
thing:
I
would
like
to
mention
is
I
look
at
snapshot
as
a
primitive
or
as
a
building
block
which
you
can
use
for
multiple
workflows
and
backup/restore
is
a
workflow
or
a
use
case.
So,
regardless
of
what
a
particular
public
cloud
is
doing,
that
shouldn't
dictate
how
humanity
should
do
it?
Just
my
walking
in
yeah.
N
So
OpenStack
similar
defines
backup
and
snapshot
an
exact
same
where
between
suggestion
here,
it's
now
shell
T,
whatever
your
storage,
goes
natively
quite
often
a
highly
optimized
copy-on-write
type
magic.
There's
a
Maccabee
a
bit
by
bit
copy
I
wrote
the
backup
software
for
cinder
and
I
have
a
few
comments
that
might
be
relevant.
Tell
me
to
shut
up
if,
if
they're,
not
the
first
one
is
that
the
performance
quite
off
for
backups
quite
often
starts
backing
up.
N
Terabyte
can
take
you
know,
hours
and
hours
and
hours,
and
the
state
management
and
error
handling
and
stuff
around.
That
is
quite
complex.
People
very
quickly
want
more
intelligent
backup.
You
know
differential
backup
and
that
sort
of
thing
because
doing
a
full
copy
engine
being
impractical.
You
certainly
want
to
be
backing
up
a
snapshot,
not
the
original
volume
again,
because
that
time
lag
tension,
but
they
can't
have
their
volume
for
20
hours
tends
to
make
them
stop
using
the
facility
pretty
quick
and
the
other
one
is
writing.
N
N
So
you
know
a
lot
of
things
called
backup
several.
If
sets
your
main
storage,
you
can't
use
most
of
the
backup
software
is.
You
can
talk
to
chef,
so
you
end
up
having
to
either
write
adapters
or
all
kinds
of
crazy
things.
So
these
were
our
experiences
in
cinder
and
cinder
back
up
is
still
the
weakest
element
of
cinder
and
we
never.
We
never
came
to
good
solutions
to
most
of
these
problems.
E
So
basically,
one
of
three
different
solutions
that
we
could
have
one
solution
is
a
just:
don't
do
anything.
Let
us
just
remain
on
the
snapshot
operas
with
one
of
snapshotting
and
that
some
other
folks
in
Sixto
is
is
working
on.
What
does
it
mean
right?
So
what
it
basically
means
is
make
sure
the
user
who's
the
customer
here
he's
going
to
use
his
backup
software,
whatever
he
is
comfortable
with
or
whatever
he
is
already
using
for
the
purposes
and
the
backup
software
would
have
to
talk
equivalent
to
do
the
snapshot
warning
operation.
E
That
anyways
would
be
available
in
queue
and
then
the
backup
software
would
have
to
know
what
is
the
infrastructure
that
is
that
will
on
which
the
kubernetes
one
am.
So,
please
don't
wait
depending
on
what
infrastructure
it
is.
It
would
have
its
own
way
of
taking
reading
the
data
and
actually
taking
a
backup
of
it.
So
basically,
your
backup
software
acceptor,
which
is
basically
in
Prague,
where
it's
going
it
with
more
and
more
complex
and
but
then
again
it
it
works.
The
only
thing
is
that
there
is
no
support
from
kubernetes
for
backup.
E
Then
that's
the
that's.
The
thing
here
and
now,
if
you
see
the
pros
or
advantageous
of
this
approach,
the
advantage
I
can
see
is
there
is
no
work
to
be
done
in
kubernetes.
Basically
just
grab
this
proposal.
Let
go
back
to
the
one
across
me
fine.
So
the
core
of
this
approach
is
that
the
back
of
Copan
vendors,
who
are
actually
experts
in
doing
it.
E
We
are
not
bringing
them
on
board
easy
and
they
are
making
it
work
complex,
so
they
become
in
trouble
and
then
and
then
the
one
common
thing
is
that
the
user
will
have
to
manage
this
third-party
software
for
doing
for
taking
the
backup
and
restore
operations.
So
it
becomes
yet
another
component
for.
E
S
E
What
we
could
do
is
we
could
come
up
with
backup
and
restore
controller,
and
these
can
have
some
backup
sponsor
in
it,
or
we
have
to
write
roundup
and
whether
the
request
comes
to
communicate
a
server.
The
backup
controller
can
actually
take
a
snapshot
of
the
volume.
Basically
talking
to
the
community
is
server
to
do
that,
but
snapshot
is
being
taken.
Then
it
can
actually
coordinate
with
the
one
you
plugin
to
actually
read
the
data
or
write
the
data
to
actually
perform
backup,
so
English
English.
So
in
this
particular
solution.
E
What
we
are
saying
is
we
are
kind
of
writing
a
backup,
a
generic
backup
software
in
kubernetes
and
exposing
API,
so
that
users
can
create
users
can
request
for
backup
users
can
fight
for
backup
objects,
and
if
something
goes
wrong,
the
user
can
also
restore
from
a
backup.
That
is
another
approach
we
could
take
so
now.
E
What
are
the
pros
of
this?
The
pros
the
biggest
advantage
of
this
is
that
the
backup
and
restore
feature
would
be
available
out
of
the
box
in
kubernetes.
You
give
my
competitors
you're
going
to
get
it.
You
could
be
in
a
very
minimalistic
form,
you
know
in
the
beginning
later
on,
we
can
add
functionalities
as
and
when
we
need
it.
E
That's
the
big
advantage.
The
disadvantage
is
that
we
are
not
really
leveraging
backers
of
the
lip.
I
told
you
guys
that
vendors,
like
experts,
are
doing
it,
that
meant
only
for
ages,
so
this
would
not
benefit
them.
That
is
one
opposite.
Okay
and
to
me
a
couple
of
vocal
questions,
in
my
mind,
were
hey:
can
all
volume,
plugins
support,
reading
and
writing
people
I'm
not
sure
I
can
say
that
we
support.
E
R
I
mean
just
this
one
last
point
on
this
is
so
what
I'm
saying
is
that
if
this
is
a
new
proposed
functionality,
the
fact
that
it
does
not
exist
today
doesn't
stop
it
right.
I
mean
if
this
is
something
that
we
decide
to
go
to
approach
to
for
kubernetes,
then
every
volume
provider
who's
interested
in
supporting
this
functionality
can
make
a
call
for
themselves
right.
Lack
of
support
today
doesn't.
E
What
you
can
configure
the
backup
software
so
that
the
backup
of
it
is
but
the
point
here
is
that
we
are
going
to
add
kubernetes
api
primitives
like
reading
pv
writing,
whatever,
whatever
ApS
are
needed
to
actually
backup
and
restore
given
a
dak
primitives
here
and
the
backup,
software
only
has
to
talk
to
community
api
server
using
those
primitives
to
actually
perform
the
backup
and
somehow
the
weakened
kubernetes.
We
will
have
to
figure
out
me.
We
need
to
figure
out
a
way
to
talk
to
one
in
plugin
who
actually
read
and
write
data.
E
Naturally,
something
that
we
already
figured
out
reading
and
writing,
and
whatever
is
needed
for
backup,
is
something
that
is
the.
That
is
this
solution.
Three
and,
as
I
said,
the
big
advantage
is
that
the
backup
software
vendors
we
take
the
job,
much
easier
to
perform,
backup
and
restore
of
TVs
and
the
con.
For
me,
this
approach
is
we
never
had
data
path,
API
seen
kubernetes,
so
most
of
them
they
were
like
control
if
you
create
a
pod
or
three
a
PV.
Something
like
that.
E
A
I
my
opinion
on
that
is
I
would
be
strongly
against
adding
kubernetes
into
the
data
path.
So
far,
it's
been
in
the
control
path.
That's
worked
very
well,
it's
an
orchestration
system,
injecting
ourselves
into
the
data
Pat
is,
should
have
a
very,
very
high
precedence,
and
the
second
bit
of
feedback
is
that
this
does
not
necessarily
need
to
go
into
the
kubernetes
core.
A
The
kubernetes
project
is
becoming
more
and
more
modularized
and
decomposed,
and
what's
starting
to
happen
is
that
the
core
of
kubernetes
is
essentially
like
the
kernel
and
there's
a
very
high
bar
for
getting
into
the
kernel
and
what
you
proposed
in
solution,
2
and
possibly
luciene
3.
You
could
actually
build
with
IG's
kubernetes
primitives
using
things
like
CR
DS
and
writing
your
own
controller.
That
might
be
a
better
place
to
start
to
figure
out.
E
R
A
Q
A
Don't
think
we
have
exact
numbers,
but
let's
wrap
this
conversation
up.
We
have
one
minute
left
in
this
meeting.
I
want
to
make
sure
that
we
get
to
the
remaining
agenda
items.
Do
you
folks
want
to
take
this
conversation
offline,
maybe
start
a
thread
on
sig
storage,
mailing
lists,
or
what
do
you
think.
I
A
All
right
cool,
let's
jump
to
the
next
agenda
item,
which
is
Q
cons,
storage,
cig
planning,
apparently,
there's
going
to
be
an
AMA
@q
con
for
folks
who
are
going
to
be
attending
from
this
sig.
Please
come
and
share
your
expertise
with
others
in
the
community.
It's
a
great
place
to
have
a
high-bandwidth
discussion,
I'm,
not
sure
who's
leading
this
is
it
Steve
watt,
I'm,
not
sure
yeah.
This
session
shows
us
Steve
watt,
okay,
so
reach
out
to
Steve
what,
if
you're
interested
in
participating
in
that,
and
and
that's
it
for
today-
is.
S
Hello,
hey-
this-
is
human
by
from
hobby,
I
actually
proposed
five
minutes,
but
look
we
are
getting
short
I
guess
we
for
the
dynamic
provisioning
of
local
storage
proposal
will
be
publicly
sharing
the
sharing
the
information
from
the
medium
least
I
think
that
might
be
OK
for
us
all
over
proposal
over
1d
the
feedback
from
the
community
and
from
this
group
and
the
feedback
pushback
you're
welcome.
I
will
share
dog
shortly
this
week,
great.
A
S
Took
my
minutes
to
describe
the
horse,
okay,
yeah
so
basically,
I
mean
in
wealth
internal
project.
While
we
have
been
doing
dynamic,
dynamically
provisioned
local
storage
is
needed
so,
which
is?
This
will
be
part
of
our
internal
project
already.
So
in
some
other
thread,
another
reveal
especially
Michelle's
design
proposal
for
the
topology
aware
scheduling
part,
and
we
realized
that
dynamic
provision
of
local
storage
is
pretty
much
needed
in
other
areas.
C
And
I've
actually
started
a
Google
Doc
for
that
I
haven't
shared
about
it's
based
on
Michelle's
topology
idea.
Cuz
local
in
the
home
are
gonna
be
along
the
same
line,
so
we
thought
we
would
consolidate
the
development
of
that.
So
I
will
attach
that
to
your
email,
and
maybe
we
can
discuss
further
because
I
think
that's
really.