►
From YouTube: Kubernetes SIG Storage 20200813
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 13 August 2020
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.m2cjoevcxwkk
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
A
All
right
today
is
august
13
2020..
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group.
As
a
reminder,
this
meeting
is
public
recorded
and
posted
on
youtube.
So
on
the
agenda
today
we
have
2020
planning
for
the
119
release.
A
So
in
this
meeting
we
want
to
get
a
end
of
quarter
end
of
release
status,
update
for
all
the
projects
that
we've
been
working
on
for
this
release
and
then
in
the
next
meeting
on
august
27
we
will
do
a
120
planning
session,
so
please
come
prepared
for
that
and
we'll
do
planning
for
that.
At
that
point
so
reminder
today
is
just
an
end
of
quarter
or
end
of
release
planning.
We
want
to
get
an
end
of
quarter
status.
A
Okay,
so
first
item
that
we
have
is
csi
online
offline
resizing
volume
expansion
a
month.
Are
you
on
the
line
by
any.
A
A
Okay,
we
will
skip
over
that
a
month
tends
to
join
later
in
the
meeting,
and
we
can
come
back
and
get
a
status
update
from
him
when
he
joins.
A
There
we
go
hey
a
month,
so
we
were
on
the
first
item
here.
I
wanted
to
get
a
end
of
release
status
from
you
on
this
csi
online
offline,
resizing
volume,
expansion
fix
issues,
and
then
you
can
talk
about
recovering
from
resize
failures
as
well.
B
Yeah,
so
the
we
made
the
only
one
pending
item
that
we
have
in
external
resize
controller
and
I
think
similar
fix
will
be
needed.
That
is
that,
when
we
update
when
we
expand
pvc
on
the
on
the
resize
controller,
we
are
reading
from
informer
to
check
the
pv
status,
and
sometimes
the
informer
has
still
data.
So
it
could
it
results
in
flakes.
B
Basically,
it
doesn't
affect
end
users,
but
it
results
in
flake
that
we
are
trying
to
fix
in
the
resize
controller,
and
I
should
be
able
to
fix
it
by
today
tomorrow
and
the
other
things
are
in
and
that
was
for
fixes,
then
for
recover
from
resize
failure.
I
have
pinged
tim,
hawkin
and
jordan
multiple
times
about
if
they
have
a
chance
to
either
have
a
call
or
like
like
think
about
whether
the
allocated
resources
field
belongs
or
what
we
need
to
do.
B
Obviously,
the
code
and
everything
is
already
ready
and
done,
but
I
will
maybe
once
the
119
release
is
done.
Then
they
will
have
more
bandwidth
to
review,
but
so
that's
where
it
is.
A
Okay
sounds
good,
would
it
be
okay
to
mark
the
first
one
is
completed.
B
A
B
A
Okay,
so
then
I'll
keep
it
as
started
for
now
and
then
that'll
be
a
signal
for
us
to
carry
this
over
to
the
120
sheet
once
we
create
it.
A
Perfect
sounds
good
to
me
thanks
a
month.
I
think
we've
got
both
of
these
items.
Covered
next
item
is
supporting
containerized
csi
node,
plug-in
in
windows
with
storage,
proxy,
deep
jing,
or
anybody
working
on
windows
on
the
call,
maybe
kk.
C
D
Yeah
deep
had
cut
an
rc
of
the
csi
proxy
for
beta,
so
I
think
they're
they're,
getting
in
good
shape.
A
C
Yeah,
so
there
are
two
main
things
that
we
want
to
get
in
before
we
cut
the
new
release.
One
is
to
move
the
apis
and
client
to
a
separate
goal
module
so
that
one
now
is
actually
looking
very
close.
So
I
think
the
pr
is
almost
ready
to
go
and
the
second
one
is
to
add
this
validation
hook.
So
andy
and
sean
has
been
working
on
that
there
is
a
cap
that
has
been
reviewed
and
he
also
submitted
a
pr
which
is
still
adding
a
boiler
plate
for
the
web
hook.
C
E
A
Okay,
and
are
we
targeting
the
119
release
or
the
120
release.
C
So
119
would
like
to
get
this
one
in
okay,
the
web
hook,
because
I
got
it
because
we
need
to
do
this,
like
in
cup
of
releases,
making
sure
that
we
can
ga
in
1.20.
So
we'd
like
to
get
this
one
in
another.
A
One
and
the
api
pr,
whatever.
C
Yeah,
that's
yeah
that
one
is
almost
ready
just
to.
I
just
need
to
take
a
look.
Take
another
look,
so
I
think
it's
already
updated
address
comment
address.
I
just
need
you
another
review,
so
it's
almost
ready
to
go
so
so
mainly
just
waiting
for
the
validation
hook
thing,
and
there
are
some
other
bug
fixing
that
are
in
progress,
but
mainly
it's
this
one,
the
validation.
I
think
it's
the
big
one
that
we
need
to
got
it.
A
And
I
think
michelle
mentioned
to
me-
there
were
kind
of
some
concerns
that
came
up
around
validation.
Do
you
guys
want
to
talk
about
that
at
all.
C
So
yeah,
I
think
there
are
some
concerns
about.
There
are
some
concerns
about
like
re.
If
you
remove
the,
if
you,
if
you
make
it
more
strict
and
then
some
there
are
some
invalid
api
objects
that
can
not
get
removed
after
that,
then,
basically
so,
basically
meaning
that
the
user
setup,
they
will
always
have
those.
So
I
think
for
that
one
we
don't
really
have
a
perfect
way
to
completely
get
rid
of
those,
because
we
don't
want
to
like
automatically
deleting
them.
C
Then
it
could
result
in
data
loss.
So
we
want
user
to
be
the
one
who
are
responsible
for
removing
those
evaluated
objects.
Michelle
are
there
any
other
concerns
from
you
and
jordan.
D
No,
I
don't
think
we
have
any
major
concerns.
I
think
we've
identified
sort
of
a
a
rollback
procedure
that
would
work
if
users
get
stuck
in
this
situation,
so
I
think
that
is
sufficient.
E
One
thing
one
thing
I
want
to
add
here
is
how
how
we're
going
to
have
the
users
know
when
it's
okay,
to
move
on,
to
check
that
there's
no
invalid
objects
left
in
the
cluster.
C
But
okay,
so
that
would
not
be
something
that
we
are
checking
automatically.
Is
that
almost
like?
This
would
be
your
users
responsibly?
Who
are
you.
D
Yeah,
so
I
think
something
like
check
developing
like
a
script
or
a
tool.
That's
based
off
of
the
validation
logic
that
we
have,
I
think,
could
would
be
something
we
could
potentially
provide
to
make
it
easier,
because
otherwise,
like
everyone
has
to
write
their
own
tool,
that
does
all
the
same
things
that
makes
sense.
B
Yeah,
I
think
the
one
of
the
problems
that
we
have
seen
is
like.
The
cluster
upgrades
could
be
blocked
by
objects
that
are
stuck
in
like
terminating
state
or,
like
the
states
like
that.
So
like
we
have
some
end-to-end
tests
where
we
run
the
snapshot
tests
and
after
that
we
have
this
objects
following
snapshot,
objects
that
are
stuck
and
now
that
cluster
cannot
be
upgraded
because
it
has
volumes.
Sorry,
it
has
objects
that
are
stuck
in
terminating
state.
B
A
B
A
A
It
will
allow
them
to
continue
to
exist
for
some
period
of
time
and
and
eventually
the
validation
will
be
made
more
strict.
As
I
understand
it,
what
this
means
is
that
it
gives
users
a
chance
to
delete
those
invalid
objects,
and
I
guess
the
discussion
here
is:
how
do
you
detect
that
you
have
invalid
objects
and
and
remove
them,
and
the
suggestion
is
around
creating
some
sort
of
tool
to
be
able
to
detect
that
any
other
comments
on
this
topic.
F
D
Anyone
want
to
take
that,
so
I
think
one
action
item
we
have
from
the
discussion
with
api
machinery
folks
is
we're
going
to
open
up
a
feature
request
to
api
machinery
so
that
they,
their
like
the
crd
back
end,
can
be
more
lenient
in
allowing
a
deletion
flow
for
invalid
objects
that
if
they
can
solve
that
at
the
crd
layer
or
the
api
server
layer,
then
that
kind
of
reduces
the
need
for
us
to
have
to
to
build
all
these
out
of
band
tools
and
and
things
like
that,.
C
C
D
C
D
If
we
had,
if
the,
if,
like
the
crd
scheme,
had
all
these
validation
features
built
into
it,
when
we
initially
released
the
apis,
then
then
we
would
be
in
good
shape,
because
the
crd
schema
like
we
wouldn't
even
need
a
validation
web
hook.
But
since
we've
released
an
api
without
using
that
schema,
then
adding
it
to
a
new
schema
will
will
be
a
breaking
change.
A
All
right
so
takeaway
is,
if
you're
using
snapshots
beta,
be
aware
of
these
changes
in
the
new
validation
web
hook
and
make
sure
your
objects
are
valid
all
right.
Moving
on
to
the
next
item,
we
have
non-recursive
volume
ownership,
fs
group,
going
to
alpha
the
last
status
update
here
was
we're
gonna
remain
in
alpha
for
120.
A
Is
that
still
the
case
the
month?
Any
changes
here.
A
Sounds
good
so
we'll
carry
that
over
to
120..
Next
up
is
sc
linux
recursive
permission
handling
yawn.
Are
you
on
the
line.
A
next
item
is
file
permission
handling
for
windows,
and
I
imagine
this
is
the
same
status.
I'm
gonna
get
that
move
to
120.
A
A
D
Yeah,
I
think
we
have
a
couple
of
prs
in
flight,
but
they're
not
in
119,
so
we
will
be
targeting
120
for
those.
G
A
All
right,
we'll
get
that
carried
over
next
item
is
storage
capacity,
tracking
that
was
completed.
D
An
external
provision
yeah
patrick's,
still
working
on
the
external
provision
or
changes.
Okay,
I
think
yawn.
Do
you
think
it's
close.
A
There
was,
it
was
done
so,
okay,
we'll
just
move
on
from
that
one
spreading
over
failure,
domains
design.
We
said
we
will
move
this
to
120.
shang,
any
updates
or.
C
Yeah,
so
I
need
to
schedule,
but
next
week
I'll
schedule
a
meeting
next
week.
A
Sounds
like
we're
move
that
as
well
and
then
csi
out
of
tree
for
the
nfs
driver
was
completed.
A
D
Yeah,
it's
still
on
my
plate.
I
just
need
to
push
the
button.
I
will
try
to
get
that
done
in
the
next
couple
weeks.
A
Cool
sounds
good
to
me
and
do
we
want
to
move
them
to
120
or
you
want
to
keep
them
in
119.
D
I
mean
it's
all
out
of
tree:
okay,
I'm
just
going
to
push
the
deprecate
or
archive
button
on
the
thing
soon,
okay
I'll
say:
preliminarily.
A
We're
moving
it
to
120,
meaning
the
120
spreadsheet,
and
then
we
can.
We
can
remove
it
if
needed,
and
so
this
is
a
a
call
out
to
anybody
on
the
call.
If
you
are
using
fibre
channel
driver
or
you
care
to
use
it
or
you
care
about
the
csi
fiber
channel
driver
and
you
don't
want
it
to
be
deprecated
or
then
you
should
jump
in,
and
this
might
be
a
good
place
to
volunteer
to
help
get
this
into
good
shape.
A
A
Next
set
of
items
is
for
the
kubernetes
incubator
organization,
which
is
being
deprecated
one
of
the
repos
for
the
storage,
kubernetes
storage,
sig.
Underneath
that
organization
is
external
storage,
and
since
we
want
to
deprecate,
we
want
to
make
sure
any
items
that
were
under
that
repo
have
a
new
home
if
they
are
still
important.
A
The
most
important
item
there
was
the
existing
core
static
external
provisioner,
and
that
was
pulled
out
already
and
there
were
a
number
of
other
provisioners
external
provisioners
that
were
there
that
were
highlighted
as
important
and
are
in
progress
of
being
moved
out.
A
Gluster
fs
was
the
was
one
of
the
ones
that
is
currently
being
moved
out.
This
is
currently
in
progress
and
we're
going
to
move
this
into
120.
nfs.
Karen.
Are
you
on
the
line.
H
Yeah,
so
the
nfa
server
is
mode.
I
think
I'm
getting
new
pr
merged
there.
H
H
A
And
then
similar.
H
Right
there's
some
cla
related
issues
that
needs
to
be
resolved,
but
I
think
we
should
be
able
to
yeah.
A
C
Because
those
are
actually
already
moved
right,
I
know
I
think
karen.
C
H
So
there
were
only
one
thing:
was
there
were
a
lot
of
enhancements
that
came
in
after
the
initial
moments?
I
went
and
tagged
all
those
issues
and
we
asked
to
take
that
into
the
new.
G
A
Next
item
is
volume
snapshot
namespace
transfer?
This
was
a
design.
We
didn't
make
too
much
progress
on
it,
so
we're
going
to
go
ahead
and
move
it
to
120.
A
Csi
volume
health
plan
is
I'll,
go
ahead.
Shane.
C
So
yeah,
so
this
one
is
looking
good.
There
is
just
one
more
pr
one
or
two
that
we
want
to
get
getting,
but
those
are
kind
of
a
small
piazza
should
be
in
there
soon
and
then
we
are
ready
to
cut
a.
C
A
A
Next
up
is
the
object,
storage
api
also
known
as
cozy
jeff
or
sid.
Do
you
want
to
give
an
update
on
this.
A
Okay,
I
can
provide
an
update
here,
so
we
had
a
cap
review
meeting
last
week
and
there's
going
to
be
another
kep
review
meeting
right
after
this
meeting
on
the
same
channel
at
10
a.m:
pacific
time
and
they're
working
towards
getting
the
cap
approved
they're
hoping
to
get
that
approval
after
today's
meeting,
depending
on
the
outcome
of
that
meeting,
so
a
preview
and
process
meetings
every
thursday.
A
A
A
The
existing
api
for
csi
ephemeral
volumes-
I
wanted
to
do
bug
fixes
here
last
status.
Update,
was
waiting
for
a
generic
solution.
No
updates
move
to
120.
Is
that
still
the
case.
G
A
A
A
A
Cool.
Thank
you.
Christian
next
item
is
vsphere
csi
migration.
I
believe
we
have
a
meeting
on
friday
to
discuss
this
anything
else
to
add
here.
C
I
think
yeah,
I
think
that's
it.
We
are
maybe
just
yeah
waiting
waiting
for
that
meeting.
I
think
there
are
a
few
things
we
are
still
evaluating
but
like
to
see
what
is
the
community
decision
on
this
deprecation.
B
One
more
comment-
just
I
had
would
not
be
sphere,
but
in
in
general
about
the
plugins
that
we
are
migrating
like.
We
are
logging
in
the
log.
This
plugin
is
deprecated,
it
will
not
be
supported
and
it
gets
locked
each
time,
fine
by
plug-in,
find
attachable
plug-in.
That
call
is
made
it's
it's
quite
spammy.
Actually,
at
least
in
some
cases
is
that
necessary.
A
Azure
csi
migration,
andy
from
microsoft,
was
working
on
this
last
status.
Update
we
had
was
azure,
disk
was
moved
to
beta
azure
file
remained
in
alpha
and
azure
file
has
dependencies
that
need
to
be
resolved
before
ga
any
updates
on
that
from
anyone.
A
A
A
A
Second,
is
with
sig
apps.
We
have
an
issue
where
pvcs
created
by
stateful
set
are
not
removed,
and
this
issue
wants
to
clean
that
up.
Last
status.
Update
here
was
that
a
cap
was
created
and
any
any
other
updates
here.
A
So
we'll
get
that
move
to
120.
Do
you
think
that
it'll
be
ready
to
implement
in
the
120
time
frame.
A
All
right
looks
like
good
progress
on
that.
Then
next
item
is
volume.
Expansion
for
stateful
sets
last
status
here
was
kept,
was
raised,
addressing
comments
any
anything
else
on
this.
B
One
yeah,
I
think
kk,
is
not
there
in
the
call
today
but
okay.
So
I
had
a
call
with
him
I
think
last
week
and
where
we
discussed
the
cap-
and
it
is
still
missing
some
important
details
about
the
the
flow
actually.
B
And
so
I
thought
he's
going
to
update
the
cap
with
those
videos,
as
we
discussed
in
the
call.
A
Okay,
so
it
might
be
that
120
is
going
to
be
a
design
instead
of
an
alpha.
B
It
could
get
be
become
implementable,
but
it
needs
like
it
needs
to
use
from
us
and
from
like
jordan
or
tim
as
well.
So.
G
A
So
we'll
keep
an
eye
on
that
and
try
to
get
that.
Moving
next
item
is
execution
hook.
I
think
we
have
some
good
news
around
that
shang.
You
want
to
talk
about
that.
C
Yeah,
so
we
had
another
meeting
with
signaled
and
also
jordan
and
tim
also
there.
So
we
actually
it's
pretty
good
meeting.
C
We
reached
consensus
at
the
end,
so
there
were
a
few
decisions
we
made
there
to
address
the
concerns
from
the
front
signal
side
like
we
don't
want
to
do
retries
in
the
cubelet
and
only
the
external
controller
will
be
the
one
to
do
retry
if,
if
it
fails
for
the
first
time
and
then
also
have
a
pod
level
status
instead
of
each
for
each
container
has
its
own
status
and
then
also,
we
need
to
add
a
section
to
talk
about.
C
What
is
the
impact
on
kubrick
if
we
are
adding
this
feature
so,
but
actually
after
the
meeting
there
is
a
derrick
actually
added
the
comment
after
the
meeting,
because
he
couldn't
join
the
meeting.
He
had
a
conflict,
so
he
was
asking
us
if
we
can't
do
a
poc
outside
of
cubelet
so
and
then
team
was
saying
that
it's
okay
to
do
the
outset,
but
then
he
does
not
want
that
to
conflate
with
the
final
design,
because
I'm
also
not
quite
sure
what
that
means.
C
A
Yeah
nice
work
driving
that
this
was
pretty
challenging.
So
for
folks
who
are
not
familiar
with
the
situation,
we
have
a
kind
of
work
that
we
want
to
push
for
the
snapshot
controller.
A
A
Initially,
we
thought
this
would
be
a
standalone
controller
that
would
execute
these
qs
and
unqs
hooks,
but
I
think
the
feedback
that
we
received
was.
We
should
make
this
generic,
because
it's
kind
of
a
common
problem
across
kubernetes
being
able
to
signal
an
arbitrary
container
or
an
arbitrary
pod
for
various
different
other
reasons,
so
try
to
make
a
generic
api,
and
there
was
also
pushback
for
security
reasons
not
to
be
able
to
exec
into
an
arbitrary
pod
or
container
and
keep
that
logic
centralized
in
cubelet.
A
So
xing
went
to
signode
with
a
proposal
and
they
pushed
back
and
said
you
know
this
should
actually
be
an
external
controller,
not
part
of
cubelet.
We
want
to
keep
cuba
as
small
as
possible,
and
is
there
really
a
need
for
a
generic
hook,
and
so
shane
was
kind
of
caught
in
the
middle
required
multiple
meetings
to
try
and
resolve
that,
and
it
looks
like
finally
there's
a
light
at
the
end
of
the
tunnel
and
there
is
consensus,
hopefully
reached.
A
A
I
think
xing
next
item
is
the
kubernetes
util
mount
library
we're
going
to
go
ahead
and
move
that
to
120.
I
think
work
was
done
but
not
completed.
Michelle
is
that
correct.
A
Okay,
so
we'll
get
that
moved
over
to
120.
all
right.
Thank
you.
Everyone
for
the
updates,
that's
all
I
had
in
terms
of
getting
a
1.19
update
and
so
next
meeting
on
august
27
we're
gonna,
do
120
planning
I'm
gonna
copy
over
the
spreadsheet
to
120
and
we'll
move
over
the
items
that
we
didn't
complete.
A
We
can
go
over
assignments
and
any
additional
items
that
you
want
to
add.
Please
come
prepared
to
the
meeting
to
add
those
you
can
add
them
as
comments
if
you'd
like
ahead
of
time,
and
that
would
be
okay
as
well
I'll,
send
out
a
a
note
before
the
next
meeting
about
that.
A
A
Okay,
well,
if
there's
nothing
else
to
discuss
we'll
end
a
little
bit
early
today
and
give
folks
time
back
in
their
day
and
we'll
reconvene
in
two
weeks.
Thank
you
for
your
time.