►
From YouTube: Kubernetes SIG Storage 20161208
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 8 December 2016
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.xicunab02h3s
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:05 From Saad Ali : [jsafrane] Safer mount manager that does not accidentally delete user data
https://github.com/kubernetes/kubernetes/pull/37698
09:06:54 From Saad Ali : [jsafrane] Configurable ReclaimPolicy in StorageClass
https://github.com/kubernetes/kubernetes/issues/38192
09:08:45 From Saad Ali : [from last meeting] [rootfs] Metrics in volume controllers
https://github.com/kubernetes/kubernetes/issues/36818
09:11:11 From Matthew De Lio : Storage Wish Wish List (Brainstorming) for 2017 and 1.6 (Starter)
Only schedule pods on nodes that support a given volume types
Out-of-tree Volume Drivers
Stabilizing AWS support for EBS
Snapshots
Data Replication?
Local Storage Support
Mount Option Passthrough
09:18:36 From Tom G. : Encryption
09:23:22 From Luis Pabón : i'm not sure if my mic is working, but I agree that this does not sound like it should be done in Kube.
09:24:06 From npramod to SIG Storage (Privately) : is there a plan for convergence of flex and out-of-tree in 2017?
09:32:05 From cmlucian : Is there a tentative date for the f2f in Q1?
09:32:11 From steve watt : If anyone wants to jam around ideas for Snapshotting / Replication / Data Migration please hit me up on Kube Slack
09:32:58 From steve watt : I think that feature is super important to enable cross-cloud application application portability - i.e. avoiding cloud lock-in
A
This
is
the
bi-weekly
meeting
of
the
storage
special
interest
group
today
is
December
8
2016.
As
a
reminder,
this
meeting
is
public
and
recorded
on
the
agenda.
Today
we're
going
to
talk
about
what
we're
going
to
do
in
2017
and
in
q1
kind
of
go
just
brainstorm
and
come
up
with
a
wish
list
of
everything
that
we
want.
We
can
do
that
last.
Let's
go
through
all
the
other
agenda
items
first,
so
first
up
a
status
update
on
things
that
have
been
going
on
in
storage.
Right
now
we
are
finishing
up.
A
1.5
at
1.50
is
scheduled
to
go
out
on
Monday
from
the
storage.
End-June
got
a
couple
of
changes
in
last
minute,
so
one
was
the
containerized
mounter
change
that
went
into
1.5
and
being
is
being
back
boarded
at
1.47,
that's
going
to
enable
NFS
and
cluster
FS
on
gke
on
GCI
images,
and
the
second
change
was
a
workaround
for
the
NFS
wedging
issue
on.
Basically,
she
kind
of
rolled
back
partially
14
changes
that
broke
sex
change
and
hopefully
that'll
ease
the
pain
of
the
NFS
wedging
issue.
A
B
C
Food
in
my
mouth
well,
a
couple
of
days
ago,
I
felt
NPR
that
makes
remove
or
much
safer.
We
had
a
bug
dead,
remove
or
accidentally
removed,
user
data
and
I
would
like
to
get
some
feedback,
preferably
from
jinx
jinx
ooh.
If
she's
there
and
she
is
there
and
we'll
both
take
a
look
at
it.
Yeah
it's
could
make
you
block
the
neck
safer.
You
want
to
give
an
overview
of
what
it
does.
C
Well,
what
it
does
it
I
copy
dream
of
all
from
golang
standard
library
and
I
make
sure
that
it
doesn't
cross
mount
boundary.
So
nice
courses
that
start
on
a
directory
and
the
parent
directory,
and
if
their
first
system
is
different,
then
it
gives
up
and
frosted
an
error,
and
that's
it
you're
going
to
modify
all
references
of
remove
all
to
use
that
yeah.
A
C
Of
them
it
looks
a
really
really
nice
change
cool
and
the
second
one.
Some
guy
on
slide
asked
me.
You
had
the
possibility
to
configure
recline
policy
in
a
storage
class
and
I
got
few,
let's
say
to
request
from
somebody
from
redhead
her
dad
that
they
would
like
something
for
that
from
the
customers
tube.
So
I
have
three
people
who
wants
to
configure
the
grandpa
same
women
pointed
out
that
some
people
want
to
configure
or
so
far
system
that
is
creative
on
dynamic,
pro-animal
provision
volumes.
A
C
A
That
PR,
but
it
does
sound
like
a
useful
feature.
It's
just
a
issue.
Okay,
what
the
code
is
doing
got
it,
so
I
think
it's.
It
makes
sense
that
something
that
we
should
fix,
we're
going
to
have
to
take
a
look
at
how
or
where
we
want
it
to
fit
into
the
API
exactly
and
if
you
have
any
other
parameters
that
should.
B
Sr
alimentive
all
the
metrics,
so
so
far
we
don't
have
any
metrics.
You
know
what
a
managing
editor
or
controller
on
the
idea
is
that
sound?
Sometimes
we
get
of
trouble
so
make
of
these.
We
don't
really
capture
and
we
didn't
really
have
good
ideas
on
how
they
perform
so
adding
matrix
will
give
us
some
ideas.
What
is
going
wrong,
I
think
the
implementation
is
trivial,
just
what
we
want
to
add.
That's
its
importance
on
so
I
do
near
on
G+.
A
B
B
A
B
A
That's
a
good
start,
so
I
think
this
kind
of
is
a
good
segue
into
our
big
topic
for
today,
which
is
coming
up
with
a
wish
list
of
what
we
want
for
pretty
much
all
the
2017
just
a
brainstorming
session,
and
then
maybe
we
could
Whittle
that
down
into
what
we
want
for
q1
for
the
1.6
release,
I'm
going
to
hand
it
over
to
Matt
Matt
is
p.m.
on.
He
works
on
both
networking
and
storage
here
at
Google.
So
it's
really
awesome
to
have
him
working
with
us,
Matt
sure
yeah.
Thanks.
D
So
some
of
the
things
that
that
I
put
down
on
my
list
were
the
following,
so
I
pasted
it
just
in
the
chat
window,
so
I
think
you
know
one
of
the
things
that
we've
found
is
at
the
face-to-face
meeting.
We
need
to
have
a
good
strategy
for
doing
out
of
tree
volume.
Drivers,
as
well
as
the
ability
to
to
yeah
push
everybody
out
of
the
tree
and
then
also
to
amount
pull
in
drivers
at
runtime.
So
that's
a
big
part
of
what
I
think
we
should
be
working
on.
D
A
few
other
kind
of
maybe
big
things
that
we
could
think
about
are
snapshots
at
a
replication
in
general
I
think
we
got
some
stabilization
stuff
with
report
to
AWS
EBS
volumes.
Local
storage
support,
I
think,
is
going
to
be
a
big
thing
in
the
future,
because
people
want
to
take
advantage
of
SSDs
and
in
another
media
that
are
on
their
their
local
system
and
I.
Think
the
last
one
I
had
was
Mount
apps
option
passed
through
so
I
mean
these
are
just
starters.
D
I
think
we
should
kind
of
I'm
happy
to
kind
of
take
notes
and
write
down
other
ideas
that
we
have
and
I
think
we
can
revisit,
may
be
figuring
out
priorities
later.
I.
Think
if
we
want
to
talk
about
that,
a
little
bit
now
I'm
happy
to
do
that,
but
I
think
more
I
just
want
to
solicit
ideas
and
kind
of
see
where
we
are
and
then
we
can
talk
about
where
we
want
to
end
up
in
2017,
maybe
in
a
later
meeting.
E
E
B
D
E
D
E
The
whole
shebang
right
really
for
me,
I
think,
like
containerized,
you
know
client
mount
drivers,
you
know
mount
propagation
is
pretty
important
to
our
are
out
of
tree
goals,
and
I
think
I
agree
out
of
tree
volume.
Plugins
super
high
on
the
list,
snapshotting
and
replication,
I
think,
is
going
to
be
non-trivial
like
that.
I
think
we
first
have
that
I
come
to
consensus
on
what
those
things
mean
and
why
we
would
do
them,
and
we've
spoken
a
little
bit
about
that
at
the
the
face
to
face
that
we
had
in
seattle.
E
But
you
know,
there's
there's
a
you
know,
sort
of
tactical
needs
around.
You
know
backups
and
things
like
that,
which
is
one
reason
why
you
do
them
and
then
there's
more
strategic
reasons
why
you
might
do
them
for
application
portability
right,
and
so
so
that's
you
know
absolutely
buy
into
that,
but
I
think
we
need
to
talk
about.
You
know
why
we,
why
we're
doing
it
and
how
that
factors
into
you
know
a
design
that
we
may
come
up
with.
E
F
I
think,
with
regard
to
replication
and
snapshots
that,
in
order
to
get
stuff
moving,
we're
going
to
have
to
stage
that,
because
we've
been
kicking
around
snapshots
for
at
least
nine
months,
I
think-
and
it
there's
a
risk
here-
that
every
time
the
subject
comes
out,
people
keep
embellishing
it
adding
on
backups
and
application
consistency
and
in
reality
it's
going
to
have
to
be
done.
Staged
and
some
aspects
of
it
reflect
right
through
to
the
volume
plugins
like,
for
example,
simply
triggering
the
snapshot.
F
But
others
like
doing
the
backups
I,
don't
think
should
be
bundled
with
the
volume
plug-in
interface,
and
it
will
help
focus
these
discussions.
If
we
keep
those
separate
so
kind
of
the
minimal
thing
we
could
perhaps
shoot
for
for
2017
would
be
simply
a
mechanism.
That's
a
path
through
asking
a
storage
provider
to
do
a
snapshot
and
kind
of
avoid
the
temptation
to
go
into
the
the
whole
thing
of
layering
on
all
the
stuff.
F
You
use
it
for
and
tried
to
tack
it
on,
because
I
think
we're
likely
to
just
spend
meaning
after
meeting
talking
about
it
did
not
get
anything
done.
Replicating
kind
of
the
same
thing
we're
in
a
big
picture:
one
form
of
replication
is
just
doing
it
within
the
same
Kuber
Nettie's
cluster
in
the
same
physical
location,
but
doing
it
across
GL
regions
is
something
customers
would
really
like.
But
if
we
from
the
get-go
expand
the
discussion
to
have
all
that
going
on,
I
think
all
will
end
up.
G
Matt,
have
you
gone
through
the
face-to-face
notes
to
pull
down
any
action
items
or
topics
from
that
as
well?
I
mean
we've
gone
through
several
meetings
in
the
past
that
have
good
information
about
prioritization
from
those
face-to-face.
It
would
be
good
to
just
kind
of
lift
import
those,
rather
than
lose
any
of
the
discussions,
because
someone
might
not
be
on
this
call
and
no
to
add
that
okay.
G
And
within
those
notes,
I
think
one
of
the
sticklers
for
me
is:
if
we
move
all
the
volumes
out
of
tree,
we
need
a
way
of
certifying
the
volumes
for
some
sort
of
minimal
functionality
that
they
must.
You
know
pass
through,
and
it
has
to
be
like
a
shared
test
environment
of
some
kind
in
which
we're
able
to
say
that
these
are
at
a
tree,
but
they
are
working
well
at
a
minimum
level.
I
think
that's
important.
I
agree.
A
D
D
A
There
may
be
other
sets
of
actions
that
are
involved
with
snapshotting,
but
that
basic
minimal
set
is
something
that
all
snapshotting
systems
should
be
capable
of
doing
and
therefore
something
that
kind
of
makes
sense
for
Cooper
Nettie's
to
expose
in
its
API
for
encryption.
I
wonder
if
that's
the
case
and
I
don't
know
enough
about
how
various
encryption
systems
for
storage
work,
search,
fashion.
A
H
A
A
confidential
data
we
have
the
secret
mechanism
of
Coober
Nettie's
to
be
able
to
move
that
around
within
the
crew
brunetti
system
on
and
the
the
data
that
an
application
persists
persist
on
to
whatever
storage
system
is
available,
and
it
feels
to
me
like
that.
Storage
system
is
responsible
for
figuring
out
and
doing
the
encryption
for
that
data.
A
I'm,
not
sure
what
it
would
mean
for
Cooper
Nettie's.
To
be
aware
of
the
encryption
of
that
storage
system.
Is
there
anything
that
crew
benetti's
needs
to
do
because
I'm
thinking
about
gcep
DS,
for
example,
and
when
this
first
came
up-
and
we
realize
well
there's
actually
nothing
Cooper
Nettie's
needs
to
do
it'll
be
it's
encrypted
by
default,
and
the
storage
system
takes
care
of
it.
E
E
E
Has
encryption
and
they
lost
they're
like
oh
yeah?
It's
got
on
disk
encryption,
but
like
I
need
all
these
other
impressions
to
you
know
which
of
like
I've,
never
heard
of
don't
know
anything
about
those
use
cases.
Things
like
that,
and
so,
like
the
on
disk
encryption
to
them.
It's
just
the
start,
so
it
would
be
kind
of
interesting
for
us
to
like
pull.
H
A
E
You
just
for
folks,
you
know
communicating
more
broad.
Do
you
like
there's
like
a
number
of
different
specs
up
there?
That
I
think
one
of
the
things
we
slide
to
observe
is
that
it's
like
really
good
that
people
are
talking
to
each
other.
Now
like
there
seems
to
be,
the
community
is
assigned
to
come
together
right.
E
Think
are,
you
know
somewhat
engaged
already
on
the
with
lib
storage
and
then
you
know,
there's
a
new
there's
another
consortium
ourselves,
which
is
open
sts,
which
is
sort
of
largely
driven
by
Huawei
and
they're.
Also
coming
to
chat
to
us
about
this,
so
I
think,
like
that's
pretty
positive,
like
everybody's
coming
together,
it
doesn't
seem
like
there's
any
sort
of
loaded
agendas.
It's
just
more
interest
in
some
sort
of
out
of
tree
spec
that
we
can
all
build
through
that
broadly
applicable,
and
so,
like
consensus,
you
know.
E
Even
that's
not
really
an
engineering
thing,
I
think
in
the
critical
path
of
sort
of
arriving
at
this.
The
spec.
But
you
know,
as
a
sick
I
think
we
really
have
started
to
pay
a
lot
more
attention
attention
to
the
out
of
tree
story
and
flex
volume
as
part
of
that,
and
we
don't
like
have
like
a
bullet
by
bullet
like
roadmap
of
it.
But
I
would
say
it's
like
floated
up
really
high
for
the
top
of
the
six
priorities
for
next
year.
E
E
Now
you
guys
saw
the
bit
that
confuses
me
honestly
is
like
so:
we've
got
young
like
latest
external
provisioner
stuff,
but
I've
heard
rumors,
mainly
because
I've
contracted
that
actively,
but
I
thought
that
there's
some
talk
about
doing
provisioning
in
the
flics
proposal
to
which
makes
us
a
bit
confused,
because
we
really
have
a
external
provisions.
Yeah.
A
I
mean
it's
for
4
flex:
it's
just
a
matter
of
mirroring
the
internal
API.
So
when
the
actual
create
call
happens,
the
implementation
for
that
specific
driver
needs
to
get
called
out
to
something,
and
so,
if
so,
if
you
implement
a
story
driver
through
flex,
you
should
be
able
to
provide
a
provisioner
as
part
of
that
implementation,
and
so
that's
what
the
flex
API
would
do
so.
A
H
A
I
He's
been
in
and
out
he's
actually
been
doing
some
of
the
development
on
it
too
I.
So
the
plan
was
to
get
attached
detach
to
work
for
the
immediate.
You
know
16
17
timeframe
and
then
push
some
of
the
extra
features
out
past
that
so
it
you
know
any
provisioning
or
any.
You
know
we
talked
about
snapshots.
We
talked
about
a
bunch
of
different
things
that
we
could
add
to
flex
in
the
future.
We
would
move
that
stuff
too.
A
A
This
to
look
like
that's,
going
to
take
a
large
part
of
2017
to
figure
out
design
implement
beyond
that
looks
like
there's
still
interest
in
expanding
the
feature
set
for
Cooper
Nettie's
snapshots
data
replication,
local
storage
support
are
all
on
the
wish
list
of
what
we
would
like
to
accomplish
and
then,
of
course
stabilization
is
something
that's
an
ongoing
effort.
It's
going
to
be
part
of
all
the
existing
volume
plugins
increasing
test
coverage
have
like
Aaron
pointed
out.
A
It'll
be
easier
for
our
vendors
to
be
able
to
develop
volume
plugins,
but
it'll
be
a
little
bit
more
difficult
for
our
user.
So
we
need
to
keep
that
in
mind
and
then
we've
got
smaller
items.
Things
like
considering
how
to
do
mount
auction
pass
through
so
Matt's
going
to
go
ahead
and
capture
all
these
ideas
in
a
doc
and
he's
going
to
send
it
out
to
the
storage,
sig
mailing
group
and
folks
feel
free
to
add
to
that.
The
next
meeting
we
have
is
going
to
be
very
close
to
Christmas
I.
A
A
D
Your
arm
yeah
just
to
add
on
to
that.
So
probably
neither
in
this
docker
and
a
separate
off.
Maybe
we
can
solicit
ideas
pacifically
for
for
q1,
maybe
as
part
of
the
the
other
doc
and
just
maybe
a
little
bit
duplication,
maybe
we'll
just
put
the
headlines
and
what
we
think
we
should
be
working
on
for
Q,
and
that
way
we
at
least
have
something
we
can
speak
to
on
the
fourth
but
yeah.
A
A
A
F
Don't
know
what
the
perspective
of
the
guests
were,
but
Delhi
MC
thought
that
the
meeting
in
Seattle
was
worthwhile
and
we'd
like
to
offer
to
host
another
one
in
santa
clara,
which
might
be
a
better
location.
I
mean
seattle
was
good
since
the
conference
was
there,
but
I
think
santa
clara
is
a
more
central
location
where
a
lot
of
people
are
local
to
the
area.
So
we've
got
a
similar
meeting
space,
an
executive
briefing
center
located
there
that
could
host
the
meeting
awesome.
A
E
I
think
these
face
two
faces
are
super
valuable
they're
like
the
lifeblood
of
like
getting
stuff
done
in
the
sig
and
the
aisle
and
I
think,
though,
like
they
could
still
be
improved
like
I.
Think
that,
like
we
tend
to
be
a
bit
add
on
the
agenda
for
these
things,
which
and
I
think
has
the
potential
for
some
tricks
to
show
up,
hoping
stuff
will
get
discussed
or
resolved,
and
it
doesn't
happen
because
you
have
to
prioritize
and
I
think
like
one
of
the
things
we
could
do
with
that
so
love
the
idea.
E
I
think
we
should
go
meet
at
that
time
at
the
location,
Steve
suggesting
the
I.
Think,
though,
what
we
could
do
is
like
you've
been
tighter
on
the
agenda
and
say
like
look.
These
are
these:
are
these
key
things
that
we
need
to
discuss
like?
We
should
have
done
like
as
well
worked
out
in
the
community,
design,
proposals
etc
before
and
then,
like
the
meeting
is
used
as
at
the
final
consensus
for
those
type
of
things
kind
of
like
what
we
did
a
beta
for
dynamic
provisioning.
E
E
A
Yeah
now
that
great
idea
I
completely
agree,
I
think
one
of
our
most
useful
meetings
was
the
one
where
we
hammered
out
the
details
of
dynamic
provisioning
and,
like
you
said
it
was
one
of
those
issues
that
had
been
languishing
for
a
while.
A
lot
of
the
the
basics
were
agreed
upon,
but
the
fine
details
were
not,
and
these
kinds
of
meetings
are
very,
very
useful
to
finalize
on
those.
A
J
I
had
a
question
if,
if
somebody
willing
to
take
it
up,
so
we
have
a
cloud
provider
from
VMware
and
one
of
the
feedbacks
we
keep
getting.
Is
everybody
uses
their
own
deployments
clicks
when
it's
compromised
and
they
are
question
we
are
asking
for
documentation
and
the
documentation.
Today
is
not
organization
of
pearl
cloud
provider
basis,
they
are
getting
started
guides
and
this
kind
of
how
to
use
coupon
it
is.
But
if
you
want
to
configure
and
feature
supported
by
a
cloud
provider,
its
kind
of
what's
the
recommendation,
there.
A
So
I
think
the
docs,
a
good,
probably
a
better
place,
ask
this
question.
My
understanding
is
that
the
docs
need
a
lot
of
work,
they're
working
on
it
at
the
moment,
I'm
not
sure
what
their
plans
are
for
cloud
specific
instructions,
but
yeah
I'd
follow
up
with
the
docks
Zig.
Anyone
else
on
this
call
have
any
ideas.
A
F
I
I'd
say
that
the
across
cloud
providers,
it
isn't
very
uniform
in
terms
of
deploying
a
goober
Nettie's
cluster
to
a
public
cloud.
So
if
you're,
expecting
some
facade
in
front
makes
them
look
alike.
As
far
as
I
know,
it
doesn't
exist
personally,
I
think
I
I,
like
Kelsey
Hightower's,
Kuber
Nettie's
the
hard
way
just
to
understand
how
to
do
it.
Yourself,
I
mean
some
of
the
things
that
would
do
with
like
the
cloud
formation.