►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG)
PVC DataSource Design Discussion 27 August 2019
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
A
Continue
the
discussion
that
we
started
yesterday
on
pbc
datasource
to
set
some
background
again.
The
volume
snapshot
and
volume
clone
features
are
currently
moving
to
beta
on
the
and
inside
the
PVC
object.
We
have
an
inline
data
source
which
allows
you
to
specify
either
snapshot
or
volume,
a
PVC
volume
for
cloning
as
a
source,
and
we
plan
to
expand
that
in
the
future
to
allow
any
general
type
of
data
source
any
type
of
C
or
D.
A
A
Basically,
the
things
that
define
an
application
checked
in
to
your
your-your-your
source
control,
and
when
you
deploy
it
on
to
a
cluster,
you
don't
have
to
modify
it
at
all,
which
is
kind
of
the
thinking
behind
the
git,
ops
principles
or
git
ops
way
of
doing
the
counter-argument
to
that
as
well.
Something
needs
to
create
your
volume
datasource,
and
you
know
what
is
that
something
and
how
do
you?
How
does
that
get
checked
in
and
I
think
my
argument
to
that
is
well,
you
know
you
can
have
something
like
a
controller.
A
That'll
automatically
create
the
volume
data
source,
but
then
the
question
is
well.
How
does
that
controller
know
how
to
create
the
volume
datasource
and
it
needs
some
input?
It
needs
something
to
tell
it
what
to
do
and,
though
that
something
is
likely
going
to
be
a
CR
D
and
those
CR
DS
need
to
be
checked
in
and
I
think
that
is
okay,
because
that
C
Rd
could
be
something
like
a
policy
or
something
generic
to
say:
hey,
please!
You
know
inject
in
inject,
the
current
latest
snapshot
the
counter-argument
that
I've
heard
to
this
is
well.
A
The
problem
with
that
approach
is
that
it
requires
you
at
deployment
time
to
have
enough
information
to
make
that
make
that
call
and
versus.
If
you
have
something
like
a
standalone
volume
data
source,
you
could
have
a
controller
that
has
you
know
all
the
fun
of
rich
functionality,
of
what
kubernetes
components
are
capable
of
doing
to
make
a
decision
at
runtime
about
what
that
data
source
should
be.
It
could
Cori.
A
You
know
a
back-end
to
figure
out
what
are
the
volume
sources
of
volume
snapshots
that
are
available
in
that
cluster
was
the
topology
of
that
cluster.
You
know
rich
information
from
inside
that
cluster
to
make
that
call
versus
if
you
were
forced
to
do
it
at
deployment
time
you
kind
of
have
to
to
at
deployment
time.
You
have
to
somehow
be
able
to
have
enough
information
to
make
that
call
either
like
call
out
to
the
backend
and
I.
A
Don't
think
you'll
have
enough
at
that
point,
honestly,
on
the
counter-arguments
for
data
source,
other
counter-arguments,
our
timeline
for
a
clone
and
snapshot
snapshot
has
already
been
out
for
a
long
time,
and
you
know
they're
trying
to
move
to
beta
this
quarter.
If
we
go
down
the
path
of
potentially
saying
hey,
we
want
to,
you
know,
do
a
whole
new
standalone
object.
A
B
And
I
asked:
has
there
been
any
any
thought
into
specifically
what
a
policy
might
look
like?
I
asked,
because
here
it
it
seems
fairly
abstract,
but
it
also
seems
super
crucial
to
how
all
of
this
would
work
like
if
we're
saying
that
the
data
source
is
created
from
some
policy,
but
we're
not
discussing
the
policy
I
think
that's
kind
of
leaving
out
a
huge
part
of
the
picture.
Yeah.
A
I
think
we
can
start
talking
through
it
kind
of
straw
man,
rough
design.
I
was
thinking
some
controller
which
spits
out
data
volume,
data
source
objects.
It
has
some
input,
a
policy
that
it
accepts
to
say
you
know
this
is
this
is
how
I
will
select,
which
data
source,
which
volume
data
source
to
pick
details
of
that
I
honestly
haven't
thought
through,
but
we
can.
We
can
talk
through
it
in
this
meeting.
C
And
and
in
your
example
of
I'd
like
to
be
able
to
check
this
everything
in
to
get
with
the
data
sources,
a
separate
object,
then,
even
on
your
first
deployment,
you
would
need
to
construct
data
sources
with
like
an
empty
data
source
for
every
one
of
your
volumes.
Wouldn't
you
like
in
the
default
case
and
you're,
not
restoring
from
something
yeah.
A
C
C
Doesn't
seem
like
a
crazy
thing
to
do.
I
mean
I'm
not
familiar
with
this
get-ups
workflow,
but
is
that
an
would
that
be
a
reasonable
requirement
to
add
on
and
say,
okay,
look,
don't
check
your
data
sources
in
we're.
Just
gonna
create
PVCs
the
points
to
data
sources
that
don't
exist,
and
then
you
got
to
go
figure
out
what
to
put
there
and
that's
that
wouldn't
annoy
anybody
or
would
people
to
start
checking
in
the
data
sources
too.
And
then
you
have
the
you're
back
to
the
original
problem
of
now.
Having.
A
A
D
We
would
want
to
impart
upon
users
even
just
creating
these
null
objects
to
support
a
workflow.
That's
outside
how
we
normally
do
storage
I
mean,
if
not,
everyone
is
going
to
support
the
get-ups
workflow
right.
If
we're
talking
about
multi
cluster,
not
that
I,
don't
think
it's
a
bad
idea,
but
I
feel
like
we're
positioning
ourselves
to
do
something
outside
that.
D
E
A
A
A
The
purpose
is
like,
if
you
specify
a
data
source
object,
kubernetes
knows
to
wait
for
the
existence
of
that
data
source
object
before
it
does
something.
It's
kind
of
the
standard.
Kubernetes
model
of
like
I
can
apply
a
bunch
of
llamo
files,
all
in
parallel
without
worrying
what
order
I
apply
them
in
and
kubernetes
does
the
right
thing,
and
so,
if
I
have
a
reference
to
a
data
document.
D
F
A
And
the
big
difference
is
that,
yes,
we
always
plan
to
open
up
the
types
that
we're
going
to
allow
for
data
source
to
be
any
arbitrary,
C
or
D.
What
we're
saying
now
is
that
there
is
a
special
type.
Data
source
is
a
special
type
that
all
the
kubernetes
controllers.
All
the
CSI
controllers
know
how
to
handle
specially,
and
the
benefit
of
that
extra
level
of
indirection
is
that
we
can
differentiate
between
I
have
a
PVC
where
I
don't
care
about
the
data
source,
meaning
I
did
not
specify
a
data
source
at
all
versus
I.
A
F
Two
things
about
that,
so
I
don't
agree
that
you
can't
do
that
with
the
other
option,
but
the
problem
with
tying
it
into
something
that
kubernetes
understands
is
we
run
into
the
same
problem
that,
in
my
opinion,
we
have
today
where
we
limit
the
ability
for
people
to
actually
develop
any
of
their
own
custom,
C
or
needs.
So
they
can't
do
this
extension
on
their
own.
A
Oh,
they
definitely
can
so
everything
that
we're
talking
about
here
with
populate
errs
and
snapshots,
and
all
of
this
it
would
still
continue
to
exist.
It
would
just
be
defined
in
a
separate
data
source
object.
So
if
you
look
at
what
we
have
for
data
source,
currently
its
name
kind
and
API
group-
we're
a
kind
and
API
group
are
going
to
point
to
some
CRD.
The
plan
is
to
move
those
into
the
new
volume
data
source
object,
so
you
still
have
the
ability
to
do
exactly
the
same
thing.
A
A
A
Because
I
think
in
my
head,
a
persistent
volume
claim
is
kind
of
defining.
Here
are
my
kind
of
minimum
storage
requirements
and
then
jamming
in
there
here
is
what
I
want
the
data
to
look
like
starts
getting
very
messy,
and
if
we
extrapolate
that
out,
it's
gonna
probably
put
us
in
a
place
that
we're
gonna
end
up
regretting,
and
so,
if
we
decouple
that
put
it
into
a
separate
object,
gives
us
more
flexiblity
create
these
objects.
Dynamically
and
you
know
in
general,
flexibility
and
an
extensibility
tend
to
have
have
treated
us
well
in
the
past.
H
Step
back
a
little
bit
so
the
use
case
for
this
is
not
really
well
understood
and
there's
a
lot
of
you
know
contention
on
whether
they
get
use
case
is
sufficient.
Like
other
people
made
the
arguments
you
can
just
not
check
in
the
PVC
or
not
checking
the
data
source
and
to
kind
of
delay.
You
know
well-known
use
cases
like
clone
and
snapshot
for
something
that's
not
yet
well
understood
seems
unnecessary
that
and
it
doesn't
prevent
you
to
add
this
later
in
the
future.
So
you
can
just
have
a
new
kind.
H
A
A
The
drawback
of
that
approach
is
that
snapshots
in
cloning
will
have
two
ways
of
doing
of
being
able
to
be
specified.
You
could
either
specify
them
directly
in
line
or
in
a
separate
object,
and
that
may
be
confusing
to
users,
but
the
benefit
of
this
approach
is
that
it
would
allow
us
to
decouple
the
timelines
and
continue.
You
know
not
block
snapshot
or
volume
cloning
I'm
open
to
that
option.
What
do
we?
What
do
folks
think
I.
I
I,
what
I
actually
mean,
though,
is
like
today
with
like
not
even
considering
this
restoring
a
stateful
set
is
hard
with
the
inline
data
source
because,
because
in
your
application,
you're
not
actually
going
to
define
individual
PVCs,
you
just
defined
the
stateful
set
and
the
stateful
set
is
the
one
that
creates
the
PVCs
so
like.
If
every
single
volume
wants
to
be
restored
from
a
different
snapshot,
I
think
that's
not
really
possible.
Today,.
H
A
Think
the
benefit
in
that
case
would
be
that
the
responsibility
of
the
state
full
set
controller
just
becomes
very
simple.
The
stateful
set
controller
does
what
it
does
for
PVCs,
which
is
create
templatized
name
and
stick
like
a
one-two-three
suffix
on
it,
and
then
it's
the
responsibility
of
some
other
controller
to
then
come
in
and
make
sure
that
those
objects
exist
right
now.
A
You've
decoupled
the
responsibility
instead
of
for
acquiring
the
PVC
or
the
stateful
set
controller,
or
whatever
creates
the
PVC
to
understand
every
type
of
data
source
and
be
able
to
give
you
the
rich
information
for
that
data
source.
They
can
then
basically
outsource
the
responsibility
of
specifying
the
details
of
the
data
source
to
some
other
controller.
J
I
J
Differ
that
much,
if
you
have
the
current
design,
you
basically
just
need
to
specify
a
kind
or
that's
the
extra
thing
that
you
want
to
remove
and
you
could
still
use
the
template
for
the
names
even
with
the
current
current
design
right.
So
the
only
thing
is
you
want
to
get
rid
of
the
kind
and
a
pure
group.
You
only
be
the
name
there.
I
think.
J
I
J
H
J
A
I,
don't
think
actually
talking
through
this
a
I
think
you're
right.
It
doesn't
help
the
state
that
case
as
much
as
I
thought.
It
would
because
you're
right
if
you
could
just
template
eyes
the
name
and
hard-code
the
kind,
an
API
group
effectively
you
would
get
the
same
behavior
then
some
other
component
can,
instead
of
creating
the
datasource
object,
would
be
responsible
for
creating
the
snapshot,
object
or
the
clone
object.
The
only
benefit
you
get
from
having
the
level
of
indirection
is
that
a
secondary
controller
could
create
the
volume
data
source
object.
F
I
I
F
Right,
but
the
point
I
was
trying
to
make
earlier
is
is
is
again
with
the
existing
model,
if
you're
pointing
that
to
a
CR
D
anyway,
then
your
your
external
controller
can
do
this,
and
you
have
this
exact
same
thing.
That's
on
this
slide
right
here.
It's
just.
Instead
of
kind
volume,
datasource,
it's
kind,
steep.
I
I
I
F
A
Think
I
think
Michelle's
argument
is
around
having
a
mapping.
So
if,
if
you
go
down
the
path
that
you're
proposing,
what
you're
saying
is
that
the
name
of
volume
snapshot
objects
has
to
match
what
the
PVC,
or
that
the
stateful
set
expects.
So
normally
like
Michelle
was
saying,
if
you're
creating
a
snapshot
you're
creating
a
snapshot
foo
with
some
timestamp
in
the
name
right.
H
A
H
A
F
A
A
L
M
Question
so
we've
been
talking
well,
I
am
here
just
from
time
to
time
circuit,
so
we're
talking
about
the
Colonna.
We
tried
I
think
at
some
point
to
discuss
replication,
Metron,
remote,
replication
and
I.
Remember
some
discussions
where
we
spoke
about
the
data
source
and
and
try
to
combine
replication
to
will
the
work
we're
doing
today.
M
I've
heard
today
that
you
guys
are
saying
that
we
need
to
look
at
the
use
cases
to
make
a
proper
decision.
I
think
it's
correct.
Maybe
we
can
quickly
take
a
look
at
how
how
the
storage
machine
and
kubernetes
will
we'll
do
this
work
for
the
user
in
snapshot
and
clone,
and
maybe
we
can
discuss
a
little
bit
of
replication,
which
I
don't
think
we
covered.
Maybe
I
am
NOT
up
to
speed
your.
N
This
is
a
Kurdish.
In
the
past
we
tried
to
use
CSI
driver
to
make
a
workflow,
which
nation
arkov
work,
where
we
would
create
thousands
of
volumes
essentially
which
are
used
as
part
of
a
machine
learning
pipeline,
and
the
fact
that
we
cannot
run
time
tell
all
if
you
want
to
use
was
a
big
limitation
and
ephemeral
volume
seemed
to
be
the
only
solution.
So
how
does
does
this
help
in
any
way
in
addressing
workflows,
frenched
I'm.
J
J
I
D
A
And
I
think
there's
a
compromise
here
where
we
I
like
what
John
is
saying,
which
is,
we
can
kind
of
have
our
cake
and
eat
it
too
by
saying:
what's:
unblock
snapshot
and
volume
cloning,
let
it
do
what
it's
doing
right
now.
If
we
think
that
having
a
separate
data
source
object
is
useful,
we
could
introduce
it
into
the
third
type
and
then
you
know
it'll
be
a
little
bit
more
confusing
for
users,
but
it'll
give
us
the
flexibility
of
velocity
I
said.
J
A
If
you
do
that,
then
you
can
only
specify
you
can
only
specify
your
volume
source
in
line,
and
so
all
these
little
subtle
things
that
we're
talking
about,
like
the
the
stateful
set
case
right,
like
I,
understand
what
Michelle
is
getting
at.
If
you
prove
in
a
bunch
of
snapshots,
you're
gonna
provision
them
with
a
certain
format
and
you're
gonna
have
to
incrementing
bits
inside
of
that
name,
one
is
going
to
be
the
you
know
the
the
identifier
for
that
particular
volume
type
like
1,
2,
3
4.
A
It
corresponds
to
the
stateful
set
replicas
and
the
second
is
going
to
be
the
timestamp.
And
now
that
should
be
your
volume
snapshot
name
in
making
that
embedding
that
logic
into
a
snapshot,
controller
to
inject
into
a
data
source
in
line
name
is
going
to
be
very
challenging.
So,
for
example,
in
this
case,
if
you
have
snapshot,
you
know
timestamp
1,
the
the
problem
is
that
now
you
fixed
this
snapshot
to
always
use
a
specific
timestamp.
G
A
A
That's
exactly
the
use
case
that
I
was
talking
about
here,
so
if
you
like,
if
we
have
a
separate
standalone
type,
you
can
imagine
that
the
snapshot
controller
for
each
one
of
those
volume
for
vault,
PVC,
1,
PVC,
2
PVC
3,
creates
a
new
snapshot.
That'll
be
PVC
1,
some
time
stamp,
PVC
2
that
same
time
stamp
or
whatever
and
in
creating
those
the.
F
Use
a
github
controller
or
github
kind
for
the
github
workflow,
which
was
the
initial
problem
for
the
stateful
snapshot
controller,
and
that
should
do
things
like
when
it
creates
the
snapshot.
It
should
do
things
like
give
it
a
timestamp
that
includes
the
stateful
set
ID
or
whatever
it
is
to
signify,
which
one
it's
from.
How.
F
F
My
view
I
haven't,
looked
at
it
like
in
an
implementation
perspective,
yet
there
might
be
you
you
wouldn't
put
any
of
that
in
there.
What
you'd
look
for
is
basically
just
listening
for
snapshot
requests
any
time
it's
all
on.
It
would
check
to
see
if
that
volume
that
was
being
snapshot
was
part
of
the
sample
set.
F
A
Whatever,
whatever
it's
called
right
right,
but
so
now,
if
there's
two
variables
here
right,
one
variable
is
the
replica
number
and
the
second
one
is
the
the
timestamp
for
that
volume
snapshot.
So
is
the
assumption
that
you're
going
to
hard-code
the
timestamp
in
here
and
then
let
up
people
said
no
I.
F
A
F
F
I
am
arguing
I'm
postulating,
that
if
we
just
remove
the
restrictions
on
the
data
source
type,
the
typed
local
object
or
whatever
it's
called
yeah
logo
object
reference.
If
we
just
remove
that
and
rely
on
series,
we
can
implement
exactly
what
you
have
here.
It
just
won't
have
the
same
kind:
it'll
have
a
you
I
think
is
okay,.
A
A
A
F
F
A
A
D
A
F
Yeah
I
get
it
so,
but
that's
the
thing
is
inside
of
the
controller
that
handles
this
when
it
creates
the
PVC,
why
why
isn't
it
good
enough
to
just
have
it
so
it
creates
the
PVC.
If
we
introduce
the
new
state
that
says,
pending
initialization
or
whatever,
whatever
we're
going
to
call
it,
it's
not
actually
ready
for
use
until
this
is
actually
satisfied,
and
then
it's
a
declarative
system
again.
How.
A
Does
it
does
it
does
so?
We
want
to
laughs,
hurt
possible
two
possible
ways
of
using
data
source.
One
is
what
you're
suggesting,
which
is.
There
is
a
third
party
external
popular
that
fills
data
and
there's
some
storage
controller
that
provisions
the
volume.
But
we
also
want
to
allow
for
the
case
where
the
populate
ur
in
the
storage
system
are
the
same
and
are
handled
by
the
CSI
driver
alone.
Right.
A
F
A
E
Yeah
I'm
starting
to
understand,
because
with
the
volume
data
source
you
can
have
special
meaning
for
the
snapshot,
the
volume
snapshot
kind
within
the
data
source
spec
and
for
the
for
the
to
do
clones
and
snapshots.
But
then
you
could
also
have
handling
with
just
a
plain
CRD
that
that
wouldn't
need
to
be
recognized
by
CSI
drivers.
Yeah.
F
So,
in
the
way
that
works
today
is
I
can
pass
in
and
I
actually
have
prototypes
if
it's,
if
it's
a
type
that
isn't
reported
in
the
capabilities
of
the
back
end
device,
then
it's
just
a
pass-through
operation.
It
goes
to
pending
and
it's
up
to
that
external
controller
to
go
ahead
and
complete
the
operation,
a
big
but.
A
The
external
controller,
remember
that
these
external
controllers,
that
we're
talking
about
are
like
the
external
provisioner,
for
example,
you
you
can't
have
it
operate
on
unknown,
CR
DS.
No,
it
doesn't
that's
the
point
it
so
then.
Let's
walk
through
this
example
that
you
have
here,
which
is:
let's
introduce
a
new
type,
we're
gonna
call
it
foo
and
what
it
represents
is
a
mapping
between
data
source
and
volume
snapshot
right.
C
F
C
A
The
reason
that
this
is
possible,
if
we
have
a
standalone
data
source,
is
because
the
existing
controllers
that
we
have
know
that
if
some
data
source
is
specified,
I,
don't
know
what
it
is
versus.
The
data
source
not
being
specified
at
all
are
two
different
things.
So
if
I
specify
a
data
source
and
that
doesn't
exist,
then
it's
going
to
hold
off
on
provisioning
altogether
and
you
have
the
ability
to
basically
interject
at
that
point
and
do
something.
A
A
C
That
that's
that's
the
separate
discussion
that
we
aren't
having
that
I'd
like
to
have
it
but
I
I.
Wouldn't
this
discussion
I
wanted
to
get
back
to
the
question
of
timing,
because
I
I
really
don't
like
the
answer
of:
let's
have
our
cake
and
eat
it
too,
because
that's
gross
API,
I,
think
I
think
we
can
all
agree
that
there's
this
separate
volume
data
source
object,
whether
it's
necessary
or
not.
It
certainly
does
make
anything
worse.
So
it's
a
question
of.
C
A
C
F
Call
it
something
different
right,
because
the
only
problem
that
it's
that
it's
really
geared
towards
fixing
is
the
the
split
brain
problem
of
the
the
snapshots
at
least
right
now.
So
you
know
if
it
comes
down
to
it
and
we
decide,
we
have
to
do
something,
you
can
always
call
it
you
and
you
want
to
introduce
a
new
kind.
A
new
you
know,
solid
API
object,
then
give
it
a
different
name.
I
mean
I.
A
Mean
I
think
naming
is
fine,
but
I
like
walking
through
the
concrete
use
cases.
I
think
there
is
a
gap
here,
especially
with
stateful
set
that
is
not
handled
with
the
existing
proposal
and
like
this
proposal
like
an
arbitrary,
like
food
type,
that'll
handle
this
I,
don't
know,
I'm,
not
convinced
that
that
would
work.
My.
D
Only
reservation
and
your
preganant
raw
lies
here,
but
is
that
having
it
be
in
the
persistent
volume
claim
when
we
want
to
do
something
besides
volumes
makes
it
restrictive,
but
I,
don't
think
that
that's
based
on
anything
that
we're
currently
doing
or
going
to
do
so.
Is
it
fair
to
say
we
could
hatch
out
the
use
cases,
look
at
the
pros
and
cons
and
then
push
this
out,
maybe
just
a
quarter
to
make
those
decisions
instead
of
committing
to
this
and
pushing
snapshots
and
cloning
out
three-quarters
I
mean,
what's
what's
the
yeah.
A
E
Can
can
volume
data
source
or
data
source
reference
or
whatever
we
end
up,
calling
it
just
be
implemented
as
a
see,
and
then
we
can
just
do
it
later.
I,
just
don't
understand
why
you
could
cuz.
Perhaps
if
you
have
that,
then,
if
the
reference
is
of
unknown
type
than
that
could
kubernetes
could
still
pass
that
reference
onto
the
CSI
drivers
through
the
object
through
the
reference,
if
you
will
or
through
the
indirection.
E
A
A
And
then
we
need
to
also
make
sure
that
stateful
sets
is
part
of
that
picture
and
whatever
we
come
up
with
so
I
guess
it
sounds
like
action
items.
Are
we're
gonna
continue
the
deep
dive
into
this
area
to
see
if
it
makes
sense
to
have
a
standalone
volume
data
source
that
would
be
introduced
as
a
separate
CRD.
A
In
the
meantime,
we
are
going
to
unblock
snapshot
and
unblock
volume,
cloning
to
continue
to
beta
this
quarter
if
they
can
make
it
or
next
quarter
and
then
before
we
introduce
data
populate
errs,
which
is
currently
in
design.
We
need
to
finish
the
discussion
on
this
generic
volume
data
source
and
make
sure
it
aligns
with
that
proposal
as
well
as
what
we
want
to
do
with
stateful
sets.
Does
anybody
object
to
that?
It's.
A
Yeah,
that's
a
good
question
Sergey
if
we're
handling
it
currently
separately.
Michelle
and
I
have
been
bouncing
ideas
off
each
other
about
how
to
handle
replication,
as
well
as
volume,
consistency,
groups
and
other
things
and
kind
of
a
strawman
between
us
around
a
new
volume
group
object
which
you
could
think
of
as
similar
to
kind
of
a
storage
class
in
PV
in
some
excel.
A
Arbitrary,
you
know,
storage
system
define
properties
on
it.
One
of
those
properties
could
be
replication,
another
property
could
be
spreading
across
some
storage,
topology
and
other
property
could
be
consistency.
Groups
I,
don't
think
that
discussion
needs
to
overlap
with
this.
One
I
think
it's
fairly
standalone,
but,
yes,
we
can
have
that
discussion
as
well.
It.
M
That's
how
it's
called
and
if
volume
is
being
replicated
remotely
one
side,
three
side
too
many
sites,
I'm
thinking
also
about
the
volume
which
leaves
yeah
in
the
storage
machine,
and
we
constantly
talk
about
volumes,
so
I
would
love
to
discuss
it
because
to
me
in
kubernetes
this
looks
like
the
logical
thing
about
the
following:
is
it
is
basically
PVC
and
PV
at
the
bottom?
So
maybe
we
can
have
little
use
case
discussion
to
clear
this
up
and
to
me.
M
A
A
M
J
M
I,
usually
like
this
proposal
today,
the
new
proposal
of
decomposing
and
having
some
some
other
object,
I
think
it's
great,
but
I
want
to
say
here
before
we
understand
how
customer
will
use
it,
how
simply
a
lot
of
him
to
do
things
in
communities
the
way
communities
nicely.
Does
everything
else
yeah.
A
B
Yeah
I
as
someone
so
as
someone
trying
to
get
a
proposal
for
CSI
support
into
our
program
and
kind
of
match
the
CSI
level
of
support.
This
will
be
disruptive
if
we
end
up
with
two
different
ways
of
doing
things,
so
we
may
end
up
pausing
our
CSI
work.
If
it's
gonna
end
up
stretching
into
six
to
nine
quarters
of
what
the
actual
solution
will
be.
A
B
So
right
now
that
it's
mostly
in
snapshots
we
may
have
uses
for
populate,
errs
so
I'm
working
on
a
proposal
for
snapshot,
support
in
Valero
to
replace
our
current
direct
to
provider.
Snap
snapshot
API
like
we
want
to
get
rid
of
Valero's
plugins
and
just
support
CSI,
eventually
God,
but
we've
been
kind
of
non-committal
on
it
because
we
don't
know
where
it's
going,
and
this
seems
like
it
would
delay
that
further.
So
it
doesn't
make
a
whole
lot
of
sense
for
us
to
pursue
our
CSI
design.
B
B
B
J
B
A
A
Yeah
I
think
take
that
into
account.
I
think
what
this
means
is
that
we
have
to
be
have
a
very
high
bar
for
introducing
volume
data
source,
I
think
if
we
were
very
early
in
the
design,
this
would
have
been
less
contentious,
but
rightfully
so
like
we're
so
far
along
there's
a
lot
of
momentum
and
anything
new
that
we
introduced
needs
to
have
a
very
high
bar
for
the
value
add
that
it
has,
which
is
basically
what
I'm
hearing
here
so
I
think
the
the
current
plan
makes
sense:
let's
not
block
volumes
snapshot
or
cloning.
A
Let's
consider
volume
data
source
as
a
standalone
thing
that
could
potentially
also
introduce
new
ways
to
do
volume,
snapshot
and
cloning,
but
we
need
to
talk
through
the
use
cases
end
to
end
and
understand
the
value
add
very
clearly
so
that
one,
we
don't
introduce
extra
confusion
into
the
community
and
two.
You
know
we
have
the
justification
for
introducing
a
new
API
object.
C
And,
and
by
the
way,
what
once
we
understand
how
we
would
do
other
future
CRD
data
sources
and
exactly
how
they
would
work
it'll,
be
a
lot
easier
to
think
through
the
implications
of
this
pointer
style
volume,
data
source
and
and
exactly
how
it
would
be
implemented
and
whether
it
would
be
ugly
or
not.
That's
my
opinion,
because
that's
that's
the
thing
that
I
keep
getting
stuck
on
is
I,
don't
know
how
I'm
gonna
implement
future
volume
data
sources
I,
just
don't
get
it
right.
A
And
that's
right,
so
basically,
what
we're
saying
is
that
the
future
data
populate
ur
discussion
is
very
closely
intertwined
with
this,
and
we
need
to
kind
of
have
those
hand-in-hand
yeah
that
makes
sense
and
Nolan
to
your
comment
on
the
chat.
Yes,
that
would
be
that'd
be
great
if
we
can
sync
up
offline
if
you'd
like.