►
From YouTube: Kubernetes SIG Storage 20200924
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 24 September 2020
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Xing Yang (VMware)
A
A
A
B
All
right
yeah,
so
the
the
fixing
issues
like
we
have
some
issues
reported
about
the
delete
bbc
being
deleted,
but
resize
is
pending.
That
is
being,
I
think,
a
kids
has
taken
to
work
on
it
and
will
we
have
some
other
issues?
I
think,
and
then
we
had
the
read,
write
many
expansion
that
we
could
not
do
in
119.
It's.
We
already
have
a
pr.
I
already
helped
here,
so
I
just
need
to
update
it.
So
those
are
things
that
will
be
working
so
yeah.
This
is
in.
B
Let's
put
the
next
one,
that
is
the
recovering
from
recess
failure,
so
this
one
we
had
a,
I
don't
know
we
had
a
call
with
team
and
jordan.
I
think
it
was
already
recorded
and-
and
the
thing
is
that
the
suggestion
that
they
gave
us
was
recommendation
was
to
follow
the
inline
part
resizing
cap
closely,
but
that
cap
is
still
evolving
actually
not
yet
sure
how
like,
for
example,
that
there's
a
talk
to
use
resize
sub
resource
to
to
capture
some
of
the
intermediate
state.
B
I
don't
know
where
it
is
right
now,
but
it
is
still
in
progress
and
then
second
one
was
the
guidance
we
got
from.
Tim
was
like.
If
it
is
possible,
then,
if
the
resize
fill
with
the
terminal
error,
then
it
should
be.
If
it
is
possible,
then
give
back
the
quota
to
the
user.
That's
kind
of
very
tricky
to
do
correctly,
because
we
don't
have
enough
error
codes
from
csr
driver
to
determine
terminal
and
non-terminal
errors
for
resize
failures,
and
we
have
to
design
something
proper
for
this.
So
this
task
will
be
converted
into.
A
A
B
B
That
means
we
can
move
existing
alpha
implementation
to
beta
in
this
release
actually,
but
we
are
still
waiting
to
hear
from
clayton
or
someone
about
the
s
linux
handling,
because
we,
the
fs
group,
adds
a
fs
group
change
policy
field
to
part
spec
and
we
wouldn't
be
able
to
merge
that
field
with
s
linux.
So
that's
where
it
is
so,
but
but
we
just
have
to
update
the
existing
cap.
B
B
A
B
Is
is
different,
but
at
the
same
time
like
in
in
119,
when
jan
wrote
the
proposal
and
wrote
the
implementation,
clayton
and
bunch
of
other
folks
commented
like
on
different
things,
and
there
was
a
thought
like
that:
can
the
new
field
be
that
part
security
policy
field
merged
for
both
srn
s,
fs
group,
but
given
the
status,
what
we
know
today,
I
don't
think
we
can
merge
it.
So
it's
a
different.
It's
so
we'll
have
to.
C
D
A
A
A
A
E
E
Some
some
developments
in
the
linux
kernel.
I
think
that
they're
they're
trying
to
rework
I
mean
this-
is
a
known
problem.
All
the
way
down
at
the
kernel
layer
like
it
just
stinks
that
that
when
you
do
mapping
of
user
ids
at
the
container
layer,
your
fs
ids
get
all
messed
up
and
ultimately
I
think
we
were
going
to
be
unhappy
and
until
the
colonel
offers
a
new
facility
to
do
this
better.
E
A
F
So
this
one
I
do
like
a
ask
around
in
sick
windows
and
so
at
first
I
think.
Basically,
we
said
we
seems,
don't
need
any
actions,
at
least
for
now,
but
later
I
think
someone
probably
a
microsoft
team
and
they
think
again
there
might
some
issue,
but
we
haven't
got
time
to
investigate
so
right
now
I
opened
up
issue,
I
think
in
microsoft,
container
side
and
slowly.
F
A
A
D
A
A
A
H
A
G
A
G
A
A
A
J
J
A
A
Oh
next
one
is
the
volume
house,
so
I
think,
for
this
release
we'll
just
be
working
on
making
sure
we
add
all
the
e3
tests
that
are
required
to
make
sure
this
is
a
stable.
I
start
to
think
about.
You
know
next
step.
How
are
we
going
to
use
the
supporting
house
information,
but
I
think
that
will
need
some
thought
and
some
design
discussions
so.
E
I
don't
know
if
anyone
has
any
opinions
on
that,
but
that's
I
need
to
make
that
decision
and
then
do
it
and
get
it
reviewed
next
week,
but
I
have
a
working
implementation
that
uses
a
the
validating
admission
web
hook
to
make
sure
that
that
we
don't
create
volumes
for
data
sources
that
that
aren't
going
to
work
and
that
actually
works
great.
So
I
I
think,
there's
a
good
chance.
This
will
get
to
beta.
It's
got
to
do
the
cup
work
by
the
deadline.
A
Okay,
great
so
right
now
they
are
kind
of
strict,
like
you
have
to
have
an
issue
associated
with
everything.
So
if
you
write
a
new
cabinet,
you
need
a
new.
You
have
a
new
issue
because
we're
getting
this
problem
visible
in
snapshot.
We
have
this
kappa
validation,
hook
added
in
the
same
folder
and
then
now
they're
asking
me
to
create
another
folder
for
that
one.
So
it's
like
we'll
have.
E
H
E
K
This
is
renee.
Actually
the
reviews
are
going
good.
There
are
a
few
reviews
this
week
we
are
actually
addressing
them.
Hopefully
we
try
to
meet
the
deadline.
Kept
is
updated
to
the
new
format
and
I
we
got
some
reviews
this
week.
We
are
addressing
them
and
on
the
code
side
we
have
defined
some
milestones
and
building
a
common
control
controller
lib,
so
that
can
be
used
by
the
central
controller
and
the
sidecar.
K
So
it's
all
going
good.
Hopefully
we
will
be
able
to
address
all
the
issues
by
next
week
before
the
kept
deadline.
Please
do
review
anyone
on
this
call.
I
request
that
review
the
cap
and
see
if
there
are
any
use
cases
we
haven't
addressed
and
the
call
for
the
cap
review
is
after
this
call
please
do
join.
That's
all.
C
A
B
Actually,
you
know
one
thing
quickly,
so
if
we
add
new
values
to
the
enum,
that's
considered
backward
incompatible
change
and
we
might
need
new,
ms
to
that,
the
fs
group
policy
in
csi
driver
field.
So
michelle
jan,
do
you
have
any
opinion
that
like
do
you
need
to
wait
before
you
move
to
beta
or
it's
okay
to
add
new?
We
know
values
to
a
beta
api.
A
A
G
L
L
A
H
H
H
L
A
M
G
A
A
Next
one
is
okay,
so
this
is
the
seek
apps
pvc
created
by
safer
side
will
not
be
automatically
removed,
so
I
think
kkk
just
send
out
some
updates.
I
haven't
read
it
yet.
He
can't
he
can't
attend
a
meeting,
but
then
he
said
he
has
some
status.
The
first
one.
Okay
said
he
addressed
current
outstanding
comments
and
then
there's
just
some
outstanding
issue:
how
to
handle
the
situation,
what
parts
get
deleted
explicitly
by
the
user.
A
A
A
Okay,
but
working
progress.
So
that's
from
kk
on
those
two
and
then
the
next
one,
the
execution
hook.
Well.
Actually,
this
one
now
is
called
a
container
notifier,
so
the
app
yeah.
So
I
do
have
an
update
so
so
chanting
and
I
worked
on
a
caps.
The
cap
is
submitted,
and
so
now
tim,
jordan
and
seth
from
signora
are
reviewing
it.
So
we
also
get
quite
a
few
other
comments
on
that.
So
so
the
plan
is
to
do
this
in
three
phases:
phase
one.
A
I
will
be
adding
a
in
line
for
definition
to
handle
comments
and
then
have
a
notification.
Api
object
to
request
that
continually
fire
and
also
the,
but
the
implementation
of
the
controller
will
be
in
a
separate
controller,
not
in
public.
Yet
so
it's
going
to
be
a
separate
repo
sponsored
by
signaled
and
then
phase
two
will
be
move
that
logic
into
kubelet,
but
then
also
add
handling
for
signals
that
need
the
cri
changes.
A
A
A
A
G
G
The
node
team
who
owns
the
cubelet
said
no,
no,
no,
no
wait
a
minute
here,
you're
increasing
the
the
kind
of
surface
area
for
cubelet.
We
don't
want
to
do
that,
and
so
it
was
a
big
fight
going
back
and
forth,
and
so
the
current
status
is
everyone's
agreed.
Okay,
let's
do
a
poc
that
doesn't
modify
the
cubelet
to
kind
of
prove
out
the
ideas
and
the
apis,
and
if
that
looks
good
as
we
approach
alpha
beta,
then
we
can
go
ahead
and
pull
it
into
cubelet.
G
A
K
A
F
F
A
mix
of
nodes
which
contains
both
links
and
windows
like
multi-writer
use
case
nfs
smb,
can
support
that
and
now
look
at
the
storage
class
right.
We
have
mount
options
so
if,
before,
if
only
linux
nodes
there,
so
you
put
whatever
amount
option
for
linux
and
now
with
windows.
It
comes
up
right
and
those
mount
options,
no
longer
applicable
for
windows
node,
and,
if
you
put
there,
it
will
fail
to
it's
a
different
mount
mechanism
right.
F
F
F
F
So,
for
example,
you
have
mount
options
and
we
can
add
some
additional
information
right,
select
prefix
to
indicate
this
is
belong
to
linux
or
unix
amount
options
and
or
it
is
belong
to
windows.
There's
an
example:
we
showed
there
and
then,
if
we
implement
inside
of
kubernetes
right,
then
kubernetes
get
those
options
right.
It
can
parse
those
strings
and
figure
out.
F
F
F
A
little
bit
concerned
in
this
approach
is
whether
we
can
appropriate
passing
the
string.
So
just
in
case
there
are
some
very
strange
amount
options
pass
along.
We
will
make
some
mistakes
passing
them
and
for
sensor
driver
right.
If
we
implement
as
a
driver,
then
each
individual
driver
need
to
handle
this
and
what,
if
they
diverge
and
also
user,
need
to
know
exactly
how
the
driver
handle
of
this.
A
F
A
F
Right
user
need
to
provide
all
the
amount
options
together
because
the
the
volume
could
be
used
by
both
linux
and
windows.
Right
so
scenario
exists
and
the
customer
might
need
to
kind
of
share
data
between
linux
and
windows.
Nodes,
okay,
but
if
you
only
give
linux
options
like
right
now
right
and
it
will
fail
to
mount
on
windows.
N
N
F
Oh
yeah
there's
some
user
like
right
right
now
with
windows,
support
available.
So
typically
your
cluster
contains
some
windows
note
and
also
a
number
of
linux
node.
You
may
not
need
it
if
your
whole
environment,
only
new
windows,
but
some
users
have
a
scenario
like
they
have
some
application
running
on
linux,
which
is
writing
data
to
a
volume
right
and
then
some
windows.
Now
they
have
some
workload
to
access
those
data
to
do
some
other
processing.
F
F
F
Typically,
we
don't
have
any
mount
options,
special
amount
options.
If
you
put
there,
I
think
it
will.
I
have
a
problem
yeah
because
it
will,
oh
so
far,
it's
up
to
the
driver.
So
if
your
driver
ignore
mount
options,
then
it
will
work.
If
your
driver
do
take
your
mount
options
and
then
it
will
have
trouble
issue.
H
F
F
F
I'm
not
sure,
like
the
other,
any
other
kind
of
parameters
we
passed
to
csi
driver
that
is,
is
up
to
the
driver.
Typically,
like
I
know
some
some
driver,
I
say,
pass
password
username
password
right
through
the
parameters,
but
I
don't
know
other
type
of
like
parameter
need
to
know
the
context
of
linux
or.
F
F
F
We
don't
have
much
like
a
special
api
spec
only
for
windows
right
now,
but
we
have
let's
say,
for
example,
webhook
to
validate.
There
are
some
fields
not
make
sense
for
windows,
so
we'll
fail
to
create
those
objects
and,
like
I
said
overall,
I
think
from
api
design
side.
We
didn't
think
much
about
windows
when
we
designed.
F
F
F
It's
also
related
to
how
you
use
the
volume
to
different
places.
Basically,
we
kind
of
scatter
some.
So
there
is
two
phase
around
how
you
create
volume
and
then
how
you
use
the
volume.
When
you
create
a
volume,
you
don't
know
how
to
use
it.
So
that's
simpler
like
what
kind
of
information
you
put
there
and
then
later
how
you
use
it,
you
might
use
it
in
different
ways
and
the
information
how
you
use
them.
I
feel
right
now
is
kind
of
scatter.
Some
mean
pause
back,
some
in
storage
class
yeah
in
the
past.
F
C
B
F
Yes,
so
we're
thinking,
because
linux
and
windows
right
is
a
kind
of
more
like
a
general
problem.
So,
instead
of
let
the
driver
need
to
figure
out
what
options
linux,
what
options
belong
to
windows
right,
which
driver
have
to
handle
separate
like
in
their
own
way,
is
that
good
to
handle
its
incubator
side?
Is
that
so
that
the
driver?
Don't
need
to
worry
about
that.
F
H
H
I
think
I
think
what
jing's
proposal
here
is
is
saying
like
either
we
prefix
mount
options
with
either
like
we
prefix
mount
options
with
the
os
or
we
have
two.
You
know
a
new
field
for
mount
options
for
windows
and
cubelet
will
only
pass
in
linux,
mount
options
to
the
driver
or
only
pass
in
windows,
mount
options
to
the
driver
or
the
the
second
proposal.
Is
we
just
pass
in
every
single
mount
option
and
it's
up
to
the
driver
to
figure
out
which
ones
are
for
linux
and
windows
are
for
windows.
E
So
so
I
get
that
the
the
biggest
problem
here
is
the
backwards
compatibility
concern.
We
want
to
do
something
better
for
windows
without
breaking
anyone.
That's
on
linux.
Is
anyone
relying
on
mount
options
on
windows
today
with
the
way
that
it
works
now,
because
if
if
they
are,
then
I
mean
I,
I
kind
of
prefer
the
whole
separate
like
place
to
put
windows
mount
options
like
make
it
a
separate
field
with
a
different
name
and
then
handle
that
especially.
H
E
E
B
From
from
css
point
of
view,
it
should
only
pass
the
amount
option
that
drive
driver
can
directly
apply
without
without
going
through
another
hoop
and
trying
to
figure
out
if
these
are
windows
or
linux
not
options.
So
I
think
in
ideal
world
we
would
like
cubelet
to
somehow
determine
that
if
these
options
apply
to
unix
operating
system
of
this
options,
applied
to
windows
operating
system
and
then
pass
the.
E
F
E
I
mean
I,
my
personal
preference
would
be
to
like
take
a
step
back
and
design
it.
The
way,
like
the
ideal
way
that
you
would
have
designed
it.
If
you
didn't,
have
to
worry
about
backwards,
compatibility
and
then
figure
out
like
given
that
we
do
have
to
worry
about
backwards.
Compatibility
figure
out
what
the
closest
approximation
of
that
is
or
or
a
path
towards
getting
there.
Maybe
in
version
of
version
2.0
or
something.