►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Volume Snapshot Workgroup - 24 September 2018
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Jing Xu (Google)
A
A
A
Also,
since
we
have
storage
class
so
similarly
for
each
individual
storage
class,
you
can
specify
how
much
storage
you
must
like
restrict
and
also
how
many
number
of
PVCs
you
can
have
30
this
storage
class
and
so
for
snapshots
I
think
we
can
have
some
kind
of
similar
concepts.
We
can
have
Kota
4
per
namespace.
We
can
help
code
out
for
we
because
snapshots
class
and
so
for
namespace.
You
can
restrict
how
many
number
total
number
of
bottom
set
shots.
A
You
can
kind
exist
in
this
namespace,
so
I
think
that's
should
be
a
straightforward,
but
for
requests.
If
we
have
requests
for
snapshots,
then
we
have
a
little
bit
issue
here,
because
we
don't
know
exactly
how
much
snapshots
takes
up
the
storage.
We
only
have
a
restore
size,
which
is
the
size
of
the
volume
that
you
take
snapshot
from,
so
whether
we
should
have
a
similarly
I
can
request
snapshots
in
Kota
or
not
I.
A
A
B
A
C
A
I
think
snapshots
and
the
storage
can
be
separate
kotas
so
because
here
we
have
central
class
right,
do
you
have
storage
class
and
for
system
I
mean
if
they
want
to
set
up
coda?
They
can
kind
of
have
a
rough
idea
like
if
they
have
total
100
gigabytes
storage.
They
want
to
have
80
gigabytes
for
storage
like
volumes
and
20
gigabytes
for
snapshots,
and
then
they
can
have
codec
for
snapshots.
A
D
Think
it
makes
sense
to
have
request
a
snapshot
because
that
gives
away
before
add
means
to
say
the
upper
bound
as
far
as
what
percentage
of
their
stores
can
be
used
for
snapshots.
What
percentage
can
be
used
for?
You
know
data
so
and
also
back
to
Ben's
argument
that
you
cannot
calculate
snapshot
sizes
correctly,
I
agree.
D
It's
based
on
the
type
of
back
end
snapshots
may
consume
more
space
or
less
space,
but
one
can
say
the
same
thing
about
volumes
volumes
based
on
whether
they're
same
provision
where
their
D
Dukes,
whether
they're
compressed
you
know
what
you
end
up
on
the
storage
backing
is
quite
different
than
what
what
you
either
may
think
so.
I
think
in
that
context,
it's
okay
to
use
the
request,
a
snapshot
as
a
way
just
to
offer
bound
what
percentage
of
storage
can
be
used
for
snapshots
or
not
yeah.
So
I.
A
A
A
A
A
So
another
thing
we
are
also
thinking:
this
is
per
namespace
per
central
Cass.
How
about
super
volume,
whether
we
should
provide
a
way
for
user
to
specify
they
can
only
take
this
number
of
snapshots
per
volume
and
if
we
already
take
well
I,
say
more
than
that
or
equal
to
that
you
can
make
economic
I
mean
more.
Unless
you
delete
some
the.
B
Problem
you're
going
to
have
here
is,
if
snapshots
are
not
linked
to
the
volume
from
which
they
came,
you
have
no
way
to
compute.
This
number,
like
the
volume,
could
be
gone.
E
A
E
C
But
it's
also
the
way
we
handle
volumes
today,
right,
like
I,
mean
I
think
well
they're
trying
to
get.
That
is
some
consistency.
It
was
the
way
we
already
managed
in
kubernetes,
and
it's
not
perfect
because,
like
Harlan
said
it's
it's
not
true
to
what's
actually
happening
on
the
back
end
in
the
storage.
We
don't
have
a
way
of
enforcing
that,
but
it's
at
least
a
way
for
an
admin
to
restrict
user
unlimited
number
of
snapshots
and
keeping
that
size
reasonable.
C
So,
in
a
typical
storage
like
outside
of
kubernetes,
if
I'm
an
admin
managing
snapshot,
do
I
typically
restrict
those
today,
I
mean
how
is
it
done
outside
of
this?
What
are
those
use?
Cases
look
like
and
are
we
trying
to
mimic
those
same
use
cases
and
Advan
wouldn't
want
to
manage
their
storage
in
a
non?
C
B
In
a
lot
of
cases,
what
ends
up
limiting
usages
is
cost.
So
if
you
people
have
to
pay
for
the
bytes
used
they'll
sort
of
limit
their
own
usage,
you
know
if,
if
they're
paying
for
the
storage
itself,
but
if
you're
providing
a
service
to
someone
else-
and
you
don't
have
a
good
way
to
build
based
on
actual
usage-
then
something
that
quotas
does
provide
ways
to
prevent
bad
bad
actors.
B
E
There's
there's
two
there's
two
things
that
I've
experienced
in
the
past
in
terms
of
quotas
and
limits
right
and
usually
the
the
limit
in
terms
of
a
number
of
objects
like
number
of
snapshots
that
usually
comes
up
due
to
device
behaviors
or
API
limitations,
or
something
like
that
because
for
the
most
part,
the
only
thing
that
is
really
of
concern
is
sucking
up
all
of
the
storage
resources
on
the
on
the
back
end.
So
it's
a
capacity
thing
as
opposed
to
and
in
using
any
things
like
count
or
number
of
snapshots
doesn't
really
mean.
E
B
E
A
A
So
we
basically
just
provide
some
mechanism
like
then
how
user
use
it
like
depends
down
there
environment,
but
those
two
like
number:
why
is
the
number?
The
other
is
the
size
seems
common
like
use
coming
way
to
like
restricts
so
I?
Think
since
we
provide
this
for
volume
and
so
far,
I
think
I,
don't
hear
any
like
major
issue
relate
to
that,
and
I
think
was
that
we
can
follow
the
same
pattern.
So
user
can
use
it.
You
know
very
come
in
a
way.
Yeah.
A
A
Thing
I
want
to
or
prevents
themselves
to,
for
forgetting,
like
take
too
many
snapshots
for
optical
volume.
If
we
provide
this,
that's
it's
my
not
that's
critical
yeah.
B
C
B
H
E
You
know
you
could
I
mean
I,
see
both
sides
of
the
argument,
but
it
does
seem
to
me
I
kind
of
agree
with
Ben.
It
seems
like
it
would
be
okay
to
leave
this
one
out
for
the
first
pass,
at
least
because
the
other
thing
is
is
the
driver
can
still
respond
if
they
have
a
specific
limitation
and
say
hey,
I
can
only
create
100
snapshots
of
volume,
and
you
ask
for
a
hundred
and
one
sorry:
do
we
see
snapshots
no
something
else.
Whatever
I
mean
it's
not
like.
It's
an
insurmountable
problem
to
solve.
A
A
Okay,
so
seems
like
we
set
around
the
story,
the
snapshots
code,
and
so
we
will
follow
the
same
pattern
as
PVCs
and.
A
And
I
also
add
something
to
the
list:
go
back
to
the
division
protection.
So
last
time
we
talked
a
few
scenario,
but
I
think
we
forgot.
One
more
scenario
is
since
we
have
two
objects:
modem
snapshot
and
one
session
content
similar
to
PVC,
PV
and
you
might
user,
might
be
beat
volume
snapshot
content.
A
While
it
is
still
points
to
the
bottom
snapshot
so
for
PVC
I
think
we
added
a
feature
to
add
finalizar,
so
you
can
ask
the
RTD
delete
PV
the
volume
if
it
still
points
to
PVC
and
currently,
if
you
deleted,
it
will
kind
of
fail
and
the
status
of
PV
is
called
terminating,
but
it's
not
actually
deleted
and
until
I
think
the
PVC
is
deleted,
and
so
for
volume,
snapshots
and
smaller
static
content.
I
think
we
probably
need
a
same
protection,
so
otherwise
the
people
bottom
set
shot
still
binds
to
this
content.
A
D
A
G
B
B
E
A
H
H
A
This
is
the
next
item:
perfect
I
called
richelene
policy
right.
So
right
now.
Yes,
we
don't
have
anything
like
policy
visit,
a
user
debate,
bottom
snapshots,
API
object
and
everything
is
emitted,
including
the
bottom
site
content
and
that
physical
snapshots
and
for
volume
we
do
have
a
policy
rights.
You
can
cut.
A
Maybe
that's,
why
is
no
longer
supported,
but
we
have
to
eat
under
retain.
So,
even
though
you
delete
the
object,
the
physical
volume
can
still
like.
You
can
still
keep
it.
Instead,
you
need
it
so
for
snapshots.
We
can
have
the
similar
policy.
Why
is
coordinates
the
other
content
in
it?
It
means
if
you
need
to
be
objective
section,
everything
is
needed
and
but
if
you
want
to
have
a
return
policy,
so
then
only
the
API
objects
will
be
deleted,
but
you
want
to
keep
the
face.
Cosine
shot,
yeah,
I
thought.
B
A
Whether
we
can
have
that
currently
we
don't
have
protections
so
I
think,
like
I
said
in
the
first
I,
don't
know
condition
protection
I
think
well,
PV
bottom
such
a
snoop
on
to
each
other.
If
you
just
delete
the
API
objects
at
the
content,
account
it
there's
no
protection
like
you,
the
API
object
will
come,
but
the
physical
snapshot
will
be
still
exist,
but
we
want
to
prevent
that
so
after
we
add
the
deletion
protection
for
that,
so
yes,
I
think
we
can
make
sure
content
is
still
okay.
B
A
A
B
A
B
I
guess
I
guess
my
only
my
only
beef
is
the
name
makes
a
lot
less
sense
for
the
garden
calling
a
reclaim,
because
even
with
a
PVD,
you
obviously
have
a
way
to
reuse
it.
You
can
delete
everything
and
then
go
use
that
for
something
else
with
a
snapshot
there
is
no
way
to
actually
reuse
it.
I
can
imagine
reasons
you
would
want
to
keep
it
around,
but
calling
it
a
reclaim
policy
is
a
little
bit
funky
because
you're
not
actually
going
to
reuse
it
for
anything
you're
just
leaving
it
there
for.
A
B
D
A
So
I,
yes,
the
fall
volume
that
makes
sense
because
volume
will
have
data,
so
the
user
first
and
I
say
the
first
user
that
could
write
some
data
to
that
volume
and
the
you
do
want
to
have
protection.
This
volume
will
be
used
by
another
user,
but
actually,
if
we
move
down
to
the
next
item,
so
I'm
thinking
snapshots
in
a
way
that's
quite
different
from
volume,
because
snapshots
you're
not
like
right
and
it
ate
her
to
it
right.
A
A
Even
let's
say
you
eat
from
the
one
namespace,
but
you
do
want
to
use
it
in
different
namespace.
We
if
we
say
after
the
snapshot
appoints
to
this
one
and
you
no
longer
use
it
for
any
other
snapshots.
It
seems
to
kind
of
restricted
for
snapshots
and
snapshots
is
sharing,
seems
kind
of
a
good
use
of
central,
great
yeah.
B
A
E
B
So
you
can't
recycle
a
snapshot,
obviously,
but
you're
saying
you
could.
If
you
had,
when
there
was
marked
delete,
you
could
change
it
to
retain,
and
then
you
could
do
this
namespace
swap
trick
and
then
you
and
then
after
it
was
in
a
new
namespace.
You
cos
changed
the
reclaim
policy
back
to
delete
and
it
would
be
just
like
it
was
in
the
new
namespace
yeah
and
that's
exactly
the
way
it
would
work
today.
A
D
So
would
I
be
using
the
retain
policy
here
to
enable
the
sharing
right
now
are
because
counting
or
retain
reclaim
follow
us
need
to
be
the
mechanism
to
enable
sharing,
or
do
we
want
to
be
able
to
support
sharing
without
using
the
retainer
client
policy,
because
I
can
see
I
mean
users
don't
have
to
leader
volume
snapshot
in
order
to
enable
sharing.
They
may
want
to
use
a
snapshot
insulting
and
also
share
it.
So
I
don't
think
this
should
be
the
mechanism
that
facilitates
sharing.
A
H
H
B
The
that-
and
it
sounds
again
like
what
we're
proposing
is-
is
to
mirror
what
happened
with
PVS
and
PVCs
again,
but
at
the
beginning
of
this
jing
you
said
you
see
it
very
differently
than
PVS
and
PVC.
So
I
don't
see
how
it's
different
after
we
after
we
make
the
statement
that
it's
gonna
have
the
same
policies
as
PVE
PVCs.
A
A
B
H
B
The
retention
typically
has
a
different
connotation
in
the
context
of
snapshots
in
the
context
of
snapshots.
There's
you
talk
about
snapshot
retention
with
regard
to
like
a
snapshotting
schedule
that
is
taking
snapshots
and
automatically
taking
and
automatically
deleting
snapshots,
and
the
retention
is
how
many,
how
many
you
tended
to
keep
before
you
delete
the
oldest
one
right.
H
A
A
D
A
D
This
question:
for
the
past
two
three
years:
I
think
that
was
the
right
time
to
ask
so
when
we
set
the
return
policy
for
a
heated
reach
and
retain
the
reclaim
to
retain
that
leaves
the
PB
around
and
the
only
way
one
can
consume.
The
data
corresponding
to
that
TV
is
to
manually,
create
another
PB
with
the
same
content
right
and
have
a
PP
bind
to
it
right.
This
is
the
only
way
somebody
can
make
use
of
that
volume
again
in
kubernetes
I.
C
Think
that
Garrett
you'd
have
to
clone
that
volume
and
create
another
one.
The
idea
of
the
retain
policy
was
the
company
said:
you've
had
to
keep
the
data
around
for
12
months
or
something
could
put
it
in
contain
and
it
would
sit
there
and
be
up
to
the
administrator
to
clean
it
up.
Does
that
answer
your
question.
D
Yes,
they
requires
manual
intervention
by
the
admin
to
whether
it's
for
auditing
or
for
any
other
purpose.
But
if,
let's
say
somebody
accidentally
deletes
the
volume
and
every
clean
policy
is
retained,
the
only
way
one
can
reuse
that
volume
is
to
manually,
create
TVs,
and
that
has
the
same
content
as
yes.
H
And
that
is
on
the
idea
is
the
default.
Behavior
is
all
automatic.
There
is
automatic
provisioning,
there's
automatic
deletion-
if
you
explicitly
are
out
of
that,
then
you're
opting
into
a
manual
process.
And
if
you
don't
like
that
manual
process,
you
can
always
change
the
policy
again
back
to
automatic.
D
A
Okay,
so
related
to
this
policy,
so
I'm
thinking
about
the
four
snapshot,
push
like
I
said
sharing
seems
very
useful
for
volume.
In
most
cases,
you
don't
want
to
share
volume
across
different
namespace
or
users,
because
it
contains
like
users,
data
well
for
snapshots.
You
might
have,
let
us
say
some
snapshots
and
you
want
to
use
it
in
different
scenarios,
likewise
for
testing
ones
for
development
in
different
namespace.
A
In
some
cases
much.
The
user
might
also
want
to
share
this
snapshots
and
right
now
for
volume
right.
We
have
this
one,
one,
nineteen
between
first
volume
in
EC
and
kV
and
I'm
thinking.
Why
for
snapshots
it's
much
this
way
if
sharing
is
useful,
since
was
that
shot
for
some
who
you
have
physical
snapshots,
and
you
have
a
snapshot
content
for
that
and
currently,
if
we
want
to
use
the
same
snapshot
in
different
namespaces.
Similarly,
you
need
to
manually
create
another
snapshot,
content.
B
I
disagree
that
the
difference
has
anything
to
do
with
the
data
inside
the
volume
into
the
snapshot.
I
think
you
can
make
the
same
arguments
about
you
know
people
wanting
to
share
data
in
a
volume
you
can
for
a
snapshot.
I
think
that
the
salient
difference
between
them
is
the
consumption
model.
Most
volumes
are
the
you
know
read/write
once
not
read/write
many.
You
know
for
a
reader
mini
volume.
You
could
make
the
argument
sure
lots
of
shared
across
namespaces
lots
of
people
mounted
and
attached
to
it.
A
A
My
idea
is
currently,
if
you
want
to
use
that
Johnny
different
namespace
right,
you
need
to
helping
content,
object
and
then
use
to
run
on
snapshots
of
like
to
find
them,
and
why
not?
We
just
have
one
content
object
corresponding
to
that
snapshot,
and
you
can
have
some
policies
in
this
content.
Horns.
B
A
A
H
B
A
C
Why
wouldn't
we
clone
that
one
and
then
make
it
so
it
can
be
cloned
and
then
it
creates
a
new
volume
so
that
we
don't
have
this
chaining
going
on
I
mean
I,
assume
the
assumption.
Is
you
create
a
snapshot
and
you
want
to
give
it
to
someone
else
within
that
namespace
to
use
or
possibly
in
a
different
name
space,
and
you
don't
necessarily
want
to
have
the
same
retention
policies.
You
want
to
be
able
to
update
that
snapshot
based
on
what
you're
running
so
we're
we.
B
A
A
C
D
C
And
I
mean
I,
guess
I
thought,
though,
that
we
would
leave
snapshots
the
way
they
were
in
snap
charts,
snapshots,
weren't,
technically
usable
til.
They
were
promoted
to
a
lot
of
you
and
if
we
fall
underneath
that
same
mechanism,
then
we
can
restrict
the
cloning
to
the
volume
piece
and
it
can
be
snapshots
or
just
you
know,
snapshotting
a
volume.
It
didn't
happen
to
be
a
snapshot.
E
Advantage
of
that
approach
was
well,
not
other,
but
we
articulate
exactly
what
what
you
were
saying.
The
advantage
of
that
is
you
don't
have
to
worry
about
the
linked
cloning
or
the
links
to
the
volume.
You
would
just
create
a
volume
from
a
snapshot
transfer
the
volume
to
the
other
namespace
and
there's
your
volumes.
A
Okay,
here
it's
just
like
kind
of
thoughts
about
sharing
policy
really
snapshots,
since
that
I
do
have
some
difference
from
the
morning
right
central.
Is
it
today
already
the
only
thing
and
they
seem
have
more
common
use.
Cases
relate
to
sharing
so
here
I
just
have
this
idea,
but
it's
it's
kind
of
just
for
discussion.
It's
not
something.
We
definitely
want
to
do
right
now
or
yes.
A
The
idea
here
is
just
we
might
for
some
time
how
about
we
allow
you
like
many
to
one
I
mean
so
I'm,
not
equal.
One
in
snapshots
can
binds
to
the
same
one
of
such
content.
So,
instead
of
you
manually
copying
content
many
times,
I,
don't
see
any
like
dangerous
thing
might
happen
from
this.
Many
am
I
being,
but
for
volume
we
want
one
one
I
mean
because
the
data
is
like
you
can
rewrite
who
they
want
to
share
it
in
many
cases.
Well,.
B
B
D
The
the
fact
that
you
can
have
safe
many
to
one
mapping
is
not
the
problem.
The
problem
is
really
who
you
can't
share
your
snapshot
with.
Only
me,
the
Intendant
people,
not
just
with
everybody,
and
these
this
problem
applies
to
volumes.
I
apply
to
other
contexts
as
well,
so
I
think
that's
a
bigger
problem.
You
need
to
address.
A
Yes,
so
the
initial
thoughts
for
me
is
the
content
can
have
some
policy
saying
which
namespace
you
allowed
to
share
this
snapshot.
So
it's
very
from
the
basic
policy
is
only
restrict
which
namespace
you
can
share,
but
if
we
want
to
provides
more
like
a
set
of
sharing
policy,
that's
probably
out
of
stroke.
So
our
great
neihaus
want
to
have
more
like
sharing
policy
across
namespace
across
which,
for
both
their
jaws
and
modems.
Well,.
B
A
Yes,
so
we
can
just
leave
it
for
now
means
we
don't
have
much
time
for
like
discussing
this
much
details
and
we
probably
have
a
different
discussion
relate
to
sharing
and
clone
volumes,
not
everything.
So,
let's
go
through
whether
we
we
have
other
things
need
to
discussed
and
for
creation,
retry
policy
design.
We
say
we
need
more
design.
I.
A
B
D
B
D
So
the
clock
starts:
whenever
I
create
the
volume
snapchat
objects
as
soon
as
I
say
keeps
each
I'll.
Create
volume,
snapshot
no
object,
then
that's
when
the
clock
starts
and
then
let's
say:
I
have
30
seconds
to
take
a
snapshot
and
that
30
seconds
is
relative
from
the
moment
where
he
created
its
natural
object
with.
B
D
B
B
B
Think
the
safest
thing
to
do
given
the
nature
of
kubernetes
is
to
not
do
a
retry
and
to
make
the
system
record
what
time
it
actually
did.
Take
the
snapshot,
and
then,
if
that
was
too
late
for
the
requester
he
can.
You
can
delete
it
and
try
again,
but
you
don't
have
to
over
engineer
it
just
say:
hey
we'll
tell
you
when
we
actually
did
it
and
let
you
decide
if
was
soon
enough,
because
we're
not
gonna
make
it
we're
not
going
to
like
there's
no
way
to
make
it
go
faster.
B
Here
you
could
also
just
say:
we're:
never
gonna
retry
we're
gonna
make
that
to
caught
the
users
problem.
Right
just
will
return
failure,
we
do.
We
didn't
create
a
snapshot.
Sorry
or
we
created
a
snapshot,
and
here
was
the
timestamp
and
if
that's
too
late
for
you
sorry
in
either
case
you
got
to
ask
again.
B
D
I
think
one
reason
why
these
are
retry
policies
make
sense
is
because,
for
example,
some
applications
they
have
some.
You
know
all
you
have
service
guarantees
that
they
only
tolerate,
let's
say
10
seconds
of
downtime
so
down
the
road.
When
we
want
to
support
application
consistent
snapshots,
we
need
to
be
enforcing
that
and
and
I'm,
not
sure
whether
storage
add
me.
D
D
H
H
H
The
reason
we
wanted
to
include
it
in
the
retry
process
was
because
traditionally
kubernetes
does.
You
know,
attempt
to
drive
towards
a
certain
state,
of
course,
snapshots
kind
of
doesn't
work
well
with
the
declarative
model,
but
given
that
we
would
have
a
period
of
time,
let's
say
you
know
5
seconds
20
seconds
30
seconds
within
which
snapshot
can
be
taken.
If
something
you
know
you
end
up
with
a
network
error.
First
time
you
hit
the
API,
but
you
have
another
25
seconds
to
recover
from
it.
H
It
might
be
a
nice
user
experience
for
kubernetes
to
automatically
retry
during
that
period.
Can
we
end
up?
You
know
designing
that
nice
user
experience
in
a
sane
way
that
doesn't
make
life
impossible
for
the
storage
vendor
or
for
the
other
components
involved.
I
think
is
the
question:
is
the
trade-off
worth
it?
The
design,
complexity.
D
D
A
A
And
also
we
have
a
kind
of
a
later
issue
relate
to
okay,
if
you
take
a
snapshot,
well,
PVC
still
not
found
it
or
the
bottom
still,
not
not
ready.
It
will
fail
right.
So
rather
we
should
want
to
retry
and
t.o.p.
Bc
is
correctly
bounds.
It
seems
like
just
a
nice
feature,
but
it's
not
very
critical.
Yeah.
A
So,
okay,
we
can
leave
it
for
just
p2
and
so
right
now
it's
already
telling
the
rest
of
them.
Also
not
I.
Think
very
critical
is
some
nice
to
have
feature,
but
so
we
can
discuss
in
the
next
meeting
any
other
like
issues
of
all.
We
want
to
end
at
a
meeting
any
features
we
may
sing.
You
think
we
are
missing.