►
Description
Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 16 March 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
It'll
it'll
be
a
very
short
recording,
so
yeah
hello
and
welcome.
This
is
the
kubernetes
sig
storage
volume,
populators
weekly
meeting.
We
only
have
one
item
on
the
agenda
today,
which
is
about
the
naming
of
the
two
new
repos
for
the
volume
populators
work.
I
had
sent
out
a
request
last
week
suggesting
that
we
name
them
data
dash
source-
that,
oh
here,
let
me-
or
how
am
I
going
to
do
this.
A
B
A
You
know
so,
if
you
wanna
share
the
email,
that'd
be
awesome
yeah,
so
we
need
two
repos.
I
think
I
mean
we
could
argue
that
they
could
be
done
in
one
repo,
but
I
think
that
in
general
we're
pushing
for
more
modularity
splitting
things
up
more
and
and
if
I
have
to
do
one
I
may
as
well
do
two,
because
I
still
have
to
it's
the
same
amount
of
work.
A
Just
I
have
to
do
it
twice,
so
the
the
one
repo
is
going
to
be
for
the
validator,
which
is
going
to
contain
the
new
volume,
populator
crd
and
the
new
controller
that
we
will
be
asking
deployers
to
install
with
their
clusters
once
this
feature
goes
beta
and
that
will
be
a
fairly
small
repo,
because
that
controller
doesn't
do
anything
other
than
watch
pvcs
and
watch
volume
populators
and
generate
events.
When
a
pvc
has
a
data
source
that
doesn't
match
a
volume
populator.
A
A
I
thought
the
data
source
was
was
two
words
in
the
pvc
spec
or
at
least
that
the
s
was
capitalized.
A
B
A
B
Think
you
can
still
just
once
you
open
the
issue
because
we'll
need
to
go
plus
one
they're
not
going
to
create
it
right
away,
they're
going
to
wait
for
class
ones.
So
then
sar
can
still.
If
you
you
know,
you
add
dash
and
then
ask
sad.
That's.
A
B
B
A
B
B
A
Right,
but
I'm
so
I'm
imagining
you
know
after
this,
let's
say
somebody
wants
to
implement
an
actual
populator
and
so
they're,
creating
their
own
repo
in
some
third-party
location
and
they're
importing
this
code
and
they're
using
it
as
a
library,
then
it
it
feels
like
when
you're
importing
go
code
from
a
foreign
repo.
You
want
it
you're
treating
as
a
library.
You
want
to
be
called
liv,
but.
B
A
B
A
Gonna
think
I
was
gonna
get
to
that.
So,
okay,
our
goal
is
to
make
this
a
sidecar
eventually,
but
if
we
release
it
as
a
library
at
all,
then
we
might
be
stuck
supporting
that
for
a
while
and
if
we
do
a
sidecar,
it
might
be
a
separate
thing.
A
C
B
A
A
B
A
But
we
don't
know
if
we
can,
and
so
I
feel
like
we're
in
a
weird
situation
where
it's
like
this
might
be
the
the
final
version
of
it.
You
know
if
we
decide
that
the
library
is
just
better
than
a
side
car,
but
yes,
I
agree.
If
we
find
a
way
to
make
a
side
car,
then
we
would
want
to
deprecate
the
library
and
only
support
the
sidecar.
B
I
mean
if,
if
we
feel
the
you
know,
the
library
is
like
stable
enough.
We
want
move
it
to
beta,
then
at
that
time
we
say
we
support
backward
compatible.
If
it's
like
after
it's
become
better,
then
we
say:
oh,
it
should
be
a
sidecar
then
at
that
point
we
need
to
propose
right,
but
at
least
unless,
if
it
is
beta,
if
it's
offer,
I
really
don't
think
we
should
support
it
and
because
that.
A
B
Yeah,
if,
if
we
are
supporting
oh
you're,
saying
the
both
both
the
lid
and
the.
D
A
Provider,
yeah
live
external
provisioner,
so
like
that's
a
situation
where
it
remained
separate
and
the
library
had
its
own
repo,
so
I
I
don't
know
I
just
I.
I
agree
that
we
would
like
to
deprecate
the
library
and
we'd
like
to
have
a
sidecar,
but
until
we
know
that
that
can
be
done,
I
I'm
not
comfortable
committing
one
way
or
the
other
and
I
feel
like
to
get
to
beta.
We
still
need
to
have
the
library
available,
so
people
can
can
experiment
if
they
want
guys.
B
A
Maybe,
instead
of
volume
popular
lab,
it's
lib
volume,
populator
and
then
yeah,
maybe
maybe,
if
we
end
up
having
a
side
car,
we
create
a
third
repo
called.
I
don't
know
what
we
call
it
external
populator
or
something.
A
Yeah
so
yeah,
I
just
I
don't
know
like
like.
I
don't
want
to
go
crazy
with
too
many
repos,
but
I
also
think
it'll
be
weird
if
we
end
up
calling
it
volume
populator
and
then
later
it
turns
into
like
a
sidecar
or
if
it
still
has
the
library
it
has
both
the
library
and
the
side
car
it's
hard
to
know
so,.
B
A
A
C
A
And,
and
for
those
that
don't
know
that
the
benefit
of
a
sidecar
is
mostly
just
maintainability
and
upgradeability,
you
know
if,
if
we
have
a
library-
and
we
find
a
security
issue
in
that
library,
then
everyone
who
uses
the
library
has
to
recompile
and
release
to
fix
the
security
issue,
whereas
if
we
just
have
a
side
car,
it's
we
fix
one
thing
and
we
release
one
thing,
and
then
everyone
installs
that
and
the
security
issues
fixed.
So
that's
the
benefit
of
a
sidecar
okay.
A
So
I'm
gonna,
I
think
I'm
gonna
go
ahead
with
like
lib,
I'm
gonna
change
it
to
lib
volume
populator
to
match
the
lib
external
provisioner,
but
stick
but
keep
the
lib
terminology
and
then
yeah.
If
we
do
end
up
with
a
sidecar,
maybe
we
just
create
a
third
repo,
go
repo
happy
and
deprecate
this
one
unless
there's
any
objection
to
that.
A
Okay,
so
that
was
the
only
thing
on
my
agenda.
I
saw
some
new
people
join.
Did
you
guys
have
any
questions
or
anything?
You
wanted
to
comment
or
contribute.
C
I
don't
have
anything,
but
I'm
remiss
for
missing
so
many
meetings
over
the
last
couple
of
weeks.
I
guess.
A
C
Hate
to
take
up
a
lot
of
time
on
this,
but
have
you
guys
figured
out
the
how
to
handle
weight
for
first
consumer?
Yes,.
A
C
A
If
that
were
ever
to
change
like
it
would
break
the
populator
mechanism,
because
the
populator
mechanism
is
just
piggybacking
on
that
same
undocumented
annotation
to
to
basically
mimic
the
behavior.
But
I
did
a
demo,
probably
back
before
the
holidays,
on
a
wait
for
first
consumer
working
exactly
the
way
we
wanted.
A
All
right:
well,
if
no
one
has
any
other
questions,
that's
the
whole
agenda,
we'll
I'll
go
ahead
and
make
make
the
requests
for
the
repos
to
be
created
and
get
started
on
filling
them
in
okay.
Thank
you
guys.