►
From YouTube: Velero Community Meeting - June 4, 2019
Description
Topics of today:
- v1.1+ planning
- restic improvements
- testing improvements
A
A
Before
we
jump
into
that.
I
definitely
wanted
to
start
by
welcoming
the
the
newest
member
of
our
team.
Adnan
he's
joining
us
at
vmware.
Excuse
me.
He
recently
joined
vmware
through
the
the
bit
nami
acquisition.
I
saw
I'm
not
just
joined,
so
you
want
to
say
hi
and
just
give
your
give
a
brief
introduction.
Yeah.
B
A
A
What
is
the
set
of
work
we
want
to
get
into,
but
we've
done
some
work
with
with
kind
of
scoping
the
1.1
release,
and
so
we
definitely
wanted
to
share
that
and
get
any
feedback
that
folks
have
on
the
set
of
work
that
we're
we're
planning
on
working
on.
So
what
we
have
here
in
the
agenda
is
kind
of
the
three
major
items
that
we
have
currently
scheduled
for
1.1
and
so
we'll
spend
a
few
minutes
on
each
of
these
just
talking
through
kind
of
how
we're
thinking
about
these
things.
C
C
We're
going
to
try
to
support
this
via
velaro
plugins
to
start
out
with.
So
we
want
to
be
able
to
support
more
providers
and
hopefully
that
this
will
give
us
the
ability
to
kind
of
get
more
provider
support
for
free,
supposedly
as
long
as
they're
using
CSI
right
now.
We're
kind
of
testing
the
waters
making
sure
we're
compatible,
and
this
is
not
going
to
be
GA
for
1.1
we're
gonna
track.
C
We
currently
have
some
prototype
plugins
up
at
the
URLs
and
I
started
a
design
document
in
that
repo,
as
well,
so
feel
free
to
come
into
that
repo.
If
you've
got
issues
or
questions
I
know
some
people
on
this
call
were
already
interested
in
talking
about
this,
and
this
is
something
that
VM
was
very
interested
in
implementing
as
well.
C
C
A
They
can
use
to
start
testing
out
and
giving
us
feedback
on,
and
then
I
think
you
know
we'll
still
need
to
figure
out
longer-term
what
the
what
the
kind
of
GA
integration
looks
like
we're.
Not
we're
not
quite
there.
Yet
we
don't
know
whether
you
know
it
will
remain
as
plugins
or
whether
it'll
be
a
deeper
integration
into
the
core
codebase,
but
we're
hoping
to
use
the
prototype
to
to
kind
of
help
us
answer
some
of
those
questions.
D
C
So,
instead
of
writing,
volume
snapshot
or
plugins
that
are
kind
of
analogous
to
our
current
volume
providers.
Is
that
yeah
yeah?
What
you're
asking?
Well
the
reason
we're
going.
There
is
because
we
want
to
process
on
the
PVCs
the
volume
providers
we
probably
could
but
I
think
it's
probably
easier
with
the
the
PVC
item
action
plugins,
because
the
way
CSI
is
implemented.
We
need
to
read
things
off
of
the
PVC
and
write
them
to
be
BC.
D
Because
I
took
that
approach
actually
and
got
some
issues
and
I
think
you
know,
as
you
said,
because
of
the
PVC
type.
You
know
mainly,
and
you
know,
with
the
storage
class,
especially
during
restore
and
because,
if
the
PVC
you
know
and
it's
not
passed
down
so
we
had
to
the
plugin,
doesn't
pass
it
down.
So
we
have
to
figure
out
so
yeah.
We
can.
You
know
we
can
catch
up
up
that.
You
know
as
well.
D
D
A
Yeah
definitely
one
of
the
things
we've
noticed
so
far
is
that
you
know
just
getting
environment
set
up
that
have
CSI
installed,
that
this
guy's
all
enabled
is
definitely
a
non-trivial
effort,
and
so
for
any
folks
out
there
who
have
those
environments
set
up.
We
would
you
know
hugely
appreciate
them,
trying
out
the
plugins
and
giving
us
feedback,
because
it
is,
it
is
a
little
bit
expensive
to
get
those
setups
yeah.
C
E
Can
I
ask
you
what
the
workflow
is
were
driving
a
backup
from
one
of
these
CSI
snapshots?
You
know
what
I
have
in
mind
is:
when
you
create
one
of
these
snapshots,
you
can
take
the
snapshot
and
create
another
second
PVC
from
it.
Conceivably,
you
could
mount
that
somewhere
and
back
up
from
that
secondary
entity.
Is
that
what
the
plan
is
here
in
the
workflow
of
doing
a
backup
or
is.
C
E
C
The
currently
the
plan
is
as
we
process
PV,
so
on
the
backup
side
as
we're
backing
up
in
C
PVCs,
we
issue
a
volume
snapshot,
which
is
the
CSI
custom
resource.
We
create
one
of
those
and
have
the
snap
to
have
that
get
run
through
the
CSI
driver,
and
then
we
consider
that
snapshot
as
kind
of
our
backup
and
that's
what
we'll
restore
from
so
we're,
not
creating
the
snapshot
and
then
mounting
that
and
then
backing
that
up
somewhere
else.
C
So
this
is
pretty
analogous
to
how
we're
doing
snapshots
with
the
current
providers,
but
that
is
something
that's
been
mentioned
before.
Maybe
we
take
a
snapshot
about
that
and
back
that
up
with
something
so
that
you
get
get
a
more
quiesce
and
consistent
back
up,
but
that's
not
something
we're
looking
at
with
this
right
now.
E
C
A
So
yeah
this
is
Valero's
current
assumption,
so
Valera
was
developed
primarily
with
the
public
cloud
providers
in
mind.
Is
that
when
you
take
a
snapshot
that
the
underlying
storage
platform,
the
public
cloud
provider
is
replicating
that
data
off
somewhere,
so
that
the
snapshot
is
durable
and
can
be
restored
from
later?
We
haven't
changed
that
assumption
in
velaro,
and
so
that's
true,
whether
you're
you
know
holding.
E
C
E
F
Yes,
t
we've
had
some
discussions
with
with
storage
providers
as
well
that
you
know
after
the
backup
is
completed,
we
would
I
mean
we
haven't,
decided
exactly
how
it
would
work
but
basically
hand
off
a
set
of
snapshot,
IDs
or
otherwise
trigger
or
indicate
to
the
to
the
storage
provider
that
these
snapshots
are
ready
for
archive
and
then
that
would
trigger
those
systems
to
initiate
whatever
their
archival
options.
Are
that
allow.
B
E
Program
or
resource
challenge
shall
we
say
to
do
everything
that's
on
the
wish
list.
There
are
a
lot
of
backup
vendors
that
would
have
a
commercial
interest
potentially
in
this
if
they
were
aware
of
an
opportunity,
so
it
might
be
worth
reaching
out
to
some
of
these
people
to
see
if
they
might
be
interested
in
committing
developers
to
this
effort
to
build
something
like
that.
E
The
advantage
of
just
doing
a
standard
kubernetes
mount
is
it
isn't,
storage
specific
at
all,
right
I
mean
you
you.
The
design
of
the
CSI
snapshot
is
that
you
just
create
a
second
shadow,
TVC
off
of
that
and
mounted
to
a
pod
and
there's
nothing
at
all.
Storage,
specifically,
are
that
the
thing
abstract
event
from
you,
which
would
be
great,
and
you
could
have
one
implementation,
then
that
moves
this
data
to
cheap,
archival
storage
and
it
should
work
for
everything.
A
All
right:
well,
we
can
move
on
to
the
next
item,
so
the
the
next
major
kind
of
bucket
that
we
want
to
tackle
in
1.1
is
making
some
improvements
to
the
rustic
integration.
So
when
we
released
1.0,
we
we
decided
that
the
rustic
integration
would
remain
in
in
the
beta
state,
so
we
weren't
quite
ready
to
call
it
generally
available,
and
so
we
do
want
to
do
some
work
in
the
upcoming
releases
to
move
that
to
GA
and
so
I'll.
Let
Carly
Xia
take
over
and
talk
through.
G
At
least
the
taste
Apple,
because
it's
a
quite
a
big
list,
what
I
did
here
is
listed,
every
single
issue
that
we
have
opened,
thats
related
to
rustic
and
I,
grouped
them
by
stability,
usability,
security
and
performance.
That
is
one
little.
We
should
related
documentation
and
I
am
not
quite
sure
if
I
should
go
over
every
single
one
right
now
like
feedback
on
that
or
if
I
should
just
say.
G
We
can
talk
about
that
and
for
people
watching
the
video
later
definitely
paying
us,
because
we
are
actively
trimming
this
list
to
where
we
are
going
to
work
on
for
one
point
one,
and
if
you
have
any
entry,
if
you
have
needs
for
anything
in
particular,
you
should
let
us
know
so
we
are.
We
are
already
we
already
know.
We
are
prioritizing
instability
because
there
is
major
points
for
for
the
rustic
integration
to
be
considered
a
for
us
and
this,
let
me
see.
G
G
G
A
Yeah
I'll
just
jump
in
and
say
you
know.
We
we
basically
like
Carly
SIA,
said
we've
kind
of
looked
at
all
of
the
issues
that
have
been
filed
in
our
github
repo
that
have
been
labeled
as
rustic
issues
and
we've.
You
know
collected
feedback
through
slack
conversations
and
other
outlets,
and
so
we're
trying
to
just
bring
that
whole
list
together
and
then
make
sure
that
we
tackle
the
things
that
are
that
are
really
must-haves
before
we.
We
consider
this
integration,
GA
and
I.
A
Think
we'd,
probably
have
you
know
more
than
one
releases
worth
of
work
here,
to
get
to
a
ga
state
and
so
we'll
be
will
be
tackling
as
much
as
we
can
and
trying
to
focus
on
the
highest
priority
items.
41.1,
but
odds
are
that
this
will,
you
know,
continue
into
into
1.2,
but
we'll
sort
of
see
where
we
are
when
we,
when
we
get
to
the
the
release
date
for
one
that
one.
A
A
I'll
switch
back
to
the
main
tab,
so
so
the
third
bucket
of
items
that
we're
looking
at
41.1
is
is
making
some
improvements
to
the
testing
that
we
have
for
Valero
and
so
we've
over
the
last
few
releases.
You
know
we
as
a
as
the
core
development
team
have
definitely
noticed
that
that
the
state
of
the
testing
for
Valero
is
a
bit
of
a
hindrance
to
us.
It
slows
us
down
somewhat
and
there
are.
There
are
several
kind
of
different
aspects
to
this.
A
A
Sometimes
these
tests
can
be
can
be
brittle
so
that,
if
we're
doing
refactoring
or
making
changes
to
packages
that
we
end
up
having
to
do
a
lot
of
rewriting
of
tests
to
actually
make
them
work
for
the
revised
behavior,
and
this
just
slows
us
down
and
also
we
ate.
We
have
situations
where,
even
though
the
tests
seemed
to
have
good
coverage
in
terms
of
code
covered,
they
aren't
necessarily
surfacing
bugs
for
us
and
so
they're
they're
less
of
a
safety
net
than
we
would
like.
A
So
that's
that's
kind
of
one
aspect
of
it
and
then,
additionally,
you
know
there.
There
are
some
parts
of
the
code
based
on
functionality
that
are
just
difficult
to
test
in
kind
of
go
level
unit
tests.
So
some
examples
here
would
be
things
like
the
pre
and
post
backup
hooks
where
we're
actually
executing
commands
in
running
pods
in
the
cluster,
and
this
is
something
that's
pretty
hard
to
test
without
actually
having
a
running
cluster
and
having
pods
running
where
you
can
run
these
commands.
A
You
know
another
example
of
this
would
be
the
cloud
provider
integration,
so
the
actual
plug-in
implementations
that
we
have
these
are
you
know
you?
Can
you
can
do
some
level
of
testing
on
these
using
you
mocks
or
fakes,
but
until
you've
really
made
API
calls
to
the
cloud
providers
and
done
kind
of
full
and
and
testing
there
it's
hard
to
have
confidence,
and
so
it's
another.
B
A
So
the
test
will
will
become
a
little
bit
more
coarse-grained,
but
we
think
that
they'll
probably
provide
us.
You
know
tests
that
are
more
stable,
meaning
that
they'll
have
to
change
less
often
as
we
as
we
change
implementation.
Details
of
these
packages
and
they'll
also
give
us
some
more
confidence
that
you
know.
A
You
know
we're
we're,
also
planning
to
look
at
integrate
or
implementing
some
kind
of
integration
testing
framework
where
we've
discussed
using
using
kind
so
kubernetes
and
docker,
as
kind
of
a
lightweight
platform
for
getting
a
cluster
up
and
running
that
we
could
deploy
velaro
into
and
actually
drive.
Some
some
end
end
test
cases
there.
A
That
would
that
would
give
us
the
opportunity
to
test
you
know,
backup,
hooks
plugins,
rustic
and
some
other
things
that
are
more
difficult
to
test
in
in
go
level
unit
tests,
and
so
we
hope
that
we
can.
You
know,
between
the
revisions
to
the
unit
tests
and
the
the
kind
integration
tests
that
we
can
cover
a
pretty
broad
set
of
functionality
that
we
want
to
test.
A
So
this
will
this
will
again
be
you
know,
a
big
chunk
of
work
for
1.1
and
I.
Think
it's
again,
it's
pretty
possible
that
this
will
continue
during
1.2
I'm,
not
sure
that
we'll
get
through
all
of
the
testing
work
that
we
want
to
and
1.1,
but
we
do
on
a
tackle
it
early.
You
know
relatively
early,
meaning
now
and
1.1
and
in
the
next
release,
because
this
is
the
kind
of
work
that
will
will
pay
dividends
to
us
over
time.
A
A
Okay
sounds
like
sounds
like
not
so
yeah:
we
don't.
We
don't
really
have
anything
in
our
what's
coming
up
section
I
mean
we're
really
just
kind
of
starting
to
dive
into
the
scope
of
1.1,
and
so
you
know
over
the
next
month
to
two
will
will
basically
be
working
on
burning
down
the
issues
that
are
in
our
backlog.
A
F
Absolutely
so
our
github
is,
is
there
at
hefty
o
Valero?
You
know
go
ahead
and
take
a
look
ad
and
issues
there.
We
do
have
the
issue
1327
and
tell
us
about
how
you're
using
Valero
would
love
to
love
to
know
more
about
specifically
your
use
case
and
and
what
your
you're
getting
out
of
Valero
our
slack
channel
is,
is
Valero
on
the
criminal
slack
lots
of
activity
there.
You
can
use
that
to
discuss
problems
you're
having
or
things
that
you'd
like
to
see
or
just
general
questions,
we're
Manning
it
on
a
regular
basis.
F
There's
always
somebody
there
and
just
let
us
know
what
you're
looking
for
in
Valero,
and
we
would
like
to
make
sure
that
that's
included
and
and
releases
to
come
again.
Just
you
know,
file
issues
on
on
the
github
is
the
best
way
to
do
it
and
we
would
love
to.
We
would
love
to
engage
further
with
you,
so
with
that
I
guess
we
can
open
it
up
for
any
community
questions
that
that
might
be
out
there.
A
Yeah
sounds
good
so
for
everyone
who's
who's
on
the
call
thanks
all
for
joining
for
those
of
you
who
are
catching
it
later
on
YouTube,
thanks
for
tuning
in
we'll
be
back
in
in
two
weeks,
so
these
meetings
will
continue
on
the
first
and
third
Tuesday's
of
of
every
month.
So
we
look
forward
to
seeing
everyone
again
in
two
weeks
with
another
update.
Okay,
thank
you
guys
thanks
a
lot
thanks.