►
From YouTube: Kubernetes SIG Storage 20180927
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 27 September 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.fhnfgkmqk4np
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:20:16 From Srinivas Brahmaroutu : I am interested in helping with Conformance Test Suite. @msau I will touch base with you.
A
A
A
As
a
reminder,
this
coming
quarter
is
shorter
because
of
the
holidays
at
the
end
of
the
quarter,
so
code
freeze,
I,
believe,
is
about
a
week
prior
to
Thanksgiving,
which
is
November
31st,
but
a
week
we
can
have
so
there's
not
a
lot
of
time
for
coding.
Let's
make
sure
we
stay
focused
and
try
to
get
finished
as
much
as
we
commit
to
so
with
that
we'll
go
ahead
and
get
started
so
for
CSI.
A
A
A
But
I
would
call
it
a
p2,
meaning
it's
not
something
that
we
would
block
the
release
on.
If
we
were
unable
to
move,
CSI
is
block
implementation
to
beta.
We
could
still
move
the
rest
of
it
to
GA
and
move
the
block
portion
on
its
own
independent
of
the
core
thoughts
on
that,
and
is
anybody
interested
in
working
on
that.
B
A
B
A
A
C
A
To
be
clear,
this
is
not
the
I
scuzzy
or
fiber
channel
common
libraries.
This
is
the
mount
code.
So
if
you
look
inside
the
kubernetes
kubernetes,
the
volume
utilities
there
is
a
mount
library
mount
go
and
then
there's
flavors
a
fit
for
each
platform,
mount
underscore
linux,
mount
under
store
windows
and
so
on
and
so
forth.
A
D
B
A
That
sounds
good
next
up
is
the
pluggable
end-to-end
test
framework,
so
this
was
an
effort
that
was
I'm
not
sure
what
the
actual
progress
here
is,
but
the
goal
was
to
modify
the
end-to-end
test
framework
that
we
have
so
that
it's
not
a
custom
test
that
we
write
for
every
single
volume
plug-in.
Essentially
you
write
the
test
once
and
then
you
can
specify
any
arbitrary
plug-in
that
should
run
it,
so
something
that's
very
important
to
continue
to
scale.
A
F
G
F
E
Strange
community
question
regarding
this
I,
so
we're
actually
working
on
a
local
storage
operator
that
may
have
some
slight
overlap
on
this
and
the
intent
is
to
I.
It's
actually
part
of
the
open
shift
for
a
platform
that
we're
changing
to
I,
don't
know
does
upstream,
do
you
guys
have
any
interest
if
we
make
this
available
upstream?
If
it's
solve
some
of
these
PV
health
money
or
and
PV
deployment
issues
present
so.
E
A
H
F
A
A
Don't
think
this
is
as
important
as
kubernetes
conformance,
because
that
becomes
much
more
of
a
an
issue
in
terms
of
who
claims
to
be
kubernetes
and
who
doesn't
with
CSI
the
fact
that
we
basically
control
the
implementation
side
of
Guber
of
CSI
and
kubernetes.
Either
you
work
with
us
or
you
don't
so
that
kind
of
acts
as
a
forcing
function
for
CSI
conformance,
but
it
would
be
nice
to
be
able
to
have
a
formal
definition
of
this.
A
E
E
Right
driver
implements
the
Specht
API
just
at
the
non-functional
level
right.
It's
just
does
this
call
return
something
but
I
don't
know
how
that
we
would
do
more
than
that.
I
mean
I,
guess,
there's
a
document,
that's
establishing
I.
You
know
at
the
CN
CF
CSI
level,
they're
kind
of
running
a
big
storage
dock.
E
A
For
CSI
conformance
I
mean
it's,
the
spec
defines
what
CSI
is.
We
need
verification
of
that
the
CSI
sanity
test
suite
that
we
have
is
one
part
of
that.
But
beyond
that,
I
think
there's
other
behaviors,
that
we
need
to
be
able
to
test
and
verify,
especially
across
multiple
calls
that
we
don't
necessarily
do
today
and
then
there
could
also
be
requirements
that
are,
you
know,
not
necessarily
tested
through
a
test
suite,
but
our
requirements
for
claiming
that
you're,
a
CSI
driver,
I.
A
F
A
E
A
No,
no,
this
is
a
the
distribution
of
KU
brandy
supports
the
kubernetes
volume
subsystem,
so
you
could
have
kubernetes
I,
believe
I'm,
not
sure.
If
the
profiles
have
been
established
but
longer
term
I
believe
you
could
have
a
kubernetes
distro
that
doesn't
really
support
state
and
yeah.
If
you
don't,
you
don't
really
have
to
worry
about
these
tests,
but
if
you
have
a
kubernetes
distro
that
claims
to
be
able
to
support
state,
then
you
have
to
be
able
to
pass
these
tests.
Is
that
no.
F
A
F
F
This
is
for
this.
The
intention
here
is
for
non-root
disks.
So
if
say,
you
want
to
dedicate
some
like
LVM
volume
group
for
local
volumes
to
do
dynamic
provisioning.
You
need
a
way
to
support
the
capacity
of
that
volume
group
separate
from
the
root
disk
reporting
that
we
already
do
for
ephemeral
volumes.
A
F
A
C
So
for
a
1.13,
the
only
thing
we
might
have
to
do
is
they're,
releasing
like
a
lease
object
or
something
specifically
earlier
election,
so
that
might
I
guess
that
would
be
a
different
item
than
this,
though
cuz
we
have
to
do
that
for
external
attached
or
two
anyway,
yeah
I
think
it's
done.
I
think
Chang
was
working
on
this
or
helping
you
work
on
this.
Oh
yeah.
A
J
I
got
a
question
on
this,
because
previously
both
provisioner
and
attach
are
using
stable,
set
and
doing
our
development
I
realize
that
if
the
one
node
is
disconnected
stays
percent
deleted
apart
automatically
and
I
found
that
in
our
office,
your
documents
say
that
kubernetes
version
1.4
annealer
would
not
delete
for
just
because
no
these
aren't
reachable.
So
this
basically
means
if
the
currently,
if
the
external
provisioner,
the
node
of
that
provisioner,
is
down
the
whole
class
they're
only
able
to
provision
anything
so.
A
I
think,
once
leader
election
is
working
which
I
believe
with
the
current
batch
of
sidecar
containers
released
with
112
it's
using
the
endpoint
object
to
do
leader
election.
You
should
be
able
to
enable
leader
election
and
then
use
a
replica
set,
because
you
don't
have
to
worry
about
if
two
objects,
accident
or
two
instances
accidentally
start
at
the
same
time,
they'll
be
able
to
figure
out
which
one
is
which
one
should
take
take
leader:
okay,.
J
C
A
A
F
F
A
G
A
A
B
A
A
Cool
all
right
next
up
is
dynamic,
max
capacity
per
plug-in
per
node
count
to
2-2
for
entry.
Si
si,
so
we
already
have
a
mechanism
by
which
we
can
measure
the
max
number
of
volumes
per
node,
and
this
item
was
saying
in
addition
to
that,
we
want
to
also
be
able
to
limit
the
max
capacity.
So
even
if
you
have,
for
example,
two
volumes
but
together
they're
a
hundred
terabytes
and
that's
more
than
the
max
limit,
you
can't
add
any
other
additional
volumes
a
month.
Are
you
on
the
line
by
any
chance?
Yep
awesome.
K
A
K
E
H
A
H
A
Next
up
is
a
large
item,
so
for
the
last
couple
quarters
David
Zoo
on
my
team
has
been
working
on
establishing
a
plan
for
migrating
the
entry
volume
plugins
to
CSI
that
is
ready
to
be
approved,
or
the
plan
basically
approved,
and
the
next
steps
are
starting
to
implement
that
we're
hoping
to
have
an
alpha
implementation
in
q4
and
then
either
beta
and
q1
or
q2,
and
then
GA
after
that.
This
is
something
that
we
need
to
do
very
carefully.
The
marker
for
success
here
is
that
it
happens
silently
and
nobody
notices.
A
You
know
if
we
mess
this
up.
That
means
that
it
would
be
a
user,
visible
issue
that
would
prevent
them
from
accessing
their
volume
and
volumes
in
the
way
that
they
want.
This
is
a
very
large
project.
I
expect
David
to
lead
it,
but
there
is
a
lot
of
room
for
folks
to
come
in
and
help
here.
I
know
there
were
some
folks
from
AWS
that
were
interested
in
helping
with
this.
Is
anybody
on
the
call
interested
in
helping
helping
with
this.
A
B
A
A
G
A
A
A
A
A
G
A
C
A
Next,
one
is
an
important
feature:
I
think
this
has
been
something
that
a
number
of
folks
have
run
into
and
there's
a
couple
of
flavors
of
this,
but
essentially
what
it
boils
down
to
is
that
if
the
node
becomes
unavailable
for
some
reason
and
is
unable
to
acknowledge
that
it
was
safely
able
to
unmount
in
specific
cases,
the
volume
is
effectively
stranded
on
that
node
and
even
though,
ideally
we
want
to
be
able
to
reschedule
that
pod
to
a
different
node.
We
can't
actually
move
the
volume
because
it
never
gets
detached.
A
There
was
a
huge
discussion
around
trying
to
fix
this
last
quarter
and
I
think
it
involved
actually
interacting
with
teams
beyond
just
storage
with
the
node
team
and
other
teams
who
are
giving
us
the
signal
of
when
a
workload
is
migrated
and
moved
and
actually
deleted,
and
things
like
that
I
think
it's
very
important
work
that
we
need
to
prior
prioritize
more
highly.
This
quarter,
I'd
like
to
call
it
a
p1
and
see
if
we
can
get
more
folks
working
on
this,
ideally
more
than
one
person
Yassin.
M
I
K
A
Thank
you,
I
mean
I,
think
this
is
one
of
the
highest
priority
items
for
us
this
quarter.
We
really
need
to
figure
out
how
to
handle
this
I.
Think
a
lot
of
people
have
run
into
this
issue,
so
we
really
need
to
fix
it.
So,
speaking
of
areas
that
are
causing
pain
in
our
current
volume
subsystem,
the
volume
reconstruction
code
continues
to
be
a
source
of
pain,
I.
Think
previously
we
prioritize
this
as
a
p3
I'd
like
to
bump
this
to
p2
I
think
we
continue
to
see
bugs
in
this
area.
A
The
task
here
would
be
to
actually
design
what
this
feature
would
look
like.
Apparently,
there
is
a
cubelet
checkpointing
mechanism,
so
the
goal
here
is:
if
we
can
Cupid's
native
checkpointing
mechanism,
assuming
it
does
what
we
think
it
does
then,
ideally,
if
the
cubelet
crashes
and
comes
back
up,
we
haven't
really
lost
state.
A
A
Okay,
I
think
it's
important
work.
If
somebody
is
interested
in
working
on
it,
please
reach
out
to
me,
and
we
can
we
can
get
you
started
on
this.
Otherwise
we'll
leave
it
unassigned
for
this
quarter.
Again,
it's
a
short
quarter
and
we
want
to
make
sure
we
remain
focused
on
what
the
higher
order
bits
are,
which
are
getting
some
of
our
features
to
GA.
A
F
So
this
is
these:
are
things
like
the
local
storage
operator
and
stuff
is
trying
to
solve?
We
might
want
to
delay
this
one
more
quarter
to
iron
out
those
issues.
I
think
the
people
that
are
really
clamoring
for
this
feature
have
already
been
using
it
in
alpha
and
beta,
so
I
think
going
to
GA
I'm,
not
sure
if
anyone
is
actually
just
waiting
for
this
feature
to
go
GA
or
not.
Okay,.
A
A
K
K
K
F
A
A
K
A
A
A
All
right
cool,
thank
you
for
the
clarification
there
next
up
is
bringing
snapshot.
Support
to
beta
I
think
this
is
a
lot
of
great
work
done
last
quarter
bringing
this
to
alpha,
there's
a
very
there's,
a
great
blog
post
coming
out
about
this
soon
on
communities,
IO!
So
a
lot
of
good
mentum.
We
should
continue
to
carry
that
forward.
I
think
Jing
and
Shang
have
a
list
of
features
that
they're
interested
in
adding
for
beta.
A
Know
it's
not
officially
like
there's
no
official
like
exact
process
on
the
graduation
in
general.
What
we
do
is
implement
it
as
alpha
and
wait
for
feedback
to
see
how
people
are
using
it
and
see
what
kind
of
issues
they
have
on
it.
Normally,
once
we
have
folks
using
it
will
will
it's
enough
of
a
signal
one
way
or
the
other
to
say.
Okay,
you
know
it's
working,
the
way
that
we
generally
intend
to
or
are
not
working
the
way
that
we
want
to.
A
Ideally,
I
don't
want
to
get
to
beta
and
have
what
happened
with
volume
attach
limits,
but
to
be
fair
if
that
shots
design
has
been
very
thoroughly
vetted.
So
I'm
less
concerned
about
that
happening
here,
but
I'm
I'd
prefer
to
take
it
a
little
bit
slower,
but
we
could
take
it
to
beta
this
quarter
and
then
keep
it
in
beta
two
quarters.
So
the.
F
J
Nice
I
think
in
this
case
we
should
keep
vendor.
Sometimes
you
see
an
integrate
with
the
feature
you
see
you
mentioned
that
is
short
quarter,
I,
don't
know,
I,
don't
know
either
at
least
from
my
perspective.
We
haven't
the
looking
slowly
into
the
snapshot
feature
yet,
but
we
definitely
want
to
support
that.
So
I
think
we
should
get
some
more
time
to
try
to
feature
and
acetal
articles
with
our
products.
I
think.
A
A
A
M
A
J
N
M
N
M
A
N
F
Working
on
refactoring
the
entry
e
to
e
framework
to
make
it
easier
to
pull
out
so
that
you
can
run
it
out
of
tree
and
David
is
also
currently
working
on
pulling
the
out
of
tree
stuff
to
run
or
sorry.
The
entry
e
to
e
to
run
out
of
tree,
but
he's
not
actually
refactoring.
Anything
he's
just
pulling
everything.
Okay,.
N
F
A
Okay,
next
up
is
automated
end-to-end
testing
for
CSI
side
car
containers.
Currently,
this
is
a
manual
process.
It
should
be
automatic
so
that
we
are
less
likely
to
have
regressions
when
you
versions
to
the
side,
car
containers
are
cut,
glad
to
see
Patrick
proposed
this
and
lead
it
if
anyone's
interested
in
helping
with
it.
Please
reach
out
to
Patrick.
Next
up
are
the
set
of
tasks
that
we
have
for
moving
CSI
21.0
into
GA
number
one
is
moving
the
spec
to
1.0
I've
gotten.
A
The
ball
started
on
this
already
and
so
far
it
looks
like
that
is
on
track.
Next
up
is
moving
the
CSI
persistent
volume
source
and
volume
attachment
API
objects
to
the
one.
This
is
these:
are
the
core
objects
in
kubernetes
for
CSI
they
are
currently
in
v1
beta-1
and
we
need
to
move
them
to
a
v1
API.
Is
anyone
interested
in
working
on
this?
Oh.
A
Alright,
cool
I
can
help
with
that
as
well.
Moving
the
object
to
GA
should
be
fairly
straightforward.
This
one
cubelet
device
registration
mechanism
to
GA
is
probably
going
to
require
more
work.
It's
about
actually
thinking
about.
What
are
the
additional
things
that
we
need
to
add
here
in
general.
This
feature
tends
to
be
led
by
somebody
on
the
device
plug
inside,
but
we
need
someone
from
our
side
to
help
guide
that
and
ensure
that
we
have
anything
that
we
need
from
our
end.
A
A
E
A
E
A
A
F
A
A
A
I,
do
we
we
should
have
it
nailed
in
one
place
before
we
go
to
GA,
but
I,
don't
think
it's
a
blocker
for
GA
all
right
next
up
is
moving
the
CSI
driver
and
CSI
note
objects
which
were
introduced
last
quarter
from
alpha
to
beta
again,
not
a
blocker
for
GA,
but
we
should
keep
the
ball
moving
there.
I
would
mark
this
as
a
p2
as
well.
A
H
A
Duplicate
that
and
I
think
we
gave
it
a
p2
above
so
we'll
be
consistent
here
and
leave
it
assigned
to
you
glide,
and
you
can
go
ahead
and
delete
one
of
those
and
just
oh
well,
and
then
the
next
item
is
PBC
namespace
transfer.
This
is
to
allow
PVCs
to
be
transferred
between
namespaces
in
some
sane
way.
It's
a
design
that
John
and
Erin
and
folks
started
proposing
as
a
result
of
the
discussions
that
we
had
around
volume
cloning.
A
E
So
we
we
broke
cloning
down
into
its
functional
pieces,
and
this
is
one
of
the
pieces
of
the
felony
right.
I
think
infusing
some
other
tasks
on
here,
because
it
was
a
aggregate
of
a
couple
of
things
now
that
said,
we
have
a
priority
3,
but
this
may
be
a
good
blocker,
removing
the
snapshot
thing
from
alpha
to
beta,
because
this
this
was
driving
some
of
the
discussion
around
the
API
from
Hampton,
so
we
want
to
it.
A
The
biggest
dependency
was
around
the
data
source
field
right
and
I
think
this
particular
task
isn't
actually
doesn't
really
care
about
the
data
source
right.
So
this
was
actually
independent
of
all
of
that
data
source
field
was
more
for
the
actual
cloning
process
that
we
were
talking
about,
which
way
I
would
haven't
signed
up
to
do
this
quarter.
H
A
M
A
A
K
A
A
Alright
sold
so
looks
like
we
have
an
established
plan
for
q4
and
again
it's
gonna
be
a
short
quarter.
So
if
you
have
any
tasks
that
are
assigned
to
you,
I
would
recommend
doing
a
taking
a
look
at
the
priorities
to
help
gauge.
What's
most
important,
peasy
rows
are
going
to
be
blockers
for
launch
P
ones
are
things
that
we
really
really
want
to
get
in
P
twos
are
nice
to
have
and
P
three
Zzyzx.
We
have
time
that'll
help
you
prioritize
what
to
focus
on
and
just
be
aware
of
what
the
deadlines
are.