►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 20 October 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
Oh
there,
it
is
okay,
get
my
little
window
open
all
right.
So
welcome
guys.
Thank
you
for
joining
and
sorry
for
the
relatively
late
notice
for
the
meeting.
I
was
trying
to
figure
out
how
to
set
this
up
correctly
and
ended
up
waiting
until
the
last
minute
to
do
that.
So
I
I
have
been
talking
in
various
venues
about
the
the
volume
populators
work
that
I've
been
doing.
B
So
I
wanted
to
start
off
with
having
like
some
weekly
meetings,
just
to
get
some
work
done
and
figure
out
who
you
know
wants
to
be
contributing
to
this
effort
and
try
to
collect
feedback
on
the
cap.
The
the
cap
update
is
still
not
merged
yet,
which
is,
which
is
fine,
because
the
feature
will
remain
alpha
for
this
release.
B
But
I'd
like
to
wrap
up
loose
ends
around
the
cap
and
then
figure
out
the
the
steps
to
get
work
for
this
done
for
the
120
release,
so
that
going
into
121
we
can
have
a
serious
shot
at
going
to
beta
and
we'll
talk
about
the
details
of
that
so
yeah.
Let
me
so.
I
have
a
in
the
invite
you
should
see.
I
started
a
agenda
doc
in
the
form
that
we
have
for
all
of
our
other
meetings,
and
I
put
some
agenda
items
on
here
to
to
discuss.
B
B
B
B
So,
with
this
feature,
gate
starting
in
118,
if
you
turn
it
on
it,
just
stops
the
validation
of
that
field
and
lets
you
put
whatever
you
want
in
there.
I
do
think
there's
a
limitation
where
it
won't.
Let
you
put
a
core
kubernetes
object
in
there
other
than
a
pvc,
but
but
any
cr
could
be
put
in
there,
whether
it's
a
valid
cr
or
an
invalid
cr,
whether
it
exists
or
not
any
kind
is
allowed,
and
the
idea
was
doing.
This
would
allow
us
to
then
go
develop
data
populators
and
later
later
on.
B
C
B
No
no
just
like
like,
if
you
put
like
a
pod
or
a
or
a
config
map,
or
something
that's
like
core
kubernetes
api
type.
Basically
with
a
with
an
api
group
of
empty
string,
you
know
it
doesn't
work,
I
think
so.
But
if
the
api
group
is
anything
other
than
the
empty
string,
then
the
validator
will
allow
it
through
and
that's
just
because
we
know
that
there's
no
other
core
kubernetes
object
other
than
a
pvc
that
you
would
like
to
be
able
to
be
the
data
source
of
a
of
a
new
pvc.
B
B
This
change
was,
we
want
to
enable
the
development
of
populators
outside
the
tree,
so
so
when,
before
we
had
any
data
sources
at
all,
the
very
first
one
to
go
in
was,
I
believe,
pvc
cloning,
and
so
we
changed.
You
know
the
validator
to
allow
pvcs
and
then
later
we
added
snapshots,
and
there
was
another
change.
The
snapshot.
C
C
B
C
B
But
if
it's,
if
it's
not
a
core
api,
it
allows
it
so
so,
like
I
was
saying,
the
whole
idea
here
was
to
allow
development
of
populators
and
other
data
sources
for
pvcs
outside
of
the
cour
tree
of
kubernetes,
so
so
that
the
problem
was
you
know
for
for
pvcs
and
for
snapshots,
getting
them
in
required,
changes
to
cube
api
server
to
allow
them-
and
we
didn't
want.
You
know
the
third
one
and
the
fourth
one
and
the
fifth
one
to
have
to
go
down
the
same
path
because
it's
slow
and
it's
annoying
and.
C
B
B
Yeah
there
was
an
iteration
of
my
change
that
literally
allowed
anything,
and
then
someone
said
I
forget
who
suggested
you
know?
Maybe
we
shouldn't
allow
core
data
types
here.
I
totally
agreed,
and
so
I
put
that
because
that
check
was
part
of
the
pre-existing
code
of
117,
and
so
I
just
put
that
check
back
in,
but
that's
that's
a
very,
very
minor
detail.
B
I
unfortunately
didn't
spend
any
time
on
it
during
119
other
than
thinking
about
it,
but
now
I
really
want
to
move
it
forward
during
120..
So
the
idea
that
we
had
was
we'll
have
a
validating
web
hook.
That
will
that
you
know
we
would
expect
distros
to
install
at
the
same
time
that
they
flip
the
feature
gate
on.
So
whenever
the
feature
goes.
B
So
we
do
want
it
to
be
administrator
controlled
so
that
arbitrary
users
can't
just
create
their
own
data
source
types
and
and
install
populators
in
the
cluster
and
then
start
doing
weird
things.
It
would
have
to
be
something
the
administrator
enabled.
But,
aside
from
that,
we
want
to
sort
of
open
the
doors
to
experimentation.
B
B
And
so
so
these
things
are
very
simple.
It's
basically
it's
an
object,
has
a
name,
and
then
it
has
a
source
in
kind
and
you
you
know
when
you
install
a
populator,
including
all
of
its
associated
controllers
and
crds,
that
represent
you
know
the
the
things
that
will
be
data
sources.
You
create
an
instance
of
a
volume
populator
cr
that
refers
to
that
group
in
kind
and
then
the
validating
web
hook
will
say:
oh
okay.
B
Now
this
is
a
valid
data
source
and
if
you
don't
create
one
of
these
attempts
to
create
a
pvc
that
refer
to
to
a
crd
that
doesn't
have
one
of
these
will
will
get
rejected
and
you'll
get
the
regular.
You
know.
Actually
I
don't
know
what
the
error
code
is.
You
get
back
from
cube
api
server,
but
it
will.
It
will
reject
the
the
object
creation
entirely
and
you
won't
get
a
pvc
until
the
populator
is
installed,
so
so
so
this
is.
B
B
Basically,
if
I
don't
have,
if
I
don't
have
to
today
today,
if
I
just
install
that
controller
and
the
crd-
and
I
flip
the
feature
gate
on
it'll,
let
anything
through
so
I
could.
I
could
just
put
a
hello
in
my
data
source
of
a
pvc
and
it'll,
be
fine.
Popular
can
do
its
job.
The
problem
is,
is
if
I,
if
I
misspell
hello
and
put
like
hello
in
there
or
something
bizarre
like
it'll,
just
go
in
and
you
it
will
be
accepted
and
you'll
get.
B
No
error
messages
and
nothing
will
happen
and
you'll
just
be
confused,
you'll
be
like.
Why
am
I?
Why
aren't
I
getting
anything
so
so?
The
point
here
is
to
validate
the
data
as
it
goes
in,
so
that
things
that
are
never
going
to
get
fulfilled,
get
rejected
immediately
and
then
for
things
that
that
are
allowed.
C
B
B
Yeah
yeah
you
can
have,
you
can
have
as
many
of
these
as
you
want,
and
one
of
the
things
I
wanted
to
discuss
later
was
right.
Now,
there's
no
way
to
prevent
multiple
populator
instances
from
referring
to
the
same
group
in
kind,
and
that
seems
like
a
problem,
but
we
can
talk
about
that
later,
but
but
yeah,
the
idea
is,
you
can
have
as
many
of
these
as
you
want
they're,
just
it's
just
a
cr.
It
only
has
two
fields.
B
Every
time
you
install
some
sort
of
populator,
you
can
install
as
many
of
these
as
you
want,
and
it
just
basically
tells
the
the
validating
web
hook
that
don't
reject
this
data
source,
because
because
I'm
something
something
else
will
provide
feedback
about
pvcs
with
that
data
source
that
that's
what
this
that's.
What
the
cr
supposed
to
indicate
is
that
there
is
something
else
in
the
system
responsible
for
watching
these.
B
Yes,
yes,
so
so
I
I
was
going
to
go
over
the
the
code
later,
because
I
have
a
prototype
that
actually
works
but
yeah.
Well,
basically,
every
time
you
get
a
a
new
pvc
with
a
not
with
an
on
empty
data
source.
The
validating
web
hook
looks
at
the
the
group
in
kind
and
then
goes
and
tries
to
find
a
cr
that
matches
that
group
in
kind
before
allowing
it
and.
E
B
Yeah,
so
so
so
that
that
was
a
sticking
point
and
that
came
up
in
my
earlier
discussion
with
elliot
and
alexi
so
to
the
the
current
design
does
not
enable
that.
But
but
but
similarly,
the
status
quo
does
not
enable
that
either.
If,
if
I,
if
today,
I
create
a
pvc
with
a
data
source,
it's
just
going
to
get
zeroed
out
and
I'm
going
to
get
an
empty
volume.
And
then,
even
if
I
install
a
populator
later,
that
would
have
populated
that
data
source.
B
B
D
B
At
that
point,
you
need
a
full-blown
controller
that
is
watching
for
pvcs
and
generating
events
as
it
sees
them,
and
that
was
actually
my.
My
first
thought.
Like
a
couple
months
ago,
I
was
like.
Oh,
we
just
need
to
have
a
controller.
That
watches
for
pvcs
looks
at
the
data
source
checks
to
see
if
the
data
source
refers
to
something
that
has
been
registered
as
a
populator
and
if
not
just
generates
an
event
and
says
hey.
This
looks
bogus
it
might
never
get
fulfilled
and
then
and
then
leave
it.
B
D
Think
the
drawback
could
be
that
events
will
go
out
of
order.
So
in
case,
if
you
like,
if
controller
sees
that
there
is
no
populator,
but
at
the
same
time
you
are
deploying
the
populator
and
populator
will
kind
of
emit
event
working
on
it
and
then
controller
will
emit
the
event
that
there
is
nobody
working
on
it.
So
these
events
may
go
out
of
order.
I
guess
I
mean
that
kind.
B
E
B
D
B
D
B
I
I
couldn't
answer
that
either,
so
that
would
be
an
interesting
research
project.
So
so
I
I
am
open
to
changing
this
to
to
a
full-blown
controller
that
just
provides
advisory
events
instead
of
denying
object
creation.
I
think
that
that's
a
reasonable
approach
I'll
have
to
rewrite
some
of
the
stuff
in
the
in
the
cab,
but
that's
no
big
deal.
I
guess
the
question
at
that
point
would
be
which
controller
so
you're
proposing
something
in
tree.
E
D
E
The
controllers
themselves
were
not
allowed
to
do
the
installation
themselves,
and
so
eventually
the
sig
architecture
said:
okay,
fine,
we'll
let
you
make
an
exception
here
and
add
it
to
the
core
and
we'll
look
into
how
to
do
this
properly
in
the
future.
So
this
could
be
another
one
of
those
things
where
we
go
to
sig
architecture
and
say:
hey:
we've
got
a
use
case.
E
C
C
B
So
that
was
my
first
idea
was,
was
don't
add
it
to
something?
That's
in
tree.
Add
it
to
the
external
provisioner
so
that
it
will
be
handled
on
a
per
csi
plug-in
basis.
So
each
csi
plug-in
will
have
to
have
its
own
external
provisioner
and
will
only
emit
events
for
pvcs
that
that
provisioner
would
have
been
responsible
for.
C
E
D
D
B
Yeah,
so
so
we
could
do
something
like
we've
done
for
snapshots,
where
we
have
in
this
external
snapshot
of
repo.
We
have
a
sidecar
and
a
controller,
and
the
understanding
is
the
controller
is
sort
of
a
centralized
thing,
that's
installed
by
the
distros
and
the
sidecar,
something
that's
installed
by
the
csi
plug-ins
and
then
just
add,
like
a
pvc
populator
controller
to
the
external
provisional
repo.
That
would
follow
the
same
model
yeah.
I.
E
B
If
what
you're
doing
looks
like
it's
not
going
to
result
in
something
good
and
that
way,
if,
if
you
either
haven't
installed
a
populator
yet
or
you
know,
or
the
populator
never
will
be
installed,
you
at
least
get
a
note
from
the
system
saying
why
your
pvc
is
not
binding
and
then,
of
course,
if
if
if
later,
the
populator
gets
installed
and
your
pvc
is
just
sitting
there,
there's
nothing
stopping
it
from
binding
at
that
time
and
then
you're
back
in
business
and
as
long
as
you
have
the
the
feature
gate
turn.
So
so.
B
Actually,
I
wonder
if
this
changes
the
the
speed
at
which
we
could
get
to
a
beta
if
we
don't
need
the
populator
to
or
the
sorry
the
the
the
validating
web
hook
to
be
installed
for
correct
behavior,
and
it's
just
a
matter
of
enabling
the
feature
gate
and
well.
I
guess
you
still
need
to
have
the
if
you
enable
the
feature
gate
without
this
controller
being
installed,
what
you
lose
out
on
is
user
feedback.
B
B
If
that
happened.
In
this
case,
I
guess
things
would
just
kind
of
work,
but
you
wouldn't
get
warning
messages
which
well
and
also
you
wouldn't
the
the
installation
process
for
the
populators
would
fail
to
create
an
instance
of
the
volume
populator,
because
the
crd
itself
might
not
be
there
yet
because
someone
forgot
to
include
it
with
the
distro.
B
B
The
object
goes
through
and
gets
created,
as
the
user
specifies,
but
then
what
happens
is
when
the
external
provisioner
sidecar
that
is
responsible
for
that
or
or
if
it's
entry
you
know
whatever
would
be
creating
that
that
volume
it
looks
the
data
source
and
it
says
you
know,
is
it
a
pvc,
because
I
know
how
to
clone
things?
Is
it
a
snapshot
because
I
know
how
to
clone
those?
B
D
B
B
B
B
B
What
happened
to
my
other
web
browser
yeah,
the
other
things
I
want
to
talk
about
were
metrics
because
they
came
up
in
the
kep
review.
We
don't
need
to
talk
about
validation.
Well,
we
could
so
so
assuming
we
add
these
yeah.
Let's
talk
about
this
one,
assuming
we
add
the
volume
populator
crd,
whether
it's
a
core
object
or
or
an
external
object.
B
We
do
have
the
problem
where,
like
you,
can
have
multiple
instances
of
this
object
that
refer
to
the
same
group
in
kind,
and
what
does
that
mean
because
all
that
the,
although
the
controller
cares
about
is,
is
there
acr
that
mentions
the
group
in
kind?
It's
not
going
to
do
anything
with
that.
Cr!
There's
no
instructions
in
here
other
than
just
basically
saying
hey.
B
D
B
D
B
B
E
E
B
B
E
Actually,
yes,
so
if
you
mark
two
storage
classes
as
default
today,
there's
no
api
time
creation.
Time.
Validation!
That's
done!
Instead,
when
you
go
to
use
one
of
these
storage
classes,
the
provisioner
throws
up
and
starts
spewing
events.
Saying
hey,
there's
two
defaults:
I
don't
know
which
one
to
use.
Sorry,
okay,
so.
A
B
B
You
know
so
just
be
aware
that
your
pvc
might
not
bind,
but
if
there
were
two
we
could
implement,
we
could
emit
a
different
message
that
says:
hey
there,
there's
two
instances
of
this
of
this
populator
cr
and
we
don't
know
what
the
heck
is
going
to
happen
exactly:
okay,
that
that
seems
reasonable
and
yeah.
That
gets
us
off
the
hook
from
having
to
write
a
whole
other
validator
just
for
this
populator
crd
okay.
B
B
Yeah
yeah
shing
is
doing
the
recording,
but
I
I
I
like
to
have
the
notes.
I
don't
have
to
listen
to
myself.
Talk
for
a
whole
hour
to
see
what
makes
sense.
I
want
to
talk
about
metrics
briefly
before
we
go
to
other
things.
So
as
part
of
the
I
don't
know
what
we're
calling
this.
This
new
process,
the
prr
process,
product
readiness
review
or
something
they're
very
interested
in
metrics,
around
new
features-
and
I
don't
know
anything
about
metrics
and
kubernetes.
B
E
So
in
general,
the
way
that
it
works
is
every
component
is
expected
to
have
a
prometheus
metrics
endpoint
and
on
that
end
point
it
can
emit
whatever
metrics
make
sense
for
that
component
in
general.
These
metrics
are
the
counts
and
latencies.
So
you
could
have
you
know,
number
of
requests.
I
got
number
of
errors.
I
got.
E
D
B
D
B
D
B
B
So
so
I
guess
what
my
question
is
is
like:
could
you
suss
out
that
kind
of
information
from
any
other
existing
metrics
like,
like
the
events,
are
there
to
go
look
at
if
you
want
to
just
peruse
the
events
like?
Is
that
not
how
they
want
to
solve
these
kinds
of
problems?
They
want
to
have
dedicated
metrics,
to
tell
you
what's
going
on.
E
B
Oh
okay,
okay!
So
so
some
guy,
whose
job
it
is
to
just
keep
an
eye
on
the
infrastructure,
yeah
and
look
for
anomalies
right,
okay,
okay,
so
so
yeah
I
can,
I
guess,
propose
some
metrics
in
the
updated
kep
along
those
lines
and
then
and
then
so.
The
this
new
controller
would
be
the
the
kubernetes
or
sorry
the
prometheus
endpoint
like
it
would
just
be
built
into
the
controller.
B
C
E
Yeah,
so
for
the
sidecars
I
actually,
instead
of
going
through
and
adding
the
same
metric
and
all
the
different
side,
cars
I
created
a
library
and
that
library
is
imported
in
all
the
side,
cars
and
it
lives
in
csi
libya
tills.
If
you
go
to
csi
libya
till
slash,
metrics
you'll
find
the
library
there
and
then
you
can
see
all
the
side
cars
imported
and
how
they
implement
it.
B
B
C
B
Okay,
so
so
I
should
throw
out
the
question
real,
quick.
It
did
come
up
before
like
should
this
thing
live
in
a
separate
repo,
or
can
we
reuse
the
external
provisioner
repo
for
this
kind
of
feature
like
I,
I
hate
creating
new
repos
just
because
of
the
amount
of
work
involved,
but
I
also
hate
having
multiple
things
live
in
the
same
repo,
so
yeah.
E
I
think
we've
seen
this
time
and
time
again
with
like
the
old
external
storage
repo,
where
we
had
tons
of
projects
and
a
single
repo
and
then
with
the
volume
snapshot
where
we
had
the
core
controller
and
the
sidecar
living
in
the
same
repo.
So
I
would
suggest,
starting
with
a
separate
repo,
if
we
decide
that
we're
going
to
do
a
standalone
controller
right.
B
C
C
Yeah,
that's
awesome
so
having
them
together,
you
can
always
test
them
together.
That's
the
yeah.
Surrender
now
like
the
apis,
actually
is
in
a
different
goal
package.
So
that's
a
separate
kind
of
separate
and
then
controllers
and
side
cars.
They
are
built
separately,
but
yeah
I
mean
yeah.
I
haven't
seen
any
I
mean
we
can
if
it's
really
really
absolutely
necessary.
I
haven't
seen.
B
B
E
I
think
that
makes
sense,
and
I
think
I
can
be
convinced
of
that-
I'm
just
going
to
play
devil's
advocate
for
a
little
bit.
I
guess
the
weird
thing
is
the
csi
external
provisioner
repo
is
dedicated
to
csi
drivers,
and
this
controller,
we're
talking
about,
is
kind
of
more
generic
and
applies
to
non-csi
as
well.
B
E
Okay,
I
can
buy
that
logic
and
I
know
in
general,
we
want
to
move
to
a
mono
repo.
I
think
this
is
one
of
those
where
the
pendulum
swings
right.
We
start
with
one
extreme.
We
find
out
how
painful
it
is
and
we
swing
to
the
other
extreme
and
go
back
and
forth.
So
I
think
the
direction
the
sig
wants
to
move
is
like
collapsing,
all
the
all
the
csi
side,
cars
into
a
single
repo
into
actually
a
single
binary.
If
possible,
oh
yeah,.
C
C
F
B
E
B
E
You
know
quickly
developing
things
that
there
were
new
side.
Cars
and
new
features
popping
up
all
the
time,
and
I
guess
the
feeling
now
is
that
it's
a
little
bit
more
stable
and
now
there's
more
pain
on
the
integrator
side,
where
the
integrators
are
trying
to
manage.
You
know
four
or
five
different
versions
of
side,
cars
and
all
the
different
versions
and
trying
to
figure
out.
B
I'm
just
trying
to
imagine
that,
because
you
know
netapp
our
our
plug-in,
like
we
support
all
the
way
back
to
kubernetes
113.
so
and
actually
maybe
further.
Now
I
don't
even
know
but
like
so
so
when
this
new
mono
sidecar
comes
along
like
we're.
Gonna
have
to
support
that
and
the
old
way
at
the
same
time,
which
might
be
even
worse
than
either
alternative.
E
B
E
B
D
B
End
of
the
world,
but
yeah
all
the
other
things
you
mentioned.
I
hadn't
even
thought
about
so
plenty
of
reasons
not
to
not
to
go
with
another
repo,
okay,
so
we're
close
to
the
top
of
the
hour
and
there's
not
really
enough
time
to
delve
into
the
mechanics
of
populations
themselves.
So
we
can
put
that
off
for
another
week.
I
I
want
to
use
the
last
few
minutes
basically
to
talk
about
what
the
plan
is
going
forward
and
answer
any
other
questions.
B
People
have
so
I
I
would
like
to
keep
this
as
a
weekly
for
at
least
the
next
few
weeks.
Hopefully
a
lot
of
decisions
will
get
made
and
the
cap
will
get
merged
and
we
can
you
know-
maybe
not
have
these
meetings
every
week
or
cancel
the
series
entirely,
but
is
everyone
cool
with
keeping
this
on
a
weekly.
B
Okay,
all
right,
so
then
did
anyone
have
any
anything
else
you
wanted
to
add.
You
know
ask
questions
if
you
have
other
topics
to
discuss,
please
just
direct
the
agenda.
Doc
is
editable
by
anyone,
so
I'm
going
to
create
a
bullet
for
next
week
and
you
can
just
throw
stuff
on
there.
If
you
want
to
talk
about
it,
I
will
write
down
the
notes
from
this
meeting
today,
while
they're
still
in
my
brain.