►
From YouTube: Kubernetes SIG Storage Meeting 2022-01-13
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 13 January 2022
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.8765qb2fo50o
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
january,
13
2022.
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group.
As
a
reminder,
this
meeting
is
public
recorded
and
posted
on
youtube.
We
have
our
agenda
listed
on.
The
screen
here
feel
free
to
go
ahead
and
add
any
suggestions
to
it
as
we
go
through
it
and
first
up
we're
going
to
go
through
the
124
planning.
The
124
release
is
underway.
We
did
planning
for
124
in
december.
A
The
upcoming
dates
to
be
aware
of
for
124
next
up
is
on
the
27th.
There
is
a
production,
readiness,
soft
freeze.
What
this
means
is
that
if
you
have
a
feature
that
needs
to
go
into
the
124
release,
any
kept
that
you
have
must
get
production
approval
a
little
bit.
I
think
a
week
before
the
actual
enhancement
freeze
date.
So
please
keep
an
eye
on
that
and
jesse.
I
see
you're
adding
a
couple
items
here.
You
wanna
you
wanna
comment
on
that.
B
B
I
just
did
add
that
extra
in
week
11
we
have
a
feature
blog
freeze
to
keep
in
mind
as
well,
which
is
not
sure
I
mean,
I
think,
you're
all
very
aware
and
very
active
there.
But
this
has
been
an
opt-in
part
of
the
cycle
for
the
last
few
releases.
So
just
as
with
caps
for
week,
11
the
deadline
for
opting
in
feature
blogs
happens
so.
C
C
A
Cool
thank
you
jesse
for
that
reminder,
and
that's
right
folks.
So
here's
the
full
schedule
good
to
remember
that
there's
also
a
option
to
have
published
blogs
for
the
features
that
we
have
and
if
you
want
to
do
that,
please
make
sure
you
add
to
that
spreadsheet
that
tracks
this
by
the
23rd
all
right.
So
with
that
we're
going
to
go
ahead
and
switch
over
to
the
spreadsheet
that
we
use
for
tracking
our
work
and
we'll
go
over
the
124
items
and
get
status
updates
all
right.
So
first
item
here
is
delete.
A
E
F
A
E
So
that's
something
I
want
to
try
in
this
release
and
there
are
there's
one
or
two
outstanding
issues
that
that
will
fix
and
move
the
expansion
to
ga
as
a
whole.
I
am
trying
to
set
up
some
calls
next
week
discuss
if
anybody
has
any
other
outstanding
issues
apart
from
recovery
and
one
more
issue
about
read,
write
many
volume
types
but
yeah.
A
Awesome
thank
you
and
for
folks
on
the
call
remember
that
if
you
are
using
volume
expansion,
it's
currently
in
beta
and
if
you
have
any
major
issues
with
it
any
concerns
before
we
move
it
to
ga,
please
try
and
attend
these
meetings
that
haman's
gonna
organize
to
raise
any
of
your
concerns.
Otherwise
it
is
going
to
get
moved
to
ga,
as
is
other
than
a
couple
of
known
issues
thanks
a
month.
Next
item
is
recovering
from
resize
failure.
I
assume
this
is
a
tied
to
the
related,
or
are
we
still
moving
these
independently.
E
Yeah
this
is
this:
will
move
independently
because
it
we
don't
want
to
block
like
resizing
as
a
whole,
going
ga
for
this,
because,
as
long
as
like
thinking
was
as
long
as
you
just
have
have
a
way
to
recover
it,
it's
fine.
So
we
do
have
a
way
now.
So
we
want
to
move
the
recovery
feature
to
beta
in
124,
while
moving
the
resizing
as
a
whole
to
ga.
H
A
A
D
A
Got
it
all
right,
so
it
sounds
like
next
steps
here
are
to
figure
out
how
these
ephemeral
volumes
are
going
to
play
with
the
security
and
given
pod
security
policies
going
away,
and
it
sounds
like
you
have
a
meeting
with
jonathan
to
discuss
that
soon,
so
progress
being
made
cool.
Yes,
thank
you.
Yawn.
C
F
A
H
J
A
A
A
C
A
E
A
A
C
A
K
K
The
the
volume
data
source
validator
controller,
which
is
an
out
of
tree
controller,
will
have
metrics
and
the
the
library
for
supporting
populators
will
have
support
for
metrics.
Although
being
a
library,
the
consuming
application
will
need
to
do
a
little
bit
of
we'll
need
a
little
bit
of
glue.
So
there'll
be
metric.
Support
in
the
library,
but
they'll
be
work
for.
K
K
A
A
A
J
Yeah
so,
based
on
our
last
discussions,
I
have
a
fairly
newish
design,
so
this
new
design,
I'm
just
now
beating
the
cap
with
it
and
then
we'll
queue
up
in
the
cigar
discussions.
The
advantages
of
this
new
designer
that
avoids
many
of
the
cri
change,
like
any
of
the
cri
changes
changes.
So
it's,
I
think,
is
much
clearer
and
yeah.
As
soon
as
I
update
the
cap,
maybe
someone
like
yan
can
do
another
review.
A
A
H
A
A
A
C
A
A
K
A
D
A
A
A
C
A
A
A
A
C
H
A
D
A
A
C
A
A
J
A
A
E
C
A
C
A
M
A
A
A
B
A
D
D
But
yeah
to,
I
guess,
summarize
the
issue
right
now
right
now,
when
you
clone
a
volume,
it
requires
that
the
source
ppc
and
the
new
pvc
be
of
the
same
storage
class,
and
you
know
in
some
cases
that
makes
a
lot
of
sense
like
if,
in
one
storage
class,
you
might
have
some
parameters
that
are
incompatible
with
the
parameters
of
your
target
storage
class.
I
think
originally
there
were
examples
like
the
fs
type
like
a
different.
C
D
C
D
D
D
C
C
D
D
D
C
I
D
D
D
D
Yeah
I
mean
we
could
say
we
could
say
you
know
it's
well
like.
I
think
I
was
already
sort
of
moving
towards
the
idea
that
it
should
be
the
responsibility
of
the
driver
to
check
that
the
source
and
the
targets
are
compatible,
but
I
think
the
main
problem
is
there
are
some
parameters
that
may
be
difficult
for
the
driver
to
check
such
as
the
fs
type,
but
I
guess
I
don't
know
what
else
besides
fs
type.
That's
like
the
main
thing
that
comes
to
my
mind,.
A
Yeah,
it
seems
like
one
of
those
things
where
yeah
we
should
probably
loosen
this
a
little
bit.
The
edge
cases
are
definitely
there
for
the
ones
that
we're
aware
of,
we
can
try
working
around
it
and
the
rest
of
it
is
like
a
csi
driver
vendor.
Please
be
careful
here
and,
as
we
discover
new,
I
think
areas
we
can
surface
it
here
in
the
sig
and
make
sure
folks
are
handling
it
correctly,
but
it
seems,
like
the
benefit,
outweighs
the
cons
in
this
case.
A
N
N
Oh
yes,
so
this
is
on
a
particular
use
case
that
I
think,
or
it
doesn't
exist
or
I
might
be
missing.
So
this
is
regarding
storage
with
a
particular
access
mode.
Read
write
once
so
just
to
explain
the
scenario,
so
I'm
trying
to
get
all
parts
on
the
same
node
same
storage
on
the
node,
but
the
problem
arises.
If
say,
I
have
to
scale
the
pod
to
a
multiple
node
and
the
new
node
wouldn't
be
attached.
N
The
new
storage
wouldn't
be
attached
to
the
new
node,
because
that
pv
is
already
attached
to
the
existing
node
and
it
wouldn't
spin
up
one
more
storage
to
attach
to
the
new
node.
So
as
far
as
I
see
currently,
there
exists
a
workflow
where
it
could
be
one
storage
per
deployment
or
each
port
could
have
its
own
volume
through
generic
fml
volume.
But
there
isn't
something
where
every
node
would
have
a
volume.
A
So
I
want
to
make
sure
I
understand
your
use
case.
So,
ideally,
what
you
want
is
all
the
pods
that
live
on
a
given
node
share
some
sort
of
volume
that
is
not
ephemeral.
It's
persistent
right
and
every
time
a
new
node
is
added
a
new
pod
that
lands
there
effectively.
A
new
volume
is
created
on
that
on
that
node
right,
that's
got
it.
N
A
D
A
He
needs
something
like
a
demonstrate,
stateful
set,
which
would
give
him
a
new
volume
per
per
node
node
yeah
I
mean
you
can
always
write
a
custom
controller
for
this
rotash.
It's
a
little
bit
of
a
weird
edge
case
that
you're
encountering
it's
not
super
complicated
to
write
such
a
controller
effectively
like
you
are
creating
like
a
demon
set
stateful
set,
and
you
could
write
a
controller
that
does
that
and
have
your
own
cr
for
how
to
define
that
and
then
create
your
own
pods
and
wire
them
up
to
pvcs.
D
I
know
the
the
ask
for
like
a
demon,
stateful
set
has
come
up
a
couple
of
times
in
the
past.
It
might
worth
be
bringing
the
stuff
into
gaps
too,
and
I
don't
know
if
they're
still,
there
might
have
been
like
old
enhancement
issues
opened
up
in
the
past
for
this.
But
I
I
don't
know
off
the
top
of
my
head.
M
A
D
M
M
A
So
yeah
that
could
be
a
easy
workaround
for
you.
Ritesh
basically
use
stateful
sets
put
a
anti-affinity
policy
that
ensures
that
the
pods
in
the
stateful
set
do
not
land
on
the
same
node
and
then,
like
michelle,
said,
write
a
small
controller
that
controls
the
number
of
replicas
on
that
stateful
set
to
be
the
number
of
nodes
that
you
have
on
your
cluster,
and
so
that
will,
you
know,
create.
A
Now
I
think
the
challenge
you'll
have
from
that
point
is:
if
you
have
any
subsequent
pods
that
are
created
on
those
nodes,
how
do
you
ensure
that
they
attach
the
volume
that
is
created
for
that
node,
and
I
think
you
can
use
a
a
web
hook
an
admission
web
hook?
That's
you
know,
checks
once
a
pod
is
scheduled,
what
the
correct
volume
should
be
for
that
node
and
you
know,
injects
it
into
that
pod.
N
Right
yeah,
I
might
have
to
try
a
few
things,
but
I
think
stateful
said
I
did
give
it
a
thought,
but
it
does
change
some
of
the
mechanism
of
the
deployment,
because
currently
I'm
using
deployment
object
right.
So
stateful
site
is
kind
of
no
go
for
some
of
the
different
design
decisions
that
I
had
to
make.