►
From YouTube: Velero Community Meeting - Feb 15, 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.
This
is
tuesday
february
15th.
We
did
not
have
a
community
meeting
for
for
a
little
while
here
so
the
past,
the
the
previous
one
was
the
first
of
february.
So
what
has
happened
since
then?
Well
yesterday
we
had
an
exciting
release,
so
version
1.8,
point
and
dot
is
out
so
that
was
released.
Yesterday
you
can
grab
it.
You
can
read
the
release,
notes.
We
announced
that
to
the
community
yesterday
as
well
and
yeah.
A
We
definitely
want
to
chat
about
it,
a
bit
so
eleanor.
I
know
you're
putting
you
on
the
spot,
but
maybe
you
want
to
talk
about
about
the
the
release.
B
I'm
happy
to
do
that.
Yeah.
We're
really
excited
to
have
this
release.
It
has
a
number
of
good
things.
One
one
thing,
for
instance,
is
that
sorry,
actually
I
just
wanna
I
apologize,
I
should
have
pulled
it
up.
One
sec,
mm-hmm,.
B
Just
if
I
try
to
do
it
off
the
top
of
my
head,
I
may
be
unhappy
with
what
happens
right.
So
one
thing
that's
great
is
of
course,
as
folks
in
the
community
move
more
and
more
to
csi
drivers.
Of
course
we
want
to
make
sure
that
valero
can
back
up
volumes
provisioned
by
csi
drivers,
so
we
made
changes
to
our
aws
and
azure
and
gcp
plugins
to
make
sure
that
that's
the
case,
so
there
should
be
no
breaking
things
going
forward.
B
In
addition,
we
have
we
did
a
lot
of
behind
the
scenes
work
in
this
release.
There
was
some
cube
builder.
I
believe
it
was
an
upgrade.
I
know
that
it
was
kind
of
modernizing
of
the
code
base.
We
added
testing
a
test
to
the
ete
tests
to
again
just
improve
confidence
in
valero's
valero,
the
blair
releases
we
also
tested
ipv6
and
ipv4
dual
stack
and
valero
pass.
So
now
we
have
confidence
that
valera
can
be
run
on
those
configurations.
B
We
also
did
have
some
smaller
bug
fixes.
I
will
note
that
this
is
the
first
release.
In
a
long
time,
we've
had
to
do
the
release
notes
without
bridget.
We
missed
dearly,
and
so
for
that
reason
we
are,
if
you
actually
look
now
at
the
release,
notes
they're
a
little
bit
sparse
and
but
we
have
a
pr
in
progress
to
kind
of
what
I
said
we
should
have
up
in
the
next
day
or
two
we're
just
kind
of
editing
in
a
bit.
B
So
that's,
I
think,
that's
the
big
things.
I'm
yes
and
I
see
that
jonas
is
sharing
a
few
details.
So
any
questions
any
comments.
C
So
eleanor
was
were
these
images
scanned
and
they
were
all
good
from
the
like
vulnerabilities
point
of
view.
B
The
short
answer
is,
I
believe,
we've
done
some
scanning.
I
don't
have
the
details.
This
is
where
I'd
love
to
have
the
engineering
team
dave
might
know
the
answer,
but
if
okay,
then
in
that
case,
what
I
would
suggest
is,
if
you're
able
to
come
to
next
week's
community
meeting
evening
time
north
america
evening
in
north
america
time
that's
when
the
beijing
team
will
be
there
and
they
are
the
ones
who
I
believe,
do
the
scanning.
So
apologies.
I
don't
have
the
answers
for
you
today.
You.
C
Yes,
so
yeah,
so
we
we
did
scan.
So
we
we
were
notified
of
issues
with
172
and
then
we
scanned
one
eight
also,
so
they
were
showing
up
in
twist
lock.
So
some
looked
false
positive,
but
some,
I
guess
were
golang
issues
like
most
of
the
items
seem
to
be
go
language
abilities
and
that's
how
twist
lock
scans,
which
tell
you
this
and
then
I
guess
the
solution
is
either
to
upgrade
if
it
is
a
vulnerability
or.
B
Well,
no,
no
you're
welcome
to
bring
it
up.
The
problem
is
that,
as
of
now,
all
of
the
vmware
engineers
are
in
beijing,
and
so
they
won't
be
attending
this
meeting
anymore,
unfortunately,
because
it's
the
middle
of
the
night
for
them.
So
I
just
don't
think
the
folks
here
have.
The
answers
are
here:
yeah
gymnast,.
A
Yeah,
I
think
we
talked
about
this
yesterday
on
with
the
vmware
maintainers
as
well.
They
scanned
it
using
trivi
and
they
and
they
did
find
a
few
yeah.
Just
like
you
said,
sikona
there
there
were
some
goaling
issues
mostly,
so
I
think
an
update
is
coming
soon,
but
it's
yeah,
it's
nothing
in
valero
itself,
but
rather
the
dependencies.
C
Yes,
so
one
thing
that
could
help
is
sometimes
if,
if
it's
even
golang,
but
if
it
doesn't
affect
claiming
I
mean
her,
writing
is
not
applicable.
Also
is
okay,
so
we
are
getting
hit
a
lot
by
the
enterprise
customers
right.
They
all
do
these
scans
and
they
want
an
answer
either.
It
is
not
applicable
because
the
function
in
the
way
library
is
used
doesn't
apply
or
ask
is
like:
when
will
the
new
update
come.
E
B
F
B
If
you
could
ask
it
on
the
kubernetes
slack
and
tag
daniel
might
be
a
reasoner.
I
can't
remember
his
looking
now.
B
B
C
B
Feel
free
to
keep
asking
your
questions,
I'm
just
saying
for
this
particular
one
I
just
I
he
can
hopefully
answer
the
particular
question.
C
Right
so
the
other
question
we
were
discussing
in
the
thread
was:
is
172
a
possibility
build
with
the
latest
1.16
yep.
B
Our
short
answer
is
yes:
172
is
actually
a
possibility
to
to
fix
the
cvs,
because
we
we
certainly
want
valero
to
not
have
cves,
and
so
it's
very
much
a
possibility
and
again
I
think
I
basically,
I
think
we're
going
to
do
it,
but
this
is
where,
having
that
conversation,
where
you
and
daniel
can
talk
directly,
would
be
really
helpful
just
to
make
sure
we're
all.
On
the
same
page,.
B
Yeah,
I
just
put
a
comment
so
valero
dev
in
particular,
because
that's
where
we
kind
of
have
valero
development
related
chats
for
folks
to
know
in
general,
valero
users
is
where
users
kind
of
help
seek
help
from
each
other.
But
if
we're
talking
about
a
development
issue
from
valero,
dev
and
then
danielle
jang
is
the
the
tech
lead
and
he's
based
in
beijing.
So
for
asynchronous
communication,
the
slack
channel
is
great.
F
B
What
I
want
to
confirm,
like
I,
don't
know
how
long
it'll
take
the
team
to
do
it,
your
questions
about
whether
the
existing
ones
are
applicable,
but
basically
the
cop.
I
believe
we
will
do
a
172..
I
just
want
to
confirm
that
the
timeline
we
can
do
work,
you
know,
satisfies
user
needs
and
I
want
to
make
sure
that
we
will
be
removing
the
cves
that
you're
concerned
about
that's
what
I
just
want
to
make
sure
we
hammer
out
in
the
slack
channel.
C
B
B
And
of
course,
there
will
be
some
validation
needed
for
172,
so
we
are
hoping
that
folks
who
are
requesting
this
172
can
help
us
a
little
bit
with
the
validation.
But
we
can
hammer
that
out
too
later,
as
well
later,.
C
Yeah
yeah:
we
can
now
help
us,
I'm
not
sure
we're
familiar
with
the
process,
but
whatever
needs
yeah
we
can.
We
can
discuss
perfect.
B
C
B
Thanks,
oh
thank
you
for
bringing
it
up.
It's
I'm
sure
that
more
than
more
than
just
your
users
are
concerned
by
this.
A
Thank
you
any
other
questions
or
comments
on
1.8.
A
H
A
Awesome,
let's
see
here,
does
anyone
have
any
other
status
updates?
Looking
at
the
maintainer
team?
Here
we
got
dave
and
scott.
Do
you
have
any
status
updates
for
today.
D
I
Yeah
not
much
me
other
than
peer
reviews
and
then
some
that
the
issues
that
shubham
has
to
discuss
are
ones.
I've
been
involved
in
those
as
well.
A
All
right
awesome,
thank
you
yeah.
So
then,
let's
dive
into
discussion
topics.
I
don't
know
why
I
put
this
here:
we're
not
gonna
change
anything
that
was
a
discussion
that
we
had
that
we're
not
going
to
change
anything
right
now,
however,
we
will
have
a
new
community
manager
joining
the
valero
community
here.
A
I
hope
he
can
be
here-
probably
not
next
week,
but
the
week
after
that,
orlean
vasilev
will
be
joining
the
valero
community
as
the
community
manager
in
a
couple
of
weeks.
So
I
will
be
handing
things
off
to
him
and
for
those
of
you
who
are
a
little
confused
and
and
remembering
wait,
didn't
we
already
talk
about
this
a
couple
of
weeks
ago
and
there
was
some
other
person.
A
Yes,
that
is
true,
but
the
current
the
current
plan
right
now
is
for
orlean
to
join
the
valero
community
as
the
community
manager
within
a
couple
of
weeks.
So
you
will
see
him
in
the
slack
channels
and
threads
and
on
meetings,
so
hopefully
yeah
again,
probably
not
next
week
but
the
week
after
that
he
will
be
a
part
of
the
community
meeting.
So
we'll
we'll
see
in
there.
B
Sure
thing
so
two
bits
today,
as
you
can
see,
one
thing
is,
you
know:
we've
been
toying
for
a
long
time
about
bringing
the
csa
csi
plug
into
ga
the
velar
csi
to
plug
the
ga.
To
remind
folks
at
least
one
of
the
major
reasons
we
have
not
so
far
is
because
csi
snapshotting
can
be
implemented
in
different
ways
on
different
systems
on
aws
and
azure.
B
For
instance,
if
you
use
a
cs
nice
snapshotting
mechanism
in
ebs,
for
instance,
it'll
take
the
snapshot
and
ebs
will
have
its
own
accord,
move
that
snapshot
to
a
different
storage
location,
and
so
that
snapshot
is
durable
and
safe
and
yay.
So,
for
instance,
if
you
use
the
csi
plug-in
on
aws
it'll
work
well
for
customers,
on
the
other
hand,
take
vsphere
which
doesn't
have
a
csi
snapshotting.
Yet,
although
it
will
soon
vsphere
when
you
do
their
snapshotting
mechanism,
it
does
not
move
the
snapshot.
B
It's
a
non-durable
snapshot,
and
so
the
valero
plug-in
for
vsphere
after
triggering
a
snapshot,
needs
to
move
that
snapshot
to
a
different
storage
location
than
the
primary
storage,
so
that
in
the
event
of
a
disaster
and
the
primary
storage
is
lost
that
the
secondary
storage,
so
that
the
the
snapshot
is
not
lost,
the
backup
is
not
lost.
So
our
concern
is
on
other
platforms.
B
If
someone
has
csi
snapshotting,
we
don't
really
know
whether
they
are
like
aws
and
actually
moving
the
snapshot
behind
the
scenes
or
whether
they're
like
vsphere,
which
for
their
own
snapshotting
mechanism
or
not,
is
not
moving
it.
So
again,
we've
been
dragging
our
feet
because
we
haven't
seen
the
need
so
far
to
bring
the
csi
plug
into
ga
because
of
those
kind
of
product
concerns
as
well
as
there
may
be
technical
concerns
that
I
actually
don't
know
about
yet.
B
B
Maybe
someone
can
put
it
into
the
webmd
while
I'm
talking,
because
I
can't
run
multitask,
and
so
the
use
case
is
this.
It's
the
so
so
number
one
is
what
I
was
just
talking
through
about
things
that
are
blocking
ga
and
number
two
is
the
hey,
there's,
probably
technical
bits
I
don't
know
about,
and
then
there
are
two
reasons,
though,
to
bring
it
to
ga
reason:
a
is
what
we've
known
about
for
a
while,
which
there
may
be
more
systems
that
implement
csi
snapshotting
that
users
want
to
use.
B
So
far
we
have
had
kind
of
independent
valero
plugins
for
each
of
those
systems.
We
haven't
really
heard
about
a
commonly
used
system
that
needs
it.
But
reason
b
is
something:
that's
just
come
to
my
attention
and
I'd
really
love
to
hear
folks
thoughts
on
it.
It's
the
idea
that
when
you
have
valero
handling
credentials
for
say,
aws
or
azure,
my
understanding
is
that
they
have
to
kind
of.
B
I
guess
the
credentials
are
just
sitting
there
in
the
cluster
engineering
folks,
you
can
tell
more
I'm
sure,
and
it's
just
a
big
security
risk
and
my
understanding
is
for
sure
for
aws
and
I'm
verifying
for
azure
that
if
we
actually
use
the
csi
plugin
instead,
then
aws
will
handle
credential
rotation
automatically.
B
This
is
will
be
true
for
eks,
for
tanzu,
for
openshift,
probably
for
others
who
use
aws,
and
so
that
would
be
a
much
more
secure
environment
for
our
cust,
our
users.
So
let
me
pause
there
like
does
that
resonate
with
folks?
This
is
something
I'm
thinking
of
making
like
a
p0
like
this
investigation,
at
least
of
bring
to
ga
learning
what
we
need
to
do.
B
What
the
next
steps
would
be,
I'm
thinking
of
making
as
like
a
highest
priority
item
for
our
beijing
team
members
for
one
night,
but
I'd
really
love
to
hear
what
the
community
thinks.
C
So
this
will
be
an
optional
plugin
that
users
can
install
now
actually.
B
Sorry
that
was
stupid.
I
took
a
bite
of
food.
This
is
my
lunch
time
to
clarify
right
now.
If
you
are
an
aws
sorry,
let
me
swallow.
B
Don't
take
a
bite
right
after
I
ask
for
questions
and
comments,
I'm
all
good.
Now.
So,
interestingly,
let's
say:
let's
look
at
aws
and
so
someone
with
an
ebs
volume
right
now
there
are
two
different
paths:
to
get
to
do
that
volume
snapshot
you
can
use
our
aws
plug-in,
which
is,
I
think,
what
most
folks
do
and
it
uses
a
certain
path
and,
in
the
end,
ebs
hands
back
a
volume,
snapshot,
id
and
valera
runs
with
it.
In
that
method,
the
credentials,
I
believe,
are
are
less
secure,
aws
credentials.
B
On
the
other
hand,
the
csi
plugin
uses
a
totally
different
path,
but
it
still
actually
triggers
the
same.
It
still
gets
the
same
id
back.
The
same
volume
snapshot
id
back,
but
the
csi
plug-in
would
do
it
in
a
more
secure
way
with
credential
rotation.
So
the
answer
in
short,
is
I
don't
believe
that
you
or
anyone
your
dell
customers
or
anyone
would
have
to
move
to
the
csi
plug-in.
But
if
folks
have
the
security
concerns,
I'm
starting
to
hear
about,
then
the
csi
plug-in
would
be
an
option.
D
Yeah,
so
somebody
else
talking.
Yes,
I
think
those
are
reasonable
reasons
to
move
forward.
We've
gotten
a
lot
of
complaints
in
various
areas
where,
like
hey,
we
don't
want
to
have
credentials
exposed
into
the
cluster,
and
you
know
for
good
and
bad.
It's
still
going
to
require
that
there
be
an
s3
identity
available.
D
I
am
to
talk
to
s3
and
talk
to
the
bucket,
so
that
would
that'd
be
a
change
in
like
the
aws
plug-in
as
well
so
yeah.
Ideally,
there's
like
well,
I'm
not
sure
about
ideal.
It's
it's
kind
of
it's.
It's
kind
of
an
interesting
situation,
but
the
possibility
of
not
having
any
credentials
present
in
the
cluster
for
backup
would
probably
be
a
good
option.
At
least.
B
D
D
B
D
An
aws
like
in
aws
each
worker,
now
each
ec2
instance
gets
like
a
default
set
of
credentials
that
you
can
fall
back
to
and
that's
actually
attached
to
the
node.
It's
outside
of
the
os.
D
D
B
Is
I
think
that
this
is
more
an
addition?
I
think
dave
is
pointing
out
that
this
bringing
it's
really
good
for
me
to
know
bringing
the
csi
snap
plug-in
to
ga
will
not
solve
all
of
our
problems
and
so
he's
discussing
another
way
to
solve
the
existing
problem.
I
would
say
that,
at
least
for
my,
I
think
that
what
he's
suggesting
is
not
on
the
is
not
what
I'm
suggesting
for
one
night
right
now,
I'm
more
suggesting
the
csi
plugin.
D
B
B
C
Okay,
so
first
you
look
for
powerpoint
yeah,
it
does
the
csi
snapshot.
So
I
wanted
to
make
sure
that
csi
would
want
it
to
be
an
optional
plugin
that
users
can
install
or
not
install.
B
C
No
both
so
so
it
does
the
creates
the
css
snapshots
and
then
moves
the
snapshot
to
it's.
A
storage
bar
protect
youtube
storage.
D
B
D
No,
so
eventually
what
should
be
happening,
the
the
thing
that
should
be
happening
is
the
volumes.
There's
the
dash
dash
volume
snapshots
option
to
valero.
If
that's
not
set,
none
of
the
volume
snapshots
should
get
triggered
csi
or
anything
else.
That
may
not
be
true
at
the
moment,
but
that
that
needs
to
get
fixed,
I'm
pretty
sure
the
vsphere
plug-in.
If
you
install
it,
will
always
get
triggered.
C
B
But
but,
needless
to
say,
sukarna
in
general,
this
is
just
taking
an
existing
plug
and
that's
beta
and
bringing
it
to
ga.
It's
basically
adding
another
option
for
users
and
it's
and
in
the
future
we
may
all
need
to
switch
to
it.
As
as
the
see
everyone
moves
more
to
csi
snapshotting,
but
for
now
it'll
just
be
a
ready
to
go
option
as
opposed
to
a
beta
option
sure.
So
I
I
would
anticipate
for
dell.
It
shouldn't
change
anything
unless
you
want
to
use
it.
F
D
Right
so
there's
a
couple
of
different
different
paths.
Right
so,
like
I
think,
if
you
do
a
an
eks
setup,
the
credentials
for
the
csi
driver
are
the
node
credentials
or
what
it
uses.
So
it's
not
visible
from
inside
the
kubernetes
cluster
there's
a
similar
setup.
D
So
you
know
vmware
has
too
many
tkgs,
so
tkgi
their
csi
implementation
puts
the
credentials
into
the
node
os
and
it's
not
visible
from
kubernetes
versus
like
the
vanilla
path,
where
they're
visible
from
where
the
csi,
where
the
vcr
credentials
are
a
secret
in
the
kubernetes
cluster.
F
Yeah,
I
think
I
let
me
take
a
step
back
sorry,
I'm
asking
questions
that
probably
have
no
context.
I
believe
that
we
should
totally
move
this
forward
to
ga.
I
totally
think
that
that
makes
sense.
F
What
I'm
trying
to
make
sure
is
that,
like
we're,
not
saying
that
we're
going
to
be
able
to
do
things
that,
like
are
just
pushing
the
problem
off
so
like
in
this
use
case,
I
still
think
like
somebody's
just
going
to
be
responsible
for,
like
some
sort
of
potential
request
responses
like
if
you're
using
valero
it
now
matters
like
which,
whoever
how
you're
using
kubernetes,
where
you're
using
kubernetes
and
how
those
credentials
are
managed
for
the
csi
driver,
which
is
fine
just
wanting
to
throw
it
out
there
that,
like
it's,
not
going
to
immediately
solve
the
problem
for
every
user.
I
F
Yeah,
I
just
wanted
to
throw
it
out
there
that,
like
that's
what's
anyway,.
D
B
Well
and
also
oh
gosh,
and
I'm
going
to
try
to
reproduce
what
one
of
the
tanzu
tech
leads
said,
but
he
said
something
about
how,
if,
basically
that
we
have
to
like
you
don't
have
to
I
mean,
maybe
that's
what
automatic
credential
rotation
is.
B
I
don't
really
know,
but
basically
that
if
we
allow
at
least
for
tan
to
allow
the
platform
to
hit,
if
valeria
doesn't
need
it
directly,
then
aws
can
handle
more
of
the
credential
rotation,
all
that,
so
it
does
not
make
it
inherently
safer,
or
does
that
resonate
with
you,
I'm
talking
about
an
area
I
know
very
little
about
so
basically,
he
said
because
valero
needs
it.
We
have
to
actually
put
the
credentials
in
the
cluster,
whereas
apparently
he
thinks
we
do
not
need
to.
If
we,
if
we
use
the
csi
snapshotting.
F
Blame
that
yeah
both
the
platform
you're
using
so
like
you
know
whatever,
however
you're
using
kubernetes
and
then
also
the
individual
csi
plug-in
it's
gonna.
It's
gonna
defer
the
problem
completely
to
them.
I
still
think
it
will
make
total
sense
to
do
it,
but
I
don't
know
if
it
like
immediately
gains
users
the
ability
to
do
automatic,
credential
rotations,
just
because
it's
just
interesting.
Okay,.
B
So
there'll
be
some
other
language
yeah
to
me.
Also,
it's
separation
of
concerns,
like
I
really
want
valero
just
to
be
just
to
have
to
worry
about
data
protection
and
not
about
security
and
to
me
this
allows
us
to
like
hand
it
off
to
the
platform,
who
may
be
better
equipped
with
security
experts
or
something.
But
I
absolutely
hear
your
point.
I
will
make
another
note
in
my
issue.
B
D
B
B
C
So
we
so
dave
was
mentioning
that,
depending
on
the
storage
provider,
the
behavior
will
change
like.
If
it
is
vsphere,
then
there
will
be
data
transfer,
plus
snapshotting,
whereas
for
aws
we
will
just
do
the
snapshot
and
have
the
underlying
storage
to
the
transfer
to
secondary
storage.
So
then,
like
for
on-prem,
so
is
that
controllable,
behavior.
B
And
then
I'm
gonna
hand
it
off
to
dave,
so
that
is
absolutely
still
a
concern
and
I
don't
have
a
great
answer
for
that.
In
my
mind,
by
bringing
the
csi
plug-in
to
ga,
I
would
want
to
be
able
to
say
aws
and
azure
users
where
we
know
underneath
the
hood
csi
snapshotting
has
data
movement
use
it.
Please
use
it.
It'll
make
things
potentially
more
secure
for
you.
B
I
have
enormous
concerns
about
non-awns
and
azure
platforms,
and
we
still
have
that
that
reason,
one
of
why
we
have
not
brought
it
to
ga
so
far.
A
question
I
have
is,
as
I
know,
that
we've
really
been
thinking
about
doing
data
moving
the
data
mover
from
the
valeria
plug-in
for
vsphere
to
valero
plot
proper
we're
going
to
want
to
start
that
work
in
one
nine
we've
been
talking
about
this
for
a
while.
B
D
So
our
one
nine
plan
was
to
get
data
movement
into
valero
and
then
once
that
was
available,
go
ahead
and
enable
the
csi
snapshotting.
So
that
was
the
original
plan.
I
you
can
certainly
go
ahead
and
enable
it
or
bring
the
csi
snapshot
into
ga
and
tell
people
it's
like.
You
know,
watch
your
fingers
yep
using.
D
You
know
don't
do
this
if
you're
in
this
situation-
and
you
do
this
you're
not
going
to
get
what
you
expect,
you
should
continue
to
use
resting.
That's
that's
just
messaging,
and
all
it's
really
going
to
result
in
is
is
tears
from
people
who
you
know,
didn't,
read
the
instructions
and
then
wound
up
in
a
bad
place.
D
I
I
think
personally,
I
think
I
think
data
movement
was
really
important
for
valero,
so
that
was.
I
would
try
to
keep
that
on
the
roadmap.
As
far
as
putting
the
data
mover
into
the
csi
plug-in,
that's
a
possibility,
but
it's
probably
about
as
much
work
as
putting
it
into
valeria.
Sorry,.
B
D
Yes,
and
no,
because,
what's
so
what
we,
what
we
don't
have
so
what
we
have
implemented
at
the
moment
in
the
valero
plug-in
is
both
the
snapshotting
through
vstr
and
that
would
get
replaced
with
the
csi
snapshotting,
so
that
that
path
is
good
as
soon
as
these
fair
implements
hold
up.
The
other
thing
is
the
data
mover
itself
currently
only
talks
to
vadp,
which
is
the
which.
D
So
then,
that's
where
we
were
looking
at
doing
data
paths
via
the
astrolabe
stuff
and
implementing
like
evs
direct,
and
there
was
also
on
my
roadmap.
There
was
a
generic
path
so
with
csi
snapshotting,
there's,
currently
no
data
path
defined.
D
So
if
all
you
have
is
the
standard
stuff,
you
can
only
use
the
csi
apis
and
that
would
require
us
to
do
snap
clone
the
snapshot
to
a
new
pv
then
attach
the
pv
to
a
container
to
a
pod
and
then
use
something
like
restic
or
copia,
or
tar
to
extract
the
data,
and
that
would
give
us
a
generic
path.
B
Yeah
well,
my
inclination
from
a
prioritization
point
of
view
is:
there
is
clear
value
like
I
think,
most
of
our
users
use
valero
on
aws
or
azure
or
potentially
vsphere
that
I
know
less
about
the
overall
user
base.
But
all
that's
to
say
is
that
bringing
the
csi
plug
into
ga
and
making
it
very
and
knowing
that
it
works
for
azure
and
aws
users
that
has
clear
value.
It
reduces
the
security
risk.
B
That's
currently
present
with
the
credentials
this
idea
of
putting
in
data
movement
for
the
non-platforms,
I
guess
as
dave's
saying
I
would
prefer
to
have
really
clear
messaging
of
like
please
don't
hurt
yourself.
These
are
the
risks
and
then,
as
we
see,
use
cases
of
platform
x
that
has
cs
you
know
that
needs
this.
B
Then
we
can
start
thinking
about
doing
this
work
and
seeing
how
how
much
there's
user
need,
and
in
parallel,
I
still
want
to
move
the
data
over
to
valera
for
a
number
of
other
reasons,
and
that,
knowing
that
we
have
that
as
a
possibility
in
the
future
is
good,
but
I'm
not
sure
if
I
would
hook
it
up
to
the
csi
plug-in
until
we
see
specific
asks
for.
D
It
there
were
a
couple
of
other
concerns
with
csi
that
I
wanted
to
make
sure
we
had
fixed
as
we
move
forward
to
ga,
okay,
and
one
of
them
is
the
scalability,
because
the
csi
snapshots
are
a
little
different
from
the
other
snapshots.
D
B
D
So
I
was,
I
was
planning
to
change
the
way
we
used
the
csi
snapshot,
so
we
didn't
leave
the
records
hanging
around,
but
just
kept
the
the
pointers
in
the
backup
and
there's
also
the
issue
of
life
cycle
management
of
the
snapshots
after
the
namespace
disappears,
because
if
you
have
a
namespace
and
you
back
it
up
with
csi
snapshots,
that's
fine,
but
then,
if
you
delete
the
namespace,
but
the
backups
still
exist
in
order
to
clean
out
the
snapshots,
you
need
to
create
a
snapshot
record
somewhere.
D
You
need
to
statically
provision,
the
volume
snapshot,
volume
snapshot,
contents
and
that
needs
to
happen
somewhere
and
since
the
original
namespace
doesn't
exist
anymore,
you
gotta
set
it
up,
so
it
does
it
in
like
a
special
place,
which
I
don't
believe,
that's
not
there.
In
the
current
code.
I
think
that's
necessary.
D
So
there's
a
couple
issues
that
we
need
to
take
care
of,
but
scale
scalability
testing
would
be
a
prime
one
and
making
sure
that
you
know
we
can
handle.
You
know
n
backups,
with.