►
Description
Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 23 February 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
meeting
on
volume
populators
today,
our
main
agenda
is
to
go
over
tim's
feedback
for
the
cap
which
which
merged
provisionally-
or
I
don't
know
what
you
want
to
call
it
tim.
But
I.
B
Yeah,
it
did
merge,
but
we
just
wanted
to
basically
settle
and
settle
on
all
the
the
loose
ends,
and
so
I
I've
sort
of
gone
over
your
kept
feedback
and
and
made
five
points
out
of
out
of
what
you
wrote
we
should
go
over.
The
first
one
I
wanted
to
cover
was
the
the
question
of
whether
to
use
an
async
controller
or
a
validating
web
hook
for
pvcs
and
their
data
sources.
B
We
originally
did
have
a
validating
web
hook
that
would
throw
out
pvcs
with
data
sources
that
we
considered
invalid,
and
then
we
scrapped
that
and
went
to
a
async
controller
instead,
and
the
idea
was
that
you
know
in
kubernetes
generally,
you
want
to
be
able
to
declare
what
you
want
and
then
satisfy
the
dependencies
and
eventually
get
what
you
get
what
you
asked
for,
and
we
didn't
like
the
idea
of
like
if
someone
was
using
a
you
know:
declarative
get
up
style
workflow,
where
you
had
all
of
your.
B
On
the
basis
that
they
had
a
data
source
that
depended
on
a
volume
populator
which
wasn't
installed
yet
because,
typically,
what
would
happen
is
if
you
ended
up
on
a
kubernetes
cluster
that
didn't
have
the
volume
populator
to
satisfy.
The
specific
request
that
you
had
is
that
you
would
just
install
it
and
then
your
pvcs
would
get
populated,
and
so
so
it
seemed
better
to
have
an
asynchronous
controller
that
just
notifies
you
that
hey
there
is
nothing
that
is
watching
for
this
particular
data
source.
B
We
just
didn't
want
to
have
a
situation
where,
like
you,
created
a
pvc
with
the
data
source
and
like
you,
never
got
any
feedback
forever
and
you
didn't
know
what
was
wrong.
So
an
async
controller
felt
better
than
a
validating
web
hook.
For
that
kind
of
case,
and-
and
I
wanted
to
know
if
you
agree
or
if
you
have
a
different
opinion,
so.
C
Let
me
walk
you
through
my
thought
process
and
see
if
there's
a
conclusion
in
general
you're
right.
We
don't.
C
We
don't
always
hard
fail
on
things
that
are
trying
to
link
together
and,
like
example,
this
would
be
a
you
can
create
a
pod
that
references,
a
secret
and
a
secret
doesn't
exist
yet
right,
yeah
and
the
pod
will
delay
until
the
secret
is
available,
and
then
you
can
go
ahead
and
use
it,
and
that
gives
people
freedom
in,
like
you
said,
just
throwing
a
blob
of
yaml
at
the
server
and
letting
it
you
know,
reorder
how
it
needs
to
the
distinction
there
or
an
important
distinction
is
that
both
the
pod
and
the
service,
in
that
example,
are
user
owned
right
and
so
like
it's
entirely
likely
that
they
may
come
in
through
the
same
like
set
of
very
quick
operations
right,
maybe
the
same
git,
repo
or
something,
and
just
because
they
came
in
out
of
order,
doesn't
mean
that
they
won't
be
resolved
versus
depending
on
something
that
is
like
a
system
configuration
and
doesn't
exist
and
is
invalid.
C
We
have
examples
where
we
fail
on
those
sorts
of
things
too
right
like
if
you
ask
a
service
for
an
ip
address
that
is
outside
of
the
valid
range.
It
will
hard
fail.
You
at
service
creation
time,
because
that's
not
something
that
a
user
is
expected
to
be
able
to
rectify
for
themselves.
Now
I
say
that
and
at
the
same
time
our
api
is
filled
with
places
where
we
have
object,
refs
with
a
kind
and
the
kind
isn't
validated
at
synchronously.
C
So
if
I
reference
a
foo
bar
and
the
foo
bar
doesn't
exist
like
my
thing's,
just
not
gonna
work
or
it's
gonna
act
funny,
and
it's
really
up
to
the
controller
to
interpret
that.
However,
it
wants-
and
we
don't
have
any
formalization
around
that-
and
that
sort
of
feels
like
what
we're
talking
about
here.
Right,
like
you
just
haven't,
installed
the
fubar.
C
But
it's
a
little
bit
different
in
that
I'm
referencing,
something
that
does
exist.
I'm
referencing
a
pod,
only
a
pod
hasn't
been
registered
as
a
data
source,
so
it's
very
similar
in
form,
but
it's
a
little
different
in
the
details.
C
I
went
back
and
forth
in
my
head
about
that
trying
to
figure
out
what,
as
a
user,
what
would
I
expect
to
happen?
I'm
a
I'm,
a
big
fan
of
synchronous
errors
when
possible,
but
I'm
not
sure
that
that
doing
it
async
is
any
worse
than
what
we
do
in
other
places.
So
I'm
not
going
to
take
a
hard
opinion
on
this
at
the
end
of
the
day.
This
is
not
my
api
to
own
right
and
if
ux
is
problematic,
you'll
hear
about
it,
not
me
yeah.
B
B
B
C
C
C
Let
me
let
me
let
me
interject
one
more
one:
more
possibility
knowing
full
well
how
much
work
is
involved
in
setting
up
admission
controllers
and
everything
else
we
we
may
choose
to
shy
away
from
this,
but
one
of
the
things
that
I
think
is
interesting
that
was
added
recently
is
the
ability
to
do
api
level
warnings
now
ligit's,
not
here,
so
I
don't
know
how
he
would
feel
about
using
that
for
this
purpose,
but
perhaps
it
would
be
interesting
to
get
an
api
level
warning
that
says:
hey
I'm
going
to
take
this
pvc,
but
just
so
you
know
the
populator
that
you're
referencing
isn't
registered
like
it's
not
going
to
work
until
you
do
something.
A
C
To
do
that,
you
would
have
to
have
effectively
both
a
synchronous
and
an
asynchronous
controller.
You
would
be
defining
your
ux
in
terms
of
it's
going
to
work
asynchronously,
but
I'm
going
to
throw
a
synchronous
warning
instead
of
an
error.
I
don't
know
if
it's
worth
the
effort,
but
it
might
be
something
worth.
B
C
Yes,
so
you'd
have
to
write
register
the
web
hook
and
then
return
that
warning
block.
I've
not
done
that
myself
from
a
web
hook.
So
I'm
not
sure
exactly
what
the
mechanism
is,
but
I'm
pretty
sure
I'm
almost
certain.
You
can
do
that
from
moving
book,
and
now
I
like,
I
said
I
don't
know
how
jordan
would
feel-
that's
not
really
what
it
was
intended
for.
It
was
intended
mostly
for
things
like
api
deprecations,
hey
you're,
using
a
deprecated
fubar.
C
E
C
It's
generally
not
done
because
it's
just
not
going
to
be
efficient
right.
It
means
that
isn't
it
well,
it's
always
going
to
be
racy,
but
it's
just
not
super
efficient,
because
now
you
have
to
store
the
cache
of
all
the
other
things
that
you're
looking
at.
In
order
to
do
it,
we
do
do
stuff
in
a
few
places
like
we
have
the
admission
controller
for
setting
defaults
on
storage
classes
right
and
that
watches
all
the
storage
classes
and
keeps
an
in-memory
concept
of
who
is
the
default
and
and
modifies
things.
C
So
it's
not
like
we
never
ever
do
any
of
this,
but
with
validation.
Specifically,
we've
tried
to
set
the
the
rule
of
you
really.
You
want
to
be
isolated
to
the
individual
resource
partially,
because
just
the
rest
infrastructure
isn't
set
up
to
do
cross
object,
validation
by
the
time
you
get
down
into
the
validation
hook.
You
don't
always
have
access
to
the
things
you
might
want.
Often
a
web
hook.
I
mean
it's
kind
of
the
wild
west.
C
You
can
kind
of
do
whatever
you
want
and
as
long
as
it's
acceptable
performance
and
and
resource
footprint
like
who's
going
to
question
you,
I
would
encourage
you
to
try
not
to
if
you
can
avoid
it.
B
That's
good
feedback,
so
so
yeah,
let's
get
on
to
the
the
existing
behavior
when
this
data
source
field
was
introduced,
was
that
if
it
isn't
a
thing
that
that
that
the
api
server
wants
to
allow
it
just
zeros
it
out
and
you
get
an
empty
volume,
I
guess
we
can
all
agree
that
that
wasn't
the
best
design.
But
it's
what's
been
shipping
for
like
two
years
now.
B
So
so
the
question
is
what
what
to
do
once
this
new
any
data
source
feature
gate
gets
flipped
on
so
so
the
existing
implementation
of
the
any
data
source
feature
gate
is
when
you
flip
it
on.
It
starts
allowing
anything
except
a
core
object,
and
we
can
talk
about
that
about
the
decision
to
specifically
disallow
core
objects,
but
but
the
the
other
question
is
four
things
that
we
still
want
to
disallow
is
just
zeroing
it
to
match
the
existing
behavior
still
reasonable.
C
Zeroing
it
out
was
a
terrible
decision.
No,
I
I
mean
that's
that's
a
little
bit
heavy.
We
we
have
a
general
principle
that
we
don't
modify
user
input.
C
So
if
the
user
said
x
and
x
doesn't
work,
then
we
either
reject
it
outright
or
we
throw
events
or
something
we
fail
to
reconcile
or,
however,
we're
gonna
handle
it,
but
we
don't
just
wipe
it
out,
and
the
only
case
where
we
do
wipe
it
out
is
things
that
are
feature-gated
right.
So
part
of
me
wonders
if
this
is
like
a
vestigial
part
of
the
feature,
gating
logic
that
just
got
carried
over
or
something
I.
E
C
Yeah
right
so
so
we
like
really
we
shouldn't
ignore
user
input
and
even
I'm
sorry
there
there's,
let's
put
it
on
a
spectrum
right
like
the
worst
thing
to
do.
Is
you
to
erase
the
user
input
or
change
it
in
this
case
slightly
better
than
that
would
be
to
just
outright
ignore
it
right,
but
that's
still
pretty
pretty
hostile,
better
would
have
been
to
actually
say
whoa.
This
isn't
going
to
work
and
throw
an
event
or
something
and
then
ignore
it,
and
probably
the
correct
answer
would
have
been.
C
You
specified
something
that
I
don't
know
how
to
work
with.
I'm
not
going
to
work
and
that's
not
where
we
are
so.
The
question
now
is
a:
are
we
going
to
make
it
any
worse
and
then
b?
How
do
we
make
it
better?
So,
let's
not
make
it
worse.
I
don't
think
this
is
going
to
make
it
worse
right.
A
So
tim,
the
correct
behavior
I
was
saying
I
I
think
this
might
have
to
do
with
the
feature
gate,
because
initially,
when
this
was
introduced,
this
is
the
fiducated,
so
you
basically
remove
it.
If
the
feature
gate
is
so,
are
you
saying
maybe
that's
correct
when
it's
future
gated
when
we
remove
the
feature
gate
we
are
supposed
to
give
the,
but
but
then
that
that
makes
sense
right.
That's
why?
If
it's
a
feature
gated,
it's
not
supported,
then
we
then
we
right.
B
A
D
C
The
the
as
if
rule
or
as
if
not
exists,
rule
for
feature
gates
is
that
if
the
feature
gate
is
off,
the
system
should
behave
as
if
that
field
is
not
defined.
And
what
do
we
do
with
you?
Can
you
can
specify
anything
you
want
in
the
yaml
and
if
that
doesn't
map
to
a
field
that
we
understand,
we
just
discard
it
right.
C
So
if
the
feature
gate
is
off,
we
should
just
pretend
that
field
doesn't
exist
and
there's
a
little
asterisk
on
that,
because
we
have
to
retain
data
in
the
case
of
rollback
and
roll
forward.
So
there's
all
you
know.
If
you
look
at
all
the
drop
disabled
fields,
functions,
there's
always
the
if
not,
if
or
if
feature
gate
in
not
enabled
and
not
in
use
right
for
the
update
path,
but
the
correct
thing
to
do
when
the
gate
came.
C
Yes,
this
is
the
there's
a
problem
in
general
of
evolving
the
api,
with
new,
effectively
enumerated
values
and
having
a
feature
gate
right,
because
I
can,
I
can
pretend
a
field
doesn't
exist,
but
if
you're
adding
a
new
value
to
an
enumeration,
how
do
I
pretend
that
you
didn't
specify
an
invalid
value
on
an
older
version
right?
That's
exactly
what
we're
facing.
C
Yeah
and
we
don't
have
a-
we-
don't-
have
a
really
good
general
answer
for
that.
Honestly,
it
hasn't
come
up
often
enough
that
we've
had
to
really
deal
with
it.
In
this
case
I
would
say,
rule
number
one
is
be
compatible,
so
even
if
I
don't
like
the
existing
behavior,
we
should
probably
not
silently
break
existing
behavior
unless
we're
really
really
really
confident
that
this
is
not
in
any
way
being
used
or
dependent
on
and
even
then
we
probably
shouldn't
break
it.
C
What
we
could
do
is
separate
the
problems
so
in
the
new
model,
where
anything
is
allowed,
it's
anything
but
core,
and
if
you
specify
something
core,
we
will
retain
the
existing
behavior
and
we
will
create
a
new
cap
that
says:
how
do
we
fix
that?
We
shouldn't
have
been
ignoring
it.
We
should,
at
the
very
least,
be
throwing
events
and
api
warnings
right,
something
we
should
be
screaming
from
the
hilltops
you've
done
something
that
we
don't
understand.
F
C
F
C
B
Things
one
simple
way
to
do:
that
would
be
to
change
the
feature
gate
to
literally
allow
anything
so
that
we
never
discarded
the
user
input
but
then
modify
the
the
populator.
The
data
source,
validator
controller,
which
is
part
of
this
populator,
kept
to
explicitly
not
allow
populators
to
act
on
core
objects,
and
so
you
always
get
the
warning
that
says.
You've
specified
something
that's
not
valid
when
you
create
a
pvc
that
say
points
to
a
pod.
B
The
wrong
thing
right
and
the
difference
would
be
that
that
your
pvc
would
exist
and
it
would
have
a
data
source.
That
said,
you
know
pod
my
pod
with
an
api
group
of
the
empty
string
and
it
would
never
ever
bind
to
anything
because
we
would
explicitly
disallow
a
populator
from
acting
on
pods,
and
I
wanted
to
there's
a
brief
digression
about
why
we
wanted
to
disallow
core
things
and
it's
related
to
every
populator
has
to
have
a
unique
in
order
to
avoid
two
populators
from
every
stepping
on
each
other's
toes.
B
B
If
you
really
wanted
to
have
a
populator
that
knew
how
to
take
a
pod
and
turn
it
into
a
pvc,
you
would
have
a
new
level
of
indirection
in
the
middle,
like
some
new
crd
that
points
to
the
pod.
The
pvc
would
point
to
that
thing
and
then
the
populator
would
be
watching
for
that
thing
and
know
how
to
take
that
and
turn
it
into
a
pvc.
And
then,
if.
C
Somebody
says
it's
sort
of
an
intermediate
like
target
plus
policy
right,
the
the
effectively.
What
do
you
mean
by
a
pod
like
assignment
backup?
What
does
it
mean
to
take
a
snapshot
of
a
pod
that
could
be
interpreted
in
different
ways
right,
so
this
intermediate
type
is
both
a
statement
of
which
pod,
but
also
which
interpretation.
B
Yes,
yes,
so,
and
and
because
because
core
objects
are
sort
of
owned
by
the
community,
we
we
you
know
we
would
never
allow
them
to
be
directly
the
source
of
these
things
unless
it
was
like
a
core
populator
which
I
don't
think
anyone's
thinking
about.
Yet
so
as
long
as
all
the
populators
are
third
parties,
we
say
you
go
write
your
own
crd
and,
of
course,
those
aren't
going
to
be
core
objects,
so
it
seems
to
make
sense
to
just
exclude
them.
C
That
makes
that
makes
a
lot
of
sense
and
the
the
explanation
holds
water
for
why
we
would
not
want
to
or
why
would
require
this
intermediate
thing
that
makes
sense
to
me.
So
I
guess
what
I
really
want
to
see
here
is
some
documentation
that
says
this
is
the
existing
behavior
and
we're
working
on
a
cap
to
refine
the
existing
behavior.
We
shouldn't
break
existing
users.
C
If
there's
someone
out
there
who's
doing
the
wrong
thing
and
pointing
it
to
a
pod
and
their
pvc
is
working
happily,
like
suppose
I
put
pod
in
there
and
you
just
erase
pod
for
me
and
my
my
my
volume
is
created
and
I'm
happy
with
it.
Don't
break
that
user
right,
throw
a
warning,
throw
an
event,
do
something
to
make
some
noise.
That's
okay,
don't
break
them!
C
B
B
So
so
what
they're?
What
you're
saying
I
mean
today?
The
behavior
is,
if
you,
if
you
put
garbage
something
invalid
in
the
data
source
field,
you
we
zeroed
out,
and
you
end
up
with
an
empty
volume
and
what
you're
saying
is.
We
should
support
users
who
are
depending
on
that
ability
to
put
garbage
in
the
field,
because
that
that's
sort
of
exceptionally
strong
level
of
backwards
compatibility
to
say,
even
if
people
are
throwing
garbage
at
us,
we
should
continue
to
accept
the
garbage
and
behave
good.
C
Yes,
but
that
is
the
bar
that
we
really
want
to
meet.
I
think
okay,
like
we
should
never
have
accepted
the
garbage
in
the
first
place,
but
we
have
to
live
with
our
mistakes
right.
B
But
I
mean
part
of
the
evolution
of
this
new.
Any
data
source
field
is
some
stuff.
Will
you
know
some
some
stuff
that
you
threw
at
us
that
would
have
resulted
in
getting
an
empty
volume,
will
now
result
in
waiting
for
a
populator
to
do
something
so
like
we
are
changing
the
behavior
for
the
data
cells
that
contain
pointers
to
actual.
C
Things,
yes,
but
you
would
have
also
had
to
have
registered
that
thing
as
a
data
populator,
which
seems
like
it's
unlikely
enough
to
happen
in
complete
isolation,
especially
given
that
you're
saying
you
can't
attach
a
populator
to
a
pod,
you
have
to
attach
it
to
an
intermediate
thing
right
and
that
intermediate
thing
can't
be
core.
So
somebody
intentionally
created
that
intermediate
thing
registered
that
crd
registered
it
as
a
valid
populator
right,
like
the
sort
of
confluence
of
those
things
all
happening
and
me
having
specified
garbage,
seems
so
diminishingly
small.
B
Yeah,
I
think
it's
it's
subjective,
because
because
you
could
make
the
same
argument
about
core
objects,
you
know
there's
like.
Why
would
someone
have
put
a
core
object
in
there
if
they,
if
the
behaviors
are
always
going
to
get
an
empty
volume,
they
should
have
quickly
figured
out
that?
Oh,
it's
ignoring
this
thing,
I'm
not
going
to
put
that
core
object
in
the
field
anymore.
C
C
So
so
this
is
there's,
let's
break
it
in
the
two
parts.
There's
the
I
put
a
core
object
in
there,
which
previously
would
get
wiped
out
right,
yeah,
yeah,
but
a
non-core
object
would
not
get
wiped
out
right.
B
Well,
that's
the
problem
is:
is
today
when
the
when
the
out,
when
the
feature
gate
is
still
alpha
and
turned
off,
you
also
get
an
empty
volume,
and
when
you
turn
this
feature
gate
on,
what
we're
going
to
do
is
we're
going
to
start
allowing
those
data
sources
through
and
and
you
won't
get
an
empty
volume.
You
will
either
get
what
you
really
asked
for.
If
there
is
a
populator
or
you'll
get
nothing.
If
there's
no
populator,
you
won't
get
an
empty
volume.
B
So
and
it
has
to
work
that
way
so
that
we
can
allow
new
populators
to
be
written,
we
have
to
say:
well,
you
know
what,
if
you
put,
if
you
put
a
put
something
in
there,
I
mean
I
guess
we
do
like
a
mutating
web
hook.
That
says
you
know
if,
if
there
is
a
populator
allow
it
through
and
if,
if
the
populator
hasn't
been
registered,
emulate
the
old
behavior
by
zeroing
it
out
and
giving
them
an
empty
volume.
That
would
be
the
only
way
to
really
maintain
strong
backwards
compatibility.
But
that's
that's
reimplementing.
C
Okay
right,
that's
that's
a
good.
C
C
I'm
not
sure
what
I
want.
I
don't
what
you
just
described
is
probably
the
farthest
thing
from
what
I
really
want.
I'd
like
to
see
a
path
towards
more
normal
behavior.
I'm
sorry.
F
Go
ahead,
oh,
I
was
just
gonna
ask
a
question
which
is:
if
we
keep
the
user
value
and
then
when
a
volume
populator
is
not
found,
it
goes
and
creates
an
empty
volume
that
would
preserve
the
behavior
and
we
would
start
to
save
that
thing
and
we
can
asynchronously
alert
the
user.
That
says
you
have
this
thing
and
it
can
move
us
in
that
direction.
Or
am
I
missing
a
huge
piece
of
this?
I
apologize
if
I
am.
B
To
to
implement
that
behavior
would
require
like
changing
the
csi,
sidecars
and
stuff,
but
it's
I
think
it
might
be
possible.
But
it's
also
a
weird
idea:
I'd
have
to
think
that
one
through
to
basically
preserve
the
input,
but
I
mean
not
discard
the
input
but
preserve
the
behavior
of
you
still
get
an
empty
volume.
If,
if
we
can't
figure
out
what
it
is,
I
I
worry
about
how
the
strange
behaviors
that
will
occur
for
like
populators
that
that
do
exist,
but
weren't
registered.
Yet
at
the
moment
you
made
the
request.
C
C
If
you
retain
the
value
but
do
something
different,
then
that
is
impossible
right.
If
if
this
goes
a
little
bit
back
to
the
is
it
user
controlled
or
system
controlled?
But
if
I
registered
with
a
populator
from
a
foo
bar
and
it
doesn't
exist
and
I
get
an
empty
volume
and
then
my
pod
doesn't
do
what
I
wanted
to
do,
because
the
foo
bar
isn't
initialized.
C
If
the
volume
isn't
initialized
from
the
from
the
foo
bar,
then
I
call
my
administrator
and
say:
oh
right,
you
need
to
install
this
fubar
extension
and
then
they
do.
And
then
I
have
to
tear
down
everything
I've
done
and
do
it
over
again.
B
You're
using
kubernetes
120
and
the
feature
in
the
feature
gates
turned
off
and
you
try
it
that's
exactly
what
will
happen
because
we
just
discard
the
the
data
source
that
we
don't
know
about
the
the
difference
is
there
will
be
no
record
in
the
pvc
that
you
ever
asked
for
anything
it'll.
Just
look
like
you
asked
for
an
empty
volume,
so
we
could
change
that
aspect
of
it.
B
C
C
It
worked
in
the
sense
that
it
didn't
fail,
which
isn't
the
same
as
working
correctly,
but
it
didn't
fail.
So
they
went
about
their
business
and
they
forgot
entirely
that
they
put
that
data
in
there
and
it's
now
checked
into
their
git
or
whatever
and
at
some
point
in
the
future
they
will
try
to
do
it
again
and
that
operation
that
used
to
succeed
will
now
fail,
and
the
question
is
a:
is
that
likely
and
b?
Do
we
care
enough
to
jump
through
the
hoops
to
try
to
be
compatible?
C
I'm
going
to
set
a
really
high
bar.
We
are
going
to
run
out
of
time.
It
turns
out.
I
want
to
set
a
really
high
bar
for
compatibility,
but
I
also
want
to
be
realistic
if,
if
you
think
that
this
is
a
completely
nonsensical
situation-
and
you
can
actually
claim
like
that
was
a
that
was
a
bug,
then
I
want
to
give
you
some
degrees
of
freedom
to
try
to
to
do
the
right
thing,
but
I
I
just
want
to
emphasize
like
if
you
can
be
compatible.
You
should.
B
Yeah
we
can
be
compatible,
but
it
means
the
long-term
behavior
will
always
be
a
little
weird
and
I
don't
think
we'll
ever
get
to
the
the
great
place
we
would
like
to
get
to
unless
we
make
some
sort
of
break
with
the
past
and
and
if
we're
going
to
make
any
break
with
the
past
like
this
might
be
the
time
to
do
it.
B
Yeah
like
before,
we
start
telling
people
like:
oh,
you
can
put
stuff
in
the
data
source
field.
That's
not
a
snapshot
or
another
volume
and
you're
going
to
get
this
new
behavior
and
we're
going
to
tell
all
the
deployers.
You
need
to
install
this
new
controller
and
this
volume
populator
crd.
This
is
the
mechanism
of
registering
them.
B
You
know
when
we're
doing
that
might
be
a
good
time
to
sort
of
say:
okay,
you
know
if
you're
putting
garbage
in
the
data
source
field,
we're
not
going
to
zero
it
out,
for
you
anymore
and
you're,
going
to
start
getting
unbound
pvcs
instead
of
empty
pvcs
and-
and
I
I
incredibly
claim
that
that
was
a
bug.
B
I
I
believe
that
that
nobody
intended
that
to
happen.
We're
all
here
saying:
no,
that's
not
what
we
wanted
to
do.
It
just
was
a
side
effect
of
the
feature
gate
process.
As
we
implemented
volume,
cloning
and
snapshot,
cloning.
C
So
perhaps
it's
a
reasonable
path
then,
to
let's
lean
on.
Let
me
just
throw
the
suggestion
out.
Don't
take
this
as
hard.
Let's
do
it
but
think
about
what
if
we
had
a
a
new
cap,
that
simply
was
don't
wipe
populator
fields
when
they
are
not
recognized
right,
and
we
call
that
a
distinct
thing
like
this
was
a
bug.
It
was
an
error.
B
C
Well,
so
that's
the
rub:
isn't
it
I?
Obviously
the
enhancement
freeze
has
come
and
gone.
I
I
wonder
what
the
enhancement
folks
would
say
about
taking
a
cap
and
actually
splitting
it
into
two
for
tracking
purposes.
Right
like
these
are
really
they
were
lumped
together.
We
really
want
to
distinguish
them
because
we
want
to
discuss
them
independently
and
we
think
they
deserve
independent
release
notes.
C
I
think
we
can
make
a
case
for
we're,
not
adding
a
new
enhancement,
but
we
are
coming
up
with
more
fine-grained
tracking
of
it.
I
don't
know
what
they'd
feel
about
it,
but
I
think
it's
worth
asking:
okay.
C
Fixing
then
I
can't
call
that
a
bunch
we
can
call
it
a
bug
fix,
but
this
is
a
of
enough
scope
that
I
think
a
kepp
is
worth
a
cap
is
how
you
get
release
notes
right.
That's
like
the
most
important
way.
It's
not
the
only
way,
but
it's
the
best
way
to
get
a
visible
release
note
and
and
to
raise
this
to
the
attention
of
people
who
might
care
about
this.
So
I.
C
C
I
can
I
can
do
the
first
half
next
week.
I
can
do
10
to
10
30.,
that's
great,
that's
great
yeah!
So
I,
let's
take
the
action
item
to
reach
out
to
somebody
on
the
enhancement
side.
I
don't
know
exactly
who
you
want
to
talk
to,
but
but
just
jump
on
the
slack
channel
first
for
enhancements
and
like
let's
open
a
discussion.
This
is
a,
I
think,
uncharted
territory
and
we
want
to
get
their
feeling
for
how
they
want
to
handle
it.
A
C
Because
I
don't
want
to
work
around
them,
but
strictly
speaking
this
cap
is
already
in
so
we
could
lump
it
in
with
this
cap
and
be
within
the
letter
of
the
law.
But
I
don't
feel
like
it's
within
the
spirit
and
I'd
rather
be
within
the
spirit.
If
we
can.
B
D
B
Not
so
important,
thank
you
and,
and
I'm
also
late
for
a
meeting,
so
I
think
we
probably
all
have
to
drop
all
right
thanks.