►
From YouTube: Kubernetes SIG Storage 20170928
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 28 September 2017
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.vcj8dh41d9r2
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:11:04 From hekumar : can you hide that zoom window and maximize spreadsheet?
09:11:28 From hekumar : Palak/Saad ^
09:24:20 From jinxu : Saad, My headphone is not working
A
A
A
A
All
right,
so
first
thing
is
1.9
planning.
We
are
at
the
end
of
q3
we're
starting
q4
1.8
shipped
yesterday,
Wednesday
for
planning.
We
have
a
new
p.m.
de
l'eau
who
is
going
to
be
working
with
zigge
storage
and
reporting
back
to
the
PM
sig.
It
used
to
be
Matt
Tulio,
but
Matt
DeLeo
is
working
with
other
steaks
now
Pollock.
Do
you
want
to
take
over
I'll,
stop
sharing
my
screen
and
you
can
share
yours.
B
B
B
C
D
A
A
We're
gonna
ask
you
to
kind
of
explain
what
what
the
feature
is
and
and
then
try
to
figure
out
what
the
priority
is
and
hopefully
assign
someone
to
actually
work
on
it
and
for
folks
who
are
new
to
the
sig.
This
is
an
opportunity
to
step
in
and
to
contribute.
This
is
where
we
figure
out
what
we're
going
to
be
working
on
who's,
going
to
be
working
on
it,
who
is
going
to
be
reviewing
it
and
that
kind
of
thing.
D
A
Gonna,
we're
gonna
call
it
we're,
not
gonna.
Freeze
it
this
right
right
now,
it's
not
going
to
be
frozen
until
the
feature
freeze
date
or
kubernetes,
which
tends
to
be
about
two
or
three
weeks
into
the
quarter.
I'm,
not
sure
what
it
is
this
time,
so
we
have
until
then
to
revise
it,
but
we
should
have
something
nailed
down
before
the
new
quarter
begins,
which
is
October
first
next
week,
but
well.
We
will
be
able
to
revise
this,
at
least
in
the
next
storage
sig
meeting.
B
B
A
E
A
B
E
F
F
B
E
A
E
A
B
B
G
A
Would
probably
call
this
a
p2
I
think
this
is
a
really
nice
feature
to
have.
It's
gonna
make
a
testing
of
antenna
testing
of
the
existing
entry
volume
plugins
much
easier
and
it'll
also
make
it
easier
to
to
have
add
support
for
these
volume
plugins,
where
you
don't
necessarily
have
the
ability
to
install
the
dependencies
on
the
host
OS.
That
said,
if
we
don't
end
up
making
it
for
any
reason,
it
wouldn't
be
the
end
of
the
world
yan.
Do
you
agree
as
p2?
A
So
the
hope
this
quarter
is
to
we're
good
we're.
Gonna
have
the
face-to-face
meeting
in
a
couple
of
weeks,
I'm
hoping
to
send
out
a
design
doc,
probably
a
week
before
that,
and
then
hopefully
we
can
finalize
on
the
design
and
start
working
on
implementation
and
I
would
like
to
drive
this
to
alpha
this
quarter.
That
would
mean
a
new
si.
Si
volume
plug-in
being
introduced
entry
that
would
enable
si
si
volume
drivers
natively
in
kubernetes.
A
A
We've
got
Brad
and
Steve,
but
I
think
I
can
probably
pull
Michelle
or
Jing
to
help
with
the
review
as
well,
so
we're
pretty
well
staffed
on
it
priority
wise
I
would
I
would
consider
this
a
p1
for
our
group
having
enabling
out
of
tree
volume
plugins
that
are
containerized
and
making
si
si
work.
I
think
is,
should
be
a
high
priority
for
this
group.
Does
anybody
agree,
disagree.
H
A
A
A
B
B
A
So
this
is
a
effort
to
try
to
come
up
with
a
generic
mechanism
to
handle
arbitrary
topology
in
storage.
When
I
say
topology
I
mean
the
essentially
availability
zones
in
kubernetes.
Today
we
kind
of
hack
around
this
for
cloud
providers.
We
hacked
in
the
zone
in
region
handling
code,
it's
passed
around
as
an
annotation,
but
it's
not
very
flexible.
The
code
and
the
scheduler
is
actually
hard-coded
to
look
for
those
specific
annotations
and
and
do
whatever
it
needs
to
do
with
them.
A
What
we
want
is
to
be
able
to
handle
topology
more
generically
for
storage
such
that
it
doesn't
matter
whether
it's
region
zone
or
it
could
be
on
Prem
racks
or
whatever
other
arbitrary
topology
it
is.
Our
code
should
be
able
to
handle
it
more
generically.
This
is
something
that
I've
run
into
on
the
CSI
side
of
things
and
Michelle's
kind
of
run
into
this,
with
local
storage
as
well,
because,
ultimately,
local
storage
is
a
topology
where
essentially,
where
you
have.
A
B
B
B
A
B
A
E
B
I
So
we
did
the
same
work
in
1.8.
We
got,
we
have
a
already
designer,
so
we
need
to
carry
on
with
this
work
in
1.9
and
I
was
like
this
to
take
two
to
be
done
in
1.9
and
I
had
more
volume
types
CAW
in
a
few
and
yeah.
Does
it
sound
fair,
like
the
parity,
wise
I,
think
it
should
be?
That's
what
it
was
in
the
last
quarter
as
well.
B
B
A
J
I,
don't
like
that
genius
Autobots
are
here
on
that.
This
is
what
I
mean.
So
we
already
have
the
external
snapshots
controller
and
it's
being
worked
on
and
there's
confidence,
that's
doing.
1.8,
it's
going
to
be
stabilized.
Hopefully,
entry
entry
API
into
plugins
will
help
is
to
guess
the
functionalities
that
has
did
and
reduce
a
lot
of
redundancy
is
we
have
as
a
external
controller.
A
The
challenge
with
bringing
it
entry
is
we're.
Gonna
have
to
make
sure
that
we
go
through
all
the
appropriate
architectural
reviews,
especially
make
sure
that
we
run
it
by
the
workloads
team.
I.
Think
one
of
the
big
outstanding
questions
around
the
snapshotting
feature
is
how
is
it
going
to
interest
with
end-to-end
flow
and
as
long
as
we
make
sure
that
we
get
all
those
approvals?
I
think
that
this
would
be
a
reasonable
goal.
Okay,.
A
I
think
we're
gonna
start
with
a
feature
repo
bug.
That's
going
to.
This
is
the
work
that
we
intend
to
do.
Then
we
need
to
go
and
create
a
design.
Doc
saying
this
is
the
feature
that
exists
out
of
tree:
here's
how
it
currently
works
and
here's
the
proposal
for
pulling
it
into
tree.
We
plan
to
add
this
controller.
We
plan
to
extend
the
API
in
this
way,
and
this
is
the
way
that
it
should
be
used
end
to
end
by
users.
A
J
B
E
A
E
E
So
the
main
goal
for
PD
paints
and
Toleration
x'
is
to
it's
sort
of
similar
to
the
notation
Toleration
feature,
mostly
used
in
health
monitoring,
where
you
can
have
some
entity
monitoring
the
state
of
your
health
of
your
disks
and
if,
for
some
reason,
your
disc
becomes
inaccessible
or
and
healthy,
you
can
taint
it,
and
then
you
can
set
Toleration
x'
in
your
app
to
say,
specify
whether
or
not
your
application
is
capable
of
releasing
it's
finding
on
its
volume.
So
the
major
use
here
is
for
distributed
file
systems
where
they
have.
E
A
K
So,
to
give
a
bit
of
background
what
this
is
currently
in,
the
the
static
provisioner
has
a
and
it's
running
a
daemon
set,
so
it's
running
in
every
single
node
and
every
every
single
pod
has
access
to
creating
and
deleting
modifying
PBS,
and
this
has
been
insecure
and
we
want
to
limit
that
scope.
So
the
new
design
we
came
up
with
is
to
only
have
that
access
in
massive
master
in
a
in
a
trusting,
node
and
then
have
have
the
pause
on
every
single,
every
other
node
as
worker
nodes.
K
So
they
will
be
reading
into
reading
the
file
system,
discovering
new
volumes
and
performing
the
deletes
a
parishioner,
whereas
the
master
has
the
all
the
central
logic
for
determining
when
to
trigger,
discover
or
to
modify
PVS
etcetera.
So
right
now,
I
have
a
proposal
out
waiting
for
seven
review
opinions
just
waiting
for
some
security
clearance
before
I
move
on
to
implementing
it.
A
L
Yeah,
yes,
I'm,
not
sure
Nick
is
here
or
not,
but
basically
is
part
of
the
capacity
isolation
feature,
so
I
think
Nick
is
working
on
it
and
I
will
help
to
review
it
and
the
target
is
in
our
beta
because
we
have
kind
of
other
considerations.
But
this
is
alpha
yeah,
it's
it's
just
part
of
the
isolation
feature
already
working
on
ones,
7
and
1/8,
and
the
priority
is
1
or
you
know,
I'm,
not
sure
we
have
0.
No,
we
don't
have
0.
So
it's
1.
A
B
M
N
L
D
L
A
M
B
A
A
A
A
It's
not
entirely
clear
how
useful
they
are
in
their
current
state
or
the
ask
here
is
for
someone
to
for
line
15
review.
The
logs
that
were
putting
out
for
things
like
mount
calls
attach
calls
provisioning,
deleting,
etc
and
make
sure
that
the
right
things
are
getting
or
making
it
to
the
logs,
and
we
haven't
sufficient
information
for
for
debugging,
and
so
16
is
is
the
same
thing
except
it's
asking
to
do
that
for
events,
the
a
skier
would
be.
Are
we
attaching
the
events
to
the
correct
objects?
A
For
example,
if
there
is
an
error
on
the
attach
call
and
an
event
is
generated,
you
know,
is
it
its
purpose
to
the
user
in
a
way
that
they
can
use
that
information
and
understand
what
went
wrong?
So
it's
more
if
they
examine
the
system
find
where
the
gaps
are
and
and
fill
those
in
any
volunteers.
For
these
two
items
would
be
great.
This
is
a
nice
intro
item
for
someone
who's
just
joining
the
community,
because
you
get
to
dig
around
the
whole
codebase
and
it's
not
extremely
difficult
to
ramp
up
on
yeah.
A
A
A
L
B
L
I
G
B
L
So
there's
still
some
issues
of
his
our
like
amendment
and
I
have
a
tab
in
this
document
called
stability
and
the
list.
Some
issues
like
we
discovered
so
far
and
would
like
to
address
them
and
also
internal
or
external
anyone
who
like
to
look
at
them.
It
would
be
great,
so
it
definitely
helped
to
understand
that
our
core
code
base
model
management,
yeah.
I
L
A
It
might
be
worthwhile
to
actually
break
the
stability
item
out
into
multiple
actual
tasks,
rather
than
just
a
generic
stability
item,
because
that's
hard
to
track.
The
second
thing
is
trying
to
under
gauge
the
priority
for
each
one
of
the
bug
fixes
after
we
break
them
out
and
figuring
out
how
much
effort
we
should
be
investing
in
in
fixing
them
I
know
there
are
a
number
of
bugs
that
exist
in
the
system,
I'm,
not
sure
what
their
priority
is,
because
we
don't
really
understand
what
how
frequently
they're
happening.
A
I
would
really
like
this
quarter
that
we
invest
in
improving
our
metrics
and
logging
to
get
a
better
gauge
for
how
frequently
these
things
are
happening
and
let
that
feed
into
the
priority
for
these
bugs,
but
two
a
month
and
jinx
point.
We
do
have
some
of
these
areas
identified
as
there.
There
are
issues
we're
not
entirely
sure
how
frequently
they
happen,
and
it's
worth
you
know
trying
to
fix
them,
but
maybe
not
as
a
p1.
We
could
mark
them
as
p2
the
most.
P
A
A
I
I
think
my
engine
can
work
together
and
try
to
like
have
separate
line
items
for
each
type
of
the
category
of
bugs,
but
one
thing
that
you
mentioned
that
I,
maybe
you
guys,
will
have
time
to
discuss
interface
to
places
like
that,
the
like
how
often
this
is
happening,
so
we
won't
have
like
the
matrix
that
we
have
so
far.
They
will
only
tell
like
okay
volume
attach
failed.
It
wide
field.
Well,
we
should
maybe
have
a
matrix
of
life.
How
many
parts
are
failing
to
start
because
of
all
the
matter?
Q
Know
I
think
it
would
be
great
on
maybe
the
six
torrid
list
if,
if
somebody
could
start
a
thread
that
just
says
ideas
on
metrics-
and
you
know-
maybe
we
start
with
a
mailing
list
and
just
throw
in
everyone's
bag
of
ideas
of
useful
metrics.
And
then
we
can,
you
know
hopefully
in
1:9,
start
finding
ways
to
expose
those
signals
and
make
them
consumable.
You
know
one
of
the
the
challenges
so
that
the
the
Google
team
got
together
and
we
were
like
you
know,
1/9
stability.
L
Q
Have
our
ideas
of
interesting
signals
that
would
help
us
make
more
intelligent
decisions
in
the
future,
but
the
real
question
is
you
know
everybody
should
be
able
to
contribute
to
what
those
signals
are
for
1/9.
So
you
know:
if
anyone
wants
to
go
to
the
list
and
say
hey,
you
know:
here's
the
signals
that
we
think
are
useful
and
then
yeah.
A
L
I
We
have
yeah,
we
have
like
last
quarter,
we
implemented
the
volume
operation
matrix
previous
quarter,
we
are
providers
to
his
matrix
and
then
we
added
last
quarter.
We
added
the
TVC
matrix
like
so
we
have
consistently
been
adding
the
matrix.
We
haven't
been
listing
them
in
one
place
because
sometimes
the
change
name.
So
maybe
we
should
list
them
and
that
could
be
an
item
itself,
but
but
does
the
the
three
three
kilometers
that
I'm
aware
of
that?
They
are
added.
So.
Q
This
is
where
my
ignorance
of
the
kubernetes
curve
comes
out
and
clear
in
the
kernel.
I
know
that
there's
trace
points,
and
you
can
always
you
know
programmatically
probe
and
find
a
list
of
trace
points
that
let
you
understand
where
you
can
collect
and
gather
signals
for
the
future
and
there's
like
three
sub
systems
to
do
that,
though,
I
think
they
converge
to
a
while
back
is
when
we
put
in
these
signals
today.
I
Q
This
is
the
part
where
I
feel
sometimes
things
you
know
stop
too
soon.
Possibly
you
know
when
you're
an
engineering,
your
developers,
that's
really
great,
because
you
understand
the
system
and
you
understand
the
code
layout
really
well.
But
if
you
are,
let's
say
a
support
engineer
or
a
cluster
admin,
you
know
something's
going
on
with
your
volumes
and
you're
not
really
sure
what
or
why
and
you
don't
know
where
to
look.
You
know.
All
of
those
signals
may
be
way
too
much
to
juggle.
Q
Q
L
Q
I
guess
I've
got
two
points.
One
is
if
we
don't
understand
how
we're
going
to
do
that.
Just
adding
the
signals
is,
you
know,
maybe
premature,
like
we
should
probably
figure
out
how
we
want
to
consume
them
before
we.
You
know
as
we're
thinking.
Oh
sorry,
let
me
organize
my
thoughts
now
seems
like
a
good
time
to
come
up
with
a
high-level
list
of
all
of
the
areas
that
we
think
we're.
Q
N
I
Yeah
I
have
documented
some
in
the
peer
surveys:
how
to
consume
them
in
how
to
consume
them
and
how
to
read
them
like
there's
a
documentation
on
communities
that
I
owe
and
but
is
not
exhaustive
and-
and
there
was
some
resistance.
Transformational
signal
situation.
Sorry
suggest
immunization
folks
for
about
like
listing
in
division
matrix
in
her
face,
because
my
changes
submit,
but.
Q
A
Some
of
that
actually
could
be
on
the
side
of
folks
who
are
actually
running
the
kubernetes
cluster.
The
first
and
most
important
part
is
actually
surfacing
the
metrics.
The
second
part
is
collecting
them
and
then
making
them
easy
to
view.
The
the
part
that
Hamas
has
worked
on
is
been
surfacing.
It
and
I
think
that
belongs
in
the
open-source
side
of
things.
I
think
these,
how
you
surface
it,
how
you
collect
it
can
actually
be
on
the
specific
to
each
deployment.
C
I
I
think
we'd
they
haven't
provided
any
specific
iodine
about
that
so
I'm,
sorry,
so
yeah,
so
we
need
to
now.
I
would
like
to
open
like
talk
to
them
again,
maybe
and
get
an
idea
like
okay.
How
do
we
like
it's
too
hard
right
now
to
figure
out
what
those
endpoints
are
call
endpoints,
where
the
matrix
R
is
like
how
to
set
them
up?
It's
like
to
difference.
I
would
like
to
talk
to
them
again.
I
I
think
I
can
do
that
this
quarter
and
and
figure
out,
okay,
how
if
we
can
find
a
way
to
programmatically,
generate
to
start
and
rather
than
have
a
static
page,
so
but
I
don't
know
if
they
will
have
a
immediate
solution.
It
repeats
the
solution
that
is
odd
series
deployment
specific.
How
one
deploys
community
is
how
it
could
be
deployment
specific
so
but.
C
Do
I
mean
are
where
the
metrics
prepended
with
something
to
indicate
that
their
storage
metrics,
so
it's
easy
to
filter
on
those?
Are
you
saying
the
piece
that's
hard
to
set
up
is
the
actual
gathering
infrastructure,
not
adding
the
pieces
of
storage
we
care
about?
Is
it
divided
out
that
way?
I
guess.
Can
we
have
like
a
demo
of
it?
C
I
Q
Sounds
like
we
have
a
lot
of
questions
about
how
to
consume
these
metrics
to
anyone
volunteer
that,
maybe
then
six
or
to
give
a
demo
like
I,
think
Aaron
has
great
idea
so
that
we
can
all
sit
down
and
see
how
it's
done,
and
if
that
person
can
also
reach
out
to
sig
instrumentation
and
hear,
if
they're
ready
to
give
any
guidance.
That
would
be
great.
So.
A
I
Q
So
that
sounds
like
a
great
action
item
so
that
we
sounds
like
there's.
Two
one
is
come
up
with
a
list
of
the
the
signals
that
we
want
to
see
that
we
think
will
be
helpful
and
then
camonte
and
jane
can
come
back
next
meeting
with
a
mini
demo
of
or
or
a
presentation
or
like
just
a
report
of
how
we
feel
they
should
be
consumed
or
where
we
are
today.
Yeah.
L
B
Sounds
good,
so
I
think
line
item
eighteen
and
nineteen
would
connect
to
twenty-three
then.
So
we
want
to
have
all
the
bug
fixes
and
some
of
the
issues
that
we
are
getting
to
be
in.
You
know
taking
so
surfacing
these
metrics
into
account
for
thinking
about
how
do
we
want
to
plan
and
prioritize
them?
B
A
So
this
was
a
line
item
I
added
I
would
prioritize
this
as
p3.
It's
a
cool
fun
item
to
investigate
and
design
and
maybe
a
push
to
alpha
this
quarter.
If
we
have
the
bandwidth,
the
idea
here
is
currently
we
create
an
empty
door.
When
a
pod
starts
it
exists
for
the
lifecycle
of
the
pod,
then
we
delete
it
if
anybody
else
gets
access
to
that
machine
or
for
some
reason
that
data
doesn't
get
cleaned
up.
A
All
that
information
is
sitting
on
encrypted
and
available
to
everyone,
and
the
suggestion
is
to
possibly
use
filesystem
encryption
to
encrypt
the
directory
when
we
create
it
and
put
that
encryption
key
in
the
kernel
ring,
and
so
if,
for
any
reason,
the
data
is
not
cleaned
up,
perhaps
because
cubelet
crashed
or
for
whatever
reason,
I
and
or
somebody
else
gets
access
to
the
actual
localhost
disk.
They
won't
necessarily
have
access
to
the
data
that
was
written
in
that
empty
der.
A
We
would
have
to
design
this
to
be
an
opt-in
feature,
because
it
would
necessarily
break
some
of
the
assumptions
about
empty
dirt
around
lifecycle,
but
that
could
be
hammered
out
in
the
design.
It's
a
cool
fun
feature
to
work
on
I.
Think
David
on
our
team
was
interested
in
taking
a
look
at
it,
I'm,
not
sure
if
you're
still
interested
David
yeah.
B
A
D
About
this
request,
so
so
far,
six
storage
I
feel
is
focusing
major
majorly
on
persistent
storage
and,
and
we
have
talked
about
few
aspects
of
availability
like
reputation.
I,
don't
know
it
is
my
ignorant.
If
they're
in
backup
has
been
talked
about,
maybe
I'm
not
aware
of
it,
and
what
I
see
is
that
customers
who
are
unit
of
anarchists
are
actively
talking
about
it.
We
have
some
backup
vendor
so
I've
reached
out
to
a
VMware.
D
D
Q
Is
the
background
really
I
thought
that
there
was
a
lot
of
like
technologies
out
there?
That
would
allow
you
to
backup
from
cloud
providers
and
even
sync,
two
ways,
and
my
other
question
is:
are
we
sure
that
this
is
functionality
that
belongs
in
the
kubernetes
control
plane?
Is
that
what
you're,
suggesting
or
just
suggesting
to
have
any
sort
of
guidebook
or
suggestion
of
how
to
do
this
even
outside
of
it?
Yes,.
Q
Q
In
any
case,
I
think
he
may
be
muted
and
listening.
Alfred
fuller
is
one
of
the
storage
experts
in
Google,
who
knows
a
lot
about
what's
been
going
on
and
sort
of
outside,
of
Google
enter
and
on
Prem
environments,
and
we've
asked
him
to
you
know
also
be
around
to
just.
Do
you
know
to
be
a
participant
to
the
sig
and
he
has
said
that
he
is
got
the
time
and
we'll
be
able
to
be
focused.
Q
So
if
you
you
know,
please
make
him
feel,
welcome
and
he's
got
a
lot
of
experience
in
both
building
storage
systems
and
storage
api's.
You
know,
he's
probably
going
to
be
focusing
on
snapshots
with
Jane
and
I.
Think
that's
it,
but
for
questions
like
the
one
that
you
just
asked
about,
and
you
know
what's
available
for
backups
and
cloud
providers,
it
might
be
another
area
where
he
might
either
have
expertise
or
know
someone
who
does
and
I.
P
D
A
A
Okay,
cool-
we
are
just
about
out
of
time.
Unfortunately,
we're
not
going
to
have
time
to
do
the
demo
that
Eric
had
planned
today
for
his
docker
volume
driver
phlex
driver,
but
we're
going
to
put
him
first
thing
at
the
next
meeting
so
that
we
have
enough
time.
For
that
last
thing
I
wanted
to
mention
was
the
face-to-face
meeting.
It
is
going
to
be
October,
10th
and
11th.
The
location
has
been
confirmed.
A
A
Unfortunately,
so
if
you
have
an
RSVP'd
and
you're
but
you're
still
interested
in
attending,
you
can
add
yourself
to
the
remote
attendees
list,
and
if
anybody
drops
out,
we
can
pull
pull
folks
in,
but
otherwise
we'll
have
a
zoom
setup
in
the
meeting
room
for
folks
we're
going
to
be
able
to
attend,
remotely
and
I
believe
Dell,
EMC
and
port
works
are
going
to
be
hosting
a
dinner
the
first
day.
Steve.
Do
you
have
any
thing
you
want
to
add
to
that.
N
A
Q
I
think
we
may
even
want
to
do
our
agenda
is
getting
so
packed
now.
It
may
make
sense
to
almost
order
and
then
again,
de
on
email
before
the
meeting.
It's
definitely
a
bummer
that
someone
had
a
demo
all
prepped
and
we
didn't
get
it
done
as
we
were
sort
of
enumerated
over
the
priorities
of
planning.
So
much
so.