►
From YouTube: Velero Community Meeting - Feb 1, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
and
welcome
to
the
valero
community
meeting.
Slash
open
discussion
today
is
february
1st
2022..
If
you
haven't
already.
Please
add
your
name
to
the
list
here
to
the
attendee
list.
It's
always
lovely
to
see
all
the
names
filled
out
there,
I'm
gonna
dive
into
status
updates,
and
then
we
have
a
few
discussion
topics.
I
don't
think
eleanor
will
be
joining
us
today.
So
I'll
be
talking
about
those
a
bit
and
yeah.
B
Yeah,
so
I'm
just
I
have
the
item
snapshotter
an
update,
progress,
pr
that
I
put
in
and
just
addressing
comments
working
on
addressing
comments
from
daniel
and
hopefully
we
can
get
that
merged
soon.
A
Awesome,
can
you
add
into
the
pr
number
there
to
the.
B
Sure,
let
me
find
it
cool.
C
Yeah
yeah,
no,
not
really
I
mean
I
guess.
The
one
thing
is
the
the
we
have
a
follow-on
from
a
proposal,
design
issue
that
I've
been
participating
on
his
with
with
emma
with
shabam
and
dylan
on,
but
in
terms
of
corvallero
stuff,
not
really
other
than
pr
review.
A
All
right
awesome,
thank
you,
yeah,
all
right,
let's
dive
into
the
discussion
topics
for
today.
So
last
week
we
had
a
community
meeting
late
at
night
here
on
in
the
us
early
morning
over
in
china.
So
I
wanted
to
just
make
people
aware
of
the
discussions
that
we
had.
Please
watch
the
recording
if
you
haven't
already,
but
we
also
documented
the
things
here
so
the
first
one
is
community
support
for
older
versions.
A
So
I
wanted
to
just
make
you
all
aware
of
this.
We
haven't
explicitly
stated
what
number
of
versions
we're
actually
supporting
we've.
Just
we've
just
essentially
said
it's
best
effort
and
then
we'll
try
not
to
update
a
bunch
of
later
versions,
but
it
hasn't
been
documented,
which
versions
we
actually
do
support.
A
So
we
eleanor
opened
this
up
a
few
months
ago,
and
then
we
had
a
really
good
discussion
last
week
and
the
community
meeting
that
we
had.
Last
week
we
agreed
on
n
minus
one
support,
and
the
plan
is
to
post
this
out
in
slack,
which
I
think
she
already
did
and
then
out
to
the
distro
list.
That's
still
to
be
done.
A
All
right,
awesome
yeah,
so
this
will
be
that
will
be
easier
as
well
to
handle
the
compatibility
matrix
and
just
making
sure
that
we
put
support
efforts
where
they're
really
needed.
A
One
thing
that
we
talked
about
in
the
compatibility
matrix
is
that
so,
if
we
support
1.8
right
now
and
the
minus
one
so
171
here
we're
supporting
kubernetes
versions
from
up
from
1.12
up
to
latest.
So
that's
a
lot
of
kubernetes
versions.
This
will
change
when
1.9
ships,
because
then
the
supported
kubernetes
versions
will
bump
up
to
116
to
latest.
A
Not
at
the
moment,
I
think
that
would
be
a
really
good
discussion
topic,
though.
D
I
I
agree
it
feels
like
at
a
certain
point.
You
might
have
to
have
an
lts
support
version
for
customers
who
have
longer
upgrade
paths
or
times
so.
I
would
like
for
us
to
at
least
consider
that,
when
we're
designing
this
support
policy.
A
Can
you
please
add
your
some
comments
into
here
around
lts,
because
I
think
that's
yeah?
I
will
do
yeah
also
yeah,
don't
because
we're
looking
at
1.9,
so
maybe
1.10
would
be.
I
don't
know
if
we
were
to
go
that
route.
1.10
could
be
the
the
first
lts
and
then
we'll
see
what
versions
we
would
support
so
yeah.
I
I
think
that
would
be
good.
It's
a
really
good
discussion
to
have
john.
Thank
you.
A
All
right
also
related
to
support
is
how
we
handle
community
support.
This
was
a
a
lively
discussion
last
week.
So
again,
if
you,
if
you
haven't
watched
the
recording,
please
do
so.
This
is
essentially
what
we
talked
about
and
what
we
thought
would
be
a
good
idea.
A
So
the
goals
here
would
be
to
encourage
valero
users
to
help
each
other.
This
is
in
slack
in
mailing
lists
and
and
elsewhere,
and
also
encourage
every
maintainer
to
decide
the
amount
of
community
support
they
do
so
that
would
be
all
maintainers
for
the
valero
project
and
look
at
what
kind
of
support
they
can
handle
make
sure
that
we
just
hit
that
is
it
one
hour
a
week?
Is
it
10
hours
a
week?
How
much
support,
in
slack
and
for
support
issues
can
be
handled.
A
The
the
third
point-
and
the
third
goal
here
would
be
to
make
documentation
better.
I
mean
better
as
a
a
very
subjective
measurement,
but
make
it
easier
to
find
things.
Maybe
so
users
can
help
themselves
better
and
non-engineers,
like
eleanor
like
me,
can
help
users
better
as
well
and
then
make
sure
that
our
users,
in
slack,
mostly
because
that's
where
we
have
the
the
majority
of
support
questions,
feel
like
the
valero
team,
the
maintainer
team
is
present.
A
This
would
allow
the
developers
the
the
maintainers
to
spend
most
of
their
time
on
feature
development
and
not
support.
So
one
of
the
things
that
we
looked
at
is
we
don't
need
to
respond
immediately,
but
we
need
to
agree
that
it's
okay
for
a
maintainer
to
take
up
to
not
necessarily
48
hours
but
up
to
48
hours
to
respond
to
support
requests
longer
than
that.
Then
I
don't
think
we
we
fulfill
goal
number
four
if
it
takes
more
than
48
hours
to
get
a
response,
we're
not
really
present.
A
So
if
we
can
agree
on
that,
I
think
that
would
be
super
good
and
then
respond
to
queries.
That
doesn't
mean
solve
the
issue,
but
respond
in
yeah,
giving
them
help
pointing
them
in
the
right
direction,
and
one
thing
that
we
looked
at
was
especially
around
debugging.
A
Debugging
can
take
a
lot
of
time.
So
we
want
to
make
sure
that
harder
questions
are
filed
as
issues,
because
that
way
they
don't
get
lost
in
slack,
but
rather
we
have
them
as
issues.
We
can
continue
to
track
them
and
see
how
we
can
handle
things.
We
we've
had
support
conversations
in
slack
in
the
valero
users
channel
we've
had
a
bunch
of
support
discussions
that
have
started
and
not
been
responded
to.
A
So
one
of
the
things
that
was
discussed
last
week
was
to
skip
the
discussion
board
so
we'll
we'll
essentially
just
remove
the
the
support
q,
a
discussion
forum
or
the
discussion
tag
or
whatever
you
want
to
call
it
that
we
have
that
we
have
pointed
to
before,
because
discussions
don't
pop
up
as
easily
on
maintainers
radar,
so
they
can
get
missed.
A
A
A
I'm
sorry
yeah.
We
we
already
have
github
discussions
for
that,
but
sometimes
they
don't
get
answered
quickly
so
and
they
don't
really
pop
up
as
issues
it's
not
something
that
the
maintainers
go
to
every
day.
So
a
lot
of
those
discussions
were
missed.
We
saw
several
that
had
been
just
sitting
for
for
two
or
more
weeks
without
a
response,
and
this
was
something
that
we
agreed
up
upon
last
year
that
we
wanted
to
drive
towards
discussions,
but
we
saw
that
that
kind
of
fell
through.
A
So
instead
we
looked
at
okay.
What
do
the
valero
maintainers
look
at?
Well,
you
look
at
issues,
so
driving
towards
issues
was
was
seen
as
the
better
road.
B
Yeah,
I
think
we
tried
discussions
and
one
of
the
issues
there
was
that
if
it
escalated
into
something
that
was
actually
bugged,
it
wasn't
an
easy
path
from
discussions
to
to
issue.
B
A
Yeah
so
issues
because
then
we
can
also
the
thought
was
here,
because
you
can
take
a
discussion
and
just
transform
it
into
an
issue,
and
that's
that's
pretty
easy,
but
with
discussions
we
don't
have
templates
and
if
you
want
to
have
good
support,
it's
easier
to
have
a
template,
so
we're
going
to
have
a
good,
an
issue
template
for
support
questions.
Where
we
ask
add
your
logs
here:
here's
the
format
that
we
need.
What
version
are
you
using?
What
are
you
running
on
so
having
that
template
to?
So
people
can
fill
that
out.
A
So
we
can
more
easily
debug
instead
of
spending
15
to
20
minutes,
asking
those
questions
to
get
that.
The
information
that
that
we
need.
D
This
might
be
a
a
difference
of
opinion,
but
I
just
feel
like
sometimes
slack
is
often
feels
like
a
synchronous
communication
method,
whereas
something
that's
more
asynchronous
would
be
helpful,
especially
with
the
maintainer
team,
being
you
know,
distributed
across
multiple
time
zones.
D
A
No
slack
slack
is
great,
but
what
we've
seen
is
that
when
someone
asks
a
question
in
slack
they
ask
a
question:
they
don't
get
a
response
within
like
30
minutes.
They
walk
away.
Then,
when
the
maintainers
jump
in
ask
a
question
and
they
don't
get
a
response
until
the
next
day.
So
it's
like.
Okay
did
I
help
you.
I
don't
know
what's
happening.
A
A
And
it
also
helps
for
visibility
if
someone
searches
for
that
same
issue
later
on
the
github
response
will
be
recorded
and
can
be
found
in
search
engines,
while
slack
cannot.
So
that's
also
a
really
big
thing.
If
we
have
the
answers,
the
the
error
messages,
the
replies,
the
answer
to
the
question
solved
there,
then
people
can
see
like
oh
that's
how
they
got
to
the
the
right
method
of
doing
x.
A
So
hopefully
that
can
help
as
well
when
we
build
out
docs
and
we
see
the
the
recorded
well,
not
necessarily
building
out
docs,
but
having
responses,
at
least
because
then,
if
someone
comes
in
and
it's
like
yeah,
I
I
have
this
issue
and
we're
like
yeah,
have
a
look
at
issue
234,
where
we
solved
this.
A
Make
some
good
points,
though
sean
so
yeah
here
we
can
add
a
guideline
that
have
discussions
get
unanswered
for
two
days,
create
an
issue
yeah.
I
think
we'll
we'll
try
to
move
away
from
this.
These
discussions
here
and
just
do
issues
so
questions
on
slack
if
they're
easy,
if
they're
like
product
related
just
product
related
or
feature
related,
then
yeah.
Those
are
questions
we
can
just
reply
to.
A
So
the
plan
is
for
us
to
try
this
out
see
if
it
works,
see
if
it
helps
with
communication
and
support
load
on
the
maintainers,
and
if
it
doesn't
work
we'll
try
something
else.
We
tried
with
discussions
and
didn't
really
work.
We
tried
with
slack
it
can
be
super
hard
to
to
keep
track
of
things.
So
we'll
try
this.
If
this
doesn't
work,
we'll
we'll
see
if
we
can
do
something
else,.
A
All
right,
so
one
last
big
big
thing,
as
you
all
might
have
noticed:
valero.io
is
no
longer
accessible,
which
is
a
bummer
for
sure.
A
So
it
turns
out
that
the
the
domain
was
registered
to
a
a
former
employee.
It
was
transferred,
but
the
transfer
wasn't
done
correctly.
It
seems
so
right
now
we're
we're
trying
to
figure
out
where
the
domain
is
actually
registered.
A
So
in
the
meantime
we're
looking
at
different
ways
of
regaining
control
over
the
domain.
We
have
other
domains
that
we
can
use
in
the
meantime,
velar.netfi.app
works
fairly
okay,
but
we
also
have
project
valero.io
that
I
am
working
on
getting
set
up,
so
we
can
use
that
as
a
fallback.
So
if
alert.io
is
unreachable
for
a
longer
amount
of
time,
we'll
have
project
delay.I
o
that
we
could
use.
So
that's
the
plan
moving
forward,
I'm
still
working
with
our
I.t
department
on
getting
everything
set
up,
so
that
should
be
done.
E
Hey
this
one
should
be
pretty
quick,
so
I
just
want
to
call
out
that
I
submitted
two
fixes
to
the
gcp
and
zero
plugins.
It's
a
cve
with
the
uid
package
and
the
main
valero
repo
actually
fixed
this
a
little
while
back.
I
just
think
we
forgot
to
catch
the
plug-ins,
but
I
wanted
to
call
this
out
in
case
I
didn't
look
at
like
the
vsphere
plug-in.
E
I
didn't
look
at
all
the
plug-ins,
only
ones
that
really
I
was
aware
of
and
consuming,
but
I
would
just
do
a
double
check.
If
anyone's
using
the
satori
uid
package,
you
should
update
the
one
in
valero.
It
seems
to
be
the
one
that
everyone's
switching
to
go
rfs.
So
changes
are
pretty
simple,
but
I
just
want
to
call
this
out
in
case
there's
other
plugins
that
are
using
this.
I
didn't
look
at
every
single
one,
so
just
a
heads
up,
that's
really
all
there
is
for
that.
One
thanks,
dylan.
A
A
Okay,
awesome
all
right
until.
F
F
So
currently,
so
do
you
guys
want
to
take
a
look
at
it
before
discussion.
F
Whenever
we
do
a
restore
and
valero
checks
that,
for
a
particular
kubernetes
object,
whether
it
exists
in
the
cluster
or
not
whether
the
instance
of
that
resource
exists
in
the
cluster
or
not
if
it
exists
or
if
it
even
doesn't
it
does
it
skips
the
restore
right,
so
we
wanted
to
make
some
changes
to
that
workflow.
F
So
this
is
a
design
doc.
Regarding
the
same,
we
won't
be
changing.
Anything
regarding
the
behavior
of
service
account
objects,
so
that
will
be
the
same,
and
this
design
dock
has
three
approaches
to
it.
Mainly,
we
want
to
add
a
spec
called
existing
resource
policy
to
the
restore
api.
This
policy
would
enable
us
to
enable
the
user
to
decide
whether
to
perform
whether
to
go
with
the
current
restore
workflow
and
do
nothing
or
whether
to
do
a
patch
or
merge
the
specs.
F
If
there
are,
if
there
is
any
diff
found
for
if
the,
if
there
is
diff
observed
in
the
kubernetes
object
present
in
the
backup
and
in
cluster
version-
and
there
is
also
a
proposal
for
a
recreate
thing-
recreate
object
if
it
consists
of
immutable,
spec
fields.
But
we
are
considering
that
as
a
non-goal
and
a
future
scope
feature
for
this
enhancement.
F
So
we
have
three
approaches
regarding
this
spec
field.
C
And
I
just
wanted
to
call
out
that
nothing
would
change
in
the
default
behavior.
So
if
you
didn't
specify
anything
different,
we
would
do
what
we
currently
do,
which
is
you
know
we
check
to
see
if
the
resources,
if
the
resource
is
there
and
it's
the
same,
then
we're
good.
You
know
if
it's,
if
it's
there
and
it's
different
the
default
behavior
is
we
just
put
a.
We
create
a
warning,
but
this
would
give
the
user
an
option
to
say
I
want
to
patch
this
instead
and
the
the
different
approaches.
C
Basically,
the
first
approach
is
kind
of
the
all-in-one
approach
of
you
know
for
the
entire
restore
do
the
same
thing.
The
second
approach
says
would
allow
us
to
kind
of
using
the
includes
excludes.
You
know
feature
to
be
able
to
say
you
know.
Actually
you
know
I
I
want
to
merge
deployments,
but
not
secrets
or
whatever,
and
that
would
that
that
would
provide
the
additional
flexibility.
Obviously
additional
complexity.
The
and
the
other
thing
is
that
the
whole,
the
recreates,
the
one
that
is
potentially
problematic
in
terms
of
that
one's
potentially
destructive.
C
So
what
we're
saying
for
now?
Let's
ignore
it,
it's
a
possible
future
feature,
but
we
have
to
be
careful
about
adding
it,
because,
basically,
you
know,
if
you're
doing
a
patch
and
the
patch
fails,
you
still
haven't
modified
the
cluster,
so
that
kind
of
falls
back
to
it's
a
warning
and
it's
what
we
do
now.
The
problem
with
the
recreate
is
that
you're
potentially
destroying
the
cluster
resources,
so
that's
kind
of
a
dangerous
option
that
you
know
we
may
still
want
people
may
want
it
as
an
available
option
in
the
future.
C
We
need
to
be
careful
in
influencing
it
and
then
documenting
that
you
know
uses
at
your
own
risk,
but
the
basic
issue
here
is
this
is
to
help
in
case.
You
know.
One
possible
case
is,
if
you
know,
if
you
have
a
secondary
cluster,
where
you're
using
kind
of
a
kind
of
a
live
cluster
replication
of
the
current
cluster
and
you're
updating
things,
you
want
to
be
able
to
update
things
that
exist
already
and
we
had.
There
was
an
existing
issue.
C
I
think
I
linked
to
it
there
where
there's
been
some
discussion,
that
frankie
had
some
comments
there
as
well,
and
I
know
there
were
concerns,
saying
hey,
we're
potentially
breaking
things
here
and
that's
one
of
the
reasons
why,
with
this
proposal
we're
saying
the
default
behavior
is
no
change
from
what
valero
currently
does.
C
This
would
just
be
an
option
that
users
could
choose.
You
know
as
an
additional
modification
of
behavior.
If
they
really
do.
You
know
and
again
the
use
case
here
is
you
know.
Well,
one
of
them
is
you.
You
have
this
kind
of
backup
cluster
that
you
want
to
keep
in
sync,
so
at
that
point,
you're
saying
whatever
is
in
the
backup
takes
precedence
over
what's
in
the
cluster
and
obviously
in
the
normal
case,
where
you,
you
know,
you're
you've
done
a
restore
and
then
your
things
are
different.
C
You
know
the
default
behavior
is
saying
hey,
I
trust
the
cluster
over
the
backup
and
then
we
don't
do
anything
here.
So
that's
that's
kind
of
the
basic
idea
here,
because
we've
had
people
that
have
and
I've
seen
I've
seen
at
least
one
upstream
issue.
There
may
have
been
other
ones
where
and
other
valero
users
have
have
wanted
something
like
this,
and
we've
got
cases
where
people
we're
working
with
also
are
wanting
something
like
this
as
well.
So
that's
why
we've
proposed
it.
B
So
I
know,
we've
gotten
a
lot
of
requests
for
this
yeah
and
I
think
it's
definitely
worthwhile
investigating,
but
I
would
well
one
you
really
need
to
work
this
through
with
daniel,
because
this
is
you
know
this
is
going
to
be
with
him.
I
really
think
it
needs
to
be
well
documented.
I
think
we
need
to
do
a
bunch
of
discussion
about
the
scenarios
and
stuff
yeah
and
what's
actually
going
to
happen,
I
don't.
C
Know
and
that's
part
of
why
we
had
the
you
know
the
design
pr
which
I
think
at
this
point
may
be
the
best
again
because
of
the
times
and
differences,
maybe
that
working
through
on
that
may
be
a
good
way
of
starting
that
process
or
discussing
you
know
not
just.
C
Of
the
design,
but
also
you
know,
are
we
missing
something
in
these
approaches?
Is
there
some
use
case
that
that
isn't
considered?
Is
there
something
about
these
approaches?
That's
going
to
break
something
for
existing
users.
You
know
we
need
to
hash
out.
All
of
that
before
we
write
any
code.
Obviously,.
B
Yeah,
so
I
don't
see
a
mention
of
pvs
and
pv
sound
like
a
hard
problem.
C
Yeah,
I
guess
part
of
it
and
again
our
thinking
here
was
that
you
know
if
you
want
pvs,
where
you
know
you
want
to
update
existing
volumes.
Some
degree
rustic.
You
know
that
that's
kind
of
where
rustic
comes
in,
but
I
know
we're
trying
to
get
away
from
mystic
I
mean
the
issue
is
with
snapshots.
B
Well,
actually,
vsphere
has
the
wonderful
option
to
revert
to
a
snapshot.
It
has
to
be
a
local
snapshot,
but
the
issue.
That
is
that
you
know
if
the
system's
running
you'll
crash
the
kernel,
yeah
and
and
even
with
overwriting
files.
You
know
if
you
have
files
that
are
open.
You
know,
unless
you
restart
the
pods
odds,
are
you
know
they'll
keep
you
you'll
either
break
what's
in
the
in
the
files
or
you
know,
they
start
writing
to
files
that
no
longer
exist
and
things
disappear.
B
So
I
would
so
I
think
tvs
are
difficult.
I
also
think
that
it's
going
to
be
part
of
the
expectation
with
this,
so
we
really
need
to
like,
if
you're
trying
to
keep
two
clusters
in
sync
people
are
gonna.
You
know
people
are
gonna,
ask
for
geez.
How
are
we
you
know
it
doesn't
help
if
I
don't
keep
my
pvs
in
sync,.
B
E
E
I
just
want
to
call
out
that
I
don't
think
we're
really
trying
to
solve
that
problem
in
this
design.
Like
I
get
what
you're
saying
that
at
a
high
level,
it's
a
it's
a
similar
need
and
requirement.
That's
the
use
case.
You
just
gave
me
for
for
volume,
yeah.
C
C
C
I
think,
is
part
of
the
larger
problem,
whether
you
want
to
scope
that
as
part
of
this
and
say,
there's
a
you
know
secondary
component
of
the
implementation,
that's
in
a
different
place
or
whether
that's
a
different
feature,
that's
in
parallel
that
you
would
need
to
use
them
together.
That's
that's
less
clear
to
me,
but
yeah.
C
Yeah
yeah
we're
saying
non-kubernetes
yeah.
I
guess
that's
kind
of
a
because
pvs
are
kubernetes
resources,
but
the
content
is
not
managed
by
kubernetes,
so
you
know
yeah.
We
should
probably
call
that
exclusively
saying
for
for
the
for
this
discussion
here.
This
solution
doesn't
deal
with
pvs.
It
may
be
a
separate
discussion
about,
as
I
said,
I
know
with
rustic.
We
have
done
that
but,
like
you
said,
the
applications
need
to
not
be
running
when
you're
doing
that
kind
of
thing
right.
We
can.
B
We
can
do
things
like
scale
up
scale
down,
so
raphael
was
working
on
this
for
the
migration
and
you
know
you
can
like
scale
down
the
the
destination
pod.
For
example,
a
replica
set
yeah.
B
C
B
B
C
It's
because
certainly
the
pvs-
I
think
that
goes
back
to
the
future
case
of
you
know
the
recreate
option
and-
and
this
again
focuses
on
that
approach
too,
where
we
can
specify
on
a
resource
basis.
You
know,
so
we
might
say
that
you
know
the
default
is
in
a
patch,
but
for
pvs
patching
the
pv
resource
is
kind
of
useless
in
this
context.
C
Instead,
what
you
want
to
do
is
you
want
to
delete
the
pv
recreate
the
pv
that
brings
with
it
all
the
other
complications
around.
You
know
finalizers
and
timeouts
and
waiting,
and
but
if
you
solve
all
that,
then
deleting
the
pv
in
pvc
and
then
recreating
them,
because,
oh
and
then
that's
the
other
problem
is
that
right
now,
valero
distinguishes
the
kubernetes
resources,
the
backup
and
then
and
the
live
object
the
same
well.
The
pvc
kubernetes
object
might
be
the
same.
That
doesn't
mean
that
the
content
in
the
underlying
volume
is
the
same.
C
Complication
because,
right
now
the
valero
notion
of
is
it
the
same
is
exclusively
relating
to
well.
I
don't
need
to
recreate
this
kubernetes
resource,
because
the
kubernetes
resources
on
disk
is
the
same
as
what
we
have,
which
ignores
the
fact
that,
for
pvcs
most
of
the
data
is
not
in
that
yaml.
It's
on
a
disk
somewhere.
B
Yep
yep
yeah,
I
think
I
mean
what
we
see.
I
think
in
support.
Is
we
get
a
fair
amount
of
people
have
how
things
should
work
in
their
mind,
yep
and
it's
not
necessarily
well
explained,
or
you
know
it
differs,
but
we
get
an
awful
lot
of
genes.
You
know
why
doesn't
valero
overwrite
the
resources?
You
know
it
always
comes
down
to?
D
C
D
We
hold
on,
can
I
jump
in
yeah?
I
I
think
I
think
that
an
important
aspect
of
this
is
that
we're
delegating
almost
all
of
the
snapchat
all
of
the
content
within
a
tv
to
other
things.
At
this
point
right
either
rustic
and
the
options
we
choose
or
csi
and
the
options
that
you
have
with
csi
and
snapshotting
and
volume
contents,
and
what
those
individual
you
know,
csi
plugins
can
support
or
what
a
vision,
a
given
item,
snapshot
or
support.
D
All
of
those
things
are
really
important,
but
I
think
they're
outside
the
scope
of
what
we're
attempting
to
do
here
right
like
I
think
that
this
is
way
more
focused
on
something
like
I
want
to
keep
my
deployment
information
in
sync,
and
I
think
you
bring
up
a
good
point
around
you
upgraded
this.
It's
not
going
to
move
the
data
over,
but
we're
already
delegating
the
movement
of
data
to
some
other
thing.
D
So,
even
if
it
wasn't
an
upgrade
and
I
needed
to
move
the
data
over,
I
already
had
to
solve
that
in
some
way.
So
I
don't
know
if
the
those
individual
scenarios
are
drastically
different
than
the
overall
use
case,
which
is
that
we
want
to
keep
the
kubernetes
resources
up
to
date.
But
the
underlying
data
is
already
being
delegated.
B
C
B
C
D
Believe
I
agree
yeah
yeah
hold
on
like
yeah.
I
agree
with
what
you
just
said
and
I
think
that
that
was
communicated,
at
least
from
my
opinion,
inside
the
enhancement
when
it
says
non-q
raised
resources.
B
D
B
B
Not
really
the
one
we
have
right
now,
you
know,
can
read
from
various
apis
and
write
to
various
apis,
but
my
point
being
that
this
is
a
feature
that
has
a
lot
of
spinning,
shiny,
blades
and
people
will
use
it,
they
will
cut
themselves
and
then
they
come
over
and
they
go.
Oh,
my
god,
you
know
what's
wrong
and
it's
you
know:
it's
not
fun.
So
yeah.
C
B
C
C
C
C
Of
do
nothing
patch
it
delete
and
recreate
it.
Well.
You've
doubled
your
options.
If
you
say
we
also
have
the
option
to
patch
and
recreate
even
no,
not
patch,
because
if
it's
the
same
basically,
the
recreate
option
might
have
a
secondary,
really
recreate
option.
To
say
for
these
resources
always
delete
the
thing
if
you
find
it
and
recreate
it,
and
that
would
be
a
brute
force
way
of
handling
your
pv
thing.
Even
if
you're,
for
example,
snapshot
provider,
doesn't
support
incremental
restores,
so
you
can't
do
the
whole
rustic
thing.
C
You
know
whatever
around
updating
live
volumes
that
would
fit
within
this
framework
with
not
a
lot
of
changes
again.
That
wouldn't
be
a
phase
one
thing
here,
because
I
think
this
this
first
approach
says
we
follow
the
valero
logic
of
saying
if
the
thing's
the
same
as
far
as
valero
understands,
we
ignore
it.
If
it's
different,
we
have
some
choices.
B
I'm
not
arguing
with
you
about,
you
know
ways
to
ways
to
go.
I
think
you
know
you
present
some
some
decent
ways
to
go.
What
I'm
saying
is,
let's
lay
out
the
scenarios
and
know,
what's
going
to
you
know,
what's
going
to
happen,
think
about
some
of
the
things
users
are
going
to,
you
know
expect
and
are
we
meeting
those
expectations
or
not.
C
A
A
Yeah
so
scott
and
dave
dylan
raised
a
really
good
question
here:
design
enhancements
are
not
for
users
they're
for
maintainers;
they
they
do
drive,
documentation
and
feature
work,
though
so
yeah
being
explicit,
definitely
helps,
but
I
think
we
we
yeah,
you
know.
A
D
How
about
this?
How
about
this?
How
about
this
it
sounds
like
dave.
You
have
some
some
of
these
scenarios
in
your
mind
that
you
really
want
to
make
sure
are
covered.
Could
you
write
them
as
a
comment
on
the
enhancement
the
shoe
bomb
can
go
and
update
the
advancement
to
cover
those
scenarios
yeah?
If
anybody
else
has
any
other
scenarios,
we
can
add
them
to
the
enhancement
and
we
can
add
them
as
use
cases,
and
we
can
get
the
answers
inside
that,
and
that
would
be
the
next
step
here.
B
B
B
B
E
Yeah
I
mean
I
have
no
disagreement.
The
fact
that
you
know
it's
it's
actually
the
same
way
today
without
folks,
usable
arrows,
restore
and
what
they
expect
to
happen
versus
what
you
know
is
actually
documented.
What's
supposed
to
happen,
I'm
all
in
favor
of
over
documenting
what
exactly
we're
trying
to
do,
but
I
just
want
to
call
out
the
design.
B
E
Sure
yeah,
so
so
we
can
happily
add
a
new
section.
There
yeah.
C
And
again,
I
think
some
of
what
dave's
suggesting
ultimately
just
ends
up
being
maybe
another
couple
of
lines
or
a
paragraph
that
may
end
up
in
the
the
non-goal
section,
just
being
clear.
If
we're
saying
certain
things
are
out
of
scope,
let's
be
clear
in
a
way
that
no
one
would
you
know,
be
confused
or
someone's
going
to
be
confused,
but
I
mean
fewer
people
will
be
confused
so
right
now
the
non-goals
section
is
pretty
short.
C
E
B
No,
I
don't
well,
so
my
no
I'm
not
saying
that's,
not
a
problem
to
be
solving
we've,
certainly
gotten
enough
asks
for
it.
The
problem
is
that
it's
a
really
dangerous
feature
and
that's
why
I
really
want
to
make
sure,
there's
a
well
a
good
understanding
of
what
it's
going
to
do
before
we
turn
it
loose
on
people.
E
C
And
the
on
the
dangerous
point
is
actually
why
I
was
because
initially
we
were
talking
about
you
know
the
patch
and
the
delete
and
recreate
is
kind
of
being
parallel
options
to
provide.
You
know
I
looked
at
that
and
I'm
like
look.
Let's
worry
about
the
the
less
risky
use
cases
first,
because
delete
and
recreate
to
me
is
very
dangerous
because
you
know
I
go
and
delete
something
because
it's
different
now
there's
a
finalizer
on
the
thing
the
delete
stalls,
which
means
there's
no
way
the
restore,
can
recreate
the
thing.
C
You've
now
deleted
customer
data
without
recreating
it
from
the
backup.
So
that's
a
dangerous
feature.
However,
you
implement,
it
doesn't
mean
we
shouldn't
implement
it,
but
I'm
saying
we
need
to
be
a
lot
more
careful
about
influencing
it.
Let's
implement
the
less
dangerous
subset
of
this
functionality
first
and
then
go
from
there.
C
C
We
don't
provide
the
option
in
the
first
iteration
of
this
to
delete
and
recreate
things,
because
that
that
is
truly
dangerous
and
we
will
eventually
want
that.
But
not
yet.
B
Yeah
yeah
and
if
we
can
get,
I'm
not
sure
what
what
raphael's
status
is
right
now,
but
his
team
was
was
had
some
similar
use
cases.
So
they'd
be
a
good
input
on
this.
D
I'd
also
like
to
bring
up
one
point,
which
is
that
you
know
certain
users
do
need
tools
that
are
foot
guns.
It's
it's
fair
to
say
that
we
need
to.
We
should
protect
the
user,
who's,
just
running
a
restore,
and
so
the
default
behavior
should
be
sane
and
safe,
but
yeah.
We
should
also
not
be
resistant
to
adding
features
that
users
need
just
because
they
could
be
on.
In
my
personal
opinion,
I
just
like
to
throw
that
out
there
and
make
sure
that
we're
all
like
is
that.
B
D
C
B
B
And
they
want
they
wanted
to
do
what,
in
their
mind,
would
be
get
me
to
like
having
a
working
cluster.
It's
like
well,
actually,
that's
not
going
to
get
you
to
a
working
cluster,
because
you
have
these
things
that
move
forward
and
you're
rolling
these
things
back
and
they're
not
going
to
play
well
together.
D
B
D
D
B
D
B
E
All
right
so
great,
I
think
I
think
it
sounds
like
we'll
go
and
update
the
design
dock
with
explicit
section
around.
You
know
some
use
cases
that
brought
to
us
by
customers,
as
well
as
fleshing
out
more
detailed
description
of
what
exactly
this
will
not
support
or
should
not
be
used
for
so
we'll
get
that
updated
and
then
yeah,
if
you
don't
mind,
just
taking
a
look,
if
you
have
use
cases
that
you
think
we
definitely
should
or
should
not
cover
on
this,
please
feel
free.
C
Yeah
yeah,
I
would
especially
say
on
anything
that
you
know
other
people
have
had.
You
know
dave.
You
mentioned
people
have
asked
for
this
in
the
past.
If
there's
any
details,
for
example,
because
I'm
guessing
what
they've
asked
you
for
is
probably
not
exactly
the
same
as
what
they've
asked
us
for
and
so
we've
become.
You
know.
C
And
you
know
we're
we're
pushing
this
as
an
upstream
first
approach,
which
means
we
want
to
handle
our
use
cases,
of
course,
but
we
want
to
handle
anyone
else's
use
cases
that
are
that
you
know
make
sense
to
include
here.
So,
if
there's
anything
that
we
haven't
been
involved
in,
there
may
be
additional
tweaks
or
additional
aspects
that
we
haven't
thought
of
yet
so
that
would
be
good
to
get
that
feedback
as
well.
A
The
what
was
I
thinking
about
yes
next
week,
so
the
maintaining
team
over
in
china
they're
off
for
the
new
year
spring
festival,
so
we're
going
to
push
next
week's
community
meeting,
so
we're
not
going
to
have
one
next
week,
which
is
late
in
the
evening
here
in
the
u.s,
so
we'll
just
cancel
that
one
and
then
we'll
be
back
after
that,
and
you
know
in
roughly
two
weeks
I
believe,
we'll
have
the
next
release
as
well,
when
the
maintainer
team
in
china
is
back,
so
we
can
handle
support,
questions
and
things
like
that
in
a
proper
way.
A
D
I
was
going
to
ask
jonas:
can
you
make
sure
that
the
maintainer
team
in
china,
when
they
do
come
back,
takes
a
look
at
the
advancement
that
we
just
discussed
as
well?
Yeah.