►
From YouTube: Kubernetes SIG Storage - Bi-weekly Meeting 2022-12-15
Description
Kubernetes Storage Special-Interest-Group (SIG) Bi-weekly Meeting - 15 December 2022
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Xing Yang (VMware)
A
A
A
So
just
the
the
formal
release
schedule
for
1.27
is
not
merged
yet,
so
this
is
a
PR.
According
to
the
soil
release
cycle
starts
on
January,
9th
and
the
it
has.
No
freeze
is
one
month
later,
it's
February
9th,
so
maybe
a
little
early
about
we
can
get.
You
started
so
I
just
copied
the
1.26
penis
spreadsheet
to
1.27.
So
just
just
start
from
here.
C
A
B
A
B
A
A
And
the
next
one
is
volume
group
API
yeah,
so
I
would
like
to
move
this
to
you
Alpha
in
1.27,
so
we'll
get
1.27,
and
so
so
there
are
some
comments
that
need
to
address.
One
comments
is
from
James
that
he
want
to
have
the
group
related
rpcc
in
a
separate
in
separate
service,
so
I
will
be
working
on
that
and
also
another
thing
is
there
are
some
questions
regarding
how
vendors
are
can
support
the
the
group?
A
C
C
A
A
A
A
C
A
A
A
C
Yeah
this
work
is
handled
out
of
tree
there.
There
is
a
design
proposal
out
for
review
and
yeah
right
now,
the
I
my
understanding
is,
they
did
a
bunch
of
work
in
a
feature:
branch
on
CS
type,
proxy
and
so
I
think
the
next
steps
are
to
get
the
design
reviewed
and
approved,
and
then
they
can
move
forward
with
that.
A
A
A
C
B
A
B
Yeah
so
I,
okay
and
he's
not
here,
but
he
has.
Why
does
the
sum
update
and
I
think
the
plan
is
to
keep
in
Alpha,
but
we
might,
which
will
be
most
likely
changing
the
API
in
the
Clusters
in
the
CSI
driver
object,
which
is
a
Boolean
right
now,
whether
the
isolinux
support
is
there
or
not?
We
want
to
remove
the
Restriction
of
like.
Currently,
it
only
works
for
read,
write
one
spot.
What
we
write
one's
part
volume
types
but.
B
It
CSI
driver,
so
CSI
driver
had
a
field
that
was
introduced
to
support
this
feature,
which
was
called
slnx
bound.
Whether
the
driver
supports
the
Linux
model.
It
was
a
Boolean
flag,
but
we
want
to
make
it
an
enum
so
that
the
purpose
of
the
enum
is
like.
It
appears
that
some
drivers
like
redirect
many
drivers,
they
support,
mounting
same
volume,
multiple
times
with
different
slns
contexts
and
it
just
works,
but
some
read
write
ones
like
that.
Have
ext4
likes
file
systems
on
it.
They
can
only
be
mounted
once
So.
B
The
plan
is
like
a
like.
A
cluster
admission
administrator
can
obtain
how
the
driver
should
behave
if
it.
If
it
supports
the
retract
many,
then
it
could
be
used
with,
like
the
same
volume
can
be
used
from
multiple
parts
and
with
Mount
option.
It
will
all
work
fine,
but
if
a
driver
only
supports
mounting
the
same
volume
with
only
once
slrs
context
that
it
has
to
be
restricted
to
read,
write
once
so,
it
might
require
a
API
change.
So
for
that
reason,
I
think
we'll
have
to
keep
that
in
Alpha.
A
C
A
A
A
A
A
C
A
A
B
A
B
But
I
don't
know
what
they're
planning
yet,
but
the
feature
has
some
blocker
works
with
congenial
runtime,
so
they're
trying
to
fix
all
of
that
I
try
to
test
it
and
it
was
not
working,
but
maybe
it
worked
now
it
works
now.
So
we'll
have
to
kind
of
get
all
of
that.
I
I,
don't
know
I'm,
not
sure.
If
they're
trying
to
move
this
to
Beta
in
127.
I
have
not
heard
anything
like
that.
B
D
D
A
A
B
A
A
B
A
A
D
A
E
C
A
F
Oh
sorry,
my
mic
is
muted.
Can
you
hear
me
yes
yeah,
so
this
is
really
quick,
but
essentially
we
over
the
AWS
EBS
CSI
driver,
we're
implementing
a
feature
to
allow
users
to
specify
the
block
size
of
file
systems,
and
my
colleague
rashob
brought
up
that
this
might
want
to
be
a
like
a
shared
parameter,
similar
to,
like
other
other,
like
common
storage
class
parameters.
A
F
A
C
D
F
G
F
G
B
I
guess
one
problem
is
like,
if
you
put
it
as
a
parameter
like
as
a
field
on
storage
classes,
we'll
have
to
also
figure
out
how
to
pass
it
down
from
like
from
the
storage
class,
we
have
to
copy
it
to
PV
and
then
to
pass
it
to
the
CSI
RPC
call
when
the
because
it's
the
driver
that
forwards
the
disk.
So
it
has
to
be.
F
B
G
Yeah
there
is
a
there's,
a
plumbing
concern
there,
because
the
wow
this
type
is
consumed
when
kublic
does
the
node
stage
right,
and
so
it
has
to-
and
by
that
time
it's
possible
that
the
storage
class
has
been
deleted.
So
you
need
to
have
copied
it
somewhere
so
that
it's
available
when
you
stage
the
volume.
B
Yeah
and
then
we
get
into
the
business
of
how
do
we
separate
like
like
Mount
option
that
are
applied
between
the
mount
flags
and
then
the
because
the
same
RPC
calls
node
stage
good,
will
call
mkfs
and
do
like
Mount.
So
it's
like
it
requires
two
separate
bag
of
hashes
or
two
separate
bag
of
fields.
It
will
require,
in
that
case,.
E
B
E
I
think
the
question
is
whether
block
size
is
so
ubiquitous
that
it
should
be
singled
out
as
not
just
a
generic
flag,
but
it
and
in
the
fullness
of
time,
mkfs
flag,
more
esoteric
file
system,
specific
nks
Flags,
like
journaling
options
or
number
of
high
nodes.
We
probably
wouldn't
want
to
call
those
out
explicitly
it's
a
good
question
here
is
whether
block
size
gets
special
treatment,
because
every
file
system,
in
theory,
has
some
notion
of
it.
F
Yeah
we
were
talking
I
believe
there
was
previously
we're
talking
about.
You
know
the
storage
class
could
be
deleted
or
whatever,
but
what
I
was
going
to
say
is
like
we
could.
The
suggestion
here
would
be
not
making
it
a
parameter
on
like
the
PVC
or
something
like
that,
but
just
chain
like
having
the
name
in
the
storage,
Class
B
like
something
well
known,
so
not
not
the
way
it's
done
with
FS
type.
F
B
F
D
D
F
B
B
And
then
it
gets
passed
to
as
a
context
to
to
the
the
node
stage
or
not
published
requests
now.
Fs
type,
on
the
other
hand,
is
stored
as
a
top
level,
not
top
level,
but
one
level
higher.
It's
not
in
that
same
map
of
volume
attributes
which
could
be
anything
generic
that
create
volume
returned
so
FS
type
is,
is
a
different
field,
a
separate
field.
B
F
B
But
the
thing
is
that
nothing
in
parameters,
field
parameter
is
a
map
of
string
string.
Nothing
in
parameters.
Field
has
a
well-known
field.
Fs
type
is
one
level
above
that
and
that's
why
FS
step
is
named
and
if
you
want
block
size
to
be
named
same
as
FS
type,
then
FS
type
has
to
be
one
level
above.
It
cannot
be
inside
that
parameter
map.
A
A
B
C
F
B
C
A
C
F
G
Part
of
the
problem
is:
is
that
there's
not
really
an
official
mechanism
for
making
those
parameters
be
standardized?
It's
just
that
for
the
ones
that
happen
to
be
in
the
sidecar
code.
They
get
treated
as
special
right.
If
someone
pushes
a
PR
to
external
provisioner
that
consumes
a
field.
That's
that
field,
sudden
that
that
string
suddenly
becomes
magical
and
but
there's
no
official
process
for
that
foreign
so
so
like.
G
If,
if
we
were
to
start
consuming
the
block
size
parameter
in
external
provisioner
like
yeah,
we
would
have
to
pick
a
string
and
that
would
become
the
standard,
but
like
I,
don't
think
we
want
to
do
that.
We
just
want
the
the
the
the
plugins
to
to
consume
it
and
do
what
they're
going
to
do
with
it
and
yeah
it's
hard
to
define
a
standard.
Then
I.
C
G
A
F
D
C
Yes,
I
added
this
one,
but
basically
I
know
some
folks
here
might
already
be
familiar
with
this.
But
I
think
this
might
be
new
for
a
lot
of
people.
But
there
is
this
Community
called
data
on
kubernetes,
which
is
basically
like
a
a
community
of
end
users
who
are
running
stateful
applications
on
community
on
kubernetes,
and
they
are
there's
a
lot
of
like
a
database
folks.
There
that
write
operators
for
the
various
databases
and
they
share
a
lot
of
best
practices
and
there's
a
lot
of
good
content
here.
C
I
thought
that
it
would,
but
it
might
be
good
to
have
sort
of
a
more
Regular
kind
of
round
table
or
Forum
between
kubernetes
and
this
ad
user
Community,
so
that
we
can
basically
collect
feedback
more
regularly
and
maybe
help
Drive
priorities
on
different
different
projects
that
we,
you
know
might
want
to
take
on
in
kubernetes.
So
I
think
we're
going
to
schedule
a
first
round
table
with
with
the
community
in
January
and
so
I'm
kind
of
going
around
to
all
the
sigs
to
gauge
interest
and
yeah.