►
Description
Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 16 February 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
A
Yeah
they
just
okay,
so
yeah.
This
is
the
volume.
This
is
the
kubernetes
sig
storage
volume,
populators
meeting
for
those
watching
the
recording.
If
anyone
so
the
I
think,
as
of
the
last
meeting,
the
kep
hadn't
been
merged,
so
it
was
merged
later
that
afternoon.
For
those
that
don't
know
so,
that's
good
news.
A
Here
is
the
version
of
it
that
got
merged
or
here's
the
cap,
here's
the
the
pr
for
the
kep
that
merged
so
so
tim
did
have
a
bunch
of
questions
about
it.
We
answered
as
many
as
we
could
and
he
sort
of
agreed
to
approve
it
from
an
api
perspective,
but
he
implied
that
he
wanted
to
sort
of
follow
up
on
some
of
the
loose
ends
that
he
wasn't
entirely
happy
with.
A
So
I
have
a
an
action
to
sort
of
either
get
him
into
one
of
these
meetings
or
schedule
another
meeting
to
sort
of
go
over
the
remaining
api
issues,
but
we
can
go
over
some
of
them
here
because
I'm
curious
to
know
what
other
people's
opinions
are
on,
how
we
should
handle
some
of
this
stuff,
so
that
in
case
the
eventual
meeting
with
tim
can
include
everyone.
I
can
at
least
represent
everyone's
opinion.
A
So
let
me
go
down
here:
get
all
the
strings:
feedback,
david's
feedback,
sod's
feedback,
okay,
so.
A
Yeah
tim
tim
did
sort
of
imply
that
he
preferred
the
validating
web
hook
approach
where,
if
you
specify
a
pvc
that
has
a
data
source
that
we
don't,
we
don't
consider
valid
as
in
the
the
data
source
or
the
the
populat
data
source
validation
controller,
that
we
should
actually
prevent
the
creation
of
those
pvcs.
A
It
can
make
sense
to
allow
the
pvcs
to
be
created
even
before
their
dependencies
become
valid.
So
that
was
the
that's
the
the
case
that
I
made
to
him
on
why
it's
better
to
have
an
asynchronous
controller
that
emits
events
than
a
validation
controller.
But
we
haven't
heard
his
response
to
that
yet
so
he
may
still
have
different
feelings
about
how
that
should
work.
The
other
big
question
was
about
the
the
existing
behavior
on
the
the
admission
controller
in
cube
api
server.
A
Where
currently,
if
the
feature
gate
is
turned
off,
and
you
specify
what
would
be
an
invalid
data
source,
cube
api
server,
just
blanks
out
the
field
and
goes
ahead
and
creates
your
pc
anyways,
which
he
thinks
is
kind
of
crazy,
and
I
think
we
all
kind
of
agree
that
that's
a
really
weird
thing
to
do.
A
But
but
that's
how
it's
been
implemented
for
a
long
time,
and
I
think
if
we
change
that
we'd
have
backwards
compatibility
problems.
So
we
need
to
have
a
discussion
about
like.
Can
we
change
that
in
a
backwards
compatible
way?
Is
there
a
better
behavior
in
the
long
run,
and
then
the
one
corner
case
that
still
exists,
which
is
even
with
the
feature
gate
turned
on?
A
A
Tim
had
suggested
that
you
know
maybe
it's
okay
to
use
core
objects
as
data
sources.
You
know
if
somebody
wants
to
write
a
popular
that
like
turns
a
pod
into
a
pvc
like
who
are
we
to
stop
them?
The
main
counter
argument
against
that
is:
we
don't
have
any
way
to
prevent
multiple
popul.
Well,
okay,
let
me
put
it
this
way.
A
A
A
We'll
never
have
this
problem
where
two
different
populators
will
be
attempting
to
respond
to
the
same
pvc
and
to
populate
it
and
and
therefore,
if,
if
you
wanted
to
basically
have
a
populator
that
could
take
a
pod
and
turn
it
into
a
pvc,
my
recommendation
would
be
introduce
a
new
crd
that
points
to
the
pod
and
then
have
the
pvc
point
to
that
object.
A
And
so
you
have
this
extra
level
of
indirection
and
then
and
then,
if
somebody
else
wanted
to
also
write
a
populator
that
could
turn
a
pod
into
pvc
or
any
other
core
object.
You
could
do
something
similar
with
just
a
different
crd
in
the
middle
that
points
to
the
same
pod
and
that
would
sort
of
prevent
the
two
from
ever
fighting
over
fighting
with
each
other,
and
it
would
also
obviate
the
need
to
ever
have
the
core
object
directly
reflected
in
the
in
the
data
source
field
of
a
pvc.
A
Yeah
yeah
I
mean
I,
I
we
need
to
keep
sharpening
up
the
cap
and
the
designs
and
explain
all
this
and
we
need
you
know.
Eventually.
This
feature
will
need
documentation,
both
user
facing
documentation
and
developer
facing
documentation.
So
we're
going
to
have
to
get
all
that
stuff
sorted
out
and
we're
going
to
have
to
make
very
clear
this.
A
A
That
was
the
third
sort
of
big
topic
that
came
up.
B
The
plan
to
eventually
you
have
this
hello
popular
right
is
the
plan
eventually
to
put
that
under,
like
kubernetes,
six
or
quincy
csi.
A
Yes,
yes,
so
so,
actually,
if
you
look
at
the
hello
popular
right
now,
like
the
package
name
actually
says
github.com
kubernetes
csi
and
then
I
think
it
says
hello,
popular.
B
A
C
B
A
To
sort
of
prove
that
actually
now
that
I
think
about
it,
probably
a
year
and
a
half
ago
or
two
years
ago,
to
prove
that
that
would
the
basic
idea
would
work.
So
I
I
wanted
to
write
the
cap
in
a
very
kubernetes
focused
way.
A
That
was
like
we're
just
changing
this
feature
gate
the
implementation
of
population
is
going
to
be
out
of
tree,
and
so
that's
how
I
initially
wrote
it,
and
he
said
no,
he
you
know,
let's
explain
how
populators
really
should
work
so
that
it's
clearly
understood
for
everyone
in
the
kubernetes
community
who's.
Reading
this
kept.
What
you're
supposed
to
do.
You
know
whether
or
not
you
use
the
library
that
I
wrote,
which
may
or
may
not
turn
into
a
side
car
in
the
near
future.
A
I
have
taken
a
look
at
taking
the
library
portion
of
the
hello
populator
repo
to
and
turning
it
into
a
sidecar
and
there's
some
issues
there
with
the
communication
mechanism
between
the
actual
populator
and
the
sidecar
when
it
comes
to
sort
of
specifying
what
the
pod
should
look
like,
because
that's
the
big
job
of
the
of
the
interaction
between
the
library
can
do
all
of
the
work,
except
for
deciding
what
should
go
in
the
pod
spec
for
the
pod.
A
That
will
do
the
population,
and
so
it
makes
a
call
back
into
the
populator.
In
this
case
the
sample
populator
to
say
you
know,
give
me
a
give
me
some
details
for
the
pod
spec
that
I
will
then
turn
into
an
actual
pod.
That
will
actually
do
the
work
and
then
everything
else
is
sort
of
done
by
the
library.
A
Maybe
what
we
would
do
is
sort
of
turn
it
into
json
and
shove,
the
json
through
the
grpc
pipe,
and
require
that
the
thing
on
the
other
end
can
like
parse
it
or
something
we
need
to
talk
about
that.
But
that's
that's
not
a
concern
that
tim
had
that's
just
a
design
concern
that
we're
going
to
have
to
address
eventually,
but
to
answer
your
question:
shane
yeah,
the
hello
populator
should
just
become
like
populator
library
or
something
or
data
populate
or
volume.
Populator.
B
A
A
And
that
that's
my
eventual
goal
with
that
library-
and
I
guess
that
that
needs
to
be
done
in
the
during
the
121
release,
so
that
we
can
have
a
shipping
version
of
that
available
and
the
other
big
thing
that
needs
to
be
done
now
that
the
cap
is
approved
is
getting
the
actual
validator
controller
merged
and
the
volume
populator
crd
merged
and
released
so
that,
like
deployers,
can
start
to
use
it
so
that
so
I'm
sort
of
getting
getting
to
a
different
topic
now,
but
but
yeah.
A
The
the
work
for
the
rest
of
this
release
primarily
is
going
to
be
on
getting
releasing
the
components
that
are
going
to
be
necessary
for
deployers
and
for
developers
who
want
to
write
populators.
And
then
you
know,
it'll
be
a
beta
feature
and
until
we
have
actual
implementations
of
populators
out
in
the
out
in
the
world
that
people
are
using
will
probably
be
staying
in
beta.
I
think
the
the
kep
criteria
for
moving
to
ga
was
that
we
need
some
number
of
you
know
actual
populators
in
production
use
you
know
so
so
that'll.
A
You
know
we
want
to.
We
want
to
lay
the
foundation,
so
that
can
happen
after
the
121
release
goes
out
to
encourage
people
to
write
real
populators
and,
of
course
we
want
to
leverage
all
that
into
the
you
know,
backup
and
restore
design
that
we're
that
we're
covering
in
in
the
data
protection
working
group.
So
I'm
just
I
want
to
make
sure
that
that
covers.
A
Oh,
there
was
one
other
area
of
feedback
that
tim
provided,
which
was
about
metrics,
so
he
was
suggesting
that
it
would
be
cool
to
know
how
long
it
takes
for
pvcs
to
bind.
A
You
know
from
the
time
the
user
creates
the
pvc
until
the
populator
completes
its
work
and
then
binds
it,
and
the
user
can
do
his
thing.
We
if
we
could
like
capture
those
timings
and
produce
a
histogram
of
values
that
would
be
useful
to
an
operator,
not
a
not
a
software
operator,
but
a
human
operator.
You
know
running
running
a
kubernetes
cluster
to
see
if
you
know
how
these
things
are
going
and
my
response
to
that
was
yet.
A
We
need
that
same
data
for
every
pvc
right,
whether
it's
an
empty
pvc
or
it's
a
clone
of
a
volume
or
a
clone
of
a
snapshot.
You
know
having
this
timing
information
you
can
turn
to
histogram
is
really
valuable
and
that
that
that
seems
like
it
should
be.
A
core
function
of
the
the
pvc
bind
controller
or
or
of
something
in
the
core,
because
this
is
something
we
went
across.
All
pvcs
wouldn't
be
able
to
time
how
long
it
takes
for
them
to
become
bound.
A
B
I
think
it
show
it.
I
think
it
probably
just
kind
of
like,
like
the
whole
time
that
probably
does
not
show
how
long
does
it
take
to
bind
or
something,
but
it's
like
how
long
does
it
take
for
the
whole
operation
to
finish
so
it's
the
entire
thing,
I'm
not
sure
exactly.
B
Yeah,
so
there
are
also
like
side
cars,
for
example
like
if
you
look
at
example
provisional
it
has
it
has
that
already
it
has
metrics
already.
So
if
you
look
at
that-
and
there
is
a
different
set
of
metrics,
that
is,
that
is
in
external
provision
and
then
in
the
entry
right.
Another.
A
Yeah,
I
know
I
mean
I
know
the
external
provisioner
has
its
metrics
for
the
work
it's
doing
but
like
it
would
not
capture
any
sort
of
other
delays.
So
so
from
the
time
you
know
the
user
goes,
and
jesus
creates
a
pvc
and
that's
basically
immediate
right
as
soon
as
that
gets
to
the
the
admission
controller
and
cube
api
server.
The
pvc
exists
right
now.
A
It's
just
sitting
there
waiting
for
someone
to
do
something
with
it
and
if
you
have
a
csi
plug-in
running,
it
will
see
that
pvc
and
then
decide
to
go,
do
something
with
it
but
like
it
might
take
some
time
for
it
to
even
notice
the
pvc
is
there
and
then,
from
the
time
he
notices
that
it's
there
until
it
starts
calling.
You
know,
csirpcs
could
be
more
time.
You
know
if
it's
backed
up
with
a
bunch
of
other
work
or
it's
queues
or
folders
or
whatever.
A
If
there's
all
kinds
of
things
that
can
happen,
that
would
slow
down
the
reaction.
Time
from
pvc
exists.
To
you
know,
csi
plug-in
is
actually
invoked
and
doing
some
work
and
then,
even
when
the
csi
plug-in
is
done
and
the
sidecar
creates
the
pv
in
response
to
the
pvc,
it's
still
not
done
right,
because
the
bind
controller
has
to
see
that
pvc
and
then
bind
the
pvc
to
it.
That's
like
another
step.
B
Yeah,
so
I
don't
know
what
the
entry
one
measure
depending
on
the
register,
I
know
the.
A
A
What
I
would
want
if
I
was
if
I
was
a
an
administrator,
I
would
want
to
know
like
the
total
time
from
pvc
got
created
by
the
user
to
pvc
became
bound.
You
know,
and
just
whatever
else
happened
in
the
middle,
there
is
sort
of
irrelevant.
Just
you
wanna
those
two
time
stamps
pvc
was
created,
pvc
got
bound
subtract
them
and
that's
your
elapsed
time
and
I
don't
know
if
we
collect
that
metric.
But
if
we
you
know
it
would
be
a
good
thing
to
add.
A
C
A
A
You
would
look
at
all
the
pvcs
that
had
data
sources
of
a
kind
that
the
populator
was
responsible
for
and
produce
a
histogram
of
of
those
pvcs
and
and
presumably
it
would
be
slower
than
other
types,
because
there's
more
work
to
be
done,
but
but
how
much
slower
would
be
of
great
interest
to
to
an
administrator?
A
C
Die
would
they
be
different
than
like
the
like
the
csi
plugins
for,
like
a
dynamic,
pv
creation?
Do
we
capture
the
metrics,
for
that?
Would
that
would
would
that
become
a
red
herring
in
that
data
set.
A
Yeah,
I
I
don't
know
enough
about
what
the
current
metric
system
does
and
what
it's
able
to
do
to
be
able
to
answer
that.
But,
yes,
we
would.
A
Want
to
make
sure
that
the
existence
of
populators
wasn't
messing
up
any
existing
metrics
and
then
we
would
also
want
to
have
some
metrics
on
the
populator
controller
that
you
know
just
covered
the
things
the
popular
controller
knows
about
like
it
can
measure
how
long
it
took
for
the
pod
to
run
that
that
did
the
populating.
But,
like
you
know,
I
think,
total
round
trip
time
from
pvc
creation
to
buying
time
is
the
metric
that
really
matters,
because
that's
the
user
observable
latency.
A
So
so
yeah
there's
just
some
more
suggestions
for
making
metrics
better,
which
I
think
it's
good,
that
people
are
thinking
about
that
kind
of
thing,
because
it's
easy
to
to
ignore
when
you're
developing
a
new
feature.
A
So
so
we're
going
to
be,
you
know,
taking
notes
of
all
the
ideas
for
metrics
and
figuring
out
how
to
address
them
all.
And
I
don't
know
what
the
you
know.
I
don't
know
if
we'll
get
all
the
metrics
in
in
121,
but
we'll
do
what
we
can
and
we'll
have
a
a
list
of
the
rest
of
the
ones.
We
want
to
add
later
all
right,
yeah
with
introducing
follow-up.
A
So
so
that
was
that
covers
the
stuff
that
tim
wanted
to
talk
about,
and
I'll
still
have
to
schedule
that
meeting
and
yeah.
The
only
other
thing
to
discuss
today
is
sort
of
the
the
plan
for
the
rest
of
this
release,
which
I
already
started
talking
about,
which
is
just
get
get.
The
crd
and
the
data
source
validator
controller
merged
and
released
before
the
121.
A
So
that's
that's
sort
of
the
main
implementation
item
between
now
and
then
and
of
course,
I'll
keep
working
on
the
actual
library
getting
it
in
the
right
place
and
making
it
available,
but
that
that's
going
to
be
in
flux.
As
we
figure
out,
you
know
whether
we
can
make
it
a
side,
car
or
not
so
future
discussions
you
know,
can
we
make
it
a
side
car?
Does
it
need
to
remain
a
library?
A
Where
exactly
is
it
going
to
live
somewhere
in
kubernetes
csi
is
my
intention.
We
got
to
come
up
with
a
name,
so
so
that's
that's
what
I
had
for
for
today
and
it
sounds
like
I'm.
Gonna
have
to
do
more
effort
to
track
tim
down
and
get
a
meeting
scheduled.
I
will
see
if
I
can
get
him
to
come
to
the
next
one
of
these,
but
maybe
something
earlier,
maybe
something
later.
If
it
doesn't
fit
his
calendar.
A
So
elliott
do
you
know
anything
about
metrics
by
any
chance.
C
B
I
didn't
do
that
work
so
so
shan
chen
has
a
design.
Doc
grant
is
the
one
who
implemented
it.
You
can
take
a
look.
Okay.
A
A
But
I
want
to
do
that
because
yeah
it's
important,
it's
valuable.
B
Yeah,
so
just
basically
just
a
this
is
so
we're
checking
the
total
count
of
operations
and
also
like
the
duration,
how
long
it
takes
for
each
from
the
start
to
end
so
this
is
this
is
not
just
one
inside
car
inside
cars
already
covered
right,
so
this
is
the
snapshot
control.
Maybe
this
is
more
relevant
actually
for
you,
it's
just
like
an
independent
controller.
A
But
we
want
to
make
sure
that,
like
all
the
metrics
are
reusable
so
that
multiple
populators
don't
have
to
do
any
extra
legwork
to
get
the
metrics
right
so
yeah
I'll
to
figure
that
out
too.
B
B
A
Okay
yeah.
Thank
you.
A
B
A
Some
notes
and
and
I'll
start
working
on
getting
tim
to
show
up
to
the
next
meeting.