►
From YouTube: Kubernetes SIG Storage - Bi-Weekly Meeting 2023-08-24
Description
Kubernetes Storage Special-Interest-Group (SIG) Bi-Weekly Meeting - 24 August 2023
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
Hello,
everyone
today
is
August
24th
2023.
This
is
the
kubernetes
logistic
meeting.
So
now
that
there's
1.28
is
released,
we
can
wrap
that
wrap
that
up
and
start
to
do
1.29
planning.
A
So
this
is
a
temporary
tentative
schedule
and
there
is
a
PR
out,
but
it's
not
merged
yet
so
looks
like
the
enhancement,
freezes,
October,
5th,
butt
code
phrases,
October
20th,
October
31st,
so
the
yes,
the
time
between
enhancement,
phrase
and
code
phrases
less
than
a
month.
A
Okay,
so
so
we
have
copied
1.28
sprushy
to
1.29
to
get
started.
A
So
if
there
are
anything
new
that
you
want
to
add,
you
want
to
tracked
for
1.29
and
targeting
even
1.29.
Please
add
it
so
I'm
just
going
to
go
through
this
one
and
see
what
needs
to
be
added
or
removed.
A
One
question
is
it's
the
same
spreadsheet
so
basically
we
just
added
this
one
new
sheet,
which
is
copied
from
1.8.
A
Right
so
this
is
the
same
okay,
so
the
first
one
is
recovery
from
resize
failure.
So
this
is
a
in
1.28.
This
is
okay
down
right
yeah.
Do
we
still
have
some
remaining
work
for
this
inside
car.
C
Those
that
those
are
done
merged
as
well,
so
we
are
just
waiting
for
the
release.
So
all
the
work
targeted
for
128
is
done
and
for
129
I
don't
know.
If
you're
are
we
just
doing
128
planning
then,
but
in
129
I
want
to
work
on
restoring
the
size
all
the
way
to
the
original
size.
That's
the
design
that
we
didn't
finish.
A
So
now
do
we
I
wonder
if
we
want
to?
Are
you
going
to
have
a
different
enhancement
issue?
It's
going
to
be
part
of
this
for.
D
C
We
could
not,
we
shouldn't
maybe
turn
it
beta
immediately.
So
right.
A
I'll
just
say
that
precisor
research
PR
merged
eating
for
release
because
like
are
released
and
then
the
other
one
is,
you
will
be
waiting
in
1.29
will
work
a
decrease
in
the
size.
A
D
D
E
Okay,
I
think
we
had.
We
had
locked
down
the
sheet
I
think
because.
B
E
Should
have
comment
access,
yeah,
but
I
think
before
it
was.
We
gave
everybody
in
the
Sig
edit
access.
E
E
F
Yeah
I
think
someone
accidentally
messed
up
the
spreadsheet,
so
we
locked
it
down.
So
if
there's
any
changes
you
want
to
make
just
put
a
comment
and
then
Shane,
Michelle,
myself
or
yawn
should
be
able
to
edit
it.
A
Okay,
awesome
so
other
than
I.
Think
this
one
okay
I
think
I
changed
this
one,
so
that
I
think
this
should
be
fine,
so
fast
API
how
to
say
API
chain
just
submerged
in
108
I'm
going
29.
A
Let's
just
say:
stay
in
Alpha,
okay,
so
the
next
one
we
crossed
out.
So
we
don't
talk
about
that
yeah
this
one
also
one
group
I,
think
it's
still
I
think
we
were
moving
to
another
status
yet
so
next
one
is
provision
voting
from
Cross
namespace
snapshot.
Pvc.
A
Do
we
does
this
stay
the
same
Michelle
or
we.
E
I
haven't
checked
the
latest
status
of
if
the
cap
for
the
reference
Grant
is
ready
to
review.
Okay.
A
Is
that
I
forgot
the
status
so
that
cap
was
not
merged
in
number
28
correct?
Okay,
the
reference.
E
Grant
was
still
under
discussion,
okay,
and
there
was
supposed
to
be
some
updates
to
the
cap,
but
I
don't
know,
I
haven't
checked
to
see
if
those
updates
were
made.
Yet,
okay.
A
All
right,
I'll
just
keep
it
design
then
so
next
one
is
the
see
if
the
wooden
house,
this
is
a
basically
at
the
E2
test.
I
think
still
I
need
to
pin
this
person
so
no
no
update.
Yet
someone
is
working
on
this
one,
but
I'm
not
sure
what
is
the
latest
status
on
this
pin
a
change
about.
B
A
Oh
so
party,
we
should
talk
about
this
one.
When
do
we
need
to
get
the
csis
back
released
for
because
we
last
time
we
talked
about,
we
want
to
wait,
see
if
we
can
get
this
money
in
before
we
cut
the
release
and
so
for
what,
if
I,
what
other
this
one
quality
of
service?
How
long
can
we
wait?
I
guess.
F
Could
we
discuss
this
at
last
Wednesday's
CSI
meeting
I
missed
that
one
we.
B
A
F
Let's
put
a
tentative
bullet
point
right
there
with
a
CSI
spec
date
right
above
the
code.
Freeze,
okay,
we
can
add
our
own
bullet
point.
Yes,.
H
A
So,
tentatively,
tentatively,
what
September
September
30,
something
like
that.
A
A
Okay,
yeah
so
Ben,
please
review
the
csis
back
and.
D
A
Also
cap,
okay,.
A
I
Yeah
I
will
probably
keep
it
in
beta
this
release
because
it
was
just
enabled
by
default
in
128.,
okay,.
D
D
D
A
D
I
A
So,
okay,
so
this
will
just
now
do
we
still
need
to
track
this?
Okay
I'll
leave
this
one
for
now
and
see,
but
but
then
this
should
probably
not
not
be
done
or
what
we
do
is
this.
A
A
D
Say
that
stay
keep
beta.
D
A
D
A
So,
okay,
so
next
one
is
done,
says
migration
for
GCE.
This
one
is
one
page
okay,
so
this
is.
This
is
for
future
1.31.30
and
this
one
is
yeah.
This
one
is
done
because
we
we
have
already
deprecated
it,
but
do
we
well
do
we
need
to
also
remove
it
I
guess
we
did
a
deprecation
right.
We
didn't.
A
131,
maybe
we
just
we
would
do
the
same
thing
say
like
like
this
one
right
so
remove.
Let's
say.
D
D
A
This
one
okay,
so
we
do
not
know
what
once
I
will
check
with
the
Grant
and
see
if,
if
they
have
any
plan
okay,
so
this
one
always
owner
reclaim
policy.
I
need
I
need
to
check
with
the
Deepak,
because
he
and
see
if
he
can
start
because
he's
going
to
look
at
the
details
and
see
if
he
can.
A
What
colors
so
we'll
add.
A
note
here
say.
A
A
D
A
A
A
I
A
Next
was
PV
last
phase
transition
time.
This
is
this
is
Alpha.
A
D
D
A
So
this
is
the
end
state
is
of.
A
A
A
Oh,
it
is,
do
you
know
if
the
cap
owner
will
do
a
design
or
I.
E
D
C
Yeah
I
am
here:
okay,
yeah,
there's
been
update
on
the
cape
I
will
have
to
check
if
updated
cap
looks
good
and
yeah.
Okay.
D
A
You
know,
are
we
stay
in
Design
This?
Look
this
quarter
or
do
we
want
to
talk
it
Alpha.
C
A
So
so
not
sure
yet
right
so
check.
Yeah
me
me.
D
A
E
Beta
yeah
I
can
check
with
Matt
if
he
thinks
it's
ready
to
go
to
ga.
Okay,
it's
been
beta
for
I,
think
two
releases
yeah.
E
You,
maybe
add,
you
can
add
it
back
here
and
we
can
I'll
try
to
check
with
that.
D
A
Add
it
here
so
next
one
not
graceful,
no
Shadow,
so
this
is
ga.
We
do
have
the
integration
test
that
we
want
to
get
merged.
So
maybe
I
will
just
change
this
one
to
the
test.
A
Okay,
that
one
merged
and
then
after
that's
March,
then
we
can
cross
it
out.
So
we
started
started,
and
this
is
so
just
oh
just
Chuck
this
as
a
bug
fix
now,
since.
D
A
So
I
think
that's
all
we
have
here.
Are
there
anything
else
so.
A
A
Here
you
add:
okay
yeah,
so
oh,
oh
this
one,
okay,
yeah.
A
Okay,
I
can
copy
it.
I
would
just
I
just
found
it's
a
little
weird.
B
So
so
sorry
I
can
describe
it
so
so
back
in
the
earlier
days
of
kubernetes,
before
we
had
the
non-graceful
another
shutdown
feature.
If
you
had
a
node
that
shut
down
on
gracefully,
you
could
have
PVCs
that
got
stuck
there
if
the
node
never
came
back.
So
we
added
this
six
minute
timer
that
would
force
detach
your
your
pods
after
six
minutes
to
deal
with
that
situation,
but
that
feature
was
always
a
violation
of
the
CSI
spec
and
it
was
just
sort
of
a
workaround
to
a
gross
situation.
B
B
B
G
So
I
remember:
we
have
some
metrics
related
to
this.
We.
A
Do
have
yeah,
so
it's
one
that
is
tracking
the
the
timeout
related
to
post
detached
the
other
one
for
the.
If
you
add
a
taint
right
tainted
related
the
first
detached,
but
that
is
I
think
that
differentiation
was
just
added
in
1.28
before
that
there
is
also
a
matrix.
That's
just
just
chucking.
The
I
think
Donnie
checking
the
the
timeout
when
I
believe.
A
Okay
yeah,
so
it
is
there.
So
if
we
disable
this
option,
then
that
will
not
happen
anymore,
so
that
metric
will
just
be
no
longer
be
used
right
for
that.
B
E
But
then
we
enhance
the
metric
also
wish
if
it
Force
detach
the
reason
why
it
Force
detached
yes,.
D
B
Yeah
I
mean
my
thinking
is
the
the
six
minute
was
sort
of
a
blunt
instrument
to
you
know
before
we
had
a
mechanism
to
do
it
quickly
and
now
that
we
have
it,
we
would
want
to
encourage
people
to
use
the
new
mechanism.
B
Obviously
changing
the
default
Behavior
in
the
future
would
require
a
release
note.
But
but
this
is
just
a
an
option
to
you
know:
allow
someone
to
disable
it
yeah.
B
Problems
in
some
of
our
installations,
that's
the
that's
the
reason
for
this
like
it
when
it
when
it
triggers
it
causes.
You
know,
kubernetes
to
violate
the
CSI
spec
and
some
CSI
drivers
don't
behave
well
when
you
violate
the
CSI
spec,
and
so
we
would.
We
would
prefer
to
have
a
knob
to
turn
this
off.
A
And
then
one
point
Thirty:
what
default
you
say
what?
What
was
that
we.
B
C
B
A
G
Yeah
I'm
wondering
like,
since
we
have
the
metrics.
How
often
we
see
this
whether
we
it'll
have
a
sense
about
frequency
and
the
human
situation.
It
happened,
but
yeah.
We
can
like
check
that
later.
Yeah.
A
B
Yeah
I'm
betting,
that
in
a
lot
of
clusters,
both
metrics
would
be
zero
but
then,
depending
on
how
how
people
are
managing
their
clusters,
they
might
have
one
or
the
other
triggering
quite
often,
and
also.
E
The
Army
for
before
yawns
fix
to
only
Force
detach
on
unhealthy
nodes.
The
force
detach
actually
happened
quite
a
lot.
E
E
Force
the
attach
happens
also,
if
just
like
unmount
is
slow.
It
used
to
be
that
Force
detach
would
happen
if
unmount
is
slow,
and
it
also
happened
because
there
were
some
bugs
in
cubelet,
like
cubelet
reported
pods
as
failed
too
early
for
jobs,
and
that
caused
us
to
force
detach,
and
there
were
some
other
a
couple
of
other
reasons
why
Force
detached
happened,
yeah,
but
once
John's
fix,
went
in
I
think
we
that
solved
a
lot
of
those
issues.
D
A
A
All
right
so
coming
back
to
the
agenda
doc,
we
have
an
item
here.
Do
we
have
a
realm
here.
H
Yes,
we
had,
we
created
a
ETV
test
with
the
idea
to
promote
it,
conformance
once
it's
proven
stable.
Thank
you
very
much
to
everybody
who
has
reviewed
it.
We
haven't
had
any
other
comments
or
reviews
that
it
needs
more
work,
so
we
believe
it's
good
to
merge.
So
if
somebody
can
just
give
us
a
approve
there,
I
really
appreciate
that
or
if
more
review
is
needed,
give
us
there.
If
you
want
to
get
it
on
the
test
grip
as
soon
as
possible.
H
D
A
J
D
J
Okay,
I'll
start,
so
this
presentation
is
about
a
proposal
to
combine
all
of
the
CSI
sidecars
industrial
single
component.
J
There
are
some
terms
that
most
of
the
people
in
the
meeting
are
familiar
with,
but
because
this
is
a
requirement
and
I'll
just
explain.
A
few
of
these
terms
like
KK
is
kubernetes.
There
is
the
coordinate
CSI
or
in
GitHub
kubernetes
6
or
here
in
GitHub,
with
CSI
CSI
sidecar,
which
is
another
three
controller,
that
watches
objects
in
the
API
server
and
perform
some
action,
and
we
have
CSI
drivers
which
interact
with
these
sidecars.
J
The
sidecars
make
calls
to
circuit
and
the
CSI
drivers
implement
the
methods
defined
in
the
CSI
spec
and
react
to
those
calls.
Then
I
may
also
talk
about
CP,
which
stands
for
control,
plane
and
MP,
which
is
node
pool.
The
agenda
is
first
I'll
talk
about
what
led
to
to
this
proposal.
J
J
I
also
wanted
to
talk
about
responsibilities
of
each
actuary
in
this
system.
There
is
the
community
which
we
are
part
of
I
listed
some
of
the
responsibilities
that
are
part
of
six
storage
and
kubernetes
CSI,
because
this
this
proposal
is
about
CSI
I'll
just
highlights
those
the
CSI,
the
current
CSI
maintainers
own,
the
CSI
spec,
the
sidecars.
J
The
way
we
test
the
sidecars
against
kubernetes
and
a
lot
of
ripples
inside
the
kubernetes
CSI
org,
there
is
also
the
CSI
driver
Ultra,
which
has
a
driver
and
needs
to
integrate
it
with
sidecars
so
that
they
resource
solution
can
work
with
kubernetes
and
they
need
to
keep
up
with
releases
of
sidecars
of
CSI
2
and
of
kubernetes,
for
example.
There
is
this
new
feature
called
volume
group
snapshot,
which
is
a
change
in
the
external
snapshoter
component.
J
Sidecar,
they
may
also
provide
default
versions
of
the
sidecars
and
on
CSI
drivers
in
in
in
manifests.
This
usually
happens
if
they
have,
if
the
the
source
code
of
the
CSI
driver
is
published
Upstream
and
they
also
create
releases
as
they
see
the
release.
Guidance
is
different
to
kubernetes,
it's
not
tight,
so
they
may
release
it
faster
or
slower,
and
finally,
they
recommend
configuration
of
cycers
and
their
CSI
driver
for
the
control
plane
on
Notebook.
J
So
it
might
be
possible
that
a
CSI
driver
is
about
support
the
feature,
and
that
feature
mean
meant
could
mean
a
breaking
change
like
in
volume
snapshot
which
went
from
B6
from
before
to
B6,
and
there
were
new
changes
in
the
new
fields
in
the
crd,
so
the
class
administrator
needs
to
plan
beforehand
to
make
that
available
and
well.
This
is
what
happens
at
Google.
We
also.
We
also
because
we
are
classroom
administrators.
We
provide
a
managed
service.
J
We
coordinate
with
other
platform
teams
on
the
testing
of
the
integration
to
ensure
that
it
works
fine
across
tests
that
are
not
covered
Upstream
like
upgrade
tests.
Let's
say
that
we
have
workloads
running
in
a
cluster
and
we
upgrade
the
cluster.
Then
it
might
be
possible
that
the
nodes
get
recreated.
So
we
hope
that
the
CSI
driver
might
move
the
workloads
from
a
node.
That's
been
turned
down
to
or
turned
down
to
a
healthy
node.
J
Okay,
so
I'll
briefly
talk
about
how
we
build
components
so
on
the
left,
we
have
I
just
pasted
two
repos
liveness
Pro,
but
no
driver
register
which
are
sidecars
and
we
have
two
main
utility
libraries.
There
is
CSI
release
tools
which
cast
all
of
the
code
to
build
this.
These
projects,
it
builds
the
binary.
It
also
builds
a
multi-arc
image
and
it
also
has
lots
of
code
to
test
it
against
the
test.
Csi
driver,
which
is
the
hostpat
CSI
driver,
and
we
also
have
additional
go
modules.
J
Different
for
for
CSI
release
tools
and
the
go
modes
CSI
release
tools
is
just
a
collection
of
scripts.
So
it's
not
really
a
go
mode
and
that's
why
it's
included
in
the
color
bases
as
a
kit
sub
3.,
it's
a
trip
and
CSI
Liberties
is
a
go
module,
so
it's
a
dependency
in
go
mode.
J
J
The
same
vulnerability
may
be
applicable
to
the
driver
too,
so
the
driver
might
need
to
update
to
to
the
same
thing,
update
the
dependency.
But
if,
if
the
boomerability
happened
on
a
sidecar,
then
the
the
outer
usually
waits
for
a
stable
release
of
the
Sidecar.
J
So
for
the
from
the
driver
point
for
the
driver
Ultra,
they
just
need
to
wait
for
the
second.
If
there
are
CV
fixes
for
the
cluster
administrator,
this
usually
depends
too
so
Google.
We
have
automated
pipelines
that
build
the
sidecars
and
whenever
there
is
a
change
upstream-
and
we
do
this-
because
we
also
have
to
make
changes
that
are
beyond
what
happens-
Upstream
like
patching
the
code
version,
for
example,
to
to
a
newer
or
update
integral
runtime
to
a
newer
version.
If
there
is
a
vulnerability
in
gold.
J
One
question
is:
if
we
have
this
fix
that
happen
in
master,
what
happened
in
previous
releases
I
think
this
is
handling
our
best
of
four
places.
So
if
we
need
to
backboard
it
that
that's
that
may
be
done
by
by
the
maintainers,
but
as
I
mentioned
it's
a
best
of
basis
and
at
Google
we
do
this
manually
internally.
J
J
For
the
driver
Ultra,
they
may
need
to
rebuild
their
driver
if
there
is
a
go.
Runtime
update
and
nothing
related
with
release
tools.
C
J
They
are
using
it
in
their
in
their
driver
and
in
for
the
Clusters
administrator
they
may
need
to
rebuild
the
the
sidecars,
let's
say
bump,
let's
bump
in
the
Quran
time
internally
and
rebuild
the
cycles,
and
we
also
have
the
same
question.
The
fix
happen
in
master
and
what
happens
in
previous
releases
I
think
it's
also
handled
on
a
best
of
four
basis,
as
usually
the
last
three
releases
are
maintained.
This
is
also
a
gray
area
because
for
let's
say,
volume
snapshot
which
went
from
B4
to
B6.
J
There
is
also
there
may
be
also
changes
in
CSI
libutils,
so
this
is
a
go
mode,
and
that
means
that
someone
makes
if
someone
makes
a
change
in
that
in
that
project.
Maybe
all
of
the
sidecars
need
to
pull
it
using
the
the
latest
kitsha
percentage,
the
driver
Ultra.
If
they
are
not
using
libutils,
and
they
don't
do
they
don't
need
to
do
anything
and
similarly
the
cluster
administrator.
They
just
need
to
rebuild
it,
but
that
usually
happens
automatically
because
of
that
dependency
update
on
go
mode
on
the
cycles
and
we
still
have
the
same.
J
So
I
also
tried
to
collect
a
few
stats
about
pull
requests
that
were
created
against
all
of
our
Cycles.
We
have
a
column
for
updates
from
dependablet
manual
propagation
of
CSI
release
tools.
This
means
creating
a
pull
request
and
assigning
it
to
someone
in
the
community
that
can
review
it
and
same
thing
for
CSI
Libya
tools
and.
J
Something
that
I
mentioned
that
I
didn't
mention
is
the
cascading
problem,
which
happens
if
let's
say
that
there
are
many
cycles
and
all
of
them
have
at
dependency,
that's
vulnerable.
So
that
means
that
there
will
be
a
pull
request
created
against
all
of
the
cycles,
and
this
effort
needs
to
be
multiplied
times.
The
number
of
releases
that
the
community
supports.
J
J
J
So
because
this
is
sort
of
a
sort
of
a
gray
area,
the
classroom
administrator
may
need
to
back
Port
the
fixes
to
previews
cycle
releases,
and
this
can
happen
all
the
way
down
until
the
last
release.
That's
currently
supported,
I
also
have
to
mention
here
that
cornetis
is
going
on
a
n
minus
3
Model
pretty
soon,
so
this
might
mean
that
we
might
need
to
increase
our
maintenance
window
for
components.
J
One
approach
that
I
think
that
could
that
that
thing
helped
Define
that
I
think
some
more
teams
were
using
was
to
reuse
the
same
sidecars
in
previous
releases.
J
J
J
J
Maybe
I
should
read
it
so
before
CSI
we
had
the
concept
of
external
provisioner.
We
have
provisioners
for
cluster,
safe,
NFS,
local
search
and
all
lived
in
the
same
repo.
What
happened
is
that
the
use
cases
and
controllers
in
the
depth
being
independent
from
each
other
and
people
will
deploy
only
a
few
and
not
dealers.
We
decided
to
split
them
in
their
own
repo,
so
that
each
project
would
have
its
own
really
cycle
and
maintainers
and
for
CSI
cars
it
facilitated
fast
development
and
it
operated
like
a
microservice.
J
We
would
have
a
mono
repo
that
has
all
of
the
code
of
the
Cycles.
We
will
also
expose
a
binary,
a
single
entry
point.
This
will
be
a
new
new
file.
That
is
a
lot
like
Cube
controller
manager,
where
we
would
selectively
decide
which
sidecars
to
start
and
for
the
other
problems
about
CSI
release,
Stills
and
CSI
libutils.
We
can
include
them
in
the
Ripple,
so
CSI
release
tools
would
be
also
part
of
the
repo
and
it
will
be
the
source
of
Truth
for
other
consumers
of
the
repo
too.
J
J
There
is
one
problem
here,
which
is:
if
we
move
all
of
the
code
to
be
internal,
how
do
we
keep
all
of
the
people
that
are
using
CSI
release
tools
and
CSI
libutils
in
the
same
state?
We
don't
want
to
break
their
stuff
right,
so
we
can
follow
a
similar
strategy
to
what
coordinate
is
the
switch?
Is
they
which
is
a
day,
publish
the
staging
folders
to
ripples,
and
this
is
done
through
one
project
called
kubernetes
publishing
both.
J
J
For
the
control
plane,
it
would
be
just
one
image
with
different
flux.
There
would
be
a
controller
slack
similar
to
keep
control
manager,
which
would
decide
which
sidecars
to
enable
there
would
be
Global
facts
like
leader
election.
There
is
also
a
new
feature
like
structural
login.
All
of
that
would
be
common
for
all
of
the
Cycles,
because
there
is
a
single
entry
point
and
there
would
also
be
flags
that
need
to
be
customized
per
sidecar,
so
maybe
we
could
add
prefixes.
J
So
if,
let's
say
a
sidecar
defines
a
timeout
which
is
different
to
our
to
the
timeouts
of
other
Cycles,
maybe
that
could
be
like
a
touch
or
Timeout,
on
provisional
timeout
and
so
on
and
for
the
notebook
it
will
be
very
similar.
We
would
add
controllers
no
driver
register
and
liveness
Pro.
J
The
first
point
is:
if
we
try
to
make
changes
in
CSI
release
tools,
how
many
pull
requests?
Would
that
mean
and
that's
the
number
of
CSI
released
to
changes
times
the
number
of
Cycles
in
the
new
model?
If
it's
a
mono
Ripple,
it
becomes
zero
because
sidecar
or
CSI
release
tools
is
part
of
the
Ripple
and
it's
Global
changes
apply
immediately
for
CSI
Liberties.
It's
the
same
thing
for
go
more
dependency
bumps.
J
D
A
J
D
A
A
So
please
review
this
and
we'll
come
back
and
talk
about
this
again.