►
From YouTube: Kubernetes SIG Storage 20170720
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 20 July 2017
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.2mv2sxq62lvp
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:07:17 From msau : sorry my mic is not working, going to reboot my laptop :(
09:43:56 From Ardalan Kangarlou : https://github.com/kubernetes/kubernetes/pull/45345#issuecomment-313136730
A
Okay,
this
is
the
bi-weekly
meeting
of
the
kubernetes
storage
special
interest
group
today
is
July
20
2017.
As
a
reminder,
this
meeting
is
public
recorded
and
published
on
YouTube.
Let's
get
started
share
my
screen
and
we're
going
to
go
over
the
agenda
doc
feel
free
to
add
to
the
agenda
doc
as
we
go.
A
If
there's
anything
that
comes
up
first
up
is
we're
going
to
do
status,
updates
on
the
items
that
we
have
for
1.8
so
pulling
out
the
big
planning
worksheet
we're
going
to
go
through
these
real,
quick
and
just
call
out
what
the
current
status
is
for
each
item
prototyping,
and
this
should
be
designing
out
of
tree-
si
si
volume
plugins.
This
is
currently
in
progress.
I
am
going
to
put
together
a
work
group
within
the
kubernetes
storage.
A
Stick
to
to
collaborate
on
this
I
had
some
discussions
with
Brad
offline
I
want
to
pull
in
chakri
and
whoever
else
wants
to
be
invited.
I'll
send
out
a
email
to
the
storage,
dig
and
maybe
create
a
separate
working
group
for
that
capacity.
Isolation
and
resource
management
for
local
ephemeral,
storage,
I'm,
not
sure
if
Jing
is
on
the
line.
James,
you
want
to
give
it
a
status
update
if
you're
here.
C
B
Thank
you.
Yes,
it's
in
progress,
so
I
create
a
sheet
also
in
this
page
resource
management
and
have
a
list
of
tasks
and
so
I
assign
a
custom
to
me.
It's
not
complete,
finished
yet,
and
also
the
committee
member
another
kingdom
member
also
will
contribute
and
ina
well,
which
is
English
area.
Please
also,
let
me
know
so.
We
can
split
the
tasks.
B
A
So
what
we
did
was
create
separate
tabs
in
the
spreadsheet
to
track
larger
features
so,
for
example,
for
resource
management,
Jing
has
created
a
bunch
of
subtasks
and
assigned
owners
and
she's
going
to
continue
to
update
that.
So,
while
the
main
task
is
tracked
in
the
the
primary
sheet
for
1.8,
subtasks
are
going
to
be
tracked
in
separate
tabs.
Hello.
A
D
D
E
E
So
we've
had
a
very
thorough
review
of
the
design
and
I'm
currently
putting
it
into
the
PR
I've
opened
the
feature
for
it.
I
talked
with
Michelle
a
little
bit
offline
about
the
PVC
definition
which
I'm
gonna
include
in
the
PR.
In
the
discussion
there
I
think
we
have
done
enough
as
a
committee
and
it's
time
to
kind
of
push
it
out
with
community
and
give
comments.
E
F
A
Done
means
that
yellow
note
is
currently
on
vacation
she's,
going
ahead,
no
food
in
the
meantime,
what
will
there
is?
Yes
will
review
internally
within
the
storage
sake
and
make
sure
everything
is
okay
and
what
you
get
back
will
get
a
review
from
Milton
Road.
Well,
it's
there
forever
for
two
months.
A
G
G
I
blocked
they
blocked
us
on
two
one:
seven
work
for
this
and
then
said:
let's
go
the
earlier
in
the
cycle.
We
can
get
a
review
better
because
it's
going
to
turn
up
to
be
like
the
end
of
one
eighth
and
they're
going
to
be
well.
This
is
too
late.
We
can't
review
it,
but
all
this
I
have
some
people
on
our
side
they're,
starting
to
push
we're
going
to
try
to
have
a
meeting
with
dish,
possibly
this
week,
just
to
discuss
this
I'm,
but
any
any
thing
that
you
could
do
on
your
side.
G
A
G
G
G
Absolutely
but
I
was
I
mean
I
testing
is
such
a.
You
know
a
fundamentally
obvious
use
case
that
I
didn't
so
essentially
I
figured
that
would
be
like
a
good
shoehorn.
I
didn't
say:
I
was
a
little
hesitant
to
to
bring
all
that
other
stuff
up
and
then
have
them.
Panic,
I,
but
you're
very
right,
there's
a
bunch
of
other
features
that
could
use
this
and
we'd
love
to
have
those
features
to.
A
C
A
Park
this
says
needing
more
attention
and
we'll
see
if
we
could
pull
in
folks
and
get
more
attention
on
the
proposals
and
apologies
to
yon
for
the
long
delay
and
I
appreciate
all
the
work
you've
done
here
so
far.
Next
up
the
Astra
DD
refactor
Jace
doing
to
give
nothing
yeah,
that's
done!
Oh
wow!
Nice
has.
H
It
been
merged
its
marriage
yep
and
we've
already
got
a
cherry
picked
into
172,
so
this
is
going
to
be
a
huge,
huge
win
for
as
your
customers
looking
for
faster
dicks
dismounts,
and
also
that
a
crazy
issue
with
slow
moving
of
volumes
between
nodes,
especially
in
a
node
failure
case.
So
huge
win,
awesome.
A
One
thing
I
want
to
be
call
out
here
is:
let's
make
sure
we
don't
inadvertently
end
up
with
regressions.
I
understand
that
late
in
1.7
there
were
changes
made
to
cinder
and
OpenStack
that
resulted
in
regressions
and
one-seven-zero.
That
made
it
essentially
impossible
to
use
from
what
I
understand
in
one-seven-zero
and
that
changes
are
going
into
either
one
seven
two
or
one
seven
three
to
fix
that.
But
you
know
we're
in
this
weird
place
where
a
lot
of
these
volume
plugins
don't
have
n
to
n
tests
because
they
can't
be
tested
in
our
system.
A
D
E
I
So
I
just
want
to
bring
that
out.
You
should
talk
about
that
you've
ever
to
step
into
what
you
need,
but
it
is
going
to
be
a
huge
test
matrix
where
the
database
person
associates
versions
that
you
have
the
similar
issues.
That
is
also
also
for
life
in
the
OpenStack
setup.
Then
you
shoot
this
issue,
so
we
just
commute
eyes
the
path
matrix.
It's
going
to
be
a
huge
burden
for
us
to
make
that
happen.
Even
a
CNC,
F
I,
don't
know
how
big
it
is
and
what
you
can
sort
of
configuration.
I
A
J
A
design
proposal
and
I
think
Michelle
just
now
approved
it,
and
it's
going
to
prove
it's
been
looked
over
by
people
who
stick
instrumentation
and
I
haven't
started
writing
code
flips,
but
there's
a
detailed
design,
implementation
design
as
well
in
the
proposal.
So
I'll
start
the
coding
to
express
the
purpose
of
this
much,
but
yet
on
track.
A
J
It's
after
the
latest
changes
that
we
are
made
in
the
way
we
are
protecting.
The
we
are.
We
are
protecting
the
calling
like
start
on
the
NFS
directory.
This
is
not
reversible
in
any
form
right
now,
actually
in
in
Cuba
natives,
so
this
is
still
larger
cousin.
Obviously,
the
architecture
could
be
modified
to
make
it
better,
but
since
it
is
not
reproducible
like
yeah,
we
have
like
the
cult
on
is
to
add
tests
so
that
it
isn't
rigorous
and
as
well.
Combat
with
Jeff
has
already
written
some
tests.
K
B
G
So
there
probably
be
two
phases
of
this
41.8
right
like
there
will
be
like
the
base
phase.
It
has
just
a
very,
very
core
features
and
then,
like
the
integration,
with
cube
phase
that
could
potentially
land
an
eight
one,
eight
or
maybe
slip
to
one
nine
I
think
there's
more
camera.
The
second
phase
of
it
than
their
first
I
think
the
first
is
pretty
low.
A
This
is
the
direction
that
we
want
to
go
in,
and
not
just
us
as
a
storage
sig,
but
also
the
workloads
teams
and
other
relevant
teams
who
you
know
should
should
more
or
less
agree
in
the
direction
that
we're
starting
to
Marcin.
I
know
talking
to
some
some
people
and
the
concerns
raised
were
around
things
like
snapshotting.
A
randomly.
A
Creating
a
snapshot
could
result
in
creating
a
snapshot
that
is
invalid
and
it
could
give
people
a
salt,
false
sense
of
security
and
that
they
start
using
this
feature
and
when
they
finally
actually
need
to
use
it
they're
using
it
for
backups
they
find
out
that
the
snapshot
was
taken
lies
that
it's
actually
corrupt,
so
those
kinds
of
issues
I
think
are
worth
I
know
they're.
They
they
can
be
kicked
off.
The
can.
Can
you
kick
down
the
road
but
I'd
like
to
see
those
discussed
more
activist?
A
B
So
taking
snapshots
doing
involved
like
users
to
take
some
action
to
prepare
right,
so
we
need
to
have
a
good
documentation,
like
kind
of
reminding
them
the
correct
steps,
and
so
we'll
say
without
those
like
crack
today,
prepared
they
for
taking
snapshots
there
by
like
get
out
corruption
or
something
we
need
to
have
a
good
documentation
kind
of
remind
to
the
youth
program
to
use
the
feature,
because
whenever
you
do
it
through
us
or
manually
phase,
those
those
are
all
needed.
Those
steps
right,
okay,.
A
So
it
sounds
like
the
it's
being
addressed,
whether
that's
going
to
be
through
documentation
or
through
some
sort
of
design
remains
to
be
seen,
sounds
like
we
might
go
through
making
sure
that
there's
a
big
warning
sign
people
don't
shoot
themselves
in
the
foot.
Okay.
Great
next
up
is
reciting.
I
support
come
on
yeah.
J
This
is
a
design
proposal
up
there
and
I
pushed
up
like
a
beta
textile
design.
A
first
today
and
I
think
the
only
blocking
thing
we
had
one
blocking
thing,
but
we
got
cleared
out
was
we
couldn't
update
PVC
from
cubelet,
but
Jordan.
We
had
a
call
with
Jordan
and
we
gotta
prove
that
if
the
node
and
PVC
relationship
could
be
validated,
then
then
PVC
state
of
only
a
state
of
siege
could
be
updated
from
the
cubelet.
So
we
got
an
unblocked
on
that
one
IDing.
J
J
A
So
my
one
big
concern
about
this
is
it's
changing.
It's
a
a
change
in
the
way
that
we
use
the
API
right.
Normally,
when
we
we
don't,
we
don't
really
have
precedents
for
modifying
the
PVC
object
and
having
operations
being
triggered
against
the
back
end.
I
I
think
this
is
a
nice
use
case,
but
what
I
would
like
us
to
do
is
get
sign-off
from
the
architectural
committee.
G
A
A
There
mean
like
normally
the
way
that
it
works
in
kubernetes
is
that
we
observe
an
API
object.
We
take
some
internal
action
to
rectify
it,
and
then
we
update
the
API
object
and
the
PvP
BC
objects
have
basically
only
feel
that
we
do
that.
For
so
far,
is
the
the
binding
between
the
PV
and
PVC
fields.
That's
it.
The
other
fields
are
more
like
this
is
the
users
intention
and
it's
used
once
and
then
never
touched
again
and
now.
A
What
we're
saying
is
that
after
binding
is
complete,
we're
going
to
allow
the
user
to
manipulate
this
field
and
it
will
start
new
back-end
operations
and
that
they're
going
to
do
things
and
we
need
to
I
just
want
to
make
sure
that
that
flow
is
approved.
It
it's
different
I
just
want
to
make
sure
that
we
have
sign
up
on
it.
If.
J
J
I
just
want
to
quickly
add
that
we
do
have
pistols
for
think
that
if
I'm
not
wrong
like
load,
balancers
and
security
groups
are
as
well
updated
in
response
to
like.
If
you
change
something
and
cue
those
objects
like
we
make
calls
to
add
additional
notes
to
security
to
that
community's
maintained.
So
it's.
A
Not
as
good
as
I
was
talking
through
it,
I
was
thinking
about
things
like
attached
and
detached
really.
They
are
kind
of
do
that,
to
a
certain
extent
where
we
are
observing
an
object,
we're
calling
out
to
a
back-end
which
is
not
part
of
kubernetes
and
then
we're
updating
internal
state.
So,
in
a
lot
of
ways,
this
could
be
very
similar.
I
think
the
difference
here
is:
what
is
that
internal
state
that
we're
going
to
update?
Is
there
a
status
being
reported
back
to
the
user?
A
A
G
The
place
to
do
the
cloud
provider,
so
this
was
Tim's
idea.
If
we
do
the
cloud
provider
or
to
resize
and
skip
the
file
system
resize
that
gets.
You
know
most
of
the
network.
Attached
storage,
I
file
system
resize,
we
could
come
in
as
our
second
base
and
do
it
right.
We
definitely
want
to
do
filesystem
resize
at
some
point,
but
wish
to
where
to
do
that
and
how
to
do.
It
was
too
thorny.
G
J
Miss
I
mean
that
so,
if,
like
again,
like
I,
would
request
able
to
read
the
proposal
again,
I
think
the
apart
from
open
coding,
the
also
resize
tools,
which
is
the
issue,
but
it's
not
like
it's
not
a
deal-breaker.
The
way
I
see
this.
There
aren't
any
major
issues
with
filesystem
resizing
the
design
as
well.
So
we
have
I
can
have
put
all
like
every
step
is
documented.
It's
not
that's.
A
H
H
There
may
be
all
sorts
of
downstream
implications
of
those
repo
breakouts
in
these
implementations
that
might
not
necessarily
be
totally
visible
from
this
particular
sake.
So
it's
just
aligning
all
of
those
various
components
in
a
row
so
that
we
can
compare
and
contrast
what
the
implementation
details
look
like.
So
again,
it's
not
about
getting
approval
or
anything
like
that.
It's
just
like.
Let's
look
it
over
and
make
sure
that
everything
is
in
alignment,
wait.
L
I'm
sorry
to
be
confused.
That
sounds
a
lot
like
just
talking
to
the
architectural
sig
and
getting
approval,
because
there
is
central
place
where
you
know,
I,
think
the
end
of
your
statement
was
trying
to
make
sure
that
everything
is
aligned.
Doesn't
that
sound
a
little
bit
like
talking
to
the
architectural
sig
to
see
if
everything's
aligned
and
that
invokes
really
kind
of
approval
to
some
degree
I'm.
H
I'm
not
I'm
not
going
to
sidestep
the
fact
that
there's
probably
there
is
an
approval
authority,
implicit
in
the
Sagarika
texture.
Charter,
okay
go,
but
I
also
want
to
make
sure
that
I've
seen
a
huge
anti-pattern
in
enterprise
architecture
that
it's
sort
of
the
ivory
tower
architects.
You
know
stamping
and
not,
stamping
you
know
approvals
and
that's
that's
just
an
athame
to
the
spirit
of
the
community
and
what
we're
trying
to
accomplish.
It's
really
about
cooperation
and
partnership,
but
also
recognizing
that
continued
stability
is
a
is
a
core
concern
of
the
entire
project.
Got.
H
L
A
F
Thing
is
that
if
we
are
going
to
solve
for
quality
of
storage
by
magic
and
scheduler
as
Michelle
is
planning
applying
at
least
then
we
can
have
really
much
use
cases
for
configuration
of
the
user
parameters.
It
landed
for
distributing
storage
among
zones
anyway,
that
now
we
don't
have
spaces.
What
else
meet
youth
users
wasn't.
G
L
L
M
L
L
They
did
a
lot
of
work
and
and
then
sort
of
as
they
peeled
into
it,
and
did
you
know
more
of
the
development
the
use
cases
became
more
and
more
of
a
and
in
the
end
of
the
day,
we
was
sort
of
now
pivoting
on
exactly
what
we're
going
to
be
doing
with
all
that
functionality.
We
really
want
to
make
sure
that
we've
got
clear
to
use
cases
to
a
wide
branch
of
customers
before
we
make
changes
to
the
API,
and
so
you
you've
got
them
like.
G
M
So
this
is
all
about
volume,
creation
options.
You
know
you
can
right
now.
If
you
want
to
do
them,
you
have
to
define
a
storage
class
for
every
possible
configuration
imaginable.
If
you
want
to
enable
let's
say
if
you
want
to
have
a
I
dental,
you
want
to
set
up
a
offs,
you
need
to
define
various
source
passes
for
different
ranges
of
aisles.
G
G
I,
don't
know
the
state
of
it
no
I
designed
I,
because
I
have
specific
use
cases
for
this
function.
That's
why
yawns
I
kind
of
stopped
work
on
it
is
when
we
lost
sight
of
like
specific
use
cases
for
this,
and
what
we're
asking
for
is
specific
use
cases
to
make
sure
we're
doing
the
right
thing.
It
sounds
like
our
law
has
them.
D
K
A
Next
up
is
improving
flex
volume.
Deployment
chain
is
working
on
this
I'm,
going
to
give
more
context
at
the
end
of
this
call
about
where
this
came
from
a
couple
of
items
areas,
one
making
sure
that,
when
a
new
flex
volume
is
deployed,
is
that
kubernetes
does
not
need
to
be
started
restarted
and
the
second
part
of
it
is
coming
up
with
a
demon
step
that
will
automatically
deploy
flex
volume
drivers,
so
just
improving
that
story
in
general
Chang.
N
A
O
Chakri,
do
you
have
any
updates
on
that?
Yes,
I
feel
wonderful
in
initial
buzz
working
on
it.
He
started
looking
into
it
and
see
how
like
at
work.
We
all
that
name
is
between
is
a
big
one.
So
she's
done
leave
this
week
so,
but
should
be
back
in
the
couple
of
weeks
and
then
we'll
work
on
it
immediately.
Okay,.
A
Do
you
want
to
send
out
a
link
the
proposal
here
so
that
folks
can
start
looking
at
it?
Yes,
cool
Thank,
You
Ann,
except
is
the
host
path,
volume
type
discussion,
I,
don't
think.
D
is
available
for
an
update,
we'll
have
to
take
a
look
at
that
TR
to
see
what
the
current
status
is.
Tim
was
the
reviewer
on
that
mount
options
to
Gigi
come
on
yeah.
J
So
they
could
give
a
very
small
performance
that
I
have
open
and
it's
like
adding
the
moving
that
annotation
to
field
and
I
also
added
the
storage
class
up,
because
really
in
like
bear,
we
needed
this
option
most
like
recently.
We
were
fighting
from
glossary
issues
and
we
needed
this.
A
storage
class,
so
I
have
added
this
option
in
the
storage
class
as
well
as
part
of
the
proposal,
so
I
need
some
feedback,
I.
Think
not.
Many
people
have
looked
at
the
updated
proposal
for
g8,
so
yeah,
but
it's
like.
A
I
A
I
C
This
is
this
is
rather
sad,
so
I'm
started
looking
at
this
I'll
I'm,
hoping
to
push
out
a
design
proposal
for
the
next
week,
and
I
need
I
reached
out
to
Jing,
because
I
think
she's
been
thinking
about
this
before
so
I
just
want
to
get
a
sense
of
what
she
was
looking
at
and
what
she
thinks.
This
feature
really
is:
okay,.
A
A
Right,
thank
you
very
much
and
data
replication
we're
in
the
parking
lot
here,
nothing
going
on
in
1.8
all
right.
Thank
you.
Everyone
for
the
update
next
on
the
agenda
is
PRS
that
need
attention,
looks
like
nobody's
that
I
added
any
PRS
here,
we're
pretty
early
in
a
milestone
that
makes
sense
designs
that
need
reduce
API
changes
for
1.8
yon.
A
F
They've
got
a
couple
PR
that
change
the
API
well
extend
the
API.
The
first
is
is
adding
FS
type
to
storage
class
people
want
to
configure
file
system
that
is
created
on
your
devices
right
now
it
is
hard-coded
in
the
parishioner.
So
somebody
at
simper
who
created
a
pull
request
that
attend
a
parameter
in
storage
cause.
It
is
a
parameter
in
storage,
class
B
and
it's
not
a
field
on
its
own,
because
not
all
storage
classes
or
volume
plugins
are
dock
devices.
F
F
H
M
A
So
we're
not
having
my
understanding
is
that
a
lot
of
volume
plugins
in
there
kubernetes
api
today
allows
specifying
the
access
type
for
mount
today,
when
you
do
dynamic
provisioning,
that
field
is
defaulted
to
some
value,
and
now
what
this
proposal
is
saying
is:
let's
allow
that
to
be
configured
as
well,
since
it
is
a
specific
for
each
volume
plug
in
some
volume.
Plugins
may
have
the
FS
type
in
parameters
some
may
not.
It
is
essentially
opaque
to
the
to
the
Tohatsu
kubernetes,
the
cluster
Orchestrator.
A
M
M
A
M
C
M
A
I
think
we're
on
the
same
page
here,
to
make
it
explicit
having
the
SS
type
as
part
of
parameters
does
not
necessarily
mean
that
in
the
future
it
will
not
be
able
to
be
controlled
by
end
users.
So
my
understanding
of
exposing
the
parameters
to
the
end
users
is
that
you
know
today
there
might
be
ten
opaque
parameters
that
are
passed
to
a
particular
storage
plug-in
that
it
accepts.
A
Today
we
force
the
cluster
administrator
to
set
each
one
of
those
parameters,
and
what
we
want
to
do
potentially
in
the
future,
is
allow
the
cluster
administrator
to
select
some
subset
of
those
and
say
I,
don't
care
what
the
value
is.
Please
let
the
user
set
it,
and
if
we
go
down
that
path,
then
exposing
the
FS
type
here
as
a
paper
ammeter
shouldn't
prevent
that
from
happening.
A
G
The
probationer
right
I
mean
if
you're,
an
auditory
probation
or
whatever
your
program
you
take
whatever
parameters
you
want.
You
can't
stop
someone
from
putting
an
FS
site
in
there,
so
I
think
the
debate
should
be
more
of
like
which
the
provision
or
exists,
and
why
and
it's
the
provision
our
needs
it.
It
makes
sense
to
have
it
as
a
parameter
that
it
is
a
parameter,
but
it's
already
there
I
mean,
like
you,
can't
stop
someone
from
from
putting
FS
type
in
the
parameters
for
an
extra
parameter,
yeah.
A
G
A
F
A
Everyone
storage
class
is
being
updated
with
a
first-class
field
for
reclaim
policy.
Everything
it's
not
an
opaque
parameter
is
because
this
is
a
field
that
kubernetes
needs
to
be
aware
of,
and
it's
not
strictly
used
only
by
the
storage
of
plugin.
That
seems
to
make
sense
to
me
any
concerns
from
anyone
else.
I've
always
thought
reclaimed.
A
So
I
the
way
I
see
it
is
the
cluster
administrator
should
get
first
dibs.
They
get
to
set
any
of
these
parameters,
though
Paik
parameters
or
these
first-class
parameters.
So
a
cluster
administrator
can
define
that
I
want
my
reclaim
policy
to
always
be
delete
user
can
never
override
it.
Once
we
have
some
mechanism
to
be
able
to
override
these
values
by
the
user,
the
cluster
administrator
should
be
able
to
say:
okay
I
want
to
leave
this
particular
option
up
to
the
end
user,
but
I
want
to
leave.
A
A
By
user
I
think
it
might
be
worth
thinking
through
that
design.
I
think
that's
a
good
point,
since
we
don't
have
that
design
and
nobody
is
actively
working
on
how
to
expose
these
parameters
to
the
end-user.
We
could
potentially
paint
ourselves
into
a
corner
by
introducing
this
Brad.
Do
you
want
to
make
that
comment
on
the
on
this
proposal
because
it
feels
like
it
will
be
closely
tied
to
whatever
that
design
can
look
like
I?
Don't.
F
A
F
A
J
Main
thing
I
want
to
like
this
cliff
is
the
weather,
the
if
you
are
going
to
add
it
to
storage
class.
We
had
a
real
use
case
where,
like
auto
mount
cluster
office,
option
could
have
prevented
certain
problems,
and
if
it
was,
this
could
be
set
in
storage
class
and
all
the
TVs
get
it
automatically
and
then
then
basically
does
it
require
a
code
change
where
you
have
to
push
a
code
change
in
kubernetes
to
make
it
happen,
because
we
couldn't
do
it
in
storage
class.
J
So
thus,
like
I
mean
it
goes
to
sim
same
discussion
that
you
had
our
file
some
type
the
proposal
I
have
put
out,
is
it
puts
it
in
isn't
in
a
parameter
to
storage,
plus,
not
a
field
I
think
that's
fine,
because
again,
not
all
of
them
type
support
mount
options
and
the
communities
the
like
it
doesn't
do
anything
that
it
just
copies
them
to
the
TV,
and
then
the
volume
plug-in
takes
care
of
it.
So
but.
A
J
J
A
Basically,
what
I'm
thinking
is
that
okay
parameters
should
be
limited
to
parameters
which
only
the
storage
plug-in
cares
about,
and
they
are
specified
in
the
API
of
that
particular
storage,
class
or
storage,
plug-in
parameters
which
are
generally
available
for
all
volume.
Plugins
things
like
reclaim
policy
and
I
believe
mount
options
as
well
should
be
first
class
because
kubernetes
needs
to
be
aware
of
them.
I.
J
A
J
Provision
could
be
external
actually
as
well
so
like.
If
we
add
it,
it
is
the
top
level
feed.
Then
the
provision
is
external
to
the
storage
class.
Then
the
sample
is
not
may
are
going
to
support
the
mods
option
so
bill
how
to
silently
accept
like
I'm,
just
thinking
like
I've
been
either
silently,
except
for
all
of
our
limit
X,
and
that
could
be
a
smart
one.
A
L
A
A
One
of
the
big
overarching
questions
was
about
what
is
the
future
of
entry
volume
plugins
we
are
moving
towards
si
si
si
si
is
not
yet
here
flex
volumes
exist,
but
they
have
some
sharp
edges
and
what
we
closed
on
was
that,
starting
with
1.8,
we
are
going
to
limit
the
limit
or
pretty
much
prevent
any
new
volume
entry
volume
plugins
from
being
added
the
reason
being
that
we
don't
want
to
continue
to
expand
the
kubernetes
api.
Every
time
you
add
a
new
entry
volume
plugin,
the
api
gets
expanded.
A
This
combined
with
all
the
issues
around
maintenance
of
in
creating
volume
plugins
means
that
we
don't
want
to
continue
to
make
the
problem
worse.
We
do
have
a
mechanism
by
which
folks
can
do
out
of
tree
volume
plugins
today,
which
is
flex
rightfully
rogue,
pointed
out
that
the
deployment
story
around
flex
is
not
very
good
right
now,
since
it
requires
direct
machine
access
to
be
able
to
drop
the
Flex
volume
drivers
onto
a
machine,
and
it
requires
you
to
restart
cubelet
on
those
machines.
A
So
that's
a
good
question.
Yes,
it
is
directly
linked,
however,
to
the
deprecation
of
the
kubernetes
api.
The
entry
volume
plugins
add,
extend
the
v1
API
and
moving
forward
with
the
v2
API,
all
network
attached,
storage
volumes
will
be
deprecated
and
they
will
be
expected
to
move
out
of
tree
to
a
CSI
volume,
plug-in
or.
C
A
Volume
plugin
there
will
be
some
subset
of
volume.
We
need
entry.
This
is
all
going
to
be
part
of
the
CSI
proposal
for
Cooper.
Today's
josh
subset
we're
thinking
right
now
is
going
to
be
at
the
very
minimum
volume
plugins
that
have
a
direct
need
to
be
exposed
as
part
of
the
kubernetes
api.
Those
are
things
like.
A
M
P
D
A
No,
no
so
to
be
clear,
the
existing
entry
volume
plugins
are
going
to
remain
in
tree
until
the
size
available.
One
CSI
is
available.
They
will
migrate
out
and
with
a
V
to
kubernetes
api,
they
will
be
deprecated.
So
you
entry,
volume
plugins
that
are
hoping
to
extend
kubernetes
beginning
with
1.8.
We
are
redirecting
them
to
flex
before
CSI
is
ready.