►
From YouTube: Kubernetes SIG Storage 20180816
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 16 August 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.ow4wfva6f90r
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:24:31 From Patrick Lang : background question - does CSI reaching GA in K8s require the CSI spec 1.0 to be finalized?
09:25:51 From Patrick Lang : thanks for clarifying
10:07:12 From Patrick Lang : thanks everyone
10:07:16 From Patrick Lang : g'day
A
A
If
there's
anything
that
you
want
to
discuss
today,
please
feel
free
to
add
it
to
the
agenda
document.
The
link
is
in
the
invite,
and
so
first
of
all,
we're
gonna
go
over
the
planning
spreadsheet,
which
has
all
the
items
that
we're
working
on
for
this
quarter
and
get
a
status
update
on
those.
Then
we're
going
to
discuss
any
PRS
that
need
attention
bugs
that
need
attention
in
any
design
reviews.
So,
let's
jump
straight
into
it.
First
up
is
spread
the
spreadsheet.
Let's
get
a
status
update
for
these
items.
A
B
Yeah
sure
those
appear
on
actual
controllers
new
review,
it
may
be
addressing
the
comments
snapshot
API
up
here
got
merged.
We
made
additional
small
changes
to
the
snapshot
api's
after
that,
so
those
changes
are
still
being
reviewed
and
that
there
are
some
discussions
regarding
data
source
in
PB
million
list
and
teams
suggested
to
use
reading
escape
feature
to
you
check.
A
To
give
a
little
bit
of
context
on
that,
so
initially
we
were
talking
about.
How
do
we
detect
the
the
case
where,
when
you
have
a
volume
provision
from
a
snapshot
but
you're
using
an
old
external
provisioner
that
doesn't
understand
data
source
from
PVC,
and
it
completely
ignores
that
and
and
provisions
of
volume
without
the
data
there?
How
do
we
detect
that
and
alert
the
user?
To
that
case,
and
the
second
use
case
was
you
know
if
I
want
to
decouple
the
component?
That's
going
to
be
doing
the
provisioning
of
the
volume
from
the
component.
A
That's
gonna
populate
that
volume.
How
do
I
do
that
and
the
initial
proposal
that
we
came
up
with
was,
let's
add
data
source
not
just
to
the
PVC,
where
you
say:
I
want
a
new
volume
that
is
going
to
be
populated
with
this
data
source,
but
also
on
the
PV
to
indicate
that
the
provisioner
actually
did
it,
and
if
the
provisioner
didn't
do
it,
some
other
component
could
step
in
and
actually
do
it
and
update
that
field
on
the
PV.
We
talked
to
a
few
folks
about
this
and
a
few
folks
in
this
thing.
A
It's
not
just
internal
kubernetes
code,
and
so
what
they
did
is
have
a
mechanism
by
which
they
could
have
a
list
of
these
external
readiness
checks
and
the
pod
is
not
going
to
move
into
a
ready
state
until
all
of
those
checks
have
been
achieved.
So
in
this
case
you
can
imagine
the
PVC
having
a
set
of
readiness
checks
where
one
of
the
readiness
checks
is
the
data
source
that
must
populate
this
PB
see.
If
we
have
something
like
that,
then
we
don't
need
to
modify
the
PV
object.
A
When
a
PV
C
is
created,
we
could
have
something
like
an
admission
controller
that
looks
at
the
data
source
and
populates
the
appropriate
readiness
check
fields
and
then
the
the
PV
PV
C
won't
go
into
bound
state
until
it
is
the
bound
phase.
Until
that
readiness
check
has
been
satisfied
by
some
some
component,
whether
it
be
the
provision
or
some
external
pop.
You
later
I.
A
So
that's
the
thing
like.
Ideally,
we
want
to
be
able
to
allow
some
sort
of
binding
where
the
populate
er
itself
could
actually
consume
this
volume
so
that
tails
of
that
need
to
be
worked
out
and
how
we're
going
to
achieve
that,
whether
it's
not
preventing
not
getting
it
to
bound
introducing
a
new
state
introducing
a
new
field
to
say
it's
ready
to
use
or
not.
We
need
to
think
through
that.
A
A
It's
going
to
remain
in
alpha
this
quarter
and
all
we're
gonna
do
is
try
and
fix
bugs
for
it.
Vlad
has
identified
a
handful
of
bugs
and
he's
looking
for
folks
on
his
team
to
help
with
that.
If
you're
interested
in
this
area,
please
reach
out
to
Vlad,
and
we
can
help
you
can
help
us
fix
bugs
in
this
area.
A
Sounds
good
next
up
the
CSI
drivers
we're
gonna
skip
over
these
we're
just
gonna
get
a
status
update
at
the
end
of
the
quarter,
they're
not
going
to
be
part
of
the
core
kubernetes,
so
we'll
just
get
in
that
status.
Update
at
the
end
of
the
quarter.
Csi
entry,
cluster,
plug-in
registration
mechanism,
I
have
a.
A
This
ended
up
being
a
entry
component,
we
went
and
talked
to
say
Gorka
texture
and
their
line
is
that
there's
no
more
entry
core
components.
You
have
a
very,
very,
very,
very
high
bar
if
you
want
to
add
anything
entry,
even
the
things
that
were
entry.
If
we
were
to
do
them
again,
things
like
pods
and
nodes,
we
would
make
them
CRD,
so
everything
is
becoming
a
CRD
and
this
should
be
added
as
a
CR
D.
So
we're
pursuing
that
and,
like
I,
said
the
proposals
out.
E
A
A
This
yes
I
mount
library.
This
is
a
lot
of
core
util
functions
that
are
used
in
the
core
of
kubernetes
that
can
be
useful
to
see
aside.
Drivers
Travis
I
believe
has
been
working
on
this
last
status.
Update
was
that
we
agreed
on
an
approach
and
we're
gonna
break
package,
util
mount
into
two
pieces,
and
once
that
was
complete,
then
there
would
be
a
second
step
to
move
the
generic
implementation
out
of
kubernetes.
D
F
A
Sounds
good
thanks.
Vlad
next
up
is
the
corona
use
device
plugin
integration
beta.
This
is
a
pretty
large
project.
We've
been
working
with
the
folks
who,
on
the
device,
plug-in
team
who
implemented
the
cubelet
device
plug
in
registration
mechanism,
the
current
status
is
they
came
up
with
a
list
of
items
that
need
to
be
done
in
order
to
move
to
beta.
As
far
as
code
on
the
core
is
concerned,
they
have
some
lifecycle
hooks
changes
that
they
want
to
make,
in
particular
how
the
the
volume
plug-in
is
unregistered.
A
So
the
if
the
UNIX
domain
socket
is
deleted.
We
want
to
use
that
as
a
signal
that
the
plug-in
should
be
unregistered
from
the
cubelet
and
that
code
is
being
implemented
at
the
moment
and
is
going
to
be
reviewed
by
Sergey
and
Vlad.
In
addition
to
that,
we
want
to
add
end-to-end
tests
for
CSI
to
exercise
this
code.
That's
going
to
be
on
our
team
to
do,
and
then
we're
also
looking
into
how
to
integrate
with
this
more
cleanly.
So
today
there
is
a
sidecar
container
called
the
driver,
registrar
and
it's
responsibility
is
talk.
A
Basically,
updating
the
note
object
with
any
labels
that
are
required
by
the
driver,
including
things
like
the
node
name
and
potentially
topology
keys,
and
things
like
that.
But
with
this
change
that
logic
moves
into
the
cubelet
and
the
cubelet
updates
the
node
object,
which
is
what
we
want
for
security
reasons.
But
there
is
a
registration
API,
a
proto
G
RPC,
proto
--that
was
introduced
for
cubelet
registration.
That
is
not
part
of
the
CSI
spec,
and
so,
if
you
have
a
CSI
compatible
driver
that
is
agnostic
to
kubernetes,
it
has
not
implemented.
A
G
RPC
service
for
registration,
so
we
had
to
implement
that
logic
inside
the
driver
registrar.
So
the
driver
registrar
now
also
exposes
a
service
which
is
only
responsible
for
registering
the
driver
with
cubelet.
The
challenge
now
is
that
the
driver
is
exposing
its
service
on
a
UNIX
domain
socket
and
the
driver
registrar
is
exposing
another
service
on
a
UNIX
domain
socket
and
the
way
that
it
works
is
that
both
of
them
expose
their
UNIX
domain.
Sockets
on
to
the
host
the
UNIX
domain,
socket
drive
dropped
by
the
driver.
A
Registrar
is
the
one
used
for
registration
and
part
of
the
registration.
The
driver
registrar
actually
returns.
What
the
path
to
the
driver
drivers,
UNIX
domain
socket
is
that
whole
thing
works,
but
even
as
I
described
it
it's
fairly
complicated
and
if
you're
a
new
driver,
it's
pretty
easy
to
get
lost.
So
one
of
the
things
that
we
were
considering
this
quarter
was
trying
to
simplify
that
and
what
we
could
do.
A
You
know
one
more
point
of
failure
and
potentially
more
latency,
so
we
may
not
want
to
do
that
and
we
may
end
up
just
adding
a
lot
of
documentation
around
how
to
set
this
up,
because
essentially
it's
a
one-time
pain
for
the
driver
author
once
they
have
their
Yama
file
set
up
correctly.
It's
not
exposed
to
the
end
user.
It's
you
know
a
one-time
setup
pain,
so
that
is
continuing
to
be
investigated.
D
A
A
So
we
need
to
make
sure
we
do
that
next
up
is
pluggable
and
to
end
test
framework.
Patrick
was
working
on
this
Patrick.
Are
you
on
the
call
of
any
chance
it
doesn't
look
like
he
is
so
we're
gonna
skip
over
the
status
update
on
that
local
PV
health
monitoring,
Nick,
Ren
and
Michelle
were
working
on
this
I
know.
Nick
is
usually
not
available
at
this
time.
Michelle.
Do
you
happen
to
have
an
update
on
this
yeah.
A
G
G
A
A
That's
like
two
hours
from
now
so
that'd
be
e.
That
would
be
useful.
Okay,
I
think
they've
got
like
a
tracking
board
now
that
you
can
get
on
that'll
help
with
that.
Okay,
next
up
is
the
CSI
external
provisioner
scalability
issues,
so
Matt
Wong's
been
working
on
this
extensively.
He
had
a
bunch
of
PRS
I,
think
most
of
them
are
merged.
Now
any
update
on
this
Fred.
A
A
And
we
have
a
question
in
the
group
chat
background
question
the
CSI
reaching
GaN
kubernetes
require
the
CSI
spec
1.0
to
be
finalized.
That's
my
goal
is
that
we
also
push
CSI
expect
to
1.0
at
the
same
time,
for
what
I
don't
want
to
do
is
couple
too
many
things.
Well,
as
we
do
the
push
to
GA
for
for
kubernetes,
CSI
I
think
at
least
the
spec
definitely
needs
to
go
to
1.0,
but
things
like
block
volumes
support,
don't
need
to
go
to
GA.
A
At
the
same
time,
what
I
plan
to
do
is
basically
D
couple.
The
core
CSI
API
is
that
we
have
and
the
additional
functionality
we're
adding
on
top
of
it,
so
that
we
can
move
these
components
independently.
We
can
GA
be
the
the
core
CSI
code
and
ap
is
and
then
the
features
that
we're
adding
on
top
of
that,
like
block
volume,
can
move
at
their
own
independent
pace.
A
G
A
A
G
A
G
A
G
I
G
J
F
A
A
D
D
It
looks
like
I'm
hoping
that
we
we
have
closed,
Matt
and
Tim
gives
us
his
blessing
it
in
later,
but
it
looks
like
we're
going
to
go
into
the
original
direction.
You
just
API
types
to
support
direct
embedding
of
the
volume
inside
expect
inside
a
pod
spent
for
CSI.
So
that's
what
we're
hoping
for
in
that
also,
the
direction
I've
already
started
a
PR.
Unless
you
know
somebody
comes
back
and
say
no,
no,
the
PR
is
already
moving
in
that
direction,
starting
to
put
in
in
place
the
types
to
support.
This
awesome.
A
Cool
thanks
blood
sure
next
up
is
passing
workload.
Information
on
to
the
node
publish
call.
This
is
something
that
Yuans
been
working
on.
There
was
a
proposal
out
and
it
was
dependent
on
the
CSI
driver
registrar
to
pass
in
a
bit
that
says
that
this
is
required
beyond
has
updated.
You
are
happy
for
that
anything
else.
You
want
to
add
you
on
no
okay.
A
K
A
K
Proposal
is
be
similar
to
this
thing:
I'll
open,
but
hopefully
tomorrow
or
Monday.
Then
the
one
question
is
that:
do
we
want
to
do
something
like
this
in
CSI
as
well,
because
we
did
this
for
for
the
attach
count.
We
might
have
to
make
a
modification
in
CSS,
but
we
can
target
that
in
the
next
release
for
CSS
yeah.
A
L
A
K
A
M
A
A
A
A
A
The
last
outstanding
item
was
inline
volume
mapping,
which
is
current
that
that
design
is
currently
outstanding.
I,
don't
know
if
David's
on
the
line,
it
doesn't
look
like
he
is,
but
I
don't
believe,
there's
been
any
further
progress.
There
I
was
talking
to
somebody
from
AWS
and
they're
interested
in
helping
with
this,
so
I'm
going
to
connect
them
with
David,
and
hopefully
they
can
help
out
with
especially
the
implementation
skip
over
the
drivers.
Next
up
is
containerized
cubelet
issues.
N
A
A
O
A
H
J
A
H
A
So
as
far
as
finding
a
home
for
this
I
think
kubernetes
CSI
makes
sense.
Let
me
know
when
you
guys
want
to
open
that
I
no
longer
have
permissions
to
arbitrarily
create
new
or
repos
and
delete
them.
It's
CN,
CF
and
kubernetes
Advan
stepped
in
and
enabled
all
their
automation
and
stuff.
So
we
have
to
go
and
create
an
issue
to
create
new
repos.
So
let
me
know
when
you
want
to
do
that,
preferably
give
it
like
a
few
days
head
start
and
because
I
think
the
turnaround
time
is
a
few
days.
A
A
So
good
question
I,
think
that
depends
on
how
much
of
the
functionality
ends
up
getting
moved
into
these
common
libraries.
If
we
discover
that
the
majority
of
the
functionality
is
moved
into
the
libraries
and
the
drivers
that
we
have
are
essentially
not
very
useful
standalone,
then
we
can
eliminate
the
drivers
and
leave
it
for
two
third
parties
to
implement
them
using
the
libraries
that
we
have.
L
A
A
It
looks
like
Ben's
not
on
the
call
we'll
follow
up
with
that.
Next
time,
host
Pat
volume,
reconstruction,
I,
don't
see,
I,
don't
think
I've
seen
any
progress
on
this
either
and
I
think
the
last
status
was
that,
ideally,
we
don't
want
this.
We
just
want
to
go
with
a
new
checkpointing
code,
which
also
has
not
moved
next
up
is
flex
volume
resizing
support.
Aniket.
Are
you
in
line?
Yes,.
N
Yes,
I
am
so
I
recently
the
pr
about
admission
controller
for
volume,
expansion
that
just
went
in
a
few
days
ago
that
had
inadvertently
the
excluded
flex
volumes
from
the
controller
from
expansion
all
together,
sighs
to
rework
my
previous
and
rework
a
little
bit
of
my
code
to
make
sure
that,
on
the
controller,
like
volume
still
allows
the
expansion
request
to
go
in
and
finally
percolate
down
to
the
actual
cubelet
level.
So
I
have
done
that
and
right
now
the
writing
the
ete
test
so
to
do
disappear.
A
A
A
A
Sounds
good,
thank
you
and
then
finally
replace
volume
reconstruction
with
the
checkpoint
that
we
already
talked
about.
You
move
to
the
bottom.
Okay,
so
we're
done
with
the
status
review.
We've
got
15
minutes
left
next
up
is
PRS
that
need
attention
so
promoting
mount
propagation
to
GA,
which
we
just
talked
about.
Pr,
is
available
and
needs
review.
A
E
A
For
those
of
you
who
are
not
familiar
with
the
feature
enables
mounts
inside
a
pod,
instead
of
being
a
separate
namespace
to
share
a
namespace
with
the
host.
The
benefit
of
that
is
that
any
amounts
that
happen
inside
the
container
are
then
propagated
out
to
the
host
machine
so
that
we
can
containerize
our
mounting
libraries,
which
is
critical
for
writing.
Csi
drivers,
so
we're
trying
to
get
this
promoted
to
GA
so
that
CSI
can
depend
on
it.
A
P
This
is
training.
Basically,
we
are.
We
find
the
need
to
support
metrics
on
Plex
volumes
and
currently
flex
volumes
doesn't
support
metrics.
So
by
introducing
a
flag
capability
flag,
see
if
matrix,
if
the
driver
supports
metrics,
then
we
would
enable
the
FS
chad's
plugin.
So
that's
the
idea
decided
to
I,
don't
know
whether
it
is
going
to
be
a
feature
or
I
mean
basically
enabling
it
it
would
be
a
bug
or,
but
we
definitely.
A
Looks
like
a
feature
because
it's
extending
the
Flex
API
in
general,
the
rule
of
thumb
for
flex,
has
been
we're
not
going
to
continue
to
add
to
it
we're
going
to
maintain
the
API
as
is
and
add,
more
functionality
to
CSI.
The
reason
for
that
is
to
try
to
not
spread
ourselves
too
thin
by
trying
to
maintain
two
different
api's,
and
since
this
is
a
feature
change
it's
something
that
we
would
need
to
declare
at
the
beginning
of
a
quarter
as
a
future
issue
before
we
accept
it.
A
J
A
K
So
so
the
thing
is
like
the
the
matrix
when
we
omit
like
we
might
want
to
say
that
how?
If
because,
if
it's
ephemeral
stories,
then
it
might
need
the
start
of
s,
call
might
not
work
actually
and
you
might
have
to
use
D
or
something
I
just
want
to
have
make
sure
that
the
same
flexibility
that
other
plugins
have
is
able
to
flex.
Maybe
just
a
quick
feedback.
Looking
at
the
change
but
I
think
we
should.
We
should
go
for
it
as
well
yeah.
So.
D
A
This
seems
simple
enough
that
it
might
be
okay
to
accept
this,
but
I
think
it's
more
of
a
principled
stance
of
if
we
accept
this.
Where
are
we
going
to
draw
the
line
if
we
continue
to
add
one
more
feature?
One
more
feature
we
end
up
in
this
loop,
where
we're
going
to
continuously
extend
the
Flex
API,
potentially
introduce
breaking
changes
at
some
point
and
be
on
the
hook
for
fixing
those,
so
I
would
really
really
prefer
to
pause
development
on
flex.
Keep
it
in
its
current
state
fix
bugs
on
it.
P
H
P
P
A
L
A
N
L
M
A
A
L
The
main
things
that
are
are
sort
of
you're
lacking
in
our
release
process
is
getting
making
sure
that
the
windows
tests
are
available
on
test
grid
and
I'm
expecting
to
have
that
going
in
the
next
few
weeks
and
then,
of
course,
making
sure
that
we
get
to
get
to
the
conformance.
There.
I
think
that
some
of
the
non
conformance
tests
still
in
particular,
have
a
lot
of
coverage
that
is
covering
basically
plastics
and
Linux
only
features,
and
so
you
know
we
will
need
to
do
some.
Some
scrubbing
there
on
how
those
are
handled.
A
L
L
L
A
L
L
Yes,
I
am
as
well
as
cig
architecture,
because
this
this
could,
in
this
impacts
multiple
SIG's.
You
know
I,
if
there's
I
mean
basically
what
I'm
looking
for
is
I
want
to
make
sure
that
I've
got.
You
know,
lazy,
consensus
from
from
each
sake
and
that
someone
has,
you
know,
reviewed
and
provided
feedback
on
behalf
of
that.
L
E
L
So
that's
what
I'm,
looking
to
basically
close
up
in
that
email
to
you
know,
give
everybody
a
a
time
period
to
say
you
know
here's
the
final
version.
You
know
you
know.
Are
there
any
last-minute
feedback
objections?
No
okay,
it's
closed
and
there
were
will
execute
on
that
and
then,
when
the
tests
are
passing,
we
declare
GA
thanks.
A
G
I
can
totally
cover
it
in
a
minute,
so
so,
basically
I
discussed
a
little
bit
with
Brian
and
he's
actually
thinking
that
we
don't
want
a
storage,
specific
confor
Profiles
sweet
instead
he's
pushing
to
have
multiple,
multiple
features
built
into
this
conformance
profile.
So
not
just
storage
but
also
include
some
networking
stuff,
and
maybe
some
are
back
and
authentication
things
as
well,
so
I
need
to
work
with
Brian
and
maybe
William
on
on
how
to
drive
a
conformance
profile
suite
that
is
sort
of
crossed.
G
A
G
That's
right
like
focus
on
some
user
functionality
in
terms
of
like
I,
don't
know
packaging
of
like
a
bunch
of
features
together
and
then
so
separately
we
can
still
go.
We
can
still
work
towards
having
like
some
sort
of
volume,
profile
qualification
suite
that
we
can
do
just
for,
like
all
the
volume
plugins
but
I,
think
that's
going
to
be
independent
of
the
conformance
effort.
G
A
C
L
A
J
J
So
at
some
point,
I
think
we
should
kind
of
figure
out
where
we
want
to
consolidate.
If
we
want
to
consolidate,
continue
to
have
all
the
three
different
options
or
you
know
what
so
just
something
that
kind
of
think
about,
and
maybe
in
the
next
couple
of
weeks
set
aside
some
time
to
talk
about
that.
If
people
have
thoughts
on
it,
yeah.
A
I
A
I
N
A
For
this
quarter,
we
the
tasks
that
we
had
were
to
try
to
come
up
with
generic
libraries
for
these
common
drivers
that
we
have,
and
the
reason
for
that
was
that
what
we
realized
is
a
lot
of
the
common
code
for
these
drivers
like
I,
scuzzy
and
NFS,
are
pretty
much
standard,
but
things
like
provisioning
are
going
to
be
custom
for
a
lot
of
different
implementations
depending
on
who
is
consuming
it.
So,
instead
of
trying
to
come
up
with
a
single
driver,
that's
gonna
make
everyone
happy.
A
I
A
A
L
J
Actually,
if
you
want
to
check
so
right
now,
I
have
two
si
si
connectors
repo
that
will
someday
move
somewhere
more
formal
right
now.
I
just
have
the
I
scuzzy
stuff
in
it.
The
idea
would
be
add,
fiber
channel,
add
whatever
other
things
and
then
also
figure
out
how
to
implement
the
windows
side
name.