►
From YouTube: Kubernetes SIG Storage 20190214
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 14 February 2019
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.mkk7l484l0kv
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:27:02 From hemant : https://github.com/kubernetes/enhancements/pull/696
09:50:17 From Dims (k8s-infra) : Travis, we can get reviews from Tim Hockin etc. please let me know!
10:00:04 From Andrew Kim : I’m happy to own “CSI in-tree: Post GA tasks” and “Post-GA in-tree topology” with some guidance :)
10:00:21 From Saad Ali : Awesome.
10:02:43 From Gerry Seidman : I'd like to shout out about Vault (as per meeting notes
A
All
right
today
is
February
14
2019.
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group.
As
a
reminder
in
sitting,
is
recorded
and
published
on
YouTube
today
on
the
agenda.
First
up
we're
going
to
do
a
we're,
gonna
go
over
the
planning,
spreadsheet
and
then
there's
a
couple
of
PRS
that
need
attention
that
need
to
be
discussed.
A
C
C
C
The
first
one
is
the
first
one
is
early
that
not
all
the
volume
types
will
be
able
to
support
user
namespace,
remapping
initially
so,
for
example,
that
in
more
volumes
such
as
NFS
not
be
able
to
support
user
name,
space
remapping,
at
least
at
the
moment
in
so
in
such
case,
to
support
to
have
the
backward
compatibility
so
that
the
workloads
which
used
to
run
earlier
should
also
and
when,
when
when
user
namespace
feature
is
enabled
in
the
cluster.
So
to
have
that
backward
compatibility,
one
option
is
to
switch
switch
to
turn
off
this
user.
C
C
D
C
Container,
if,
if
the
board
has
asked
for
remapped
username
space-
and
it
is
not
possible
to
it-
is
not
possible
to
move
the
UID
or
GID
of
volumes
which
have
been
used
by
the
pod,
for
example,
in
the
NFS
case,
then
containers
will
not
be
able
to
use
those
volumes.
So
it's
not
just
a
first
row
even
in
just
to
access
the
volume.
C
If,
if
the,
if
the
username
Spacely
mapping
has
been
asked
by
the
four
containers,
we'll
have
to
move
the
UID
and
GID
of
the
volume,
so
some
it
is
not
possible
today,
for
some
of
the
volumes
will
have
that
also
like,
for
example,
not
just
remote
volumes
in
case
of
host
Pat
volumes.
It
will
also
not.
It
will
also
make
sense
to
do
not
allow
user
namespace
remapping
for
for
the
port
containers,
the
one
which
is
asking
for
a
host
bath
volume.
B
B
There's
two
issues:
I
see
there
one
we,
the
containers,
could
all
be
running
as
different
user
IDs,
and
also
this
isn't
something
that
we
do
for
without
user
namespaces.
So
I
guess
I,
don't
really
see
how
this
is
different
from
just
you
know.
I
ran
I'm
running
a
pod
that
runs
with
user
ID
3,
and
this
volume
is
filled
with
files
that
are
owned
by
root.
It
sort
of
feels
like
the
the
use
case
that
FS
groups
is
trying
to
solve
so
I
guess
what
I'm
wondering
is.
C
E
B
C
F
C
But
we
want
to
have
the
container
right
to
it,
because
if
the
container
is
running
with
the
remap
username
in
space,
so
the
UID,
which
is
essentially
route
inside
container
username
space,
should
be
able
to
access
its
volume
from
within
the
container,
though
outside
on
the
host.
It's
something
else,
not
the
UID
view.
I
think.
C
C
C
C
C
G
B
G
That's
correct
I'm
asking
this,
because
now
that
we
have
si
si,
we
don't
necessarily
have
information
about
exactly
which
drivers
support,
FS
group
or
not.
So
what
we
did
with
the
CSI
implementation
is
that
we
assumed
any
single
Rider
vol
supports
FS
group
and
any
multi
rider
volume
does
not
support
FS
group.
G
H
F
Because
I
had
questions
so
like
so
this
FS
group,
the
mapping
between
the
host
and
the
container,
is
it.
It
says
the
documents
is
one
on
one
on
one
like
sis
like
we
really
didn't
go
the
into
the
steps
and
yet
so
is
it
like.
So
if
the
art
has
a
face
group
mm,
the
the
current
the
container
runs
has
same
mm
or
like
how
does
that
work?
F
C
I
was
like
in
the
current
proposal
to
support
the
SS
group
a
tree.
It
was
just
opposite
to
what
was
being
said
it
when
what
has
been
suggested
just
now,
if
at
first
opens,
is
present
in
a
in
a
pod
back
then,
and
it
was
then
it
was
not
being
translated
to
a
different
host
ID,
the
other
it
has
been.
It
is
big
enough.
C
I
C
I
understood
how,
after
school,
you
think
a
FS
group
should
be
I.
I
didn't
think
in
this
direction
that
each
container
can
be
running
with
it
afraid
you
are
so,
and
we
get
back
from
this
point
and
the
next
problem
which
I
was
I
wanted
to
discuss,
was
that
was
related
to
how
I
was
proposing
to
reset
the
ownership
at
a
breach
at
the
UID
and
GID
volumes.
C
F
Actually,
so
I
think
the
performance
I'm
just
concerned
it's
his
son
c63
agenda
to
kind
of
like
fix
it,
but
we
have
to
look
trying
to
look
at
it
from
other
angles
and
one
of
the
concern
that
Michelle
raised
for
this
skipping,
the
ownership
was
to
how
it
interacts
with
user
name
spaces
in
particular.
So
I
don't
know.
I
like
this
proposal
is
proposes
that
that
we
record
the
AFS
group
of
the
PVC.
F
It
will
only
work,
obviously
for
PVC
and
the
current
proposal
that
we
have,
but
in
general,
for
if
you
have
to
support
for
all
volume
types
that
it
has
to
be,
it
has
to
be
more
generic
and
should
work
for
Emlyn
volumes
as
well,
so
that
I
guess
guy
only
will
have
to
live
with
this
performance
hit
until
we
have
a
proper
solution
for
matrix.
For
this.
C
Thanks
for
that
yeah,
so
these
were
the
two
points
that
I
wanted
to
discuss.
So
on
the
first
one
related
to
this
posterior
namespace
in
volume,
I
think
I'll
rethink
my
approach
based
on
the
inputs
and,
as
I
said,
I'm
not
sure
I
have
totally
understood
by
he'll.
Listen,
this
recording
and
we'll
come
back
on
this
I.
F
C
Because
of
this
problem,
that
ports
can
be
on
different
nodes
and
they,
if
they
want
to
share
a
volume
using
FS
group,
then
if
the
user
name
space
configuration
is
different
on
different
nodes,
then
they
will
not
be
able
to
use
the
FS
group
in
a
remapped
configuration
because
then
translated
host
ID
will
be
different
on
different
nodes.
If
the
configuration
is
different
so
to
handle
this
I
was
thinking
to
have
a
one-to-one
mapping
for
FS
group
like
and
whatever
FS
group
ID.
B
C
B
A
C
A
A
A
L
I
can
give
you
an
update,
so
a
couple
weeks
bill,
the
cap
got
merged
and
that's
what
we
did
with
that
and
now
I've
been
working,
getting
the
the
new
changes
that
were
introducing
the
cap
and
we're
basing
the
OPR
into
a
new
PR.
So
we
could
not
track
and
track
the
changes.
So
I
should
have
APR
ready
for
review
eminently
awesome.
A
H
H
H
H
To
begin
with,
particular
there's
fuzziness
around
you
know
whether
multi
attach
means
multiple
pods
on
one
node
or
multiple
pods.
On
multiple
nodes,
so
we'll
have
to
cover
that
with
the
CSI
community
next
week,
but
everything
is
is
sort
of
looking
good
there's
a
lot
of
code
reviews
and
I'm
the
bottleneck,
so
I'm
gonna
try
to
get.
J
H
A
A
G
We
were
all
three
of
the
features
were
blocked,
they're
all
using
the
CSI
co
DS
and
we
were
blocked
on
a
way
to
automatically
install
the
CR
DS
into
the
cluster.
By
default
we
went
to
cig
architecture
and
they
agreed
that
we
can
move
our
CR
these
back
to
entry
objects
in
order
to
unlock
us.
So
Shane
is
working
on
that
now
perfect.
M
A
G
Give
an
update
on
her
behalf.
Yeah
we've
had
discussions
with
the
no
team,
along
with
the
G
Weiser
team,
on
this
we're
and
also
the
security
team,
so
yeah
we're
still
trying
to
scope
out
what
solution
solutions
we
want
to
pursue.
There's
quite
a
few
different
options.
We
can
go,
go
choose
from
okay.
A
A
G
A
F
A
D
D
D
G
A
A
Next
up,
we're
gonna
skip
that,
since
it's
already
complete,
then
you
have
non-recursive
volume
ownership.
This
was
something
that
was
brought
up
in
the
design
discussion
earlier.
The
recursive
toning
of
all
the
files
in
a
volume
can
be
very
slow
and
caused
performance
issues.
Almonte
and
Matt
have
been
looking
into
you
into
solutions
a
month.
You
want
to
give
an
update
on
this
yeah.
F
So
we
had
a
kept
but
kept
did
not
March
and
Michelle
had
some
concerned
about
like
how
it
plays
out,
with
with
user
name
spaces
and
in
general
UID.
So
I
guess,
like
I,
think
there's
no
broad
disagreement,
but
it's
just
that
we're
trying
to
find
like.
So
we
will
convert
this
task
to
a
cap
only
design
normally
in
this
quarter.
If
we
can
come
to
a
conclusion
down
the
grade
for
this
quarter,
okay,.
A
M
A
I
A
A
G
A
A
A
I
A
Next
item
is
the
CSI
library
move
the
mount
library
which
is
used
by
coronaries
code
into
an
external
common
repo
so
that
the
core
kubernetes
code
can
use
it,
but
also
CSI
drivers
can
use
it
instead
of
writing
their
own
mount
library
every
time
so
important
work
travis
has
been
working
on
this
last
time.
It's
fabulous.
N
Yes,
right,
I
I
did
finally
get
some
really
in-depth
reviews.
Last
week,
both
from
Michelle
and
address
I
came
from
sick
cloud
provider
and
based
on
that,
we
made
some
changes
to
the
interface
to
kind
of
make
it
be
a
lot
more
clean
than
what
I
was
trying
to
do
so
I'm
reworking
on
that
right
now,
I
hope
to
have
something
new
up
in
a
day
or
two,
but
I
think
my
main
concern
about
this
is
basically
the
size
of
it
because
it
does
end
up
touching
100-plus
files.
N
Some
of
those
are
minor
changes.
You
know
one
little
thing
in
each
file,
but
I
think
it'll
be
really
hard
to
get
the
reviews
and
the
sign-off.
So
if
this
new
version
doesn't
work,
we
might
need
to
take
approach
and
figuring
out
how
to
do
it
in
smaller
chunks,
I'm
hoping
it'll.
This
will
just
go,
but
that's
that's
my
primary
concern.
Okay,.
A
N
A
N
N
It
also
does
block
the
like
the
tree
work,
we're
doing
with
cloud
providers,
because
the
Kota
is
imported
and
we
can't
stage
the
cloud
providers
without
moving
that
out.
But
yeah
but
I
agree
like
we
shouldn't.
We
shouldn't
rush
this
because
it's
pretty
important,
but
if
we
can
get
it
done
for
this
quarter
or
that
would
be
great
agreed.
A
Cool,
thank
you
both
for
the
update.
Yep
next
item
is
provisioning
capacity
reporting
for
generic
topology.
This
was
a
design
for
this
quarter.
There
were
a
number
of
people
that
expressed
interest
in
helping
with
this
Michelle
was
gonna,
add
them
to
her
brainstorming
Jacque.
No
one
had
taken
ownership.
Any
change
on
that.
No.
A
A
A
Next
item
is
moving
NFS
driver
to
a
separate
repo,
so
a
number
of
people
started
a
thread
on
six
storage
on
the
sixth
orange
mailing
list.
Expressing
interest
in
this
and
I
think
we
ended
up
with
four
owners
here.
Matthewson
and
I
think
it's
pronounced
in
the
way.
&Amp;,
pratik
and
I
think
critiques
sent
out
APR
against
the
new
repo.
That
is.
G
A
G
M
A
A
All
right,
so
that's
the
NFS,
CSI
driver,
I,
see
CSI
driver
and
fibre
channel
CSI
driver
good
progress
on
all
three
next
is
moving
the
online
resizing
code
to
beta
the
design
was
moved
to
a
cap.
There
was
no
need
to
file
an
exception,
I
believe
the
cap
had
merged
I
had
a
couple
of
outstanding
comments
on
the
cap,
but
they
were
pretty
minor.
Nothing
blocking
no.
F
F
We
need
P,
probably
I,
don't
I'm,
not
sure
if
going
to
see
cos
will
help
right
now,
but
the
same
time
I'm
going
to
that.
If
that's,
what
will
help
us
unblock
it,
but
we
need
to
decide
if
we
need
to
make
it
configurable
or
not
so
I'm.
Having
some
conversation,
we'll
probably
have
a
follow-up
call
in
six
stories
amongst
storage
members
itself,
and
then
we
can
go
from
there.
A
F
So
does
it
design
out,
it
has
necessary.
Lgt
Amanda
proved
actually,
but
it's
right
now
on
hold
the
so
it
was.
It
was
made
as
an
exception,
but
the
thing
is
that
is
an
outstanding
question
that
how
you'll
handle
offline
only
one
and
expands
in
that
it
that
the
kept
that
in
written
down
it
written
answers
that
the
cap
has
provisional
tag
on
it.
It's
been
approved
by
C
gaps,
I,
don't
know
if
six
always
wants
to
approve
it
like
remove
the
hold
and
it
will
merge.
F
A
J
J
This
is
a
kind
of
driver
that
doesn't
really
have
a
vendor
associated
with
it,
and
so
where
the
these
drivers
should
be
housed.
It's
kind
of
an
open
question
we
talked
a
while
ago
and
it
seemed
like
the
community's
CSI
namespace
might
be
a
good
place
to
house
it.
There's
probably
gonna,
be
other
drivers
in
this
category,
like
the
CSI
and
a
fest
driver
or
something
that's,
that's
not
specific
in
any
way
to
any
vendor.
J
A
C
A
J
J
A
A
A
Before
you
do
that
start
a
thread
on
sig
storage
and
cc
in
bread
and
say:
hey
I'm
I'd
like
to
propose
this
repo.
What
do
you
guys
think
we'll
go
ahead
and
+1
and
thumbs
up
that?
Okay,
that
in
this
issue
that
you
open
as
like,
hey
I've,
gotten
approval
to
have
this
repo
opened?
And
then
you
can
look
in
this
for
older
examples
of
existing
repos
that
we've
opened
and
just
open
up
the
issue,
and
then
the
kubernetes
old
folks
will
help
you
get
that
opened.
Okay,.