►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Workgroup for Volume Snapshot Workgroup - 09 July 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1qdfvAj5O-tTAZzqJyz3B-yczLLxOiQd-XKpJmTEMazs/edit#heading=h.quayk7hfm761
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Jing Xu (Google)
B
B
We
have
reviewed
the
basic
CSS
snapshots
proposal
that
API
design
and
we
have
designed
our
PR
out
for
the
video
and
the
link
is
here,
I
think
so
far
we
got
yawns
comments
and
probably
because
this
snapshot
design
has
been
like
I
reviewed
a
couple
times
and
there
are
not
much
like
issues
around
it,
but
the
only
thing
I'm
currently
once
you
confirm
with
everyone,
is
in
the
previous
design,
we
always
say
snapshots:
we
take
snapshot
from
a
volume
and
the
volume
represented
by
a
PVC.
So
we
have.
B
This
is
a
modern
Korean
name
in
the
bottom
sex,
a
snapshot
spec
to
specify
okay,
rich
volume.
You
want
to
take
snapshot
from
and
now
thinking
about,
the
future,
like
we
plan
to
support
many
different
kinds
of
volume
operations,
including
Chrome,
and
the
right
now.
We
propose,
for
example,
to
add
source
data
source
into
the
PVC,
to
specify
ok,
what
data
source
I'm
from
and
seeing
the
boss
snapshot.
B
You
specify
ok,
where
you
want
to
where
these
snapshots
come
from,
so
if
it
is
PVC
name,
then
that
means
you
want
to
take
that
shot
for
that
volume
returned
about
its
PBC
and
if
we
want
to
support
Isis
it'll
mean
want
to
they're
activating
exceptions
for
their
PvE
without
PVC
like
users.
That's
why
QVC?
We
can
also
have
a
PD
name
there,
or
if
we
want
to
support
cologne,
we
can
also
have
a
snapshot
name
there
representing
this
is
a
clone
operation.
B
But
it's
is
your
icon,
not
finalize
where
we
should
have
clone
operation,
for
example,
maybe
as
possible.
We
also
want
to
put
colonial
function
into
the
volume
operation.
Last
time
we
discussed,
we
have
a
let's
say
a
generic
volume
operation,
API
object
and
claw
operation
could
be
one
of
those,
so
not
very
clear
right
now,
whether
let's
say
we
should
marry
construct
for
the
data
source
or
for
snapshot
have
natural
source.
So
I
want
to
hear
someone
like
your
comments.
Feedback
around
this.
A
Have
a
question
so
is
the
proposal
or
basically
added
new
struct
to
capture
specifically
what
snapshots
is
going
to
look
like,
like
our
I
think,
the
original
proposal
was
that
it
would
be
just
a
type
and
a
like
name.
Two
strings
and
I
missed
the
last
meeting,
so
has
that
sense
changed
into
a
first-class
struct,
so.
B
Last
time
we
say,
for
example,
for
PVC:
we
want
to
support
his
clone,
then
we
can
have
a
source
struct
and
the
inside
of
the
house
or
struct.
You
can
have
different
I
say
the
source
could
be
from
snapshots.
Then
we
have
a
snapshot
source
or
it
is
for
clone
operation.
The
source
would
be
a
PBS
another
PVC
name.
Then
we
have
a
position.
Volume
convey
kind
of
like
a
the.
A
So
the
the
problem
with
that
approach
is
that,
in
order
for
anybody
to
extend
this,
they
will
have
to
basically
extend
the
kubernetes
api,
and
ideally,
we
want
this
mechanism
to
be
extensible
without
modifying
the
kubernetes
api
right.
We
want
to
be
able
to
add
in
new
types
of
sources
without
having
kubernetes
be
aware
of
what
those
sources
are.
A
If
you
imagine
the
the
silly
case
that
everybody
wants,
which
is
the
github
repo
source,
ideally
that
github
repo
volume
source
controller
lives
outside
of
kubernetes
and
kubernetes,
is
not
aware
that
it's
a
type
of
volume
source.
If
you
have
opaque
way
to
represent
the
source,
then
we
don't
have
to
actually
modify
the
kubernetes
api.
B
B
A
And
the
reason
for
that
is
just
based
on
everything
that
cig
architecture
said
when
we
went
to
them.
They
want
more
and
more
for
the
core
of
kubernetes
to
be
a
very
simple
minimalistic
api
and
everything
should
be
an
extension
on
top
of
that.
So
things
like
the
ability
to
add
in
different
types
of
volume
sources
should
no
longer
be
encoded
into
the
core
api
they
should
be
just
mentions
on
top
of
the
core
API.
Okay,.
C
But
there
has
to
be
some
place
in
which,
if
a
bunch
of
drivers
all
want
to,
or
if
everyone
wants
to
have
the
same
kind
of
source,
there
needs
to
be
a
way
to
sort
of
set
a
standard,
Ross
implementations
that
maybe
is
outside
of
kubernetes,
but
also
isn't
completely
opaque.
There
has
to
be
a
middle
ground
where
you
can
say:
okay,
everyone
who
wants
to
create
volumes
from
snapshots
this.
A
A
And
then
we
have
first-class
provisioners
that
we
provide
so,
for
example,
a
CSI
provision
or
which
we
say
hey
if
it's,
if
you
see,
if
you
specify
a
provision
or
a
kubernetes
out,
io
/
CSI
or
whatever
we're
going
to
take
ownership
of
that,
somebody
else
can
come
along
and
create
one
that
will
also
respond
to
the
same
string.
Nothing
prevents
them
from
doing
that,
but
the
system
is,
is
opaque
and
easily
extensible.
Well,.
C
D
Well,
okay,
so
I'm
getting
confused.
I,
don't
disagree
that
we
should
have
a
standard
way,
at
least
within
the
API
to
say
volume
source
and
then
have
that
be
you
know
could
be
snapshot.
It
could
be
an
image.
It
could
be
a
link
directly
to
the
source.
It
could
be
a
registry
location.
It
could
be
many
things
and
I
think
that
was
James
original
question,
but
the
other
piece
of
it
aren't
all
mainly
the
variables
going
into
the
storage
class
today
opaque.
So
are
we
proposing
to
change
that?
A
I
think,
what's
that
question
here
is
whether
the
volume
source
type
should
be
opaque
or
the
type
should
be
a
first
class
like
an
email,
more
something
that's
encoded
into
the
API
I'm,
arguing
that
it
should
be
opaque,
I.
Think,
then,
your
argument
was
basically
that
the
difference
between
a
provisioner
is
that
it's
a
cluster
admin
object,
whereas
this
PVC
is
a
user
facing
object.
C
The
the
reason
I
think
it
makes
a
difference
is
because
different
administrators
are
going
to
configure
their
instances
of
kubernetes
differently
and
they're
going
to
have
to
make
choices
that
they
understand.
One
of
the
powers
of
having
an
API
like
the
Corinna's
API
is
that
consumers
of
it
can
write
applications
that
just
expect
to
run
against
a
kubernetes
cluster,
not
knowing
which
one
they're
running
against
you
can
write
a
standard.
C
You
know
that
having
a
standardized
API
gives
you
a
way
to
just
consume
the
value
of
the
API
in
an
arbitrary
way,
and
if
one
of
the
things
we
want
people
to
be
able
to
do
is
to
create
snapshots
and
then
the
concern
with
snapshots.
There
needs
to
be
a
standard
that
that
people
can
expect
rule
will
always
work
right
and.
A
A
C
A
E
I
have
a
random
thought
so
to
tackle
both
different
types
of
audio
sources
in
a
PVC
as
well
as
conformance,
why
not
have
snapshot
as
a
volume
operation
so
right
now
we
are
talking
about
doing
cloning
modifying
volumes
doing
everywhere
at
least
or
everything
through
volume
operation.
Why
cami
makes
natural
itself
a
title
volume
operation
and
that
way,
a
Bible
by
product
of
volume.
Operation
snapshot
is
a
PVC,
so.
A
E
Let's
say
if
you
have
a
volume
operation
that
generates
a
snapshot
mm-hmm,
you
can
specify
the
destination
looking
the
destination,
the
PBC,
and
once
the
PVC
is
generated
in
the
snapshot,
you
can
just
consume
it.
You
don't
have
to
worry
about
whether
its
source
forms
natural
source
from
PVC
or
source
from
something
else.
Like
all
that
complex,
it
is
masked.
E
D
E
A
couple
of
things
right
now:
you're
making
snapshot
like
a
special
operation
that
is
separate
from
other
volume
operations
and
this
I
think
it's
a
little
awkward,
especially
because
we
store
from
snapshot
is
done
through
volume
operation.
So
why
should
we
make
a
special
case
for
snapshot?
So
that's
what
I
wanted.
C
B
Yeah
restore
bitterly
like
I
mentioned
last
time.
It
involved
two
steps,
one
is
create
new
volume
from
snapshot
and
the
second
one
is
basically
swap
two
sets
of
PV
PV
C
pointers.
So
that
is
this
thing.
There
is
all
here,
I
mean
it's
in
place,
restore.
That
means
you
have
a
distinct
EDC
and
you
want
to
replace
with
volume
that
provision
from
snapshot.
B
A
C
B
Yeah
volume
operation
I
mentioned
whether
we
should
support
like
cross
namespace,
and
there
is
another
like
discussion
ready
to
cross
namespace
operation.
I
should
and
so,
or
go
back
to
the
original
question
like
whether
we
have
we
have
if
we
want
to
add
a
struct
called
some
source
little
source
for
PVC,
and
we
are
saying
okay,
we
can't
have
a
type
and
have
a
string
name,
but
the
one
problem
is:
if
we
want
to
support
late,
different
kinds
of
sources,
type,
a
name
by
not
enough
so
I,
say
type
for
keep
tribal
type.
B
A
C
A
A
B
A
And
the
point
being
that
it's
opaque
right,
the
in
general,
it
doesn't
really
make
sense
to
have
a
map
unless
both
the
consumer
and
the
sender
are
going
to
benefit
from
having
it
as
separate
pieces
of
information.
All
right.
If
one
party
is
basically
just
going
to
completely
ignore
the
the
individual
pieces
and
treat
it
as
an
aggregate,
it
doesn't
really
make
sense
to
have
distinct
API
fields,
for
it.
A
F
A
B
Yeah,
the
intention
for
volume
operation
thing
is
for
the
higher
level
operations,
so
it
normally
and
I
say,
involve
steps
and
maybe
even
multiple
objects.
So
we
have
a
higher
level
controller
to
help
user
to
like
perform.
These
really
complicated
operations
so
and
also
show
the
status
and
is
appreciate.
B
A
How
do
I
get
a
handle
on
to
it,
like
the
reason
that
we
did
a
snapshot
is
both
a
namespaced
and
non
namespaced
object
was
so
that
user
could
have
a
handle
on
it
and
the
the
details
of
it
could
be
hidden
behind
a
non
namespaced
object.
So,
okay
I
can
buy
that
argument.
I'm
willing
to
put
that
to
rest
art
align.
Do
you
agree.
E
F
C
We
need
to
have
the
debate
about
whether
we
need
a
a
restore
operation
or
whether
it
can
be
removed
and
replaced
with
the
combination
of
the
create
volume
from
snapshot
and
then
the
swap,
because
I
think
that's
a
much
more
straightforward
way
of
doing
a
restore
and
then
having
this
funny.
The
the
first
operation
in
the
list,
I
think
just
be
remove
and
everything
else
would
be
great.
C
D
D
So
the
idea
of
having
them
both
so
is
it
the
intention
that
users
can
create
and
restores
restore
snapshots
without
an
admin
assisting
is
that
accurate?
Is
that
the
okay?
Yes?
So,
having
said
that,
then
I
think,
and
are
we
tied
up
on
switching
between
create
a
snapshot
object
to
a
PVC?
We
believe
those
should
be
the
same
type
of
objects.
Is
that.
C
Could
you
scroll
up
in
this
document
back
to
the
number
one,
the
the
restore
case,
so
this
this
is
about
taking
a
snapshot
and
restoring
it
to
an
existing
PVC
that
is
probably
already
bound
to
a
pod.
So
I
think
we
agree
that
we
need
a
way
to
create
new
PVCs
from
snapshots,
and
we
also
need
a
way
to
take
PVCs
and
sort
of,
or
take
two
PVCs
and
to
Vivi's
and
sort
of
swap
their
their
ownership
that
has
uses
outside
of
destroying
snapshots.
Yes,.
D
C
A
C
A
C
A
D
I
think
the
PVC
should
drive
the
operation,
so
if
the
user
asks
for
it
from
the
PVC,
a
new
one
should
be
created
in
a
volume.
Operation
could
happen
because
of
the
request
in
the
PVC
and
that's
always
been
our
flow
of
how
the
the
flow
follows
so
I
I
do
agree
with
that.
I
think
it's
dangerous
to
have
an
existing
PVC,
be
populated
with
something
else.
We
could
have
major
data
corruption.
Permission
I
mean
there
could
be
lots
of
problems
there.
This
well.
C
A
D
C
B
This
operation
will
first
create
a
new
volume
from
the
snapshots
standard,
1,
0,
1,
and
then
the
controller
will
also
have
a
new
PV
PV
silicon,
PV
C
prime
PVC
PE
prime,
to
represent
this
new
volume
and
Y
in
the
second
equation.
Then
go
ahead
to
swap
the
existing
PVC
12.1,
the
new
volume
represented
by
PB
prime
and
the
old
volume
will
be
now
referenced
by
a
PV,
C
Prime.
So
now
user
have
two
sets
of
PV
PV
C's
for
PVC
one.
B
C
B
C
B
D
A
B
A
B
B
So
here
the
current
creates
new
warning
from
snapshots
in
the
existing
social
API
desires.
We
have
snapshot
source
information
in
the
PVC
and
then
the
CSI,
like
the
external
provisioner,
will
recognize
the
snapshot
and
the
provision
of
volume
from
the
snapshot
and
I
have
a
question
saying:
ok,
since
now
we
have
different
operations
and
clone
or
something
whether
we
should
make
it
a
general
source.
Mm-Hmm
question
yet
before
is
just
very
simple:
in
the
PVC
we
add
a
new
field
called
natural
resource.
B
C
I,
don't
think
we
have
to
agree
on
the
specifics
of
that.
We
just
have
tributed.
There
is
a
way
to
define
a
PVC
that
causes
a
volume
being
created
from
a
snapshot.
If
that,
if
that
is
true,
then
you
don't
need
number
one
as
a
as
an
operation,
because
you
can
combine
whatever
that
is
with
the
swab
and
you're
done
no,
and
then
then,
once
what?
If
we
can
agree
on
that,
then
we
can
go
back
to
arguing
about
what
that
is
and
exactly
how
you
create
that
PVC
from
a
snapshot
and.
A
A
A
B
C
E
What,
if
what,
if
you
redefine
we
store
from
snapshot
to
B,
we
are
creating
a
new
PVC
with
a
new
PV,
just
like
creating
a
PVC
B
stores
from
snapshot,
so
that
would
replace
that
operation
and
so
in
this.
Basically,
in
the
case
of
restore
from
a
snapshot
they're
creating
a
new
PVC
and
in
UPB,
there
is
no
binding
unbinding
business
here,
we
don't
have
to
worry
about
that
in.
C
E
E
C
A
E
C
E
C
A
A
Problem
I
have
with
it
is
just
like
how
it
shifts
the
action
that
the
user
is
taking
for
provisioning
a
volume
like
one
step
back
so,
instead
of
actually
creating
a
PVC
object,
they're
creating
something
else,
and
that
implicitly
creates
a
PVC
on
their
behalf
and
then
now
that
PVC
object
doesn't
necessarily
have
a
strict
like
mark
saying
that
the
source
of
this
was
something
I.
Guess
you
could
add
an
annotation
on
it.
But
you
know.
B
E
When
you
think
about
it,
sound
like,
if
he's
one
support,
for
example,
cloning
across
namespaces
or
things
like
that,
you
know
somebody
has
to
create
a
PVC
somewhere
else.
So
look
the
controller
has
to
clone
it
across
names.
Races
create
a
new
PBC
in
a
different
namespace.
So
what
what
I'm
proposing
is
not
so
much
different
from
that.
E
F
B
C
D
A
C
A
Anyways,
if
you
move
the
provisioning
logic
into
a
separate
object
now,
you're
gonna
have
to
duplicate
all
the
things
that
we
already
built
for
PVC
into
this
new
object
right.
So
if
you
have
a
new
way
to
be
able
to
create
a
volume
except
this
time
with
a
special
type
of
source,
you
also
need
to
be
able
to
specify
things
like
what
is
my
storage
class
going
to
be
essentially
you're?
Recreating
the
PVC
object,
so
every
time
you
change
the
PVC
object
to
have
some
new
field
on
it.
A
E
A
I
feel
like
volume
operation
might
be
like
a
crutch
for
us.
It's
like
we're
we're
trying
to
find
a
place
to
fit
these
things
and
we're
just
throwing
them
there,
because
it
seems
easy,
and
maybe
we
should
look
at
these
cases
more
closely
and
see
if
there's
a
better
home
for
them
so
like
for
creating
provisioning
of
volume.
There's
a
very
natural
home
in
the
PVC
object
for
creating
a
snapshot.
A
B
B
D
B
B
A
B
A
A
You
know
I.
If
a
story
system
allows
you
to
automatically
upgrade
your
I/o
speeds
after
a
volume
is
created,
should
I
have
to
basically
snapshot
and
create
a
new
volume
or,
if
I,
do
it
in
place.
I
think
so.
The
the
ability
to
change
the
storage
box
of
an
existing
PVC
is
an
interesting
and
viable
use
case
to
me,
but.
A
D
A
A
A
We
don't
have
to
design
that
here.
The
the
point
is
that
I
I
think
there
are
better
ways
to
handle
both
resizing,
which
you
know
the
the
we
already
have
that
API
in
the
PVC
for
the
storage
class
thing
may
be
actually
changing.
The
storage
class
on
the
PVC
should
trigger
it.
Instead
of
a
volume
operation.
B
A
E
C
A
C
A
C
A
A
B
A
A
Think
my
gut
feeling
is
I.
Don't
like
duplicating
objects.
It's
like
duplicating
code,
it's
you're
gonna
end
up
with
skew
and
different
like
oh.
Why
does
this
exist
here?
But
it
doesn't
exist
here,
kind
of
thing,
so
we
should
avoid
that.
So
wherever
we
feel
like
the
volume
operation
is
duplicating
an
existing
operation,
that's
a
no-no.
Let's
not
do
that
only
put
operations
and
volume
operation
that
we
have
absolutely
no
way
of
putting
somewhere
else,
yeah.
B
C
B
That
can
trigger
a
clone
more
like
a
clone
rights,
so
you
can
clone
snapshots.
So
that's
why
I'm
thinking?
Okay,
if
we
want
to
support
the
same
way
either
in
monochrome
some
shots,
then
PVC
will
have
a
source
snapshot
will
have
a
source
yeah.
That
shot
has
a
single
field
to
call
the
PVC
name.
If
you
want
us
about
a
clone
the
same
way
as
clone
PVC
like
we
can't
propose
to
change,
there's.
B
A
D
C
F
E
A
A
A
A
C
C
C
C
A
A
B
General
bottom
section
is
he's
doing
order
design,
so
we
still
have
time
to.
But
the
the
main
thing
I
want
to
close
is
not
whether
we
have
a
PVC
name,
just
a
single
PVC
name
as
a
single
field,
to
what
I
say
take
that
chance
from
this
volume
or
we
have
a
source
natural
source.
So
it
could
extend
to
other
things.
A
I
mean
we
definitely
want
to
make
the
volume
source
something
that's
opaque.
Sorry,
no!
No!
Let
me
take
that
back.
We
definitely
want
to
have
a
volume
source
that
will
allow
supporting
of
more
than
one
type
of
volume,
plug-in
or
sorry
volume
source.
So
things
like
we
want
to
support
both
snapshots
as
well
as
something
arbitrary
like
a
git
repo.
A
The
debate
is
about
how
we're
going
to
expose
that
whether
it
should
be
an
opaque
field
or
a
first-class
field.
There's
arguments
in
both
directions:
I,
don't
think
that
should
be
a
blocker
for
you
yet,
like
I,
think
you
can
break
your
project
down
into
three
steps.
The
first
step
is
the
snapshot
and
snapshot
data
API.
A
B
F
A
C
F
B
A
B
A
A
Like
the
migration
scenario,
the
way
that
it
makes
sense
in
my
head
is
that
you
just
create
a
new
snapshot,
object
in
that
cluster
and
and
that's
it,
and
if
it's
within
the
same
cluster,
then
it
should
have
different
names.
The
source
here
is
not
another
snapshot,
it's
still
a
particular
PVC
I
guess
you
could
have
it's
as
long
as
it's
optional.
Right
like
you,
could
have
a
snapshot
that
exists
that
didn't
come
from
a
PVC.
A
B
A
I
think
the
what
we
need
to
focus
on
is
what
is
the
verb
here.
The
verb
here
is
volume
snap.
It's
not
snapshot
of
a
snapshot
so
having
the
source
here,
just
be
a
persistent
volume
claim
name,
makes
perfect
sense.
Having
the
source
here
be
something
more
opaque
or
arbitrary,
where
it
could
be.
Another
snapshot
does
not
make
sense
to
me.
I
I
support,
leaving
it
like
this.
We.
C
C
A
A
A
A
Like
if
you
have
a
TV
that
already
exists,
you
create
a
TV
with
a
partial
pointer
back
to
a
PVC,
and
then
you
create
a
PVC
to
complete
that
so
similar
you
have
snapshot
and
snapshot
data,
so
you
create
a
snapshot,
data
for
a
pre,
provisioned
snapshot,
and
then
you
create
a
snapshot.
Object
that
points
to
that
snapshot.
Data
object.
B
A
B
B
F
I
do
have
one
question
about
the
data
source
how
we
decided
on
that
I
thought.
I
was
just
some
questions
about
the
data
source
part
yeah,
so
we'll
leave
that
one.