►
Description
Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 09 March 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
Okay,
so
hello
welcome.
This
is
the
sig
storage
weekly
volume
populators
meeting
today
is
the
code
freeze
date
and
we
don't
have
anything
merged,
except
for
the
original
cap.
So
there's
a
let
me
let
me
try
to
share
my
screen.
B
So
I
I
put
together
an
actual
project
board
on
the
kubernetes
csi
page
to
track
the
various
things,
so
you
can
see
them
here
and
where
they're
at
so
the
there
was
a
the
original
kept
merged,
but
then
based
on
feedback
from
tim,
he
wanted
to
split
it
into
two
cups,
one
for
the
volume
populators
and
one
to
deal
with
the
the
sort
of
backwards
incompatible
data
source
behavior
that
we
wanted
to
treat
as
a
bug
fix,
and
so
I
I
submitted
the
pr
to
split
the
kep,
and
I
made
the
exception
request
to
be
allowed
to
do
that,
but
neither
of
those
have
gone
anywhere.
B
Then
there's
two
specific
code
changes
that
would
go
into
kubernetes.
One
is
the
updating
the
any
volume
data
source
feature
gate
to
beta.
Let's
see
if
I
can
easily
yeah.
This
is
a.
This
is
a
two
line
change
all
it
does.
Is
it
changes
the
the
feature
gate
to
beta,
because
all
the
actual
code
for
this
is
out
of
tree?
So
this
shouldn't
be
hard
to
review
and
approve
if,
if
we're,
okay
moving
the
feature
to
back
to
beta,
the
other
change
was
the
the
backwards
incompatible
handling
of
data
sources.
B
This
is
it
so
this
is
the
other
cap.
I'm
calling
it
implement.
Reject
invalid
pvc
data
sources.
It
adds
zero
lines
and
removes
312
lines.
So
basically,
I
just
removed
all
the
code
that
drops
invalid
data
sources
and
their
associated
tests.
So
it's
a
pure
deletion
change.
In
fact,
I
deleted
a
whole
directory
because
there
was
nothing
in
that
directory,
except
for
this
one
feature,
and
it
just
removes
these
two
calls
to
drop.
B
So
again,
assuming
that
we
agree
with
the
intent
of
the
change,
the
actual
code
change
is
trivial
to
to
look
at
and
understand
and
hopefully
agree
with
so
so
the
I
think
the
the
big
challenge
is
like
getting
agreement
that
this
is
what
we
want
to
do
and
tim's
suggestion
had
been
like:
let's
get
basic
agreement,
that
this
is
a
good
direction,
get
it
merged
and
then,
if
anyone
objected,
we
can
always
go
back
and
reverse
these
decisions
later
on,
and
I
think
that
was
mostly
just
an
admission
of
where
we
were
relative
to
the
to
the
deadline.
B
B
The
other
sort
of
big
rock
is
is
the
out
of
tree
changes,
and
those
are
something
I
want
to
talk
about
today,
because
they're
kind
of
ready
to
merge,
but
they're,
not
merged
and
and
I'm
I
know
that
we're
a
little
bit
wishy-washy
about
the
the
code
freeze
and
out
of
tree
stuff
and
we've
been
trying
to
get
more
strict
about
enforcing
the
code.
Freeze
deadline
on
out
of
tree
stuff
as
well,
but
this
this
this
is
the
the
big
change,
the
data
source,
validator
controller.
B
It
is
implemented
as
a
addition
to
the
external
provisioner
repo
and
it's
well,
it's
it's
mostly
huge
because
of
all
the
vendor
directory
changes,
but
it
adds
the
new
crd,
the
volume
populator
crd,
which
is
a
very
simple
crd.
I
don't
need
to
go
through
all
this.
I
was
hoping
I
could
just
see
a
list
of
the
files
that
got
changed
but
yeah
this.
B
B
Because
if
it
does
deserve
a
separate
repo
like
we
should
get
that
established
before
we
merge
this
and
then
we
already?
We
already
agreed
that
the
populator
library
that
will
form
the
reusable
part
of
volume
populators
does
need
its
own
repo
and
that's
another
thing
that
I
haven't
tackled
yet.
So
I
wanted
to
talk
about
those
things
today.
You
know
what
repos
should
this
code
go
into?
B
C
Think
we
should
wait
a
release
and
not
rush
it.
We
might
step
on
toes
if
we
try
to
push
it
in
and
make
a
mistake.
B
B
B
C
Think
it
looks
like
it's
in
very
good
position
to
be
merged
very
early
in
122.,
so
I
think
as
long
as
we
kind
of
and
we
can
keep
the
pressure
up
as
well
right
yeah.
So
we
can
keep
the
momentum
up.
I
think
it's
pretty
much
ready
to
go.
C
B
C
Of
this
code,
I
prefer
to
have
separate
repos
for
separate
functionality.
Is
there
overlap
between
what
the
external
provisioner
is
doing
and
what
this
code
is
responsible
for.
B
B
C
There
is
another
aspect
of
this
which
is,
I
know
in
the
longer
longer
term,
michelle
wants
to
put
all
the
side
cars
into
a
single
mono,
repo
and
so.
C
B
B
So
so
maybe
the
node
driver
registrar
remains
separate,
because
it's
not
running
in
the
controller
but
yeah
I
could
see
merging
all
the
side
cars
but
then
like
then
we
would
be
faced
with
the
fact
that
the
external
snapshot,
repo
has
a
non-sidecar
controller
in
it.
You
know
the
the
snapshot
controller
is
there
and
we
got
to
figure
out
what
to
do
with
that.
C
A
About
that
and
then
I
was
like,
I
just
feel:
there's
not
too
much
gain
of
bringing
it
up.
So
I
think
then
that's
why
we
didn't
really
yeah.
B
B
C
And
it
should
be
easier
now.
I
think
that
now
that
there's
like
common,
build
tooling
status,
it's
like
a
standalone
repo
that
you
can
just
import
should
be
easier
to
get
off
the
ground.
C
So
start
with
michelle,
I
think
she'll
be
super
familiar
with
it.
Okay,
for
this.
B
B
All
right,
and
maybe
I'll
just
request
two
repos
and
get
started
on
both
the
the
data
source
validator
and
the
the
populator
library,
and
just
do
them
both
in
parallel.
Given
that
we
need
to
do
two
sounds.
C
B
What
this
would
enable
us
to
do
is
to
do
an
alpha
release
of
those
libraries
like
now
in
the
121
time
frame
and
then
go
into
122
and
actually
have
beta
releases
of
both
of
those
repos
to
coincide
with
putting
the
feature
into
beta
in
the
122
time
frame.
I
was
nice.
I
was
going
to
jump
directly
to
beta
with
the
with
the
volume
populator
crd,
which
I
don't
think
is
actually
controversial,
but
it's
weird
to
go
straight
to
beta,
so
yeah.
B
B
B
But
the
thing
that
occurs
to
me
then
is
is:
we
would
need
a
a
version
conversion
web
hook.
B
A
Oh,
we
do
yes,
I
think
there
is
a
conversion.
I
think
it's
automatic.
Actually,
we
don't
really
have
a
separate
some
like
it's.
I
think
it's
automatic
converted.
A
We
don't
really
have
any
extra
logic
in
the
controller.
To
do
that.
I
think
it's
a
it
might
be
the
cue
builder
the.
What
is
that
the
the
controller
gen
or
something
might
be
something
like
that.
B
A
Yeah,
so
it's
basically
the
because
the
default
right
so
basically
the
store
we
have
like
a
stored
version.
It
is
still
we
won
beta
one.
So
if
you
you
can
request
v1,
but
we
store
it
at
v1
beta1.
Basically
so
right
now,
it's
still
it's
just
you
can.
You
can
have
two
requests
version,
two
server
version
or
something
yeah
and
then.
D
B
A
We're
not
supposed
to
support
backward
compatible
for
alpha
anyway.
Why
do
you
want
to
that's
not
kubernetes
current
normally
quantity
does
not
support
advanced
move
to
beta
right.
It's
not.
B
B
And
you
just
take
the
alpha
and
stamp
beta
on
it.
Then
there's
no
reason
to
break
any
existing
users
of
the
alpha
feature.
You
could
just
convert
it
to
beta
magically.
C
I
would
recommend
taking
a
look
at
cube
builder
they've,
actually
gotten
pretty
advanced
in
helping
you
build
crd,
apis
and
controllers,
and
you
can
even
use
it
just
to
build
a
crd
if
you
want,
and
just
things
like
handling
this,
the
conversion
web
hook
and
all
of
that
they
make
it
pretty
straightforward.
B
Yeah
I
actually
discovered
this
when
I
was
tinkering
with
my
code,
because
currently,
the
both
the
snapshotter,
the
snapshot
controller
and
this
data
source
validator
controller-
are
using
kubernetes
119
version
of
the
code
gen
and
I
thought
to
myself:
oh
I'll,
just
upgrade
to
version
20,
120
and
everything
changed
and
everything
broke
when
I
did
that
because
they
added
a
bajillion
new
features.
And
so
so
I
said:
okay,
I'm
just
going
to
go
back
to
119.,
because
I
don't
want
to
have
to
learn
all
these
new
features.
But
but
now.
B
B
D
A
B
A
Yeah,
I
think
some
of
those
things
like
for
I
think
our
web
hook
right
if
we
use
the
computer,
that
will
be
much
easier,
but
because
we
don't
have
that.
We
actually
have
to
manually
write
that
so
yeah.
B
Oh
yeah
yeah,
I've
heard
all
the
good
things
about
q
builder.
My
question
has
always
been:
to
what
extent
are
we
allowed
to
rely
on
it
in
core
kubernetes?
Because
you
know
the
cozy
guys
have
been
talking
a
lot
about
using
cube
builder
and
and
the
and
the
pushback
was
well.
B
Becomes
in
tree
or
or
they
figure
out
a
way
to
refactor
it
to
avoid
circular
dependencies,
but
but
yeah,
that's
all
stuff
to
be
figured
out.
So
all
right,
I
think
I
know
what
to
do
on
the
versioning.
I
think
I
know
what
to
do
on
the
repos
I
gotta
follow
up
with
michelle.
B
I
can
withdraw
the
exception
request
and
send
it
out
to
tim,
saying
we're
going
to
punt
it
to
122
so
there's
time,
and
I
still
want
to
push
on
the
the
backwards
incompatible
data
source
handling
kep
and
see
if
we
can
get
people
to
make
a
decision
on
that.
Because
again,
the
code
is
very
simple:
you
just
delete
a
bunch
of
stuff.
B
I
I
guess
I'll,
ask
I'll,
ask
shing
and
saad
if
you
guys
have
any
memory
of
what
we
were
thinking
with
it
with
this
I'm
gonna
load
the
code
again
with
this
drop
disabled
fields.
These
drop
disabled
field
calls
when
we
initially
implemented
data
sources.
A
I
I
don't
remember
there
was
any
like
recently
under
it's
just
just
to
probably
just
follow
some
other
examples
and
then
just
I
don't
really
remember
like
we
had
any
discussions.
D
A
B
B
Right
now,
let
me
see
if
I
can
so
it's
in
persistent
volume
claims
strategy.
B
So
it's
okay
yeah
there.
It
is,
let's
do
annotate
with
git
blame.
C
That
is,
that
is
surprising,
like
it
usually
does.
What
he's
doing
so,
when
was
this
2018.
A
B
White
yeah
I'm
trying
to
to
load
up
this
here,
persistence,
look.
B
B
I
don't
know
who
this
is.
I
touched
it
here
when
I
added
my
alpha
feature
gate
the
rest
of
it
is
griffith
shang.
You
touched
one
line
or.
A
C
Yeah
griffith
might
know,
since
he
was
probably
the
one
who
added
it.
My
guess
is
liggett
did
a
refactor,
but
if
john
doesn't
know,
we
can
check
with
jordan
poking
on
both
and
being
like
yo.
You
remember.
B
Yeah,
okay
yeah,
so,
but
this
is
something
I'd
like
to
get
at
least
agreement
on,
so
we
can
merge
this
one
first
thing
in
120
to
if
that's
what
we're
gonna
do
and
then,
of
course
the
rest
of
it
may
or
may
not
be
ready.
The
moment
122
opens
up.
B
B
I
don't
know
what
else.
Let
me
see
what
else
is
on
the
agenda.
So
yeah
we
talked
about
the
the
new
repos
talked
about
the
code
free
status.
Yeah.
I
guess
that's
all
I
have.
I
guess
I
guess
the
the
work
item
for
me
is
to
sort
of
tell
people
we're
not
going
to
put
this
in
121
and
then
get
to
work
on
the
the
repo
stuff
so
that
we
can
get
those
alpha
releases
out
and
then
be
positioned
to
go
early
in
122.,
sound
good.
B
B
All
right:
well,
that's
all
we
have.
I
guess
the
other
question
is
about
these
meetings.
I
guess
in
order
to
try
to
keep
attention
on
this
or
we
can
keep
them
at
weekly,
but
there's
probably
going
to
be
less
stuff
to
discuss,
because
it's
just
going
to
be
working
on
the
repos
and
and
a
bunch
of
side
discussions
with
jordan
and
tim,
I
guess
and
other
people.
B
C
Yeah,
let's
keep
it
weekly
for
now
and
then,
if
needed,
just
cancel
it
preferably
the
day
before.
If
there's
no
agenda
and
then
if
we
find
that
we're
canceling
too
frequently,
we
can
reduce
the
frequency.
Okay.
C
I
think
yeah
it's
on
the
official
sig
calendar.
You
know
just
add
it
to
the
agenda
doc.