►
From YouTube: Kubernetes SIG Storage Meeting 2023-09-07
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Workgroup for Container-Storage-Interface (CSI) Implementation - 07 September 2023
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.o13ve033n8my
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
September
7
2023.
This
is
the
meeting
of
the
kubernetes
storage
special
interest
group.
As
a
reminder,
this
meeting
is
public
recorded
and
posted
on
YouTube
on
the
agenda.
Today
we're
going
to
go
over
the
items
that
six
storage
is
committed
to
for
the
129
release.
A
We
have
previously
completed
the
128
cycle
and
if
you
have
anything
that
you
want
to
discuss,
please
feel
free
to
add
to
the
agenda.
The
link
is
in
the
calendar,
invite
we
already
have
a
couple
of
PRS
that
need
attention,
as
well
as
a
design
with
that
I'm
going
to
go
ahead
and
switch
over
to
the
planning
spreadsheet
to
see
if
we
can
get
some
status
updates
for
the
129
items.
A
First
up
we
have
recovery
from
resize
failure
which
in
129
stays
in
Alpha.
Api
changes
were
emerged
in
128
and
we
want
to
add
support
for
qos.
B
A
Next,
we'll
switch
over
to
provision
volumes
from
Cross
namespace
snapshot
PVC
this
continuing
design
for
this
cycle
volume
populator,
is
work
in
progress.
Any
updates
on
this
one.
A
That
is
blocked.
Next
item
is
CSI
volume,
Health
additional
metrics.
C
A
C
C
So
we
talked
about
that.
We
attentively.
We
want
to
cut
the
release
by
September
30th
right
for
the
CSS
back
release
right,
but
Ben
do
you?
Do
you
have
any
update
on
this.
D
I,
it's
on
my
computer,
be
reviewed
and
I
should
get
to
it
soon,
but
I
haven't
I,
haven't
actually
done
the
review
yet.
A
A
B
A
A
Okay,
let's
keep
moving,
we've
got
CSI
migration
stuff,
so
remove
entry,
vsphere
I
guess
this
is
for
130.
So
let's
skip
over
these
and
these
two
are
for
131..
C
All
right,
so
we
are
20
move
to
Beta
in
this
release
and
Deepak
is
working
on
the
E3
tests
and
he's
going
to
update
the
cap.
Surely.
A
Awesome.
Thank
you.
Shane
next
is
a
quality
of
service
for
volumes.
Moving
to
Alpha
from
design
phase.
Do
we
have
sunny
on
the
call
or
anybody
with
an
update.
A
Got
it
so
I
heard
apis
ready
for
review
and
demo
is
ready
as
well.
B
E
A
Awesome,
thank
you.
Michelle
next
are
the
set
of
items
that
are
co-owned
by
multiple
six.
This
one
is
co-owned
between
six
storage
and
Sig
apps
volume.
Expansion
for
stateful
sets
any
updates
on
this
one
from
anyone.
A
Okay,
hopefully
we'll
get
an
update
on
this
when
a
month
is
able
to
attend
we're
gonna
move
over
to
the
next
one.
This
one's
co-owned
with
signal,
non-graceful,
node
shutdown
tests.
A
A
Well,
thank
you
Shane.
Next,
we
have
Auto
delete
PVCs
with
stateful
set.
It
looks
like
this
is
new
I
think
we
have
this
in
any
previous.
C
E
Yeah
I
have
not
had
a
chance
to
do
that,
but
I'll
work
on
that.
A
And
this
is,
was
beta
or
is
moving
to
Beta.
C
C
A
A
And
who's
the
primary
Dev
lead
here.
C
A
C
A
Cool
and
API
reviewer
normal
reviewer.
A
Okay,
we'll
start
tracking
this
one
I'll
put
a
new
update
for
now,
and
we
had
one
more
item
added
here,
which
is
ADD
option
to
disable
six
minute.
Force
detached
timer
I'll
put
the
description.
A
A
D
D
A
D
A
Makes
a
lot
of
sense,
so
I
guess
question
is:
does
this
PR
require
a
cap
or
is
it
going
in
as
effectively
a
bug
fix
we're
considering
it
a
bug
fix
a
fix?
Okay,.
D
A
Makes
sense
so
for
this
cycle
we'll
call
it
a
bug
fix
and
then,
when
we
come
back
to
try
to
do
a
deprecation,
we
will
need
to
do
we'll
need
to
go
and
do
proper
cap,
for
it
do.
A
I
think
we'll
need
to
talk
to
folks,
like
Jordan
Segar
folks,
to
make
sure
I
think,
generally
speaking,
when
you
have
a
change
of
Behavior,
especially
when
there's
like
a
deprecation
or
something
there
might
be
a
kept
requirement,
I'm
not
certain.
So
we
should
follow.
D
We
would
definitely
want
release
nodes
and
to
follow
the
the
proper
deprecation
procedure.
Right.
I
have
to
think
that
there
have
been
other
things
that
have
been
deprecated
without
caps,
but
but
if
that's
the
the
current
stance
that
we
need
it,
then
we
would
do
that
next
release,
I,
guess,
yeah
I,.
E
Think
in
in
terms
of
say,
like
we
recently
deprecated
like
the
Seth
plugins
I,
think
those
did
not
go
through
a
cap.
It
was
just
an
issue
where
we
were
discussing.
A
E
A
Okay,
so
that
may
be
the
case,
so
hopefully
we
can
keep
it
low
low
cost
here
as
well.
A
So
PR
adding
knob
is
ready
and
who,
who
created
the
pr?
That's.
D
A
That
was
robit,
perfect
and
who's
helping
review
this
one.
D
I
intend
to
review
it,
but
I
haven't
done
that's
another
one
on
my
list
of
reviews
got
it
I,
don't
know
who
else
is
already
taking
a
look
at
it.
A
Okay,
anybody
else
interested
in
reviewing.
D
A
So
first
item
is
from
rain
PR's
to
discuss.
Do
we
have
do
we
have
them
on
the
call.
B
A
B
On
the
call,
I
can
go
ahead
all
right
last
meeting.
Thank
you
very
much.
We
brought
a
PR
for
review
and
approved
it's
merged.
It's
around
flight
three
for
the
two
weeks
that's
required,
except
there
was,
if
like
that,
is
linked
to.
If
you
look
at
the
the
hyperlink
that
I've
got
in
there,
it's
a
known,
flake
related
in
an
API
Machinery
test.
B
So
the
flag
is
not
related
to
the
storage
space.
We
thoroughly
checked
it
and
it
only
reflected
once
in
the
first
24
hours
after
that
it
ran
perfectly
smooth.
So
we
will
promote
that
test
Monday
morning,
New
Zealand
time,
so
your
your
Sunday
and
then
we'll
also
take
the
same
information
in
another
hour
with
360
architecture.
To
discuss
there
as
well
so
they'll
also
be
aware,
then
we're
making
good
progress.
B
We
brought
another
PR
yesterday
for
another
e2e
test,
with
the
idea
to
promote
it
to
conformance
once
we've
got
the
two
weeks
flag.
Free
already
got
our
LG
TM,
so
we'll
appreciate.
If
we
can
get
a
and
approve
on
that
as
soon
as
we
can
get
the
the
senior
people
of
the
sector
review
it
for
us
and
that
will
kill
another
seven
endpoints
of
technical
there.
A
Awesome,
thank
you
so
much
and
yeah.
We
will
take
a
look
at
these
folks
on
the
call
who
have
approval
permissions.
Please
I'll
take
a
look
at
that
PR.
B
E
B
A
Okay,
we
got
pinged
offline
by
gnome
to
help
review
this
CL.
It
is
in
the
external
provisioner
Library
and
it
is
addressing
this
issue.
A
So
please
help
take
a
look
at
this
PR
as
well.
So
we've
got
a
couple
of
PRS
that
need
attention
today.
A
All
right
with
that
I
will
switch
it
over
to
design
reviews
and
hand
it
off
to
Mauricio.
We
didn't
have
enough
time
last
cycle
last
meeting
to
discuss
this
so
Mauricio
I'll
stop
sharing
and
I'll.
Let
you
drive.
F
So
in
the
in
the
middle
notes,
I
posted
a
link
to
this
presentation
and
a
couple
of
weeks
ago
we
already
talked
about
the
background
of
this
proposal.
So
I'll
continue
from
that
point
and
just
talk
about
the
proposal.
So
just
as
a
summary
of
what
I
discussed
last
the
last
meeting
with
our
current
model
with
CSI
sidecars
in
many
repos,
we
have
a
few
problems
like
changes
in
codependencies
which
Cascade
to
many
repos.
F
F
There
is
also
some
confusion
about
what
versions
of
Cycles
to
use
on
their
deployments.
This
is
usually
a
task
done
by
cluster
administrators
and
one
problem
that
I
didn't
explain.
F
F
So
in
the
diagram
we
have
on
the
left,
the
current
state
on
the
right,
the
proposed
state-
and
we
have
at
least
six
six
sidecars-
that
we
regularly
use
those
or
attach
a
provision
or
snapshot
resizer
liveness
probe,
no
direct
registered.
We
also
have
additional
controllers,
like
health
monitor.
There
is
also
another
controller
in
snapshooter.
F
F
We
also
have
live
external
provisioner,
which
has
utilities
and
that's
a
dependency
of
provisioner,
and
we
also
have
this
Library
called
CSI
Libya
tools,
which
has
lots
of
utility
code
for
all
of
the
sidecars
to
do
the
connection
with
the
socket.
So
the
idea
is
to
move
all
of
the
code
of
this
components
into
a
mono
Ripple.
The
code
would
be
under
a
ripple,
let's
say
in
the
folder
PKG,
and
then
we
will
also
move
release
tools
to
be
part
of
this
repo.
F
F
So,
to
avoid
all
of
this
or
third-party
consumers
from
importing
the
entire
kubernetes
called
the
base,
they
set
up
infrastructure
to
push
these
directories
in
stationed
to
their
own
ripples
in
the
kubernetes
GitHub
work.
So
I
think
we
could
do
something
like
that
too,
and
that's
this
orange
arrow,
so
we
would
need
to
set
up
something
with
kubernetes
something
related
with
cornetti's
publishing
both
to
push
these
changes
from
Master
automatically.
That
was
was
there
any
question.
D
F
The
problem
with
CSI
Liberty
is
that
it's
a
dependency
of
all
of
the
sci
cars
and
whenever
there
is
a
change
in
CSI
little
deals,
it
needs
to
be
propagated
to
all
of
the
sidecars
too.
So.
F
I
think
that
score
here,
maybe
Michelle,
has
more
more
background
about
why
that
library
was
created
and
why
it
is
in
kubernetes.
Six
I
was
not
sure
when
I
created
these
slides.
If
this
Library
would
be
part
of
of
the
repo,
given
that
it's
only
used
in
this
stack
by
provisioner
I
know
there
are
other
third-party
consumers.
Yes,.
E
So
at
least
back
in
the
day
before
CSI
right,
we
did
have
this
other
thing
with
external
provisioners
that
use
this
library,
and
so,
when
we
initially
created
this
Library
like
we
decided
to
put
it
outside
of
CSI,
because
it
was
being
used
by
non-csi,
external
provisioners,
but
I
think
now
that
we
have
go
modules,
I
think
it's
possible
to
put
it
all
into
a
single
repo.
But
we
could,
potentially,
you
know,
release
a
separate
go
module
for
it
to
still
support
those
older
use
cases.
E
D
Okay,
okay,
so
so
my
other
question
then,
is
assuming
we
do
this.
How
do
we
handle
new
Alpha
sidecars?
If
we've
already
started
talking,
you
know
about
doing
a
backup
or
not
a
backup?
Sorry,
a
change
block
tracking
sidecar
to
enabled
backup
applications
so
like,
assuming
that
this
work
had
already
been
done.
Would
a
new
sidecar
like
just
be
added
to
the
mono
repo,
or
would
it
still
be
a
separate
thing
that
would
go
through
Alpha,
Beta
GA
before
getting
absorbed
into
this
into
this
monorepo.
F
So
Michelle
had
some
ideas
in
this
area.
One
of
those
ideas
was
to
include
it
as
part
of
the
Ripple
and
control
its
deployment
through
feature
Gates.
F
F
Have
to
reinvent
the
wheel
to
let's
say
what
we
currently
do
for
CSI
release
tools
is
we
we
import
it
as
a
GitHub
module
that
would
no
longer
be
done
also
for
the
classroom
administrator
that
that
would
be
easier
to
just
pull
that
Alpha
feature,
because
it's
part
of
the
monoree
already
in
some
release
instead
well
right
now,
what
what
we
would
need
to
do
to
have
a
an
alpha
feature
is.
We
would
first
need
to
set
up
all
of
this
pipeline
to
build
the
component
internally
before
we
can
start
using
it.
C
D
D
A
sidecar
and
and
I'm
trying
to
figure
out
like
if,
if
we
have
experimental
stuff
where
it
you
know
we're
just
we
want
to
try
out
a
new
idea,
it
might
fly,
it
might
not
fly.
Is
there
a
downside
to
putting
it
into
this
repo
and
then,
like
maybe
later
deciding
it,
was
a
bad
experiment
and
having
to
get
rid
of
it
like?
Will
we
where
we
create
new
Problems
by
having
all
the
code
in
one
place
and
having
a
single
release
process?
That's
not
flexible!
That!
That's
that's!
That's!
D
My
worry
is
how
do
you
do
experiments
that
might
fail
in
a
in
a
mono
repo
setting
like
this
feature,
Gates
seem
like
a
reasonable
idea
like
but
I'm
yeah
I.
Remember
when
we
added
a
snapshotter,
we
put
all
of
the
API
objects
in
the
snapshotter
repo,
and
that
resulted
in
the
need
to
like
bump
the
major
version
of
the
repo
like
five
times
so
I
think
the
most
recent
version
of
external
snapshot
was
like
six
point
something
right,
I'm
worried
about.
How
do
we
handle
versioning
for
like
new
stuff
that
needs
to
go
through?
D
F
Yeah,
that's
that's
true.
That's
actually
something
that
I
I
haven't
talked
a
lot
about.
Michelle
brought
some
ideas.
Initially,
I
thought
that
this
morning,
repo
would
only
hold
projects
that
have
reached
beta
status,
but
she
suggested
that
maybe
we
could
reuse
the
same
infra
for
new
new
projects.
F
C
D
D
And
the
strategy
in
upstream
kubernetes
was
to
say
for
experimental
stuff
like
we
don't
want
it
right,
do
your
experimental
stuff
in
another
repo
and
then
only
bring
it
into
kubernetes
after
you've
proven
that
it's
a
real
thing
and
that
people
want
it
and
that
it
works
so
on
and
so
on.
So
my
worry
here
is
the
same
right.
D
If
someone
wants
to
do
something
experimental
that
may
or
may
not
work
out,
there's
going
to
be
an
incentive
to
like
not
integrate
it
into
the
repo
because
of
the
churn
that
it
will
cause
and
and
the
headache
that
it
will.
You
know
the
the
impact
on
everyone
who
actually
uses
these
sidecars
having
having
experimental
code
go
in
and
then
maybe
get
ripped
out.
You
know
we'll
be
people
won't
want
that
to
happen
on
their
production
sidecars,
so
it
it
creates
another
incentive,
then
to
like
push
experimental
stuff
somewhere
else.
E
Everything
I
I
would
prefer.
We
go
all
in
on
one
model
instead
of
having
to
support
like
two
different
models,
because
it
will
simplify
our
tooling
right.
We
don't
have
to
maintain
two
different
kinds
of
processes
depending
on
if
something
is
experimental
or
not,
and
then
so
I
I
just
feel
like
from
like
a
maintenance
standpoint,
it's
a
lot
easier.
If
we
just
have
a
single
model
that
we
can
support.
D
D
So
you're
talking
about
like
three
years
from
now
when
everything
has
been
deprecated
and
yes
and
and
it's
all
and
everyone's
on
the
new
model,
and
then
there's
only
one
way
to
do
things:
okay,
yeah,
because
I
I
think
it's
inevitable
that
there'll
be
some
multi-year
period.
Where
we'll
be
doing
both
things
and
continuing
to
support
the
old
way
for
for
all
of
the
existing
deployed.
Csi
drivers.
F
Thank
you.
Thank
you
all
right,
so,
going
into
more
details
about
the
Ripple.
Well,
I
think
that
right
now
we're
also
in
a
good
time
to
make
this
switch.
Probably
before
it
was
not.
We
didn't
have
enough
to
lean
to
this,
but
now
with
go
workspaces
we
can.
F
We
can
link
csially
Beauties
to
all
of
the
sidecars
through
go
workplaces
and
also
make
CSI
blue
utils
available
to
third
party
consumers
by
using
the
kubernetes
publishing
board.
Infra
I
I
think
there
is
a
lot
of
work
there
to
set
that
up,
because
that
repo
was
made
with
the
intention
to
work
with
kubernetes.
So
if
we
want
to
reuse
the
infra,
we
need
to
understand
how
that
works
and
apply
it
to
our
repo.
F
So
also
part
of
this
modern
repo
is
that
we
would
have
a
new
entry
point.
It
would
be
a
new
go
file
that
is
very
similar
to
cube
controller
manager
and
Q
control
manager
enables
some
controllers
it
bundles
through
the
controllers
flag.
So
we
can
do
something
like
that,
and
this
is
how
the
deployment
looks
now
and
how
it
could
look
like.
So
in
the
current
state
we
have
the
CSI
driver
in
both
control
plan,
work
node
in
the
control
plane.
F
F
There
would
also
be
some
variables
that
affect
properties
of
all
of
the
Cycles
like
a
global
timeout,
and
it's
possible
that
each
sidecar
has
its
own
needs
for
for
a
timeout,
for
example.
So
we
could
have
the
same
variable
prefixed
with
the
name
of
the
sidecar,
so
that
it
only
affects
that
Sidecar
and
in
the
notebook
it
will
be
very
similar.
We
only
deploy
a
couple
of
components:
we
have
no
driver
register
and
liveness
probe,
so
yeah,
that's
how
it
will
look
like
as
part
of
the
design.
F
F
Don't
do
other
ripples,
similarly
to
CSI.
Similarly,
in
CSL
Vehicles
we
no
longer
have
to
make
PR's
tool
repos
for
go
mode
dependency.
Bumps,
for
example,
let's
say
there
is
a
go
dependency
that
created
a
new
release,
fixing
a
vulnerability
that
would
mean
that
it
needs
to
be
propagated
across
all
of
the
sidecars,
but
not
only
the
latest
version
of
the
sidecar,
because
it
could
be
possible
that
previous
versions
of
the
Sidecar
are
still
using
that
library
with
a
vulnerability.
So
it
needs
to
be
backboarded.
F
So
the
the
total
number
is
number
of
dependencies
changes
times
number
of
CSI
releases
supported
and
so
current
time
update.
I
think
this
is
I
talk
about
this
in
CSI
release
tools,
something
similar
and
also
one
one
number
in
that's
important-
is
the
number
of
releases
that
we
will
have
so
right.
Now
we
release
we
make
one
release
per
cycle,
but
if
it's
a
mono
repo,
then
we
just
have
one
release
for
the
entire
one
repo.
F
There
are
also
a
lot
of
Pros
in
this
approach.
I
linked
I
I
added
a
link
to
a
presentation
done
by
the
person
that
did
the
staging
the
staging
working
kubernetes.
F
There
have
been
lots
of
benefits
of
having
just
mono
ripples.
We
have
issue
releases.
We
no
longer
need
to
worry
about
having
many
many
components
each
having
its
own
really
cycle
easier,
testing
two.
This
means
that
let's
say
that
there
is
a
feature
that
affects
two
cycles.
At
the
same
time
that
thing
could
be
tested
at
once.
We
no
longer
need
to
create
one
test
for
let's
say,
let's
say
that
a
sidecar
moves
ahead
first
and
then
do
some
testing
and
wait
for
the
other
sidecar
to
keep
up
before
doing
more
testing.
F
Then
there
are
Global
changes.
This
is
like
CSI
release
tools
and
CSI
libutils
no
need
to
propagate
them.
To
all
of
the
sidecars.
Is
your
integration
or
sidecars?
This
is
about
the
deployment
manifest
and
how
it
would
look
like
this.
Pro
is
assuming
that
we
would
have
a
release
model
aligned
with
kubernetes,
and
there
are
other
other
Pros
to
related
with
the
code
itself.
F
There
is
also,
as
we
saw,
consolidation
of
parameters
that
are
common
across
all
of
the
Cycles,
like
literal
election
and
structural
login,
and
there
is
this
other
this
this
last
one
which
is
related
with
the
alpha
feature.
So
if
an
alpha
feature
is
part
of
the
repo,
then
it
would
be
built
as
part
of
it.
So
that
means
that
the
cluster
administrator
could
start
using
it
without
setting
up
pipelines
to
build
a
project
first,
so
there
are
all
always
going
to
be
cons.
F
F
F
Then
there
was
also
the
corn
of
expressing
per
sidecar
configurations
and
I
I
added
an
idea
of
how
we
could
do
this
with
prefixes,
and
there
are
a
lot
of
things
around
defining
how
development
would
would
look
like
in
this
new
repo,
like
Alpha
features
or
other
components
like
CSI
test,
which
is
not
part
of
this
proposal.
So
that's
a
problem:
how
we
do.
How
do
we
Define
when
a
component
is
part
of
the
report.
F
Oh
and
let's
say
that
we
have
this
one
report:
if
a
subcontroller
dies
in
the
entire
would,
would
that
mean
that
the
entire
project,
the
entire
binary,
just
dies,
or
do
we
Define
that
boundary
where
an
error
needs
to
be
propagated
all
the
way
until
some
point
and
do
we
need
to
restart
the
entire
container
or
should
we
just
restart
the
controller
I
think
we
would
need
to
read
a
lot
about
how
Cube
controller
manager
does
it
under
a
few
risks?
These
are
also
related
with
the
development
workflow
in
the
new
repo.
F
So
let's
take
volume
snapshots,
for
example.
F
D
I
think
the
version
the
versioning
issue
with
the
external
snapshotter
was
because
the
API
objects
were
in
the
same
repo.
So
when
you
wanted
to
change
the
API
objects
like
we
considered
that
a
a
major
version,
because
there
were
things
that
pulled
the
API
objects
out
of
the
external
snapshotter
sidecar
into
other
things
like
the
snapshot,
controller
right,
snapshot,
controller
Imports,
the
snapshot
objects
from
the
external
snapshotter
repo,
and
so
it
needed
to
be
so
so.
My
question
would
be
like
four
things
that
have
API
objects
that
are
used
outside
of
the
sidecars
like
snapshots.
F
F
D
There
will
be
more
things
in
the
future
like
that.
You
know
new
API
objects
that
will
be
go
through
Alpha
Beta
GA.
Are
we
okay
just
sort
of
putting
them
in
there
they're
in
that
client
directory
and
gradually
expanding
it
and
and
not
doing
major
version
bumps
as
those
API
objects
evolve?
Is
that
going
to
be
okay.
F
Well,
initially,
I
thought
that
they
could
be
part
of
this
Ripple,
but
if
I
I
can
definitely
analyze
if
they
can
be
moved
away
from
this
repo,
just
the
client
part,
let's
say
API
crds,
but
the
code
for
for
it.
For,
for
these
components
to
work
like
the
snapshot,
controller
or
CSI
snapshotter,
those
would
still
be
part
of
this
Ripple.
F
D
But
there
was
a
there
was
a
time
when
they
weren't
a
core
component.
There
was
a
time
when
they
were
experimental,
so
I'm
just
trying
to
figure
out
what
is
the
on-ramp
for
a
new
experimental
feature
to
to
become
eventually
a
ga
thing.
Does
it
just
start
here
and
spend
its
whole
life
here?
Does
it
start
somewhere
else
and
then
move
here
at
some
point.
F
F
F
So
oh
I
was
talking
about
the
risks.
I
talked
about
the
breaking
change
in
crds
that
for
us
it
meant
up
a
major
bump.
How
would
that?
What
would
that
mean
in
this
new
model?
F
Also
about
vulnerabilities,
now
that
we
have
a
mono
repo,
which
is
a
union
of
dependencies?
There
is
a
higher
change
chance
of
having
more
vulnerabilities
reported
in
for
the
entire
mannerable,
and
that
would
affect
the
entire
company,
not
only
one
part
of
it,
and
there
are
a
couple
of
things
that
are
still
pending
in
the
definition
of
the
problem
like
what
happens
moving
forward
once
we
have,
let's
say
a
stable
model
of
this.
How
do
we
Define?
F
F
F
And
if
you're
interested
in
working
on
this
project,
which,
as
we
saw,
simplifies
the
deployment
of
all
the
CSI
drivers,
then
you
can
reach
out
to
me
on
Slack
in
in
the
dock,
I
have
identified
a
few
Milestones
that
we
could
achieve
for
this
project.
The
first
Milestone
was
to
try
this
out
in
an
experimental
repo
where
I,
combined
external
attacher,
CSI,
release
tools
and
CSI
libutils
and
I
link
them
all
the
way
to
core
workspaces
and
it
it
looked
like
it
looked
fine,
but
it's
an
experiment.
F
It's
not
something
ready
to
be
used
in
production,
especially
because
we
have
one
of
the
issues
that
we
should
solve
is
how
do
we,
for
example,
take
all
of
the
CSI
sidecar
code
and
import
it
into
monetary,
for
preserving
git
history
I
think
that's
a
very
important
problem
and
that's
one
Milestone
and
I
already
found
some
problems
so
yeah.
If
you're
interested
in
this
area,
please
let
me
know
yeah
thank.
F
Yeah
definitely
so
one
of
the
ideas
that
I
had
for
this
was
that
development
should
still
continue
on
the
sidecars
and
for
the
mono
Ripple.
We
could
export
all
of
the
diffs
that
are
happening
in
all
of
these
other
sidecar
Ripples
and
start
importing
them
into
the
mono
repo
progressively
so
I
had
that
idea
well
had
that
idea,
and
it
involves
just
exporting
divs
with
this
command
and
applying
them
with
this
command.
But
there
are
already
some
problems
that
I
I
found
but
yeah.
That's
that's
a
plan.
F
It's
not
to
have
two
models
working
at
the
same
time,
it's
more
about
having
the
csisi
course
development
going
just
fine
and
then
importing
them
into
the
modern
repo
progressively
and
at
some
point
we
definitely
need
to
make
a
hard
cut
where
we
say
we're
no
longer
gonna
make
changes
in
the
sidecar's
repos
and
instead
the
development
should
go
into
the
modern,
Ripple
and
same
thing.
D
I
guess
if
we
do
that,
we
need
to
like
formally
deprecate
the
existing
model
once
the
new
model
is
consumable,
so
that
the
storage
vendors
who
are
shipping
sidecars
know
that
they
have
to
change
something
by
some
deadline
right
and
then
give
them
a
deadline
like
this
is
going
away
a
year
from
now
or
18
months
from
an
hour
nine
months
from
now.
Whatever
the
you
know,
start
the
clock
ticking,
because
all
the
different
vendors
are
going
to
have
to
change
their
deployment
process.
To
use
this
new
thing.
F
Right,
yes,
yeah.
That
will
happen
at
some
point
once
we
know
that
this
model
is
working
first,
we
hostpot
and
then
maybe
we
can
try,
try
it
out
in
some
drivers
and
then
we
would
say
okay.
This
is
this
is
when
we
are
going
to
switch
to
the
new
model,
and
you
will
have
this
timeline
to
do
it.
Yeah
yeah.
A
All
right
thanks
a
lot
Maurice
here
for
the
presentation.
Let's
take
the
discussion
to
the
design
doc,
which
is
linked
in
the
spread
in
the
in
the
agenda
Doc,
and
if
you
have
any
questions,
please
feel
free
to
reach
out
to
Mauricio
directly
as
well
with
that
I
think
we
are
at
the
end
of
the
items
for
today.
Anything
else
before
we
go.