►
From YouTube: Kubernetes SIG Storage 20180621
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 21 June 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.jao3ko4fvugu
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
N/A
A
A
Quarter
for
the
1.12
release
and
our
planning,
spreadsheet
and
I
sent
a
message
to
folks
to
go
ahead
and
start
adding
items
there
and
I
pre-populated
with
some
of
the
items
that
I
know
about.
So
we're
gonna
go
ahead
and
take
a
look
at
that.
We've
got
a
number
of
items
under
design
reviews
today,
I'm,
not
sure.
If
we're
gonna
have
time
to
get
to
that.
If
we
don't,
we
can
either
punt
them
to
the
next
meeting
or
you
can
set
up
one-off
meetings
to
discuss
them
with
a
sake.
A
A
Something
else
I
was
thinking
about
was
support
for
Windows
in
general.
We
kind
of
not
really
thought
about
that,
and
we
haven't
had
too
many
folks
from
Windows
for
Microsoft
attend
this
SIG,
but
before
we
take
block
volumes
to
beta,
it
might
be
worth
thinking
about
what
blog
on
Windows
looks
like
I
actually
have
no
idea.
A
Don't
know
I
was
thinking
just
Windows,
10
or
Windows
whatever.
What
does
a
block
device?
Look
like
on
that,
because
apparently
kubernetes
now
works
on
Windows
I
have
no
idea
what
that
means,
but
it
might
be
something
that
we
should
probably
look
into.
Is
there
anyone
from
Microsoft
or
anybody
interested
in
Windows
on
this
SIG
I.
C
C
D
A
A
C
There's
been
some
people
already
that
have
been
working
on
this,
so
I
think
they
can
continue.
I,
think
it
sums
if
you
just
copy
each
other
area,
I'm
sure,
but
the
main
thing
I
think
the
main
criteria
here
is
in
order
for
this
to
go
to
beta.
We
really
need
an
entry
plugin
to
implement
it
and
you
need
tests
for
it.
So
I
think
that
is
gonna
be
a
blocker
for
beta
okay,.
A
C
C
A
B
A
All
right
cool
next
up
is
topology
support
for
kubernetes
si
si
so
si
si
makes
implementing
new
features
in
kubernetes
interesting
because
they
first
need
to
be
implemented
in
the
si
si
spec.
Then
they
need
to
be
implemented
in
kubernetes.
Then
the
sidecar
containers
need
to
be
updated
to
support
them,
and
then
the
drivers
need
to
be
updated
to
support
the
feature.
So
the
core
topology
support
logic
went
into
kubernetes
last
quarter
and
the
CSI
spec
was
updated
last
quarter
to
support
topology.
A
E
F
G
A
A
When
CSI
goes
ga,
it
will
go
G
a
so
everything,
pre
1.0
is
going
to
be
considered
alpha.
It's
a
weird
designation,
but
it's
kind
of
looking
at
right
now.
Next
up
are
the
driver,
related
changes,
the
AWS,
EBS
CSI
driver
exists,
I,
think
yeah,
or
somebody
was
expecting
to
pick
that
up.
Is
that
still
the
case
for
this
quarter?
Yeah.
A
B
A
A
All
right
think
next
up
or
the
GCPD
CSI
driver,
so
we
already
have
a
CSI
driver
currently
is
checked
into
cornetti
SIG's
and
for
this
quarter
we
want
to
continue
to
add,
extend
it
add.
Support
for
topology
david
has
agreed
to
work
on
that
and
I
can
help
review
actually
Michelle.
Would
you
be
interested
in
reviewing
the
topology
sure
or.
A
A
E
A
A
But
it's
probably
worth
having
an
item
to
figure
out
what
we
want
to
do
with
them.
Next
so
I
know,
we've
been
talking
about
I
think
at
the
last
face
to
face
building
out
an
NFS
common
library,
a
nice
cozy,
common
library
and
potentially
a
fiber
channel
common
library,
our
folks
interested
in
picking
up
that
work.
This
quarter
so.
D
C
H
C
C
I
think
also
like
yeah.
Definitely
we
don't
have
to
start
from
scratch
and
I
think
it
would
be
good.
This
has
I
think
it
would
be
good
to
also
clean
up
the
intrigue
kubernetes
mount
code
to
also
kind
of
refactor
that
library
that
way,
we
don't
have
two
copies
of
the
same
library
like
kubernetes,
could
actually
pull
from
that
outside
mount
library.
Oh
yeah.
F
Yeah
I
was
gonna,
swear,
I
was
gonna,
say,
is
a
the
thing
I
don't
know
is
who
who
will
be
consuming
it
and
I
would
need
to
coordinate
with
if
I
was
gonna
write
one
of
these
common
libraries,
so
obviously
we
would
want
kubernetes
to
be
one
of
the
consumers,
but
any
drivers
that
would
need
to
pull
from
it.
We
would
want.
F
Yeah
I
mean
so
there's
some
obvious
ones,
but
that
I
was
wondering
you
know.
Are
there
any
other
implementations
of
NFS
drivers
me
I
know
the
net
up
one
does
we
have?
You
know
the
same
thing
with
I
scuzzy,
so
we
want
to
make
sure
that
to
get
all
the
interested
parties
together,
let's
have
a
list
of
interested
parties.
So
once
we
have
something
that
can
pass
it
around
and
say
hey
what
do
you
guys?
Think
of
this
and.
C
C
C
A
A
I
C
A
C
F
A
A
B
B
A
J
F
C
F
A
F
A
So
then,
it
probably
makes
sense
to
leave
it
where
it
is
today,
which
is
under
a
treatise.
Repo
I
think
there's
plans
to
split
out.
Currently
it's
under
kubernetes
CSI,
slash
drivers
and
there's
a
bunch
of
drivers
underneath
there
and
there's
plans
to
rip
that
repo
up
and
in
two
separate
repos
for
each
individual
driver,
but
it
will
all
be
under
kubernetes,
so
so
that
makes
sense.
F
H
A
Free
to
swap
it
if
you
feel
the
need
awesome,
anyone
interested
in
doing
the
same
for
the
fiber
channel
common
library.
B
K
F
Just
like
to
point
out
that
testing
all
of
these
libraries
is
gonna,
be
a
bit
of
a
challenge
like
to
prevent
regressions,
I'm,
not
sure
what
the
plan
is
to
do,
QA
on
the
libraries
themselves,
other
than
just
to
run
kubernetes
using
the
library
and
see
if
it
breaks
it's,
probably
not
the
best
way
to
QA
them.
No.
C
F
B
E
A
A
A
C
A
E
E
I'll
bring
that
up
back
to
client
to
see
you
know
what
we
can
do
there.
Okay,.
E
B
B
C
A
I
A
A
Next
up
is
the
entry
volume
plugins
that
need
to
be
updated
to
support
topology,
so,
like
I
mentioned,
topology
core
framework
went
in
last
quarter,
currently
both
AWS
and
GC
and,
as
I
understand,
Asher,
basically
have
annotations
as
hacks
to
get
around
topology.
Now
that
we
have
a
framework,
we
need
to
update
these
plugins
to
to
support
this
deep
did
I.
Add
your
name
incorrectly
to
some
of
these,
but.
D
A
A
D
A
A
I
A
J
A
A
G
D
C
A
A
All
right:
where
are
we
so
we
just
went
through
the
entry
plugins
next
up
is
local
volume,
dynamic,
provisioning,
I
would
call
that
a
Pichu
and
it
looks
like
we
already
have
an
assignee
for
it
and
it's
mostly
out
of
tea
tree.
So
that's
also
good
moving
on
lines
resizing
to
beta
homuth.
Is
that
something
we
want
to
do
now
or
do
you
want
to
give
it
a
quarter
to
bake.
A
Sense
I'll
go
ahead
and
remove
that
next
up
is
implement
out
of
trees,
volume,
snapshot
or
and
controller
Shing
and
Jing
will
be
working
on
this.
We
have
updates
on
this
I
think
it's
scheduled
than
later.
I'm,
not
sure
we're
gonna
get
to
it,
but
long
story
short.
We
went
to
sig
storage
last
week.
Sorry.
E
A
The
proposal
is
that
we're
going
to
only
add
this
functionality
to
CSI
and
can
do
that
pretty
nicely
with
a
sidecar
container
concept
that
we
have
today
and
Shing
and
Jing
will
present
on
that
later,
and
so
the
item
here
is
to
go
ahead
and
implement
that
I'm
gonna
call
that
a
p1
next
up
is
dynamic,
max
volume
per
node
count
to
beta,
among
implemented
this,
the
last
quarter
a
month.
Do
you
want
to
push
this
to
beta
this
quarter
or
weigh
a
quarter?
Yeah.
I
A
A
E
A
E
A
E
A
Next
up
is
inline
volume
support
for
CSI.
This
is
something
that
we
want
to
do
to
make
it
easier
to
use
with
ephemeral
volumes,
but
we
have
to
do
it
thoughtfully,
because
there's
a
reason
we
tried
to
avoid
having
inline
volumes
for
CSI.
It
ends
up
with
a
lot
of
pain,
for
example,
supporting
topology
and
I.
Think
Michelle.
We
were
talking
about
some
other
painful
points
about
you,
inlining
I
think.
C
H
A
All
right
next
up
is
skipping
external
attach
detach.
This
is
very
closely
related
to
the
next
item,
which
is
cluster
plug-in
registration
mechanism.
Vlad
looks
like
you've
signed
up
for
both,
so
that
looks
good
to
me.
I
think
yan
you've
been
very
interested
in
this
topic
as
well.
Would
you
be
interested
in
north?
You
sure,
okay,
thank
you
and
we'll
go
ahead
and
call
that
an
alpha
feature
as
well.
I
C
E
A
A
A
If
you
try
to
provision
like
100
volumes
at
once,
resulting
in
throttling
from
the
API
server,
which
results
in
crippling
the
external
provisioner
altogether,
there's
other
issues
like
the
process
of
retries
and
whether
there's
delete
operations
that
happen
in
between
or
not,
and
what
the
back
off
logic
looks
like.
The
external
provisioner
currently
has
a
dependency
on
the
the
CSI
external
provisioner
has
a
dependency
on
the
external
provisioner
and
the
external
storage
repo.
A
B
A
A
In
order
to
get
the
stamp
of
approval
on
a
kubernetes
cluster
that
this
is
an
approved
implementation
of
kubernetes,
we
have
a
set
of
tests
that
you
must
pass.
We
have
a
very
minimal
set
of
tests
currently
for
some
of
the
ephemeral
volumes.
We
need
to
establish
what
the
the
tests
are
for
the
rest
of
the
volume
framework.
Michelle
has
already
got
some
work
started
on
on
this
and
then,
similarly
for
CSI,
what
does
it
mean
to
be
a
conforming
CSI
plugin?
A
Dynamic
max
capacity
per
plugin
per
node,
so
this
is
an
item
that
Michelle
brought
up.
It's
related
to
the
max
attachable
volumes
per
node
limit
that
we
have.
It
turns
out,
at
least
for
a
GC
persistent
disks
that
there's
not
only
a
maximum
number
of
disks
that
you
could
attach
to
a
node,
but
that
limit
is
also
affected
by
the
capacity
of
those
attached
disks
there's
a
maximum
capacity,
so
you
could
potentially
have
fewer
than
the
max
attached
count
and
have
very
large
disks
and
hit
that
limit.
A
We
can
do
this
pretty
easily
with
pv
PVCs,
because
the
capacity
is
available
there
for
inline
volumes.
We
won't
have
the
capacity
available,
so
whoever
works
on
this
needs
to
decide
what
to
do
for
that.
We
can
decide
that
we're
not
going
to
do
anything
if
you
do
inline
volumes,
but
anybody
interested
in
helping
out
with
that
issue.
Yeah.
G
G
A
A
C
Sure
no,
this
is
this
is
for
dynamic
provisioning.
If
you
want
to
report
capacity.
J
C
A
A
G
G
A
C
C
A
All
right,
cool
next
up
is
finalizing.
The
migration
plan
for
entry
plugins
to
CSI,
David
and
yon
have
been
working
on
this
last
quarter.
The
plan
this
quarter
is
to
come
up
with
a
design
that
we
all
agree
on
and
then
a
subsequent
quarter
try
to
start
implementing
it
or
start
implementing
it.
This
quarter
it's
kind
of
up
to
how
quickly
it
gets
approved,
and
we
already
have
a
signees
there,
so
we're
good
next
up
is
a
refactor
that
we
were
considering
for
a
long
time.
A
If
we
have
some
way
to
checkpoint
the
entire
in
memory
state
of
the
cubelet
volume
manager,
then
we
can
eliminate
this
volume
reconstruction
code,
ideally
because
the
state
for
before
and
after
a
crash
would
be
persisted
if
anyone's
interested
in
this
raise
your
hand.
Otherwise
we'll
leave
an
unassigned
sorta.
A
E
A
F
I've
been
trying
to
figure
out
how
to
what
is
what
is
the
best
way
to,
because
there's
there's
a
lot
of
things
we
could
do
here,
but
but
the
basic
problem
at
this
fixing
this
bug
is
that
you
need
to
reconstruct
the
sub
paths
after
cubelet
crash
and
sub
has
their
Linux
specific
concept
that
there
doesn't
seem
to
be
any
higher
level
concept.
And
so
we
need,
like
a
whole
new
reconciler
loop,
to
go.
Look
for
orphaned
sub
paths,
which
is
a
lot
of
new
code.
That's
kind
of
gross
yeah.
C
C
D
E
C
C
C
F
A
A
A
A
B
A
A
B
F
A
E
E
A
C
A
A
A
Kubernetes
conformance
Michelle's
already
agreed
to
help
drive
that
and
then
pluggable
end-to-end
test
framework.
So
if
you
look
at
the
end-to-end
test
that
we
have
in
storage
today,
they
basically
are
rewritten
for
every
single
volume
plug-in
and
that's
pretty
inconvenient,
considering
that
most
of
them
kind
of
do
the
same
exact
set
of
things.
So
if
we
could
come
up
with
a
framework
that
will
allow
you
to
write
the
test
once
and
then
plug
in
different
types
of
either
entry
or
CSI
plugins,
that
would
be
extremely
valuable.
This.
A
Yes,
so
Patrick
ping
me
right
before
this
meeting
as
being
interested
in
helping
drive.
This
I'm
writing
down
design
as
the
goal
for
this
quarter.
But
you
know,
depending
on
how
things
move,
we
may
get
some
sort
of
implementation
here,
and
that
is
all
that
I
have
for
the
1.12
planning.
Is
there
anything
else
anybody
wants
to
add
to
this
list?
We
have
a
lot
of
items
you.
A
And
if
you
have
an
item
assigned
to
you
and
the
feature
repo
bug
is
read,
please
make
sure
you
open
a
bug
before
the
future
repo
issue
deadline,
and
that
is
all
that
I
have
for
today
for
the
design
reviews,
let's
punt
them
to
next
week.
If
they
are
super
important
set
up,
one-off
meetings,
I
know
miss
Jing
I
think
you
wanted
to
set
up
a
meeting
this
coming.
Monday
or
Wednesday
at
nine
am
hi.