►
From YouTube: Velero Community Meeting - March 22, 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
So
welcome
folks
today
is
march
22nd.
This
is
the
valero
community
meeting
I
apologize.
I
need
to
screen
share
shall
settle
that.
First.
A
Okay,
hopefully
everyone
can
see
my
screen,
so
if
you
have
not
done
so,
please
put
yourself
as
attendee.
It
just
helps
us
know
who's
who
so
without
further
ado,
we'll
dive
into
status
updates
looks
like
I'm
calling
out
daniel
as
he's
updating
daniel.
Are
you
able
to
give
an
update,
or
do
you
want
a
long
to
go
first
and
actually
fong?
It
looks
like
yours
is
more
of
a
discussion
topic.
So
do
you
mind
if
I,
if
you
don't
like.
B
Yourself,
I
can,
I
can
do
the
update
yeah,
the
one
thing
I
want
to
announce
or
inform
other
community
members
that
we
upload
the
internal
discussion.
We
have
made
the
decision
that
we
will
ga
the
csi
plugin
for
the
phase,
one,
which
means
we
ga
the
functionality
that
does
not
require
data
movement,
we're
gonna,
ga,
the
css
plugin
in
the
form
of
the
current
design,
the
backup,
automation,
resource
manager
and
delete
item
action.
B
We
have
done
some
tests
and
pull
out
a
list
to
fix
the
issues
we
think
that
are
important.
So
this
is
the
list,
as
is
in
the
link,
as
it's
also
shown
in
eleanor's
screen,
so
we're
gonna
fix
this.
The
estimate
is
that
we're
gonna
fix
it
in
around
four
or
five
weeks,
so
I
think,
can
be
done
before
the
planned
fc
date.
B
A
request
to
the
community
member
is
that
if
you
think
there
are
any
additional
issues
that
are
important
for
the
csi
plugin,
please
feel
free
to
ping
us
on
the
slap
channel
or
add
me
in
the
github
to
make
sure
that
those
are
in
our
radar
and
we'll
re-estimate
and
see
if
we
can
also
prioritize
them
so
to
provide
a
better
functionality
for
the
csf.
Plugin
yeah.
That's
for
the
sat
plugin
and
another
thing
is:
I'm
also.
A
I'll
just
note
just
quickly
for
the
csi
plugin,
if
you
want
to
see
that
list
later,
if
you
have
forgotten
the
label,
if
you
go
just
a
reminder,
our
roadmap
is
accessible
if
you
go
to
the
wiki
and
then
to
the
sidebar
and
so
for
that
item
for
the
csi
plugin
for
notes.
That's
where
I
put
this
list
of
issues.
So
if
you
want
to
find
it
later
or
you
can
just
look
at
the
community
notes
daniel,
please
continue
yeah.
B
Another
item
I
didn't
put
in
the
hackmd
is
that
I'm
reviewing
dave's
pr
yeah,
it's
a
large
one
and
I
haven't
been
looking
at
it
for
for
for
some
time,
so
it
still
needs
some
time
for
us
to
finish,
but
yeah
just
shout
out
today.
Thanks
for
his
efforts
to
continue
working
on
that.
A
A
Okay,
now
maya
suggests
that
we
first
of
all
time
box,
because
we've
got
three
big
items.
I
don't
know
how
big
the
version
plug-in
is
but
plug-in
versioning
is,
but
I
want
to
make
sure
we
have
time
for
everything.
First
of
all,
fun.
I
think
we
can
definitely
do
a
plug-in
versioning
first,
since
you
actually
had
it
before
I
put
the
other
two
on,
shall
we
estimate.
A
D
So
basically,
I
think
daniel
already
merged
in
the
design
dock
for
the
version
name
right
daniel
yeah.
So
I
think
the
next
step
is
we're
gonna
start
with
implementing
it,
but
whether
we
want
to
go
make
it
go
in
into
this
release.
I
think
I
I
think
we
should
do
that
for
the
next
lease,
because
we
might
not
have
time
to
do
it
for
this
release
right.
B
Yeah,
that
depends
because,
in
the
various
teams
where
we
are,
I
think
we
we
will
be
focusing
on
the
csi
plug-in
and
the
copy
and
data
mover
stuff.
B
So
yeah,
because.
D
And
I
think
we
we
discussed
earlier,
I
think,
scott
and
and
I
post
on
the
the
flat
that
we
want
to
firstly
factor
the
code
to
make
sure
it
is
still
working
with
the
existing
one.
First
right,
we
really
factor
we
put
it
into
like
a
version,
one
directory
and
we
make
sure
that
it's
still
working
with
the
product
plugin.
D
That
is
the
first
thing
you
want
to
do
and
that
one
will
not
introduce
should
not
introduce
any
any
break
or
anything
like
that
yet
before,
and
then
we
will,
after
that,
one
coming
in
merchant
and
everything
right
and
then
we
will
start
adding
version
two.
So
that
alone,
I
think
the
first
one
alone
might
take
about
one
month.
E
E
I
mean
I
mean
that's
a
road
map
question
not
not
so
much
a
development
question
in
terms
of
what
you
work
on
right
now,
unless
those
are
the
priorities,
meaning
that
you
know
if
you
on
one
extreme,
you
know
if
a
week
from
now-
and
I
know
that's
not
going
to
be
the
case-
it's
done
then
probably
there's
time
to
get
it
in
and
test
it.
For
you
know
one
nine,
but
if
it
takes
three
months
to
you,
know
get
this
pr
written
and
approved
and
merged,
and
then
it
wouldn't.
E
E
I
think
the
first,
the
first,
the
first
pr
to
put
together
to
get
merged,
is
going
to
be
introducing
the
concept
of
plug-in
versioning
and
declare
all
the
current
plug-ins
to
be
version
one
without
adding
a
version
to
anything
to
make
sure
that,
like
you
said,
everything
works
with
the
infrastructure
around
versioning
for
version,
one
of
everything,
so
that
all
of
the
you
know
everything
works
and
in
terms
of
version
two,
I
don't
think
we're
gonna
make
a
version
of
everything
we
only
need
to
ver.
E
We
only
need
to
increment
those
plugins
where
we
have
the
changes
to.
So
you
know
if
no
one's
changing
backup
item
action,
for
example.
If
we're
not
adding
it,
you
know,
then
we
don't
have
a
version.
Two
we'll
just
stick
with
version
one.
We
only
need
to
make
a
version
two
for
those
plugin
interfaces
that
we
actually
need
to
change.
So
you
know
whatever.
E
D
Okay,
in
that
case,
I'm
gonna
start
create
a
brand
and
score
refactoring
to
make
sure
the
version
one
working-
I'm
gonna
start
this
week
and
whatever,
let's
see
how
far
we
can
go
with
that
one
and
then
after
that,
if
if
we
can
merge
that
in
in
then
we
talk
about,
you
know
adding
version
2
afterwards
right.
E
Right
and
again
the
version,
the
version
2
discussions
are
going
to
be
based
on
what
features
we
need
to
add
that
you
know
change
the
versioning,
so
that's
the
timeout
stuff
you're
talking
about
and
then
there's
the
additional
items,
readiness
code
that
I
need
to
add.
So
I
know
those
are
those
are
the
stories
I
know
those
are
the
only
two
things
that
we
know
we're
adding
to
the
plugin
versions
right
now.
So
that's
so
you
know
and
is,
is
your?
Is
the
the
change
you're
making?
E
D
E
E
That,
too,
is
that
when
we
start
talking
version
two,
you
know
you
there's
one
change.
One
set
of
changes
for
backup,
item
action
version,
two,
that's
kind
of
driven
by
your
requirements
and
then
there's
the
restore
item,
action
version,
two
that
I
need.
So
those
two
pieces
of
work
are
that
independent.
E
You
know
creating
version
two
for
backup,
item
action
and
version
two
for
store
item
action,
so
those
can
be
done
kind
of
separately
from
each
other
once
the
v1
stuff
is
all
in
place
and
then
maybe
that
you
know
the
infrastructure
makes
it
into.
You
know
the
next
release,
although
I
don't
know
that
at
this
point,
but
you
know
the
actual
v2
implementations
may
not
make
it
until
a
subsequent
release,
because
they're
really
independent,
you
need,
you
can
do
those
at
the
same
time.
E
You
know
we
can
whatever
next
release
that
includes
versioning
could
include
a
v2
for
some
things,
but
it
doesn't
have
to.
It
could
be
that
a
release
includes
just
the
infrastructure
around
versioning
and
the
v1
for
everything.
But
it's
just
the
next
release
that
actually
adds
a
v2
for
something
depending
on.
D
B
Yep
yeah,
if
you
have
anything
the
phone
and
sky,
if
you
have
anything
you
want
to
discuss,
please
make
it
public
on
the
valero,
dev,
channel
and
yeah
involved.
That
makes.
B
One
kai,
because
we're
going
to
be
reviewing
the
pr
as
well
yeah.
F
B
And
one
more
thing:
as
for
the
v2,
what
change
needs
in
the
v2
api
have
that
all
been
discussed
already,
because
after
I
joining
the
vm,
I
mean
the
valero.
I
don't
think
anything
has
discussed
like
how
the
v2
should
look
like.
D
We
did
discuss
back
then,
but
I
think
I
can
restart
the
conversation
again.
That's
with
that
yeah
yeah
for.
D
E
E
B
I
mean
I
have
a
concern
because,
for
example,
you
have
a
change
in
backup
item
action.
You
want
to
add,
say
a
contacts
in
the
parameter,
but
would
that
only
happen
in
backup
as
an
action?
Should
we
also
add
them
to
the
restore
item,
action
or
delete
item
action
to
you
know
for
consistency?
That's
something
we
need
to
think
about.
B
E
Make
sense
and
to
answer
the
question
on
the
on
the
the
restorative
action
change
that
I
that
I
was
talking
about.
I
need
to
check
that
as
I
I
had
an
approved
design
doc
and
then
I
think
there
was
a
pr
that
to
change
it
again.
It
does
it
doesn't
address
I
gotta
go.
I
can
look
at
it
because
I
think
that
design
doc
does
mention
the
change
to
the
interface
that
would
be
needed,
but
that's
obviously
not
in
the
context
of
the
plug-in
versioning,
so
that
probably
needs
a
separate
design.
E
Dock
specific
to
the
plug-in,
versioning
change
so,
and-
and
also
this
relates
to
funk's
point
about
you
know
in
terms
of
implementing
this.
The
first
iteration
of
plugin
versioning
is
just
to
get
the
infrastructure
in
place
to
support
versions
at
all
and
make
everything
of
you
one.
I
think
in
parallel
to
that
we
can
get
the
design.
E
You
know
discussions
going
for
any
interface
changes
we
want
for
v2,
so
we
can
work
on
the
v2
design
while
the
v,
while
the
infrastructure
for
v1
is
being
put
in
place,
but
we
wouldn't
actually
start
implementing
those
until
the
the
infrastructure
and
the
v1
stuff
is
all
done.
E
D
E
On
my
side,
I
will
hopefully
over
the
next
week
or
two
put
together
and
try
to
collect
the
the
aspects
from
that
prior
design
that
actually
involve
versions,
versioning
changes
and
try
to
get
that
into
a
separate
design.
E
Specific
to
you
know
a
change
we
want
to
make
for
our
store
item
action
and
I
think,
on
the
context
part
the
fun
is
talking
about
if
it
makes
sense
to
add
that
same
change
to
other
plugin
types
that
might
make
sense
as
well
for
consistency
as
long
as
there's
a
valid
function
for
that
context.
There
that
makes
sense
to
have
I
mean
I
don't.
A
Okay,
so
let's
figure
out
by
the
way
who's
doing
the
review
on
pr's
danielle.
Are
you
putting
that
in
or
is
that
a
different
person
meet
one
someone's,
adding
stuff
for
review
on
pr's,
and
I
was
wondering
daniel?
Is
that
you
or
is
that
someone
else.
A
Great,
what
I'm
trying
to
figure
out
is
timing,
say
what,
let's,
let's
time
box,
I
don't
know,
you
know
what
we'll
just
keep
it
a
little
bit
open-ended.
My
concern
is
that
data
mover,
I
think,
can
take
up
as
much
time
as
we
want.
So
I'm
inclined
so
just
so
folks
know
today
what
what
we're
thinking
of
I've
talked
to
dylan
and
he
elise
can
stay
after
this
meeting.
A
As
can
I
so
our
thought
is
to
maybe
start
the
data
mover
discussion
last
and
then
folks
who
want
to
stay
on,
can
go
late
and
will
of
course
record
so
that
folks,
who
don't
want
to
stay
continue
to
stay
on,
can
watch
it
later.
So
I
think
I'm
going
to
reorder
it
like
this.
If
folks
are
okay.
E
A
Yeah
yeah
perfect:
I,
like
that
plan
a
lot
good,
okay
and
so
copia
either
can
be
a
lot
or
a
little.
So,
let's
start
and
we'll
kind
of
see
where
the
discussion
goes
and
we'll
go
from
there.
So
just
to
remind
folks,
we
have
on
our
one
nine
road
map.
One
of
our
items
is
to
investigate
copia
and
see
whether
we
might
want
to
replace
rustic
with
copia,
and
so
I
think
it
was
ming
and
yanghui
I'm.
A
A
So
if
anyone
wants
to
look
at
this,
so
I
think
the
question
is
have
people
basically,
we
are
leaning
towards
replacing
rustic
with
copia.
I
think
that
this
well,
actually,
let
me
stop
jungkook
or
someone
else
from
the
valero
vsphere
team.
Does
anyone
want
to
say
what
we're
leaning
towards
and
I'd
love
to
hear
what
others
think
about
it?.
B
I
think
we
are
leaning
on
towards
replacing
rustic
with
cobia,
but
one
thing
I
would
like
to
point
out
is
in
our
discussion.
B
We
also
talked
about
what
should
be
the
backup
ripple
for
the
data
movement,
and
it
seems
it
makes
sense
to
you
know,
introduce
this
unified
a
little
bit
more
unified
data
path
to
you
know,
use
copia
as
a
backup
repo
for
the
data
movement.
So
there
is
some
dependency
in
terms
of
the
implementation
when
we
want
to
deliver
all
the
functions
and.
B
Yeah
I
like
the
fact
I
like
we
worked
again.
I
mean
I
like
to
work
together
on
them,
but
I
just
want
to
point
out.
There
is
some
dependency,
so,
for
example,
if
the
data
mover,
we
make
a
quick
progress,
but
then,
if
we
decide
that
the
data
more
will
depend
on
the
copia.
A
I
see
okay
good
call
out.
I
know
that
the
oedp
folks
specifically
want
data
mover.
I
wonder
whether
that
will.
I
guess
we've
talked
about
more
if
we
get
the
design,
so
I
guess
question
for
the
oedp
folks.
Will
that
be
a
blocker
for
you
or
if
we
get
the
design
done
for
data
mover,
you
guys
can
go
ahead.
Do
your
work
and
if
we're
a
little
delayed
due
to
copia
integration,
will
that
be
okay
for
you
or
you
can
think
about
it
and
get
back
to
us.
Yeah.
E
A
C
E
H
E
E
To
be
clear
at
one
point,
this
was
probably
a
year
ago
I
remember
there
was
discussion
about
the
the
rustic
replacement
discussions
kind
of
centered
around
making
it
pluggable,
so
users
could
replace
that
with
something
else,
and
it
sounds
like
we're
not
talking
about
that
at
this
point,
we're
talking
about
ripping
out
rustic
completely
and
replacing
it
with
copia.
So
you
know
valero
version
n
minus
one
will
have
rustic,
but
not
copia
and
version
n
will
have
copia
but
not
resting.
F
Well,
I
would
like
to
see
that
there's
a
plugable
repository
model
and
that
copia
is
a
reference
implementation
of
that,
but
that
we
could,
for
example,
you
know
replace
that
with
the
veritas
one
and
I
asked
amber
to
make
it
amber
vet
is
the
lead
over
at
veritas
he's
in
india,
though,
so
he
wasn't
able
to
make
the
time
but
they're,
definitely
an
interested
party.
F
I
think
from
the
casting
side,
we'd
like
to
look
towards
shared
infra
and
especially
like
on
vsphere,
so
tkgs
is
driving
us
nuts
and
we'd
like
to
not
have
to
implement
our
own
data
mover
for
tkgs,
but
we'd
like
to
have
something
that's
that
we
can
plug
into
that
vmware
ships,
yeah
vr
yeah,
so.
F
What
it
gets
interesting
is
when
you
do
non-file
system
things
when
you
store
blobs
into
it
and
that's
where
copia
makes
it
more
and
makes
it
better
and
there's
actually
changes
for
pushing
so
casting
is
pushing
changes
into
copia
to
handle
change,
block,
tracking
and
basically
large
blobs,
going
into
it
better.
H
Yeah
actually
make
a
pluggable
repository
is
also
the
goal
we
discussed
internally
and
for
the
first
phase
we
will
just
introduce
the
copia
and
but
we
will
introduce
a
unified.
H
You
know
plugin
and
interface
as
architecture,
so
that
in
future
any
other
kind
of
repository,
like
you
know,
any
backup
repository
or
any
other
open
source
repository
can
be
plugged
in.
That
is
the
the
intelligence
and
that's.
H
Actually
we
haven't
discussed,
you
know
the
detailed,
the
interface
or
something
like
that
internet.
F
E
Okay,
so
and
there's
a
again
I'm
sorry
this-
I
I
just
scanned
the
document-
I
don't
see
it
here,
but
maybe
this
is
already
addressed,
but
one
of
the
things
in
the
past
I
know
we've
done,
is
you
know
so
you
know
a
backup
done
on
valero.
One.
Seven,
for
example,
should
work
finder
store
on
valero
one,
eight,
I'm
assuming
that
with
the
switch
from
rustic
to
copia
we
would
be
explicitly
not
backwards
compatible
in
terms
of
rustic
backups
from
the
old
old
version.
B
I
think
there
will
be
a
couple
of
minor
versions
that
we
need
to
make
sure
that
if
users
are
back
up,
you
know
using
the
rastic
can
be
restored,
that
we
we
have
to
ensure
that,
but
I
think
in
the
installation-
maybe
I'm
not
thinking
through
all
the
details,
but
in
the
in
the
installation.
Maybe
we
let
user
to
choose
to
use
jurassic
or
copia.
E
F
E
F
E
Make
yeah
yeah,
that's
true,
so
I
mean
I
guess
that's.
The
question
is:
is
that
one
of
the
goals
that
we
that
we're
trying
to
preserve
here
are?
Are
we?
Are
we
going
to
tell
users
that
they
have
to?
You
know,
restore
to
yeah?
I
mean
you
know,
restore
with
an
old
valero
and
then
back
up
again
with
a
new
one,
or
are
we
going
to
allow
rustic,
restores
kind
of
for
some
transition
period,
but
yeah
you're
right?
F
E
Yeah-
and
this
is
a
special
issue-
an
issue
given
that
we're
trying
to
you
know
in
some
cases
by
necessity
like
the
v1
beta,
1
ap
and
the
crds,
but
also
just
in
just
from
our
supportability
point
of
view.
You
know
we're
not
supporting
you
know:
kubernetes
111
through
122.
You
know
in
the
same
release
now.
F
I
think
it
definitely
I
mean
it
sounds
like
you
know,
daniel
wants
to
go
in
that
direction.
I
think
it's
definitely
the
direction
we
would
want
to
go
in
unless
it's
completely
infeasible,
but
I
don't
see
why?
Because
we
already
have
all
the
rustic
restore
code,
you
know
if
you
take
it
out
of
the
backup
side.
It's
probably
not
that
big
a
deal.
E
Yeah
as
long
as
the
way
you
implement
the
the
copia
or
this
plugable
thing
with
copia,
you
know
kind
of
tied
into
it
because
because,
because
now,
in
a
restore
you've
got
you
know,
snapshot
restore
rustic,
restore
and
this
new
plugable
restore
copy
restore.
So
you
you
know,
you've
got
multiple
things,
so
you
do
have
more
things
to
worry
about
in
terms
of
annotations
and
and
what
mode
you're
in
you
know
the
whole,
because
the
whole
like
default,
thoracics
versus
default
or
not
resting.
That's
that
you
know
that's
a
boolean,
basically
right.
F
A
Now
I
just
want
to
pause
and
ask
a
question,
because
I
want
to
be
cognizant
of
the
other
things
we
want
to
do
today.
Do
we
feel
like
we
have
enough
agreement
to
to,
for
whoever
on
the
team
will
be
working
on
copy
a
bit
more
to
kind
of
move
forward?
Think
more
about
a
design
think
more
about,
I
mean.
A
Obviously,
I
should
probably
have
think
about
this
kind
of
requirements
for
users
like
basically
do
we
want
to
discuss
more
today
or
do
or
do
we
feel
like
we've
covered
major
objections,
we've
called
out
two
good
points,
which
is
plugable
repo
model
and
kind
of
backwards
compatibility,
and
then
maybe
we
can
come
back
to
this
in
a
couple
weeks
and
and
dive
deeper
once
we've
done
some
more
designing.
A
F
I
mean
you,
don't
have
to
do
anything,
but
I
think
it'll
be
a
lot
easier.
If
you
make
it
plugable
because
then
you
know
you
have
the
option
to
change
it
out
with
something
else,
and
it's
also.
I
it's
definitely
more
palatable
from
the
casting
point
of
view,
and
I
think
you
know
like
veritas
would
probably
want
to
have
that
as
well.
F
B
Yeah,
that's
a
gut
feeling
because
currently,
for
example,
in
the
backup
status
or
when
you
describe
backup
you
have
this
rastic
chunk
as
an
example,
we
can
add
a
copier
chunk,
but
in
the
plugable
design
that
won't
work,
we
need
some
other
way
right.
That's
just
one
example.
I
I
assume
there
are
other
parts
we
need
to
think
about.
That's
in
the
implementation,
it's
quite
different.
If
we
decide
to
go
the
pluggable
model.
A
F
No,
I'm
just
thinking
that
you
know
we
want
to
put
other
things
in
besides
file
systems,
so
you
know
we're
talking
about
like
cassandra,
for
example,
streaming
directly
in
so
you're,
probably
going
to
want
to
have
a
repo
api
of
some
form.
It's
not
going
to
be
straight
copia
and
once
you've
built
that
api.
It's
like!
Why
not
abstract
it
out
enough
that
it,
you
can,
you
know,
switch
it
around.
B
A
More
generally,
I
think
a
question
too,
especially
if
we
might
be
putting
a
cast
in
repo
in
our
veritas
repo
dave.
I
don't
know
if
you'd
have
any
availability
to
kind
of
help
out
with
the
design
a
bit.
If
this
would
be
helpful
daniel,
you
tell
me
or
maybe
amber
as
well,
basically
folks,
who
are
more
familiar
with
other
repos
that
we
might
want
to
plug
in.
I
have
to
imagine
that
that
might
help
as
we're
designing
if
we're
designing
a
repo
api.
F
Yeah,
I
would
like
to
you
know
either
myself
or
get
some
of
the
other
casting
folks
in,
because
I
think
one
of
our
hot
buttons
is
supervisor
cluster
with
vsphere.
And
how
do
we
back
things
up
without
us
building
a
whole
bunch
of
weird
stuff
in
supervisor
cluster?
So
it'd
be
nice
if
we
could
share
vmware
infrastructure
like
a
data
mover
that
gets
put
into
supervisor
cluster,
and
we
could
use
that
rather
than
having
to
install
our
own
up
there.
F
F
We
have
two
back
ends,
so
one
is
copia
that
sits
on
top
of
object
stores.
The
other
is
integrated
with
veeam
veeam,
backup
repository,
and
so
we
we
need
to
be
able
to
use
either
back
end.
F
Yeah
yeah,
okay
yeah
those
back
ends,
so
you
can
think
so.
If
we
have
like
a
replay
api,
we
can
put
vbr
behind
it.
It
actually
gets
kind
of
interesting
and
the
other
thing
we
can
do
is
we
can
also
start
to
promote
the
repo
api
out
to
other
people
so
like
they
can
back
up
their
operator,
for
example,
and
go
directly
into
the
repo
rather
than
having
us
move.
The
data
for
the
possibility.
A
Okay:
okay,
thank
you
for
clarifying
that.
Well
daniel!
Let's
talk
a
little
more,
I
mean,
let's
think
about
this.
I
think
that
we
can
kind
of
you
know.
B
H
Yeah,
I
think,
maybe.
H
We
need
to
know
how
the
you
know
the
things
like
veritas
occasion
how
how
how
they
use
copyright.
I'm
sorry
how
how
do
you
use
the
weather
right
so
dave?
Maybe
we
can
ask
you
first,
how
will
the
kitchen
use
with
arrow.
F
Yeah,
so
currently
we
don't
right-
and
that's
actually
so
we
were
discussing
before
I
moved
over.
There
was
a
discussion
of
collaborating
together
on
the
astrolabe
layer
and
that's
been
a
little
bit
of
a
hot
button
from
the
cast
inside,
because
tasting
feels
that
valero
is
a
backup
product
and
putting
caston
and
or
k10
and
valero
kind
of
working
with
each
other
is
a
little
weird,
whereas
like
astrolabe
was
positioned
as
insulin
and
that
was
like
yeah
k-10
uses,
astrolabe
valero
uses
asteroids.
F
That
was
more
palatable,
so
what
we'd
like
to
do
is
we'd
like
to
be
moving
forward
in
terms
of
how
we
design
out
the
interest
stuff
so
that
we
can
push
things
down
to
kubernetes
use
more
community-based
stuff.
For
you
know
these,
these
low-level
things
veritas
is
embedding
valero,
as
is
dell
emc
as
a
number
of
other
people,
so
they
need
to
be
able
to
do
things
like
get
valero
to
work
with
their
repository
directly.
F
So
that's
something
we
should
get
yeah.
I
really
like
to
see
more
input
from
the
the
people
are
actually
embedding
valero
into
these
designs,
and
so
that's
something
I
think
we
need
to
reach
out
a
little
bit
more.
So
karna
is
not
here
today,
as
you
know
so,
sikana
from
dell
emc,
you
know
just
the
regular,
the
usual
suspects.
A
Okay,
although
we
do
have
a
bunch
of
dell
emc
folks
here
today,
so
thank
you.
That's
great
to
see
you
all
here,
so
I
did
I
might
suggest.
I
do
think
we
should
put
a
pin
on
this
just
because
we
have
those
pr's
and
we
should
at
least
start
a
little
bit
of
data
mover
discussion
before
and
I
added
one
thing
about.
I
realized
it's
like
a
meta.
How
do
we
have
these
bigger
discussions?
So
is
it?
A
G
G
G
Thank
you,
so
this
will
request
is
regarding
the
design
dock
which
we
agreed
upon.
So
this
was
released
last
week.
So
I
wanted
to
request
some
reviews
on
this.
It
would
be
really
great.
This
implements
the
approach
number
one
specified
in
existing
resource
policy
design
and
the
summary
also
gives
a
bit
of
what
is
added
there.
So
I
would
like
some
review
from
the
developer
team.
A
B
Yeah
in
our
weekly,
we
will
only
review
the
new
pr
for
those
ones
like
I
said,
if
you
want
us
to
take
a
look,
please
feel
free
to
clean
us,
otherwise
it
may
easily
slip
out
of
the
notification
and
by
the
way
I
see
the
reviewers
already
assigned
by
the
assignee
bot.
So.
A
Okay,
so
two
good
points
one,
I
good
for
me
to
know
for
the
future:
okay,
so
every
okay.
So
if
it's
a
new
pr
it'll
be
picked
up
by
the
weekly
review,
if
it's
a
returning
pr,
we
should
ping
and
then
the
second
question
is
so
dave.
Are
you?
Are
you
still
regularly
reviewing
pr's?
Are
we
good
to
leave
you
on
that
bot?
Are
you
less
involved
than
before.
F
A
And
hopefully
can
we,
but
hopefully
can
you
review
prs
that
are
more
related
to
the
more
infra
layer
that
interest
you
more
yeah?
Okay,
okay!
So
to
that
point
then
so
daniel
can
we
put
on
someone
else.
Who
could
I
mean
because
I'm
assuming
scottish
ruby?
I
know
that
scott
has
pointed
out
that
if
red
hat
folks
are
reviewing
other
red
hat
folks,
it's
nice
to
have
other
viewpoints.
So
am
I
basically
daniel.
Can
I
ping
you
on
this
yeah.
E
Yeah
and
obviously
I'll
review
it
as
well,
so
we
have
we
need,
we
need.
You
know
it's
a
second
reviewer.
G
A
B
Okay,
so
this
one
is
not
a
design.
This
one
is
for
the
implementation
right.
B
Yeah
yeah,
I
think
we
will
discuss
offline
with
other
vmware
folks
and
assign
someone
to
review
thanks.
A
Thank
you.
I've
just
commented
on
it
daniel
to
kind
of
make
it
an
email
in
your
inbox,
so
okay
good
to
move
on
to
the
next
pr,
then,
is
it
the
same?
Well
here
I'll
move
on
to
the
next
pr
tell
me
if
I
want
to.
G
Yes,
so
this
is
a
different
one:
it's
a
design
one.
So
if
you
move
on
to
the
last
comment
here
yeah,
so
I
just
wanted
to
know
if
this
is
a
good
idea
to
go
ahead
with
the
implementation
daniel,
is
it
okay?
If
we
just
expose
the
feature
why
apis
and
not
via
cli,
so
like
wanted
to
know
about
that
about
your
concern.
B
Yeah
yeah
next
time,
please
yeah,
maybe
that's
also
my
bad
because
you
added
me,
but
I
didn't
see
the
notification.
If
you
expect
my
response,
you
just
ping
me
on
the
staff.
You
don't
need
to
wait
for
a
full
week
until
next
community
meeting.
A
G
Wanted
to
put
that
on
the
map
for
review
and
the
second
one
I
wanted
to
know
whether
we
wanted
to
like
go
ahead
with
the
implementation
or
not.
So
that's
it.
Thank
you.
Well,.
A
I
really
appreciate
you
asking
these
questions,
because
I,
I
also
didn't
know
how
pr
reviews
were
working
lately
in
terms
of
pinging,
so
I
think
it's
great
that
you're
asking
because
now
everyone's
hearing
how
to
if
they
need
a
pr
reviewed,
what
to
do
so.
Thank
you
and
this
data
mover
design.
Is
this
bridget's
original?
Oh,
no!
No!
No!
Okay,
oh
so
shoe
palm
you've
put
a
new
design.
Is
this
basically
in
line
with
the
dylan's
kind
of
prd
doc.
J
I
can
just
spread
a
little
clarity
on
this.
We
want
to
be
kind
of
clear
about
what
this
is,
so
what
we
put
together
in
the
product
requirements
talk
is
basically
what
we
gathered
off
of
prototype
of
solution
here,
shoe
bombs,
design
dock.
There
tries
to
highlight
a
lot
of
the
goals
that
were
captured
from
everyone
that
commented
in
that
dock,
which
is
excellent,
but
we
also
just
wanted
to
include
like
how.
J
So
we
are
developing
a
version
of
a
data
mover
for
oadp
in
the
meantime,
but
basically
an
upstream
tool
that
technically
anyone
could
use
it's
not
actually
related
to
odp.
It's
in
a
whole,
separate
repository
that
just
tries
to
solve
this
from
like
a
pure
controller
approach,
and
we
just
want
to
detail
how
that
works
here
in
this
design,
and
then
the
thought
was
that,
as
the
prd
gets,
you
know
discussed,
and
we
kind
of
come
to
a
conclusion
as
to
what
exactly
this
should
look
like
integrated
back
into
valero.
J
We
can
keep
working
to
update
this.
So
I'm
sorry,
I
didn't
mean
to
cut
you
off,
but
I
just
want
to
be
clear
like
there
is
a
lot
in
this
that
is
really
specific
to
what
we're
doing
right
now
just
to
solve
this
problem
in
the
meantime.
But
we
really
want
to
keep
this
like
an
open
discussion
in
terms
of
now,
you
guys
can
see
what
we're
doing.
J
Let's
just
have
a
chat
like
how
this
should
go
when
it
gets
intended
back
into
valero,
and
this
can
be
like
a
living
breathing
design,
doc
that
gets
updated
over
time.
So
is
that
well
fair,
sorry,
I
don't
know
it's.
A
I
may
ask
that
right
now:
let's
first
see,
if
there's
any
meta
conversation
about
the
having
this
design
doc
versus
elsewhere,
I
don't
want
to
dive
into
implement
technical
details
before
we
have
another
meta
conversation
and
then,
lastly,
we'll
dive
into
data
mover
technical
details,
you'll
see
why
it
yeah.
So
are
there
any
comments
on
having
this
design
doc
versus
the
prd,
or
are
we
now
that
we've
heard
the
explanation?
Are
we
good.
J
Yeah
because
I
just
wasn't
sure
if
this
belonged
somewhere
else,
so
I'm
definitely
open
to
if
we
want
to
take
that
somewhere
else,
if
you
want
to,
if
you
want
to
put
in
hackmd,
that's
fine
just
wanted
to
kind
of
explain
this,
isn't
like
the
full.
We've
come
up
with
the
design,
we're
not
we're
not
changing
it.
It's
just
kind
of
a
little
intro.
I
guess.
J
The
hope
is
that
we
could
put
it
here.
If
you
actually
look
at
this,
it's
it's
like.
We
try
to
segment
it
into
what
are
the
high
level
goals
of
data
mover
and
how
does
this
relate
to
valero
and
then
there's
just
a
whole
section
at
the
bottom?
That's
explicitly
detailing
how
we're
doing
this
today
with
full
sync,
so
it
our
intention
is
that
we
should
just
put
all
the
work
here,
because
the
existing
data
mover
design
pr
was
closed
by
bridget.
J
A
I
would
on
a
totally
just
again
meta
level
you
might
want
to
consider
putting
this
in
the
wiki
only,
and
I
can
give
you
permission
if
you
don't
have,
I
can
give
permissions
only
because
I
I
feel
like
we
can't
as
dynamically
kind
of
make
discussions
or
actually
never
mind.
I
guess
commenting
is
better
anyways,
never
mind
you
all
I'll,
be
doing
this
less
than
the
rest
of
you
so
never
mind.
Danielle.
Do
you
want
to
respond?
Sorry?
I
I
jumped
in.
B
No,
I
I
think,
yeah.
We
can
first
check
this
pr
then
decide
if
we
need
a
new
pr
for
design
or
we
continue
refining.
I
think
it
will
be
a
bit
easier
if
we
have
a
google
doc
to
have
everything
you
know
settled
when
this
concrete
and
someone
submitted
new
pr
to
have
all
the
details,
and
this
one
is
a
reference.
We
may
get
some
some
comment
in
it.
B
While
we're
working
on
the
you
know
the
the
the
design
that
will
be
revealed
and
emerged.
Do
you
do
you
think
that
that
sounds
like
a
good
plan
dealing
or
do
you
want
to?
You
know,
ask
keep
commenting
on
this
one
refining
this
one
and
have
this
particular
pr
merged?
Finally,
which
one
do
you
prefer.
J
I
just
figured-
and
again
I
don't
know
what
you
guys
were
thinking
here,
but
you
know
we
have
a
lot.
We
have
a
few
engineers
that
are
definitely
focusing
focusing
on
this
day
to
day.
So
we
were
happy
to
kind
of
push
forward
the
design
here,
okay
in
this
document,
but
if
you
guys
actually
wanted
to
help
contribute
to
that
process
too,
and
it
makes
more
sense
to
do
that
on
google
docs,
that's
fine
too
we're
definitely
open
to
whatever
is
going
to
collaborate.
J
The
easiest
I
just
I've
always
done
this
in
get
up
before
so
I
didn't
know
if
that
made
more
sense,
or
what
do
you
guys
want
to
do?
Yeah,
maybe.
B
K
Sure,
whatever
choice,
we
make
make
sure
that
we
keep
the
history
of
the
discussions
so
that
later
on,
when
somebody
says
hey,
why
did
you
do
it
this
way?
We
have
a.
We
have
a
track
of
that
discussion
that
the
community
can
look
at.
We
might
find
out
that
we
were
wrong,
but
at
least
we
have
the
reasoning
why
we
chose
that
to
at
least
one
tell
people
and
to
for
our
own
sanity.
When
we
go
back
and
look
at
it,
I
have
found
that
that
is
helpful.
J
Agree,
that's
why
I
like
get
up
for
this
for
sure
google
docs,
like
you're,
going
to
lose
you
close
comments
and
stuff.
It's
just
github's
always
been
pretty
good
for
this.
You
have
a
whole
comment,
trail
and
all
that
stuff.
So,
but
I'm
moving
your
ideas.
B
What
do
you
think
shall
we,
you
know
continuously
commenting
or
adding
stuff
in
this
pr
to
make
it
finalized
and
merged.
B
A
A
Speaking
of
kind
of
pain
points,
so
I
I
have
a
pain
point.
We've
been
wanting
to
talk
about
data
mover
and
there's
a
whole
bunch
of
people
who
need
to
be
involved
for
the
discussion,
or
I
know
our
stakeholders
and
because
we're
in
different
time
zones
plus
scheduling
on
the
fly
is
quite
hard.
So
I
don't
quite
know
the
solution.
A
I'm
wondering
whether
we
should
fertilize
as
times
like
these,
when
we
seem
to
have
a
lot
of
deeper
dis
things
that
need
to
be
discussed,
copia
and
data,
mover
being
that
and
frankly,
maybe
plug-in
versioning,
although
that
does
seem
to
go
faster.
A
I'm
just
wondering,
for
instance,
I'm
wondering:
should
we
reserve
the
this
time,
but
next
week,
potentially
as
like
a
longer
discussion
thing,
basically
or
maybe
it's
just
for
data
mover
and
copia
discussions-
I
think
right
now
we
don't
have
anyone
in
europe
working
on
that
so
this
time,
but
next
week
should
work.
Is
there
another
time
we
can
also
potentially
go
after
this?
J
I
love
the
idea
of
breaking
this
into
a
working
group
so
that
we
don't
have
to
bog
up
every
community
discussion
with
this
topic.
I
think
that's
a
great
idea
and
I'd
also
suggest
just
because
we
have
engineers
in
north
america
that
are
also
interested
in
this,
but
they
necessarily
can't
always
join
these
nighttime
calls,
and
we
could
maybe
split
it
up.
Sometimes
this
morning,
north
america
time
sometimes
evening,
like
obviously
we're
happy
to
make
it
work
because
we're
all
across
the
globe.
E
Well,
and
also,
I
know,
12
really
doesn't
work
for
people
in
china
in
terms
of
timing
at
all,
but
like
a
morning
north
america
time,
you
know
a
little
earlier
earlier
than
our
normal
north
american
meeting
might
work
that
doesn't
work
as
much
on
pacific
time,
but
I
don't
know
if
you
know
so
you
know
again
that's
the
challenge.
I
guess.
G
A
J
A
We're
at
12
hours
right
now
so
tentatively,
especially
because
we're
in
planning
period,
maybe
we'll
do
this
exact
time
next
week
on
the
29th
plus.
I
don't
know
if
this
would
be
too
soon,
but
I
wonder
if
we
could
do
for
north
americans
wednesday.
The
third
I
don't
know
actually
never
mind.
That's
two
two
back-to-back
meetings,
maybe
thursday,
the
31st.
I
guess
I
guess
the
question
is:
how
many
meetings
do
we
need
and
how
far
chance
do
we
schedule
them
or
we
could
just
do
wednesday.
A
Yeah,
so
how
I
mean
so,
that's
probably
my
question.
I
guess:
could
we
do
two
back-to-back
meetings
so
like
this
time,
but
next
week,
so
dave
can
get
his
thoughts
in
and
like
the
beijing
team
can
sync
with
dave
and
those
in
north
america
who
want
to
come
and
then
we
could
actually
do
a
meeting
one
or
two
days
later,
but
8
a.m
for
additional
engine
and
everyone
could
watch
the
recording
and
then
additional
engineers
could
discuss
further.
That
would
give
us
two
discussions
next
week.
Hopefully
that
would
help
us
move
through.
B
Yeah,
I
I'm
fine,
because
actually
the
community
meeting
in
beijing
time
zone
is
bi-weekly
so,
but
we
can
preserve
the
you
know.
The
8
a.m.
9
a.m,
time
slot
in
beijing.
Whenever
I
mean
on
wednesday,
whenever
we
are
available
for
the
data
mover
discussion,
I
have
a
bi-weekly
meeting
on
a
friday
morning.
Eight
a.m.
Nine
a.m,
but
yeah.
But
whenever
it's
you
know,
I
have
a
times
a
lot.
I
think
we
can
preserve
that
also
for
that
more
to
make
quick
progress.
B
So
it's
the
tuesday
and
thursday
evening,
north
american
time.
The.
A
B
A
E
E
But
if
we
alternated
at
least
the
people
that
can't
come
to
any
of
the
evening
meetings
in
evening
north
america
meetings
that
could
come
to
the
other
ones
and
so
and
okay,
but
but
but
I
I
also
don't
know
I
mean,
does
the
8
pm
beijing
time
work
on
on
those
days.
A
Okay,
I
think
I
have
some
consensus.
Actually,
here's
what
I
propose,
because
we
have
a
lot
of
discussions
going
on
I'm
going
to
schedule
two
meetings
next
week
this
time
next
week,
plus
I
will
let
dylan
and
scott
you
can
and
sean
you
can
talk
to
your
north
american
colleagues
and
figure
out
whether
wednesday
or
thursday
works
better,
plus
I'll
talk
to
the
beijing
folks
and
see
if
one
of
them
works
better
in
the
morning.
A
So
I'll
do
this
tomorrow
morning
and
so
basically
I'll
schedule,
two
meetings
next
week
and
the
fall
and
then
we
can
see
which
one
should
repeat
the
following
weeks.
We
can
be
checking
ahead
of
time
to
see
who
shows
up
who
will
show
up
so
that
we
don't.
We
can
cancel
meetings.
Basically,
if
we're
not
gonna
need
them.
So.
J
Yeah
yeah,
no
eleanor.
I
think
that's
a
great
idea
and
I
just
recommend
on
the
working
group
idea,
which
I
love.
If
maybe
we
can
just
like,
appoint
one
person
per
company
that
can
do
the
scheduling
for
that
entire.
Oh.
E
E
Would
be
better
than
wednesday
so
that
the
people
that
come
thursday
that
didn't
come
on
tuesday
will
have
had
a
chance
to
watch
the
recording,
because
they
won't
have
done
that
if
we
meet
at
8am
after
an
8pm
meeting,
you
know
12
hours
later.
A
B
Week
not
this
week,
yeah,
I
think
it
works.
For
me
at
least
with
three
of
us.
I
think
at
least
one
in
the
three
or
four
of
us
will
be
able
to
attend.
I
think
that's
okay,.
A
And
then
I
really
great
so
good.
So
that's
what
I'll
schedule
next
week
we
can
see
how
that
feels
and
we'll
all
kind
of
schedule
another
week
or
two
out
and
we
can
move
them
around.
This
is
eleanor
we'll
do
this
and
then.
Secondly,
I
think
dylan
made
a
good
point
about
scheduling.
I
never
know
who
I
need
to
message,
so
I
think
for
scheduling
kind
of
working
group,
at
least
for
scheduling,
working
groups,
scheduling.
A
Dylan
will
be
for
red
hat.
Sorry
did
not
spell,
I
will
cover
vmware,
although
I
may
talk
to
one
of
the
beijing
folks
to
cover
themselves
dave,
I'm
assuming
well.
Actually,
I
guess
I'll
just
ask:
does
anyone
else
here
want
to
represent
their
company
or
in
these
discussions
should
be
looped
in
dave?
Shall
I
loop
you
in.
A
A
Perfect
easy
to
volunteer,
if
he's
not
even
here,
perfect,
perfect
and
to
dave's
point
amber
ved
and
yeah
and
I'll
actually
be
losing
in
shane
as
well,
because
she,
even
though
we're
both
vmware
she
kind
of,
represents
vsphere
in
a
way
that
the
rest
of
us
do
not.
Okay.
That
gives
us
a
little
bit
of
a
working
group
for
scheduling,
although
of
course,
I
think
we
should
try
to
do
as
much
of
our
scheduling
and
every
other
discussion
on
valeria
dev
as
possible.
So
it's
visible.
A
So
anyone
else
want
to
comment
on
the
this
kind
of
scheduling,
issue
or.
B
A
We
certainly
can,
I
know
who
to
email
on
the
kubernetes
slack
channel
now
to
do
so
code.
Ranger,
I
think,
is
his
name.
I
don't
know
how
do
folks
feel?
Personally,
I
don't
think
there's
that
much
chatter.
I
think
I
think
it
would
be
okay
to
be
on
valeria
dev,
but
I'm
not
a
dev
and
I
defer
to
the
rest
of
you.
J
F
A
I
A
Great
and
now
so
the
last
question,
then
we
are
we're
at
time.
As
I've
said
we
will
meet
next
at
this
time
next
week,
but
that'll
be
a
full
week.
It
seems
I
at
least
have
been
trying
to
write,
use
cases
and
failing
miserably,
so
I'm
gonna
stay
after
it
sounds
like
dylan
can
stay
after.
A
So
I
think
that
dylan
and
I
alone
can
have
a
good
conversation,
but
I
invite
anyone
else
who
wants
to
chat
about
data
mover
to
stay
if
you're
able
we'll
keep
the
recording
running,
so
you
can
absolutely
catch
up
later.
If
you
can't
so
without
further
ado,
I'm
going
to
dive
into
data
mover
feel
free
to
drop.
If
it's
the
end
of
the
hour,
of
course,
good
comments.
A
Okay,
looks
like
we're
going
into
data
mover
so
at
least
now
this
I.
So
this
is
a
prd.
If
folks,
don't
I
I
put
it
in
the
so
agree
so
agree
more
gifts
would
be
great
okay.
So
if
you
don't
have
access
to
this
data
mover
prd
doc,
I
think
that
if
you
request
access,
dylan
should
be
able
to
give
you
access,
but
please
literally
speak
up
now.
If
you
want
access-
and
you
don't.
J
Yeah,
I'm
sorry
if
I
missed
anyone,
it's
I
don't
know
why
the
the
permissioning
is
so
difficult
on
that
sheet,
but
I've
been
trying
to
grant
anyone
requested.
A
A
A
Oh,
is
he
is
he
red
hat?
Yes,
I
can.
J
Actually,
unless
I
I
it's
possible,
I
screwed
up
the
permissions
again
when
I
changed
it,
though,
to
be
honest
with
you,
I'm
not
totally
sure,
so
I
will
make
everyone
at
least
commenter,
and
if
you
want
edit
access,
I'm
happy
to
upgrade
it.
I
just
wasn't
sure
who
needed
that
perfect.
A
Perfect,
so
all
this
is
put
in
the
zoom
chat
and
I'll
call
it
out.
If
I
see
it
so
just
to
set
the
stage
of
course,
we
have
to
design
how
the
data
mover
works,
but
first
we
should
actually
figure
out
the
darn
requirements.
That's
what
prd
is
project
requirements
document.
This
is
a
place
to
list
our
requirements
at
least
two
ways
you
can
do
it.
We
can
list
requirements,
which
is
what
dylan
started
to
do
awesome.
A
I
did
get
an
ask
from
daniel
to
try
to
do
use
cases
which
I
tried
to
do
literally
right
before
this
meeting
and
boy.
Am
I
exposing
my
the
limits
of
my
knowledge,
so
we
can
do
to.
Personally
I
have
questions.
I
want
to
advance
my
use
cases,
but
more
than
that,
I
just
think
that
there's
a
number
of
discussion
topics,
so
I
mean
we
can
do
a
few
things.
I
think
what
what
do
folks
think
about
maybe
going
through.
I
can
look
at
the
comments
and
see
if
there
are
open
discussions.
A
Maybe
I
go
bit
by
bit:
if
that's
okay,
and
if
folks,
as
we're
kind
of
going
through,
if
you're
kind
of
wanted
to
add
a
comment,
we
can
do
that
or
we
could
do
a
silent.
I
don't
know
are
folks.
Okay
with
that.
Maybe
I
start
with
the
comments
and
going
through
or
do
we
maybe
want
to
go
section
by
section
and
take
comments
as
necessary.
A
Okay,
if
there's
nobody
well
let
you
let
me
yeah.
Let
me,
let's
start
with
this,
I
oh
we
did.
Basically
there
been
a
goal
listed
here.
It
was
very
oadp
specific,
and
so
I
thought
it'd
be
worthwhile
to
call
it
the
valero
goal
as
well.
I
put
it
first
since
for
the
valero
team
and
then
oedp
is
some
of
us
I
care
about
and
then
certainly
we
can
have
others,
for
instance,
ching
might
add
a
vsphere
specific
goal
if
needed.
A
So,
let's,
let's
do,
as
I
said,
you
can
start
to
read
through
this
okay.
So,
let's
go
bit
by
bit,
and
I
think
that
this
one,
for
instance,
is
an
open
discussion.
So
I
think
I
will
talk
through
that,
if
that's
okay
and
as
folks
want
to-
maybe
you
can
add
comments
later
on
and
that's
how
we
can.
Basically,
I
think
we
can
use
comments
to
have
an
orderly
discussion.
If
that's
okay
with
folks.
A
Okay,
so,
first
of
all
daniel,
I
I
daniel
made
this
point.
He
wants
to
clarify
the
e-to-e
scenarios.
He
asked
if
a
user
creates
a
backup
takes
a
snapshot.
Why
does
he
want
to
move
the
snapshot
to
another
cloud
provider,
while
the
backup
itself
is
not
moved?
Oh
good?
If
this
is
the
first
question
I
had
when
a
snapshot
is
moved,
how
could
it
be
consumed
by
the
end
user?
So
I
have
two
questions
for
that.
Let's
see
what
I
basically
agreed
with
him
about
use
cases.
A
Let's
see
what
dylan
said,
the
promise
of
csi
in
the
long
term
is
to
make
snapshot
storage
agnostic
so
that
a
snapshot
isn't
tied
to
a
specific
vendor.
The
current
backup
restore
flow
in
valero
restores
the
pvc,
as
is
data
mover,
can
abstract
this
functionality
to
restore
any
type.
I
halfway
understand
that
answer.
Let
me,
though,
first
ask
if
you
don't
mind,
I'm
going
to
ask
daniel
what
do
you
mean
that
this
I
agree
that
the
snapshot
is
moved.
A
For
example,
we
take
an
ebs
snapshot
and
then
we
might
want
to
move
it
to
azure
object.
Storage.
Let
me
ask
a
quick
question.
Actually,
when
we're
doing
csi
snapshotting-
and
we
have
a
data
mover,
are
we
assuming
it'll,
move
it
and
put
it
into
a
data
store,
or
are
we
assuming
that
the
repo
will
determine
if
it's
a
data
store?
Sorry,
an
object,
store
a
block
store.
A
Know
I
asked
like
five
questions.
I
have
a
sorry
I'll
ask
my
question
later.
I
want
to
ask
you
a
question
first
or
I'll,
ask
you
a
question
about
your
question.
So
you're
saying
you
take
an
ebs
snapshot
and
then
it's
moved
to
azure.
What
do
you
mean
that
the
backup
itself
is
not
moved?
What
do
you?
Do?
You
mean
the
back
of
valera
backup
cr,
do
you
mean?
Are
you
including
the
kubernetes
resources.
B
Yeah
the
way,
the
way
I
think
of
the
process
is
how
valero
user
could
use
this
feature
and
if
I
take
a
css
snapshot
using
valero
backup,
so
the
backup
turbo,
which
includes
all
the
metadata,
remains
in
the
f3
storage.
Then
you
say
you
want
to
move
the
snapshot
from
the
snapshot
of
the
eds
from
s3
to
azure,
but
that's
a
little
confusing,
I'm
not
sure
how
a
user
would
consume.
B
This
snapshot
after
it's
moved
to
adder
and
as
for
a
difference
point
because
currently
does
it
mean
do
you
imply
that
we
also
need
to
update
the
way
user
to
interact
with
valero
in
the
restore
sub
command,
because.
F
A
Respond
to
yours,
that's
an
excellent
question.
So
your
point
is,
we
know
the
snapshot
is
moving
to
another
location,
what's
happening
with
the
kubernetes
resources.
So,
let's
I
think
that's
a
pretty
important
thing
to
call
out.
First,
do
other
folks
here:
have
they
thought
about
this?
What
to
do
with
the
kubernetes
resources?
Can
they
is
it
acceptable.
A
J
A
J
I
don't
actually
think
there's
a
misunderstanding
here,
because
if
you
think
about
the
rustic
scenario,
it's
we're
not
talking
about
moving
snapshots
across
buckets
and
object
storages.
What
we're
talking
about
is.
I
have
a
pvc.
That's
on
ebs
storage.
I
back
up.
I
take
a
snapshot
that
snapshot
gets
moved
to
object,
storage
and
now
I
want
to
take
that
snapshot
and
consume
it
on
a
different
storage
provider.
So
I
want
to
create
an
azure
volume
and
restore
it
from
this.
Given
snapshot,
it's
not
about
moving
the
snapshots
across
object,
storage.
F
F
So
one
path
that
we
can
do
is
we
can
keep
local
snapshots,
for
example,
to
do
quick,
restores
and
also
make
another
copy
into
an
object
store.
So
you
could
potentially
have
multiple
copies
of
the
snapshot
and
the
snapshot.
Data
should
be
immutable
and
then
we've
got
two
different
paths
for
copying
out
the
snapshot.
Data
one
would
be
a
straight
file
system
copy,
like
we
do
with
rustic,
which
we
could
also
do
directly
with
copia.
F
F
So
I
think
we
should
be
supporting
both
those
paths.
I
think
daniel's
question
is
like
so
once
you've
moved
the
snapshot
around.
What
does
that
mean,
and
I
think
that's
really
like
how
do
we
name
or
identify
snapshots,
and
how
do
we
like,
for
example,
like
we
should
be
able
to
move
a
backup,
not
just
the
snapshot
but
the
whole
backup
from
one
object
store
to
another?
At
some
point,
when
you
do
that,
there's
probably
some
translation
that
would
have
to
happen
or
the
object
ids
have
to
be
mapped
somehow.
F
L
B
L
Another
scenario,
maybe
beyond
that
you
did
another
kind
of
data,
move
more
like
a
data,
verification
from
one
side
to
another
site
from
one
core
private
cloud
provider
to
another
cloud
provider
similar
like
that.
But
in
this
data
mooc
are
zero
and
I
think
previously
daniel
then
also
mention
another
case.
It
is
migration
right,
so
we
can
use
this
movement.
If
we
can
provide
the
ability
it
can,
I
mean,
can
migrate
the
the
backup
I
mean
to
restore
to
another
cloud
provider
from.
F
Yeah,
so
definitely
right
now
we
can
do
that.
You
know
it.
Doesn't
we
never
so
right
now,
valero
doesn't
have
any
mechanisms
to
move
backups
once
they
land
in
an
object,
store
they're
going
to
stay
there,
but
we
do
have
the
ability
to
restore
from
pretty
much
any
object
store.
We
have
credentials
to
to.
F
L
L
K
Moving
backups
between
object
stories
is
not
the
goal
of
the
data
movement.
My
understanding
of
data
movement
is
much
more
focused
on
not
like
less
focused
on
cloud
snapshots
and
more
focused
on
other
data
providers.
Snapshots
csi
snapshots
that
do
actually
live
locally
right
clouds,
snapshots
live
in
the
cloud
and
therefore
auto,
like
persisted
and
persisted
across.
K
I
don't
disagree.
I
don't
disagree.
What
I'm
trying
to
get
at
is
that
the
idea
is
moving,
that
that
data
inside
that
snapshot
somewhere
else
to
keep
it
safe
right.
That's
really
what
the
data
move
for
from
my
understanding
is
really
trying
to
provide
right.
There's,
probably
some
sub-use
cases
in
here.
I
don't
disagree,
but
if
we
can
keep
the
high-level
goal
here
like,
I
think
that
will
help
explain
it
so
we're
not
what
I'm
trying
to
do
is
re-scope
it
so
that
we
can
get
one
use
case
written
down.
K
That
is
like
solid,
that
we
understand
d
scope,
all
the
other
pieces
parts
of
it
and
we
can
add
those
back
as
we
go
right.
I
don't
know
if
going
through
all
the
sub
use
cases
and
all
of
the
edge
slash
other
things
is
going
to
like
help
us
move
it
forward
in
this
particular
path,
because
it
is
such
a
intractable
problem
in
a
lot
of
ways.
It
is
a
very
large
problem
with
lots
of
sub-use
cases,
with
lots
of
things
that
we
got
to
think
about.
K
So
I'm
not
saying
that
we
don't
need
to
go
through
them.
I'm
just
saying
like:
can
we
get
like
the
most
basic
one
down
first
before
we
dive
into
all
of
the
other
ways
that
we
could
use
this
feature
because
I
think
I'm
getting
lost
in
all
of
the
edge
cases.
Sub-Use
cases
all
this
other
stuff?
I
don't
know
if
anybody
else
is.
Maybe
I'm
just
the
only
one
that's
unable
to
follow.
J
Sean,
I
agree
with
a
lot
what
you're
saying
there,
and
I
also
wanted
to
add
like
as
in
terms
of
scoping
this
to
a
specific
goal.
You
know
my
understanding
was
always
that
this
is
needed
to
bring
the
csi
plug-in
to
ga
right.
So,
if
we're
gonna
start
discussing
like
moving
backups,
we're
gonna
start
talking
about
moving
and
again
actually
the
csi
coming
at
us
from
the
csi
angle,
you
can
actually
support
the
cross
region.
Cloud
provider
snapshot
bit
right,
so
I've
always
been
using
this
as
like
scope
down
to
csi
snapshots
themselves.
K
Is
going
to
kill
us?
I
think
that
that's
like
a
really
good
point
for
a
technical
thing,
but
I'm
can
you
help
me
understand
how
that
relates
to,
like
the
larger
conversation
here,
like
the
need
for
like
that
particular
piece
of
the
api
needs
to
be
there.
For,
like
a
specific
use
case,
I
don't
disagree,
but
for
the
larger
goal
that
we're
trying
to
do
does
that
need
to
be
included
in
this
requirement.
F
A
Wait,
let
me
pause
there,
because
that's
something
that's
new
to
me
or
like.
I
want
to
ask
okay,
so
you're,
saying
dave
that
say:
aws
and
azure
you're
saying
do
kind
of
their
version
of
csa.
Snapshotting
is
kind
of
different
from.
F
F
One
is
that
you've
got
to
clone
the
volume
and,
depending
on
the
platform
that
may
be
very
expensive
and
vsphere
in
particular,
is
extremely
expensive,
because
you
copy
every
block
before
you
even
start
being
able
to
read
data
from
it,
and
you
know
on
the
cloud
providers,
it's
like
yeah.
You
got
to
pay
for
a
disk
that
has
a
terabyte
worth
of
of
space
allocated
for,
however
long
it's
there,
while
you're
backing
it
up,
and
if
you
go
through
the
file
system
api,
we
don't
get
change
tracking,
so
we
have
to
do
block
level.
F
A
And
here's
another
question
follow-up
that
I
think
might
be
relevant.
Obviously
we
have
vsphere
vmware
care
about
vsphere,
maybe
a
bit
more
than
other
folks,
so
making
it
more
compatible
with
vsphere
is
something
we'd
like
to
try
to
do?
I'm
hearing
that
casting
may
be
interested,
and
I
guess
the
question
is
oh
adp
folks.
What
are
the
clouds
that
you're
most
interested
in
and
well
and
same.
J
With
the
development
problems,
yeah
hearing
it
here's
my
problem
with.
First
of
all,
I
don't
disagree
with
anything
you're,
saying
david.
I
think
that
makes
a
lot
of
sense,
and
I
I
want
to
hear
about
those
use
cases
that
this
is
like
a
performance
solution
for
what
you
guys
need,
but
I
have
problems
if
we're
coming
at
this
from
the
angle
of
like
well,
the
technical
implementation
of
this
csi
snapshotter
causes
problems,
because
then
we're
not
really
solving
this
from
like
a
native
kubernetes
api
level,
we're
then
we're.
J
But
but
if
we
start
from
the
kubernetes
api
right
you,
you
can
always
build
upon
this
to
support
these
individual,
and
I
think
this
actually
gets
tied
into
a
lot
of
the
discussion
that
which
I
found
very
fascinating.
Last
time
we
talked
about
this
in
terms
of
what
astrolabe's
value
add
is
for
different
data
providers
and
stuff,
like
that,
I
don't
necessarily
see
why
there
is
a
there
has
to
be
a
disconnect
in
terms
of
okay,
we're
targeting
the
kubernetes
api.
J
Well,
this
storage
fighter
needs
x,
y
and
z
to
make
this
more
performant
like.
Why
can't
that
be
built
on
top
of
it?
For
that
specific
data
mover
if,
if
we're
targeting
the
kubernetes
api
and
then
we're
saying
bring
your
own
data
mover,
a
vsphere
data
mover
can
be
more
performant
for
easter,
maybe
aws
data
to
be
working
more
performance
for
aws,
but
so.
J
F
So
one
thing
is
that
if
this
doesn't
work
well
on
vsphere,
this
is
so
I'll
leave
my
vmware
hat
on
right.
They
should
throw
it
away,
but
if
we
simply
if
we,
if
we
design
something
that
doesn't
actually
work
well
for
vmware,
I
don't
see
why
vmware
would
be
interested
in
in
doing
this.
You
guys
can
correct
me,
but
it
doesn't
seem.
J
F
J
J
If
I
take
a
snapshot,
a
csi
snapshot-
and
I
know
that
you
said
that
you
know
different
file
system
and
disk
arrays
can
handle
this
differently.
Seph
is
a
good
example
of
this
right.
You
take
a
snapshot
in
cfs
that
snapshot
lives
on
cluster
there's
no
actual
protection.
If
your
cluster
goes
through
a
disaster
scenario,
so
we
need
to
be
able
to
push
that
snapshot
elsewhere
right.
This
is
all
coming
from
the
native
kubernetes
api.
We
just
want
to
target
a
csi
snapshot
and
make
it
portable
and
durable
right
how
that
data
movement
occurs.
J
It's
a
one-size-fits-all
solution
right.
If
we
target
csi
and
then
you
can
bring
your
own
data
mover,
then
the
storage
that
backs
it.
You
can
have
a
more
performant
data
mover
for
those
different
blues,
given
providers
right
and-
and
I
I
think
that
the
biggest
frustration
with
for
always
targeting
vsphere
for
these
solutions.
H
Actually,
you
know
not
only
the
wheat
player
has
this
problem.
Actually,
a
lot
of
other
stories
had,
for
example,
the
the
scythe
also
has
this
problem.
So
so
by
that
I
mean
we
need
to
have
two
passes.
The
first
is
non-path
like
we
mount
the
the
the
same
chart,
the
css
and
chart
like
some
cloud
and
read
the
data
from
inside
the
port
and
the
other
is
we
use
the
direct
assessment,
but
I
personally,
I
don't
think
this.
You
know
they
are
independent
from
each
other.
H
I
don't
think
we
we
need
to
run
or
develop
them
together,
or
something
like
that.
So
my
question
is
why
we
were
concerning
these
two
passes,
because
we
we
can
do
both
the
both
parts
in
parallel
or
you
know
one
after
another.
K
K
If
we
could
write
a
interface
that
would
be
able
to
give
a
generic
controller,
the
ability
to
tell
the
more
specific
ones
like
you
were
saying,
the
parallel
paths,
because
that
would
allow
valero
in
my
mind,
if
I'm
putting
on
my
like,
how
are
we
going
to
write
a
controller
that
will
actually
be
able
to
tell
david
mover?
Do
things
tell
the
during
upload
backup
to
do
all
those
things
like
at
the
end
of
the
day?
K
The
user
interface
to
this
should
probably
be
the
backup,
and
the
backup
controller
should
be
telling
the
information
on
this.
So
a
generic
interface
that
would
allow
us
to
go
to
a
specific
thing
that
says:
hey.
Do
your
whatever
your
movement
based
on
whatever
is
performance
for
you,
like
you,
were
saying
right.
Those
are
two
parallel
paths
like
each
one
can
do
their
own
thing.
I
agree
with
that,
but
I
think
the
more
generic.
K
Like
interface,
so
that
the
controller
can
both
request
the
data
movement
of
things,
as
well
as
see
information
about
the
data
movement,
so
that
it
can
report
back
errors,
information
warnings
status
on
how
the
data
movement
is
is
going
these
types
of
things
on
the
back
of
cr,
because
I
think
that's
probably,
if
we're
just
looking
at
it
from
like
a
holistic
user
experience
perspective,
that's
probably
where
the
user
would
want
that
information
to
live.
In
my
mind,
maybe
I
am
wrong,
but
that's
kind
of
where
my
head
was
at.
F
Yeah,
so
I
think
there's
a
requirement
that
we
be
able
to
do
a
performance
solution
and
the
csi
stuff
to
me
is
a
is
a
fallback,
some
systems
it
works.
Well
many
systems
it
does
not.
Vcr
is
a
prime
example,
because
you
know,
and
then
that's
an
example
for
red
hat
as
well.
You've
got
a
lot
of
open
shift
on
vsphere,
so
you
know
if
we
come
up
with
a
solution
that
doesn't
work.
Well,
that's
probably
not
great.
No.
J
No,
that's
I
mean
that's
not
what
I'm
saying
the
point
is
that
yes,
csi
is
a
catch-all,
because
that's
what
kubernetes
is
developing
right,
there's
nothing,
there's
nothing!
Stopping
you
from
taking
a
specific
data
mover
for
those,
that's
actually
the
goal
that
I've
specified
here
is
like.
You
should
be
able
to
bring
your
dating
mover.
You
have
a
vsphere
data
mover
which
you
guys
have
for
vsphere
and
obviously
that's
going
to
be
valuable
to
everyone
in
the
community.
That's
running
on
vsphere.
F
Targets
yeah.
I
agree
it
should
definitely
not
so
one
of
the
things
that
I
wanted
to
be
able
to
do,
though,
was
reuse.
The
data
mover
infrastructure
for
doing
different
types
of
objects
and
potentially
having
different
things,
coexisting
together,
reusing
the
back
end,
repo
structure,
all
that
stuff.
So
that's
why
I
was
going
down
the
aspellate
path,
which
is
more
like
a
set
of
different
drivers
that
can
sit
on
that
can
be
consumed
by
the
data
mover
so
that
the
data
mover
is
kind
of
a
generic
thing.
F
J
I'm
probably
telling
this
because
I
don't
necessarily
understand
a
lot
of
specifically
how
block
level
backups
are
working,
which
is
the
level
of
vsphere
itself,
but
when
I
take
a
snapshot
well,
I
guess
let
me
ask
the
question
a
vsphere
csi
snapshot.
What
exactly
happens
over
the
hood?
Does
it
not
integrate
with
the
block
level
backup
system?
Yes,.
F
It
does
well,
it
doesn't
integrate
with
the
block
level,
backup
it
creates
a
block
level
snapshot.
Now
this
is
the
same
as
with
ebs
or
anybody
else.
You
get
back
a
snapshot
handle
into
the
volume
snapshot
contents
and
then
you
can
go
to
the
storage
system
and
you
can
get
access
to
the
contents
of
the
snapshot
or
you
can
create
a
new
volume
from
that
volume
snapshot.
F
H
Okay,
steve,
do
you
have
some?
You
know
specific
data
for
the
performance
for
a
degradation
about
you
know.
Every
storage,
like
you
know,.
F
I
can't
give
you
you,
everyone
I
mean
vsphere,
I
will
tell
you,
is
going
to
make
a
complete
copy
of
the
snapshot.
It's
going
to
make
a
new
volume
copy
every
block
into
it.
So,
however,
long
that
takes
is,
however
long
it
takes,
but
you
basically
negated
any
speed
up
from
change
block
tracking,
because
you've.
H
H
Yeah
I
understand
that
and
also
for
self.
I
said
that
for
a
30
gb
of
data,
it
take
half
an
hour
to
prepare
the
same
shot,
but
I
I
I'm
just
you
know
trying
to
to
know
for
various
storage
like
for
the
very
large
enterprise
storage
like
what
is
the
apartment's
degradation
photo?
Maybe
you
know
when
they
do
some
open.
My
data
optimization
from
the
solid
side
there
is
not
so
much
degradation.
That
is
something
I'm
imagining,
but
I'm
not
sure
quite
sure
about
that.
H
F
H
Yeah,
it's
not
hard,
but
you
know
we
need
to
develop
a
specific
solution
for
every
storage.
That
is
a
problem.
Well,.
J
B
In
my
word,
the
way
you
access
the
snapshot,
then
how
we
keep
that
out
of
tracer
question.
Okay,
is
that
possible?
We
do
that
via
grpc,
I'm
not
very
sure,
I'm
quite
new
to.
F
So
I
have
a
I
have
the
code
sitting
out.
I
did
grpc
plugins
for
astrolabe.
I
need
to
put
the
pr
in
for
it,
but
that
would
let
us
not
have
everything
compiled
together,
because
that
is
not
good
and
not
not.
H
So
I
think
I'm
just
curious
at
that
whether
we
can
do
the
normal
part
first
and
then
we
on
the
design
even
on
the
design
level,
and
then
we
will
consider
because
if
we
do
them
together
and
design
them
together,
that
will
be
a
very
large
scope.
F
L
L
Yeah,
even
in
january,
pass
yeah
the
product
provided
the
block
month
mode
right
yeah.
We
can
go
with
both
first
session
level
and
block
level.
H
F
F
J
F
J
Right
so
I
hear
a
lot
of
discussion
about
performance,
specific
improvements
for
storage
providers.
That
makes
a
lot
of
sense
to
me,
but
at
the
end
of
the
day,
we
still
have
this
fundamental
gap
with
csi,
with
the
current
csi
plug-in
that
it's
not
providing
enough
functionality
to
bring
it
to
ga
and
when
I
think
about
data
movement,
I'm
trying
to
come
at
it
from
that
angle.
J
If,
if
we're
targeting,
if
the
fundamental
problem
is
that
you're
saying
csi
snapshots,
are
you
lose
performance
with
specific
storage
fighters
and
that's
a
fair
statement?
In
fact,
everyone,
a
lot
of
people
complain
about
that.
Are
we
aren't?
We
still
not
solving
that
problem
by
trying
to
work
around
that
limitation
and
say
well
for
this
specific
provider?
We
need
a
solution
that
works
for
this,
because
because
the
way
that
it
works,
it's
not
performing
we're
not
actually
fixing
the
problem
that
the
csi
plug-in
is
introducing.
A
I
would
say
I
don't
quite
agree
with
that.
Yet
the
question
is:
where
do
folks
want
to
use
csi
plug
the
csi
plug-in?
We
have
the
durable
cases
aws
and
azure,
and
we're
bringing
that
to
ga
in
this
quarter,
and
that
gives
us
security
benefits
yay.
But
I
would
argue
that
that
covers
aws
and
azure
gcp.
I
don't
know
about,
but
I'm
actually
assuming
it's
probably
durable.
We
should
figure
that
out.
I
should
know
that
then.
What
are
the
other
cases
for
us?
A
So
that's
good
to
know,
but
I'm
just
saying
that
yes,
we
can't
totally
bring
the
csi
plug-in
to
ga
for
non-durable
bits
yet,
but
that's
not
a
huge
problem
yet
for
us,
and
so
if
in
at
least
from
my
perspective,
if
we're
going
to
do
that,
it
would
be
good
to
get
additional
benefits.
But
this
is
where
let's
talk
about
it,
maybe
there
are
these
non-durable
cases
besides
vsphere
that
I
don't
know
about.
J
Yeah
I
mean,
I
think
the
problem
from
my
perspective
is
what
we're
essentially
saying
is
we're
going
to
have
to
start
knocking
away
at
the
most
commonly
used
storage
providers
that
implement
csi,
as
opposed
to
coming
this
from
the
angle
of
csi
itself
as
an
interface,
the
the
snapchat
is
taking
its
stored
on
that,
given
storage
provider,
we
want
to
be
able
to
pick
it
up
and
move
it
right.
It's
like
we
can.
J
F
And
you
can
push
things
like
the
vsphere
implementation.
My
plan
was
always
to
push
that
to
the
vsphere
team
and
have
them
support
that,
but
have
it
plug
into
valero.
F
K
K
J
K
It's
not
cloud
providers
that
we're
targeting
is
any
csi
driver
provider.
There
are
many
other
types
of
resource
systems
that
provide
csi
drivers
that
we
are
attempting
to
do.
This,
isn't
just
clouds
yep
working
on
the
csi
level
allows
us
to
integrate
with
anybody
who
has
created
a
csi
driver
yeah.
So
that's
your
fallback
position.
K
Data
mover
interface
that
could
be
extensible
but
starts
out
with
like
a
way
for
us
to
drive
data
movement
right,
and
we
probably
just
want
to
start
with
csi,
because
it's
the
most
like
you
were
saying
the
most
ubiquitous
one
right
and
yeah
like
it
totally
needs
to
be
extensible.
That
needs
to
be
part
of
the
goals
that
it
should
be
extensible.
K
I
totally
agree
that
makes
100
sense,
but
I
think
that
let's
just
start
with
csi,
because
one
is
the
most
ubiquitous
like
we
just
described,
it
would
allow
us
to
catch
every
single
driver
out
there
that
provides
storage
out
of
tree
to
kubernetes,
which
is
the
main
way
that
everybody's
providing
storage.
Now
right.
If
I
am
misunderstanding,
the
way
that
things
are
going,
I
think
all
of
the
drivers
are
moving
out
of
tree,
so
everybody
will
be
providing
csi
at
this
point
right.
K
I
think
it
makes
a
lot
of
sense
just
to
start
with
csi
get
the
one
and
then
make
it
accessible,
so
that,
like
like,
you
were
saying
like
there's
going
to
be
people
that
need
more
performance
ones.
I
don't
think
any.
I
I
don't
think
anybody
here
is
disagreeing
with
with
that
or
the
need
for
it.
I
think
what
we're
saying
is
like,
let's
start
with
csi,
because
it
will
get
us
the
most
bang
for
our
buck.
K
How
do
we
extend
the
thing
and
we
can
get
a
lot
of
work
done
on
those
types
of
things
just
by
starting
with
csi
and
then
moving
from
there
right.
Like
that's,
I
think,
like
that's
a
I
like.
Can
we
agree
on
moving
forward
with
that
as
our
base
requirement
and
then
extending
it,
making
sure
that
we
have
extensibility
as
a
goal
and
bring
it
into
the
design.
F
J
Yes,
I
agree
100.
I
definitely
think
that
needs
to
be
clearly
cut,
but
there
was
like
a
clarification
of.
We
need
to
be
targeting
specific
providers
and
their
file
systems
and
their
block
storage
things.
That's
coming
at
it
from
a.
Why?
Don't
we
just
leave
it
as
it
can
be
extensible
to
support
those
things
we
don't
need
to
be
so.
F
A
A
As
you
said,
sean
and-
and
I
would
at
least
imc
the
users
I'm
seeing-
are
vsphere
users
generally
and
aws
azure
users,
but
they're
not
relevant,
because
they've
got
the
durable
snapshots
so
for
us
like
looking
at
actual
users,
I
know
of
whom
I
use
this
for
me,
I'm
seeing
folks
generally
on
vsphere
and
to
dave's
point.
I
think
they
might
want
more
performance,
but
I
totally
recognize
that
you
all
oedp
folks
are,
I
think,
are
seeing
a
more
generic
use
case.
Could
we
develop
in
parallel?
A
Is
there
a
way
to
have
a
design
that
does
up
front
satisfy
both
our
needs
and
the
red
hat
folks
can
maybe
do
more
of
the
oh?
You
know
you
can
work
on
a
part,
that's
more
relevant
to
you
and
then
vmware
folks
can
work
on
something
that
might
support
vsphere
a
bit
more.
Is
that
possible
to
get
both
at
the
same
time
or
do
we
truly
have
to
choose.
K
A
I
100
agree,
that's
and
I'm
really
sorry,
if
I'm
doing
a
poor
job
of
of
stating
it
that
way.
But
when
I'm
saying
an
interface,
what
I
kind
of
mean
is
a
common
way
for
something
to
drive
data
movement
because
at
the
end
of
the
day,
something
needs
to
drive
these
data
movers.
So
as
we
make
it
extensible,
it
needs
to
have
something
that
can
drive
it
and
we
want
to
make
those
things.
The
extensibility
point
and
that's
like
the
interface
that
I'm
kind
of
referring
to
I
apologize.
J
Well,
I
I
want
to
clarify
some
wording
in
that
document,
because
maybe
this
is
where
it's
getting
lost
is,
when
I
say
bring,
a
third
party
can
bring
their
own
data
mover
like
I'm,
I'm
implying
that
that's
vsphere,
that's
ebs
like
any
anyone.
That's
not
kubernetes
specific,
because
we're
kubernetes
specific
backup
provider.
Here,
that's
what
valero
is
right.
If
you
have
a
data
mover
that
works
better
for
a
given
storage
provider,
you
should
be
able
to
bring
that
in
and
consume
it.
H
A
A
Wait,
can
I
ask
a
clarifying
question
for
me
and
maybe
others
as
well?
Are
there
two
ways
you
can
make
it
extensible,
where
someone
brings
a
whole
data
mover?
Maybe
a
vsphere
data
mover
or
ebs
data
mover
or
just
everyone
uses
the
same
data
mover
and
then
the
hookup
at
the
end
is
different.
Are
there
basically
more
than
one
way
to
make
this
extensible.
A
B
A
F
F
Specific,
it's
very
abstract
it
doesn't.
It
doesn't
work
in
terms
of
vc
or
disks,
and
you
know,
and
the
fact
that
the
vsphere
driver
is
relatively
large,
is
an
artifact
of
v80p
and
it's
not
an
artifact
of
being
a
driver,
so
the
ebs
version
of
that
is
like
500
lines
and
it
works
with
ebs.
It
works
with
the
existing
data
mover.
The
data
mover
needs
a
few
tweaks
because
some
vsphere
is
crept
in,
but
in
general
it's
just
like
hey
move.
A
H
No,
I
think
you,
you
have
already
asked
my
question
so
so
it's
the
same
thing
actually
so
for
the
data
movement.
We
have
the
data
more
toward
to
to
to
interact
with
the
workload
and
we
have
the
repository.
H
So
in
order
to
consider
the
everything
make
everything
in
the
picture,
we
need
all
also
consider
the
the
repository.
So
we
can,
we
can
give
you
the
the
third
part
when
there
to
replace
the
the
data
mover,
but
what
about
the
repository?
That
is
the
thing
we
need
to
consider.
H
Yeah,
so
that
means
the
data
memory
is
pluggable
and
the
repository
is
pluggable.
F
K
So
don't
we
already
have
object,
storage
definitions
that
exist
today
in
valera,
that
is
pluggable.
F
So
the
problem
with
the
object
store
is
the
object
store,
is
not
really
good
for
storing
like
incrementals
and
stuff.
So
that's
the
problem
that
we
ran
into
when
we
built
out
the
vsphere
data
mover-
and
you
know
the
easter
plugin-
is
that
the
tricky
part
so
the
the
naive
way,
which
is
where
I
started,
is
just
copy
the
whole
all
the
blocks
into
an
s3
object.
F
That's
good!
The
difficulty
is
incrementals
are
really
difficult,
then,
because,
if
you
do
like
incrementals
is
the
changes
from
a
previous
one
and
you
want
to
delete
the
the
the
snapshot
in
the
middle
of
a
chain.
It's
like
you've
got
to
do
all
this.
You
know
messing
about,
whereas
something
like
copia
is
handling
that
versioning
for
us
on
top
of
the
object
store
and
you
need.
F
I
mean
so
so
having
like
a
repository
api
that
lets
you
talk
about
things
in
terms
of
here's,
an
object,
here's
a
snapshot
for
that
object
and
you
push
the
details
of
how
that
gets
in
the
object
store
or
in
some
legacy
provider
thing
you
push
that
behind
that
api.
It
gets
a
lot
easier,
because
talking
directly
with
the
object
store
is
basically,
you
have
to
put
copia
on
top
of
it
in
order
to
really
make
it
work
for
incrementals.
B
F
K
How
would
that
be
different
than
our
current
of
enhancing
your
current
object
storage
plug-ins?
To
do
that,
dave.
F
So
we
we
might
be
able
to,
but
so
the
current
object,
storage
plug-in,
basically
is
a
one-to-one
mapping
between
the
object
store
and
you
know
the
api,
so
it
doesn't
have
any
concept
of
here.
I'm
giving
you
a
new
version
of
this
object,
so
you
know
we'd
have
to
so
object
stories.
Don't
don't
let
you
do
that
really
right!
It's
like
here,
you
wrote
an
object.
Yeah,
that's
pretty
much
immutable!
Now
I'm
going
to
write
another
object
with
a
different
name,
which
is
how
we
use
it.
F
So
we
pretty
much
need
to
have
a
repo,
an
api
for
the
repo
that
deals
with
snapshot
chains,
so
objects
chains
of
snapshots
for
the
object.
So
we
can
keep
the
dips.
A
Can
I
ask
you
a
quick
question?
I
asked
in
the
chat,
but
I
are
we
talking
about
two
different
sets
of
apis.
Like
the
data
mover,
I'm
assuming
would
have
apis.
That
would
be
called
you
take
the
snapshot,
and
then
you
call
the
data
mover
apis
to
get
it
to
move
it,
but
then,
at
the
other
hand,
when
it's
interacting
with
the
repo
would
then
we
have
a
repo
set
of
api.
So
basically
do
we
have
a
source
apis
and
destination
apis,
or
is
it
data
mover
apis
and
repo
apis,
or
is
it
not
clear.
F
Yet
so
I'll
give
you
my
model,
which
is
that
we
have
essentially
two
repos
one
would
be
the
local
repo
and
one
would
be
the
the
back,
the
remote
repo,
the
source
and
the
destination
repo
they're.
Actually
the
same,
and
the
data
mover
api
sits
on
top
of
those.
So
you
can
save
the
data
mover,
move
it
from
a
to
b
and
it
gets
it.
A
F
A
K
F
Well,
no
between
the
snapshot
mechanism
that
we
use,
which
presumably
is
going
to
be
csi,
but
eventually
it
might
be
other
things,
not
not
volume
snapshots.
So
we
would
want
to
be
so
whatever
it
is.
Whatever
snapshot
id.
So
we've
got
a
two-phase
thing:
we've
got
a
snapshot
that
we're
taking
in
that's
under
valera's
control
and
then
we're
having
a
data
movement
where
data
where
valero
has
to
go
from
what
it
took
a
snapshot
of
to
telling
the
data
mover
to
do
it,
and
so
that
id
that
was
returned
originally
has
to.
J
A
Yeah
well,
and
that's
where
I
I'm-
and
this
is
where
I'm
less
clear
on
yes
on
what
what
is
required
to
requirements
and
whatnot
on
a
side
note,
at
least
for
me,
I'm
going
to
drop
in
13
minutes.
I
don't
know
how
folks
feel
I
can
leave
the
recording
going
and
folks
want
to
discuss
longer,
but
I
thank
you
okay,
anyway.
Okay,
so
I
guess
the
question
would
be
so.
First
certainly
I'll
schedule,
another
discussion
a
week
from
now.
A
K
F
I
think
so
so
long
term
yeah
I'd
like
to
have
the
ability
to
put
other
things
through
it.
It
doesn't
have
to
be.
You
know,
phase
one,
but
if
we
design
it
right,
it's
not
that
hard.
A
But,
and
is
that
the
same
discussion
as
what
we're
having
about
prioritizing
any
solute
kind
of
a
more
generic
any
solution?
For
that?
That's
a
different
discussion
right
than
the
prioritizing
a
generic
any
solution
versus
a
more
specific
performance
solution
for
certain
clouds,
correct.
K
So
I
think
the
the
requirement
that
we
talked
through
initially
that
I
think
we
all
agree
on
is
that
whatever
does
the
data
movement
needs
to
be
extensible
in
some
way,
so
that
systems
that
have
extra
requirements
or
things
that
they
need
to
do
need
to
be
able
to
handle
that.
I
think,
there's
a
open
question
requirement
around
change
blocks.
K
That
seems
to
be
another
sticking
point
that
we've
been
stuck
on
eleanor
I'll
just
I'll
go.
I'm.
K
That
I'm
just
doing
something
I'm,
I
think
I'm
just
trying
to
get
everything
out
and
see
if
anybody
disagrees
with
either
a
an
open
question
or
a
requirement
that
we
did
agree
to.
So
I
think
we
did
agree
on
whatever
data
mover
is.
It
needs
to
be
extensible
so
that
other
things
can
do
that.
A
K
I
don't
disagree,
I'm
wondering
if
this
need
can
be
behind
the
question.
I
think
that
would
come
out
of
the
requirements
right
is.
Does
that
need
a
lot?
Is
that
provided
by
the
extensibility
of
the
data
movement?
Or
do
we
need
to
bake
that
into
the
core
upstream
data
mover
thing
that
we
build
right
so.
F
F
K
I
think
that's
what
that's
exactly
what
I
was
trying
to
say
right
is
that
like,
if
does
the
data
mover
itself
have
to
work
on
change
blocks
as
a
method,
or
can
the
underlying
thing
inside
the
data
mover,
extensible,
piece,
work
on
change
blocks
or
not
work
on
change
blocks
right.
K
K
Oh,
I
would
what
I
would
be
really
wary
of,
and
I
don't
know
if
other
people
agree
or
not
what
I'm
really
wary
of
is
going
and
prototyping
something
and
then
it
not
being
even
close
to
what
they
get
right.
F
F
Phong
involved,
for
example,
we
prototype
it.
So
there's
not
a
lot
to
see
it's
a
list
of
blocks
that
changed
and
you
run
over
it
measure
copy
and
you
say:
do
I
want
this
block?
No,
let
me
skip
ahead
right,
it's
pretty
simple
and
so
right.
The
thing
is,
what
we
don't
want
them
to
do
is
to
implement
a
cbt
that
actually
doesn't
work.
F
F
A
In
I
mean
we're
going
a
little
deeper
into
specifics
and,
of
course
I
think
a
lot
of
us
are
tired
and
we're
kind
of
wrapping
up,
maybe
a
medic
again
ending
with
a
meta
thing,
might
be
worthwhile.
I
don't
know
about
all
of
you
and
actually
it's
a
question.
A
I
don't
think
valero
team
has
ever
really
had
to
deal
with
this
kind
of
big
differences
in
opinion
for
a
large
feature
before
it's
always
just
been
vmware
folk,
for
I
think
the
big
features
and
then
lately
we've
been
working
on
small
features
together
in
a
bigger
group,
but
it's
been
pretty
easy,
so
I
guess
one
question
I
have
is
hey.
I
want
to
call
it.
I
think
that
this
is
there's
just
gonna,
be
a
lot
more
discussion
as
we
figure
this
out.
A
A
B
J
Well,
I
also
think
out
of
that,
like
there's
a
there's,
a
limitation
when
we
have
to
well.
First
of
all,
I
think,
breaking
to
a
working
group
will
improve
this
process
significantly,
because
I
think
that
the
people
who
have
a
vested
interest
in
this
and
are
potentially
working
on
this
day
to
day
we
can
drive
it
forward
more
asynchronously
than
having
to
discuss
this
all
on
a
large
call.
So
I
think
that's
going
to
improve
the
process
I
mean.
J
I
think
this
is
a
great
lively
debate,
there's
a
lot
of
stuff
that
I'm
learning
and
listening
to
here.
So
I
think,
there's
nothing
wrong
with
what
we're
doing
right
here.
I
do
agree
with
daniel
that
if
the
process
is
going
to
be,
we
meet
once
a
week
and
have
to
hash
out
ideas
that
you
know
get
really
deep
in
the
weeds.
J
It's
going
to
be
tough,
but
if
we
can
form
a
working
group,
we
get
you
know
some
slack
channel
or
something
to
discuss
this
or
there's
a
lot
more
of
a
certain
miscommunication.
J
I
think
that
might
improve
a
lot
of
this
because,
for
example,
like
I'm
hearing
a
lot
of
debate
about
requirements,
I'm
gonna
have
to
go
back
and
listen
and
retype
a
lot
of
this
stuff
because
I
just
haven't
been
able
to
do
both
at
the
same
time.
If
we
had
this
conversation
in
slack
look,
these
are
my
requirements.
Do
you
agree
with
this?
That
conversation
is
like
saved
and
threaded,
it's
actually
a
really
good
tool
for
asynchronous
communication,
and
the
google
doc
can
do
that
as
well.
Obviously,
so.
B
M
B
B
A
So,
actually
quickly
on
that,
I
should
just
advertise
since
I
didn't
get
to
that,
I
tried
to
do
some
use
cases
an
end
to
end
which
might
be
kind
of
what
daniel
is
suggesting.
So
on
to
his
point.
I
agree.
If
we
talk
from
the
user's
point
of
view,
we
may
dive
less
into
implementation.
Details
folks
may
want
to
take
a
look.
You
might
be
able
to
use
this
and
add
kind
of
thens
and
whatevers
to
kind
of
get
a
more
complete
use
case
or
to
daniel's
point.
A
J
I'll
just
say
too:
there's
those
use
cases
at
the
bottom
of
this
dock,
or
I
guess
it's
the
middle
or
whatever,
there's
a
lot
of
things
that
were
discussed
today,
that
I
think
kind
of
delved
outside
of
those
use
cases,
and
so,
if
we
can
explicitly
narrow
down
what's
highest
priority
in
tackling
these
problems,
which
I
don't
know,
you
clearly
started
to
deal
with
the
p0
p1
stuff.
I
mean
that
one
yeah.
D
J
M
J
That's
a
good
place
to
start.
I
I
wouldn't.
A
J
A
Be
clear,
I
had
not
really
thought
about
performance
and
understood
all
the
implications
I
made
from
the
vmware
valero
hat
side
or
the
vmware
representing
the
vmware
developers.
I
may
need
to
pre.
I
have
to
figure
out
what
we
need
to
prioritize
our
development
work
on,
but
from
a
design
perspective.
If
we
can
kind
of
get
both
that's
great,
but.
K
Yeah,
no,
I
think
I
think
the
biggest
question
open
then
that
I
that
I
think
that
we
disagree
on
from
a
larger
requirements.
Perspective
is
given
the
basic
backup
of
csi
snapshot
versus,
like
the
the
last
one
that
you
had
there,
which
is
like
I
I
want
c
cbt
to
work.
K
Does
that
have
to
happen
at
the
does
that
happen
at
the
data
mover
layer,
or
does
that
happen
at
the
extensible
piece
of
the
data
mover
right
and
that's
where
I
think
we
have
the
biggest
disagreement
and
I
think
that's
where
we
need
to
come
to
a
consensus
and
from
there.
I
think
everything
will
flow
out
of
that.
K
Maybe
I'm
wrong,
but
that's
where
it
seems
to
me
to
be
the
biggest
source
of
disagreement
and
then
I
think,
dave.
I
don't
even
see
anything
about
like
generic
things
in
these
stories
I
could
have
been
wrong.
I
might
have
quit
parsing
of
it,
but
we
probably
wanted
to
add
a
story
for
that,
because
that
seems
to
be
one
of
the
things
that
you're
thinking
of
as
well
and
we
would
need
then
agreement
on.
Is
that
a
extensible
thing
is
that
part
of
like
the
moon
data
movement
concept?
K
I
think
I
think
those
are
the
two
main
disagreements
and
I
think
those
are
like
healthy
debates
to
have,
but
I'm
hoping
that
once
we
get
agreement
on
those,
then
we
can
move
forward
much
quicker
and
it
won't
take
two
years.
Hopefully
we.
A
Hope
so
I
see
we're
at
time.
I
want
to
kind
of
correct
one
thing
by
the
way:
I'm
not
correct
dave
by
the
way
had
no
chance
to
put
use
cases
and
he
didn't
have
access
and
the
valeria
team
or
the
sorry.
The
vmware
developers
have
not
had
a
chance
to
look
at
these
use
cases
either.
So
just
be
aware
that
the
use
cases
might
change
even
from
the
vmware
developers.
I
just
wrote
them
literally
right
before
this
meeting,
so
I
think
action
items.
A
Let's
keep
maybe
working
on
this
doc
plus
doing
I
like
dylan's
cloud
of
more
async
communication
in
the
channel.
We
do
have
a
full
week
before
we'll
have
our
next
sit-down
meeting.
So,
let's
challenge
ourselves
to
make
as
much
progress
as
possible
async
young
way.
I
see
you
called
a
question
in
the
chat,
so
you
might
want
to
put
it
in
the
doc
or
in
the.
H
A
H
Maybe
we
can
put
it
in
the
open
discussion
in
the
dark.
The
question.
A
H
H
Maybe
we
need
to
consider
this
and
that
will
be
that
will
be
impacting
our
design
overall
design.
A
Yeah
good
call
out
definitely
put
in
open
questions.
That's
great
yeah
cause,
of
course,
we'll
lose
it.
The
zoom
chat,
of
course,
is
ephemeral.
Thank
you
all
again.
I
think
that
we're
trying
to
do
a
hard
thing
and
we
are
not
only
trying
to
solve
the
hard
problem,
but
we
are
trying
to
figure
out
how
to
talk
about
the
hard
problems.
So
if
we
all
have
patience,
I
think
we're
going
to
start
to
see
progress
as
we
figure
out
at
least
the
meta
part.
A
So
thank
you
all
folks,
yep
and
dylan
is
calling
out.
Of
course,
if
people
don't
have
the
right
access,
please
poke
him.
So
I'm
gonna
end
this
meeting
now,
but
definitely,
let's
keep
chatting
and
I'll
send
out
the
invites
tomorrow
for
next
week's
in-person
chats
any
last
comments
before
we
drop.
A
Well,
my
pleasure
for
trying
it's
an
awkward
situation
where
you
all
have
more
technical
knowledge
than
I
do,
but
it's
I
am
excited
to
be
involved
in
this.
Thank
you.