►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Workgroup for Volume Snapshot Workgroup - 16 July 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1qdfvAj5O-tTAZzqJyz3B-yczLLxOiQd-XKpJmTEMazs/edit#heading=h.wjt1rgh2hhtm
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Jing Xu (Google)
A
A
A
A
We
can
also
rename
the
bottom
steps
they
had
tied
and
we
thought
a
little
bit
about
it
and
have
a
few
like
suggestions.
Bottom
snapshot
TTL
what
in
snapshots
resource,
but
if
you
call
volume
resource
natural
resource
it
will
become
here
the
constant
name,
I'm,
not
sure
it's
become
modern
stock
shot.
The
data
is
a
resource.
No
bottom
snapshot
resource
resource,
Prudhoe
pro-roh.
B
A
A
A
But
if
you
check
the
suggestions
like
for
conditions,
conditions
is
not
many
used
for
to
represent
X
state
machine
states
and
right
now
we
cannot
follow
the
state
machine.
States
pattern
like
first
place
is
creating,
and
this
and
then
move
to
the
next
phase
is
uploading
and
after
the
finish,
it's
become
writing
and
if
you
see
other
like
conditions,
most
of
the
condition,
I
think
is
suggest
to
use
something
like
observation,
like
user
care
about
and
for
snapshot
case.
If
we
think
about
what
user
care
about,
they
don't
care
about.
A
A
So
from
that
it's
kind
of
subtle
difference,
it's
not
a
major
difference,
but
from
that
point
of
view,
are
we
we
think
about
condition.
We
can
have
a
condition
cards.
Is
ready,
then
it's
ready
when
it
has
become
true.
That
means
the
snapshot
is
completely
ready.
User
can
use
it
to
provision
new
volumes
and
another
condition.
Pod
is
thicken
or
it's
cuts,
but
seems
taken
in
some
more
formal,
so
is
taken
means
the
snapshot
is
already
taken
and
or
cut.
A
But
right
now,
if
you
say,
is
taken,
become
true
and
then
after,
if
there
is
uploading
face
the
central
ready,
then
you
can
make
is
ready
true,
but
you
don't
need
to
modify,
is
taken
true
to
force
anymore
because
is,
do
is
taken,
so
it's
no
longer
like
a
state
machine
or
states.
So
you
must
move
from
this
to
next
one
and
change
the
previous
one
to
force,
etc.
A
B
I'm,
trying
to
if
I
may,
I'm
trying
to
understand
the
differences
a
little
bit
so
I'm
going
to
try
to
state
it
back
so
is
taken
means
that
the
storage
has
all
all
the
bits
of
the
snapshot.
So
you
could
resume
at
that
point
and
is
ready
means
that
the
data
is
available
so
that
you
could,
for
example,
promote
it
to
another
volume.
Are
those
the
right
states
or
do
I?
Have
it
wrong.
A
B
For
me,
taken
when
I
hear
taken
I
keep
thinking
like
somebody
has
it
like
it's
been
taken
by
somebody
else.
So
therefore
it
might
not
be
available
to
me
I,
almost
wonder
if
is
created
at
that
point.
I
know
we
had
the
state
creating
so
there's
a
little
confusion
there
but
created
to
me,
says:
okay,
it's
there
now,
but
then,
and
then
maybe
something
like
available
that
to
me
suggests
that
the
like
the
data
now
is
a
veil.
A
C
A
D
A
A
A
A
So
that
also
means
those
conditions
are
not
mutually
exclusive
right,
so
but
I
think
it's
also
true
for
other
type
of
conditions.
I.
B
A
If
they
don't
have
like
uploading
faces
most
of
time
when
the
snapshot
is
like
they
can
is
created
at
almost
the
same
time,
it's
ready
to
be
used.
So
you
can
set
those
two
conditions.
So
true,
almost
at
the
same
time,
but
if
there
is
a
loading
phase
for
some
cloud
providers
and
now
they
available
wheel
comes
later
and
or
much
later,
then
create
it.
A
B
I
have
one
other
question
about
it,
so
if
is
there
a
difference
in
how
you
might
need
to
handle
the
object
if
it
had
been
created,
but
not
available
versus
available?
So
if
there's
this,
you
need
to
differentiate
the
error
states
from
an
end
user
perspective,
or
would
we
expect
that
deleting
the
object
from
its
error
could
be
handled
in
the
same
flow.
B
A
A
A
And
one
nothing
related
to
controller
implementation
is
right
now.
I
think
we
discussed
this
before
in
instead
of
have
controller,
to
keep
trying
creating
snapshots
like
a
controller
normally
are
working
to
reduce
and
I
keep
trying
to
create
my
same
volume.
We
only
try
to
create
a
shot
once
if
there
is
arrow
well,
if
the
operation
failed,
we
will
just
return.
The
result.
A
Keep
trying,
because
we
thought
snapshot
is
operation,
is
very
tense.
Escape
the
user
start
like
snapshot,
they
might
prepare
something
and
when
it's
finished,
they
need
to
resume,
and
we
don't
want
to
keep
it's
a
long
operation.
I
keep
trying
and
user
mind
forget
it,
and
they
have
snapshot
much
long
like
later
time
and
I
just
want
to
confirm.
Anyone
has
like
concerns
about
that
logic.
E
I
see
this
is
one
of
this
should
be
what
people
are
facing
with
the
resize
controller.
Now,
once
you
should
that
request,
if
the
cause
is
not
satisfied
on
the
storage
vendor,
it
will
be
keep
retrying.
There
is
no
way
to
actually
require
that
scenario.
So
I
don't
know.
Does
it
make
sense
to
better
cancel
option
for
snapshot
at
least.
A
A
A
A
D
I
may
add
it's
actually
a
kubernetes
api
first
off
its
intent
base.
So
as
long
as
there's
a
natural
object
that
says
that
there
should
exist
snapshots
of
this
TV.
The
controller
will
try
to
fulfill
that.
In
fact,
until
we
know
it's
impossible,
even
fry
error
makes
sense.
The
conservation
would
be
done
just
by
deleting
the
objects.
D
F
Dynamic
provisioning,
dynamic
provisioning,
if
you
specify,
let's
say
wrong
storage
class
for
some
reason,
you
cannot
do
provisioning,
you've,
gotta,
keep
failing,
and
the
user
has
dealer
the
PVC
realizing.
You
know
what
the
failure
wall
us,
so
they
can
remedy
the
situation.
Same
thing
should
happen
here.
I
think,
if,
if
it's
still
reason
for
the
failure
in
snapshot,
reoccurs
you
have
to
realice
that
problem,
and
that
goes
well
with
the
whole
declarative
model,
because
otherwise
it's
just
a
one-time
operation.
As
soon
as
you
encounter
an
error
in
snapshot,
then
that's
it.
E
A
Yes,
by
using
like
central
ID,
if
you
keep
yes,
the
operation
like
creating
from
CSI,
it
won't
clearly,
it
should
not
create
a
second
new
one.
So
it
should
see
there
is
already
one
there,
even
though
it's
not
finishing
it
and
it
won't
create
any
one,
but
so
for
controller
point
of
view,
as
I
discarded
used
somewhat
some
still
thinking
to
like
controller
keep
trying,
just
as
the
same
as
other
great
PVC
volume
right,
I,.
F
I,
don't
know
I
mean
if
you
want
to
keep
the
behavior
consistent
with
other
things
in
kubernetes
the
whole
declarative
models
such
as
to
do
that.
Otherwise,
it's
very
much
internally,
it's
just
a
one-time
operation
that
we
do
and
it's
I
think
a
new
type
of
behavior,
not
just
for
storage,
but
also
for
other
areas
in
communities.
A
It's
true
forms
consistent
point
of
view.
Reason
like
we
think
we
don't
want
to
retry.
Is
this
nap
shot
is
kind
of
one-time
thing
how
the
user
wants
you
crazy,
charts
right
now
and
we
don't
want
to
have
controller
just
behind
like
keep
trying
to
do
it.
That's
my
concern
about
that
from
user
point
of
view,.
F
So
you're
right
when
you
just
want
to
think
it's
not
shot,
especially
applications
consistence,
not
just
it
wants
not
just
to
be
created
at
a
certain
point
in
time
so
and
even
for
schedule
snapshots.
You
want
your
snapchat
to
be
taken
at
a
certain
point
in
time.
If
you
fail
in
the
time
window,
you
don't
want
to
truly
try
two
minutes
later
five
minutes
later
so
I
agree,
it's
not
just
or
somewhat
different,
but
also
the
case
we're
talking
about
where,
for
example,
the
whole
purpose
of
this
fall.
F
So
if,
for
some
reason,
snapchat
fails,
I
think
we
should
leave
it
to
the
user
if
they
want
to
restart
the
application,
which
is
again
a
manual
operation,
so
they're
heavily
involved
or
if
the
application
is
already
paused
for
the
snapshot
to
be
taken,
then
on
at
the
users
mind
if
it
gets,
we
tried.
You
know
multiple
times
so,
based
on.
You
know
whether
it's
on
demand
snapshots,
where
the
part
is
paused
or
not
whether
it's
scheduled
snapshots
or
not,
I.
Think
retry
may
make
sense
for
may
not
make
sense.
A
F
So
I
think
application
question
of
snapshots
where
the
application
has
to
be
paused.
We
trying
they
make
sense,
but
some
users
may
not
be
comfortable
because
if
it's
a,
if
application
is
going
to
be
paused
for
a
long
time,
that's
not
desirable,
because
but
the
clients
of
that
application
would
notice
the
downtime
and
so.
F
A
F
A
C
A
B
So,
regarding
the
retries,
it
seems
that
you
could
do
this
in
a
phased
approach
and
later
on,
add
like
a
max
retries
parameter
that
defaults
to
zero.
If
we're
having
the
default
behavior
to
not
retry,
and
then
that
way,
the
user
actually
can
specify
the
number
of
retries,
because
otherwise
the
next
question
would
be
if
it's
a
boolean
value
who
gets
to
set
the
number
of
retries.
A
We
do
have
such
parameters
like
the
number
of
really
trying
snapshot
design
and
somehow
we
job
it
at
some
point
seems
like
it's
a
useful
feature,
and
so
everyone,
a
everyone,
think
it's
very
useful.
We
can
like
try
to
already
know,
and
also
the
place
to
have
this
parameter
is
y,
is
in
storage
snapshot
class.
The
other
is
that
there
are
three
masback.
B
A
C
A
Sorry
yeah
doing
this
last
week
and
we
haven't
a
chance
to
share
with
everyone
and
so
about
this
meeting.
I
share
it
and
I'll,
see
like
how
many
people
have
like
comments
depends
on
that.
We
can
like
yeah,
decides
when
to
merge
it
so
just
like.
If
anyone
have
thoughts,
please
let
us
know
yeah
as
soon
as
possible.
Okay-
and
this
is
bottom
snapshots
back
I
thought
there
is
a
snapshot
class.
A
A
A
B
Yeah
I'm
kind
of
thinking
about
it,
I'm
trying
to
think
if
there's
any
other
objects,
that
would
need
to
be
snapshotted
ever
like
any
configuration
of
a
pod
spec
or
something,
and
nothing
is
really
coming
to
mind.
So
I
almost
feel
like
just
as
long
as
we're
consistent
with
all
the
different
types,
whether
they
have
the
volume
before
or
not.
A
B
A
C
A
A
You
can
have
another
like
volume
as
source.
It's
it's
a
clone
or
like
GC,
some
cloud
provider
supports.
You
have
a
source
image,
so
they
opened
the
door
for
people
to
use
different
sources
to
populate
data
on
their
volumes,
and
we
propose
to
have
a
data
source
in
a
PVC
and
this
how
to
struct
how
to
have
the
business
or
struct.
We
still
have
like
well
not
settle.
A
The
problem
is
is
kind
of
limit
what
we
can
do,
since
you
only
have
a
string
there
right.
So
thinking
about
the
sources.
Actually
one
type
of
source
is
another
API
object
from
the
system.
Like
snapshot,
is
another
source
with
represented
by
AP
object
or
for
clone.
Pvc
is
another
API
object?
So
it's
easy.
You
just
gave
the
baby
object
name,
but
we
want
to
support
more
type
of
sources
and
how
we
represent
them,
or
we
should
like
just
may
be
consistent.
A
So
if
you
have
other
type
of
sources,
then
somehow
you
create
even
using
CRD
or
something
make
it
a
P
object,
and
we
just
put
a
new
object
name
as
a
string,
but
then
we
need
some
controller.
That
was
this.
The
controller
need
to
handle
this
and
also
whether
we
can
support
let's
say
cross
namespace,
then
whether
we
should
specify
namespace
in
the
source.
B
I
think
I'm
trying
to
address
you
know,
there's
a
lot
there
for
sure,
so
I
think
on
one
hand,
it
could
be
really
interesting
with
this
idea
of
moving
certain
things
out
of
tree
to
actually
have
like
out
of
tree
components
that
can
be
responsible
for
implementing
the
datasource
logic
and
I
mean
that
opens
up
a
whole
different
can
of
worms
for
sure.
So
I
wonder
if
there'd
be
a
way
to
allow
you
to
use
entry
objects
or
out
of
tree
objects.
B
A
Yes,
so
for
API
perspective,
oh
let
me
talk
is
like
a
like
a
dock
temperature
team.
They,
they
are
like
saying
they
should
be
okay,
well,
I,
say
entry
in
the
objects
and
I
say
PVC
to
have
reference
to
like
CRD
autumn
tree
no,
but
they
want
to
make
sure
that
they
design
it.
They
should
quite
generic.
So
you
don't
want
to
add
small
things.
Keep
adding
small
things.
A
E
A
B
B
I
was
just
thinking
like
one
just
to
be
a
little
concrete
about
a
potential
third
party
data
source
could
be.
You
could
have
some
sort
of
controller
that
manages
like
importing
from
arbitrary
sources
like
downloading
content
or
other
things
like
that.
So
that
would
be
an
interesting
out
of
tree
project
to
incorporate
into
something
like
this
and
I.
Don't
want
to
broaden
the
scope
of
this
PR
at
all
that
it
was
just
an
example
where
it'd
be
cool.
B
A
Make
as
they
appropriate
parameters
and
ICSI
right,
it
will
put
those
parameters,
so
the
C
as
I
call
so
yes
now
I
can
know.
Okay,
what
is
the
source,
for
example?
What
is
the
parameters
they
should
use,
and
so,
from
that
point
of
view
we
can
say,
let's
say
a
type
and
a
stream,
so
we
say
either
it
is
chained
to
a
lot
of
tree.
Then
it
is
always
a
cabbage
accents
journey
or
just
in
court
ID.
D
A
We
won't
have
other
like
you
cannot.
They
are
today,
just
put
some
arbitrary
name
string
or
something
in
the
source,
so
it
always
be
a
just
object
if
you
have
a
dead,
but
you
can
have
new
type
of
object.
Yeah
is
then
in
destruct.
Well,
we
will
have
will
change
to
what's
next
I
mentioned
before
the
the
datasource
struct
would
have
a
type
industry
more
or.
A
Have
but
whether
to
kind
of
restrict
the
type
yeah
so
right
now,
alright,
we
only
know
and
I
say
to
type
snapshot
and
another
PC.
We
could
have
a
validation
like
user
cannot
have
other
time,
but
then
the
user
cannot
take
advantage
of
sources.
Mm-Hmm.
B
Another
question-
and
you
can
tell
me
if
it's
going
a
little
opening
too
much
here
but
I,
see
the
git
repository
type
here.
My
question
is:
is
there
any
idea
to
have
these
sources?
Are
they
resolved
only
by
the
dynamic
provision
or
at
the
volume
provisioning
time
or
are
we
are
we
proposing
to
have
it
so
that
a
provisioner
could
provision
an
empty
volume
and
then
some
other
component
after
provisioning
is
responsible
for
populating?
B
So
the
reason
I'm
asking
is
get
repository
seems
like
pretty
generalized
logic
that
you
wouldn't
want
every
wouldn't
want
to
force
every
single
provisioner
of
storage
to
implement
within
their
own
code.
That
would
be
something
you'd
want
to
maybe
be
composable
outside
of
the
fact.
Have
we
considered
that
there
might
be
some
user
space?
That's
the
exact,
really
bad
term,
but
like
basically
pod
space,
PVC
pop
you
laters
and
then
maybe
some
provision
or
space
populate
errs.
Oh.
D
A
F
A
B
The
reason
the
reason
that
I
kind
of
asked-
that
is
because
there
probably
be
a
bit
of
entry
changes
required,
maybe
potentially
to
add
another,
add
more
complexity
to
the
PVC
state
machine,
because
you
would
probably
want
a.
If
you
have
this
sort
of
pod
space
populate
err.
It
would
have
to
be
able
to
attach
the
like
start
a
pod
and
attach
to
that
PVC
before
anyone
else
could,
while
the
PVC
was
in
a
certain
state.
Perhaps
so
there
might
be
some
changes
to
consider
pushing
up.