►
From YouTube: Velero Community Meeting/Open Discussion - Feb 25, 2020
Description
Feb 25, 2020
Agenda
--------
Status Updates
--------
[steve]
community support last week
shipped v1.3.0-beta.2 with a couple more fixes
updating v1.3 blog post
[carlisia]
Slow progress with the CLI design/PoC
Caught up on PRs that requested my review
Intention for the week: go over other helm+velero PRs
Stretch: go over issues and give feedback
On PTO next week
[nolan]
Got PR #2264 finished
Reviewed Ashish’s PR for CSI updates
Will be at KubeCon EU
Need to follow up on https://github.com/kubernetes/kubernetes/issues/87675 from Scott Seago
[ashish]
Working on integration of CSI snapshot APIs into the csi-plugin-for-velero.
This PR implements backup support for volumes backed by CSI drivers.
This was demo’d for the team internally and we will have a demo for the community in the coming weeks.
Will be continuing work on the restore scenario.
On community support this week
Also want to get started on a blogpost about setting up an environment that supports CSI external-snapshotter APIs.
Discussion Topics
--------
@dymurray Restic Restore Failures with OpenShift (https://github.com/vmware-tanzu/velero/issues/1981)
@dymurray Custom CA bundle design update (https://github.com/vmware-tanzu/velero/pull/2259)
Contributor Shoutouts
--------
@jenting - back up PVs to correct location with restic (https://github.com/vmware-tanzu/velero/pull/2244)
Helm/Velero chart: https://github.com/vmware-tanzu/helm-charts/pulls?q=is%3Apr+is%3Aclosed
A
I
were
one
a.m.
and
welcome
to
another
episode
of
the
Valero
commuter
meeting.
Slash
open
discussions
today
is
February
25th,
2020
and
per
usual.
We
get
a
bunch
of
stuff
that
we
want
to
cover.
If
you
want
to
add
anything
to
the
agenda,
please
do
so
I'm
gonna
share
it
in
the
chat
here
and
I
will
also
share
my
screen.
So
you
all
can
see
the
agenda
as
we
talked
about.
A
B
Sure
last
week,
I
was
on
community
support.
Definitely
kept
me
busy.
There
were.
There
are
lots
of
issues
to
catch
up
on
and
slack
conversations
going
on,
so
that
took
up
a
good
chunk
of
my
time
anyway.
Yesterday
we
finally
got
the
last
fix
merged
for
the
1.3
second
beta,
so
we
had
discovered
an
additional
issue
around
CRD
backup
and
restore
so
Nolan
got
that
fixed
done
and
we
merged
that.
So
I
was
able
to
push
out
the
second
beta
for
1.3.
So
that's
out
there
now
the
images
and
the
release
are
published.
B
So
if
anyone
has
a
chance,
please
take
it.
First
bin
send
us
any
feedback.
Hopefully
at
this
point
you
know
we
don't
discover
any
more
critical
issues
and
we
can
move
this
shipping,
the
the
official
1.3
release
before
too
long
and
then
to
spend
some
time
yesterday,
updating
the
blog
post
to
account
for
the
additional
CRD
fix,
since
the
blog
post
does
go
and
do
some
depth
on
the
the
set
of
CRT
issues
that
we
resolved.
So
that's,
that's
mainly
it
for
me-
has
a
little
bit
of
a
scattered
past
few
days
with
support.
B
I,
don't
have
a
specific
date
in
mind,
but
probably
next
week
I
mean
you
know.
If
we
don't
get
any
issues
reported
I'd
say
we
could
we
could
push
it
out
next,
I,
don't
know
Monday
or
Tuesday.
I
did
a
little
bit
of
testing
yesterday
and
and
things
look
good
I
tested
the
specific
bug
around
CR
DS
and
that
looked
good
and
we
haven't
really
gotten
any
other
issue.
Reports
from
the
first
beta,
so
so
yeah
I'd,
say
early
next
week
would
be
a
target.
C
C
You
know
sort
of
a
little
some
time
ago,
PRS
that
I
don't
think
that
might
not
have
requested
my
reviews,
but
I
just
wanna
look
at
them
same
thing
with
issues
they're
a
bunch
of
I'm,
just
gonna
go
over
and
give
feedback,
and
the
next
week
I'm
on
pto.
So
going
back
to
the
first
bullet,
I
made
slow
progress
with
the
CLI
design.
C
E
E
The
tail
end
of
last
week
was
going
through
a
shishas
PR
for
updates
to
the
CSI
prototype,
which
he'll
talk
about
also
found
out
last
week.
That
I
will
be
going
to
Q
Khan
EU.
So
if
you're
there
come
say,
hi
I
won't
be
doing
a
talk
or
anything,
but
I
will
be
hanging
out
at
the
DMI
booth.
At
some
point,
and
I
also
saw
a
couple
hours
ago
that
they're
close
to
selling
out.
So,
if
you're
not
going
yet,
which
are
interested
and.
E
I
need
to
do
that
myself
to
you
and
then
something
that
that
has
been
all
my
radar,
but
I
haven't
I
haven't
actually
followed
up
on.
It
is
something
that
Scott
CEO
reported
is
something
I
bubbled
up
upstream
there's
this
conversion
issue
with
CR
DS
and
I
got
feedback
from
Jason
or
John
Liggett
that
it
may
not
be
a
problem.
E
E
E
So
I
need
to
I
need
to
get
a
more
detailed
response
back
to
him,
but
it's
been
a
little
while
so
I
need
to
go
refresh.
My
memory
on
this
and
I
think
Jenny
Jenny
Buckley
from
what
I
had
looked
around
on.
She
was
doing
a
lot
of
the
work
around
the
this
area
of
the
code,
so
I'm
not
surprised
that
they
assigned
her
there,
but
given
I
hadn't
done
a
lot
of
activity,
I
wouldn't
be
surprised
if
this
gets
marked
stale
soon,
so
I
need
to
go
update.
E
A
D
D
A
G
D
G
D
G
D
G
D
A
H
Real
quick
I'll
just
give
a
brief
update
on
the
custom,
see
a
bundle
thing
so
Steve
left
me
some
good
feedback
on
the
way
that
Valero
currently
handles
the
rustic
repository
gran
shalls'
and
how
that's
inserted
into
the
pod
of
rustic
and
I
was
actually
able
to
confirm
that
I
could
do
the
same
thing
with
the
sea,
a
bundle
and
then
execute
commands
with
the
CSR
flag
too
rustic.
So
I
updated
the
design
this
morning,
just
with
a
couple
paragraphs
explaining
this
approach
and
linking
to
the
rustic
repository
okay.
H
So
if
you
guys
don't
mind
just
taking
a
quick
look
at
that,
then
I'm
hoping
I'm,
not
sure
how
long
this
is
gonna.
Take
me,
but
I
need
to
clean
up
the
code
that
I
hacked
together
to
just
test.
If
this
actually
was
gonna
function,
I
mean
I'd
like
to
figure
out
where
exactly
in
the
valar
code,
that's
going
to
go,
I,
don't
know
if
I
should
go
in
this
talk
or
if
this
is
more
of
just
like
a
you
know.
H
This
is
the
general
approach
and
that's
when
you
want
to
merge
it,
but
either
way.
I
just
need
to
really
know
what
the
next
step
you
guys
think
I
should
do
if
this
should
get
merged
or
should
we
include
all
that
information
on
this
doc,
but
other
way
whenever
you
guys
get
a
chance
to
take
a
look
at
that
any
questions
about
that
before
I
move
on
another
one.
B
H
H
So
the
intention
here
is
that
do
we
see
value
in
actually
installing
this
custom
server
for
the
backup,
storage
location
on
the
clients,
actual
machine
I
wasn't
initially
envisioning
doing
that,
but
mainly
because
I
didn't
see
that
necessarily
as
what
the
CLI
tool
was
used
for,
but
I'm
also
coming
outside
and
removed
from
where
you
guys
see
that
that
CLI
tool
developing
so
I'm
kind
of
indifferent.
If
you
guys
think
that
fits
in
this
design,
I'm
happy
to
add
that
into
the
design
dock,
because
that
wouldn't
be
too
hard
to
change.
B
Ok,
so
I
know
we
had
I,
don't
know
six
months
ago
or
something
we
had.
Someone
contribute
a
PR
to
allow
the
unsecure
skip
verify
flag
and
as
part
of
that,
there
was
some
discussion
around
impact
on
the
CLI,
for
these
commands
off
to
go
refresh
because
I,
don't
remember
all
the
details,
but
I'll
just
update
with
any
comments.
I
have
on
the
PR,
for
you.
E
Commands
they
use
a
one-time-use
URL
from
the
object
store.
So
usually
they
say:
hey
s3,
give
me
a
URL,
that's
good
for
one
use
to
download
from
here
and
what
a
lot,
what
the
issue
I
link
to
is.
Is
the
user
was
like
hey
my
resource
list
when
I
do
backup
describe
the
resource
list
is
just
garbled
text
and
they're
using
Mineo
on-prem,
and
if
you
change
the
BSL
or
if
we
have
them
change
the
PSL,
you
have
a
public
URL.
E
Then
it's
resolved
just
fine
and
they
can
grab
their
resources
in
plain
text.
But
if
they
want
to,
you
know
have
secure
communications,
they
need
some
CA
sort
to
grab
that
information.
So
I
think
I.
Think
if
we're,
if
we're
doing
custom,
CAS
support
I
think
it
may
to
me
it
makes
sense
to
have
CA
support
for
the
client
side
to
do
these
downloads.
E
I,
don't
know
about
doing
full-on,
like
velaro
installs,
the
cert
on
every
possible
OS,
because
right
there's
that
was
kind
of
my
concern
was
was
where
do
you?
Where
do
you
kind
of
cut
this
off
right?
My
opinion
is,
we
would
just
allow
a
flag
that
we
say
cert
or
whatever,
and
you
point
it.
But
okay,
that
that's
that's
my
opinion
and
that's
easily
need
documented
and.
E
That
that
I
think
is
acceptable,
and
maybe
we
allow
that
as
a
config
in
the
client
config.
So
like
the
client
I,
think
it's
in
home,
dot,
config,
slash
falero
and
you
can
say
you
could
set
the
you
could
set
a
flag
for
the
the
CI
start
there,
so
that
you
don't
have
to
specify
it
every
time
for
people
that
use
okay,
so
I
think
that's
a
good
middle
ground
between
installing
it
in
the
guest
or
in
the
client
side.
Os
and
not
making
user
specified
all
the
time.
H
Okay,
yeah
sounds
great.
I
will
add
these
notes
to
the
doc
and
should
have
done
the
next
hour,
so
I'll
just
wrap
it
up
right
now.
So
thank
you
for
that.
Unless
you,
the
other
thing
that
I
wanted
to
bring
up,
was
this
issue.
That's
actually
been
hoping
for
a
while
and
I
remember
I
coming
in
a
few
months
ago,
and
it
has
to
deal
with
rustic
volumes,
not
being
restored
specifically
was
reported
because
they
were
using
open
ships
with
diploma
configs
and
I.
H
H
B
Yeah
I
can
definitely
connect
with
you
right,
I
kind
of
somewhat
remember
this
issue,
though
it's
been
a
few
months
and
yeah
I.
Think
that
you
know
the
assumption
that
we're
making
in
our
code
is
that
if
we
restore
the
pod
first
that
when
we
go
restore,
you
know
a
replica
set
or
a
deployment
that
that
replica
center
deployment
will
basically
adopt
the
pod
that
we've
already
created,
and
that
seems
to
have
been
working
pretty
consistently.
So
yeah
I'm
also
not
totally
clear
on
why
there
is
the
diff
between
you
know.
B
H
I
Think
and
I
can't
remember
whether
this
was
salmon
sets
or
this
was
jobs.
But
there
was
one
where
I
remember
when
you
restored
the
pod
and
the
the
owner
of
the
pod,
the
owner
references
we're
doing
something
weird
in
some
cases
where
you'd
end
up
with
a
new
pod
being
created
by
the
the
daemon
set
or
again
the
job
I,
don't
remember
which
type
it
was
it
was
doing
this,
but
because
the
owner
references
were
being
a
little
weird.
I
What's
that
one
resource,
it
wasn't
deleting
the
old
one
and
you
end
up
with
two
pods
running,
and
so
the
kind
of
you
know
big
hammer.
Workaround
was
let's
just
not
restore
pods
that
have
owners
that
will
that
are
maintaining
them
again.
I,
don't
know
what
the
normal
process
is
here
that
it's
kind
of
related
to
what
Dylan's
was
talking
about,
but
just
in
general,
this
question
of
you
know:
what's
on
the
pod
versus
what's
on
the
owner
of
the
pod
and
how
do
those
get
managed
and
restored
and
in
a
way
that's
sane.
E
Steve,
didn't
we
early
early
on
like
zero,
four
zero,
five
didn't
didn't
Valero
at
one
point,
just
restore
deployments
and
like
we
didn't
restore
pods
directly,
we've,
let
whatever
own
restore
them
and
then
about
the
time
we
brought
rustic
around.
We
started
restoring
the
pods
directly.
Is
my
man
yeah
right
there
yeah.
B
I
think
it
was
for
even
longer
than
you
know,
405
I
think
up
until
maybe
like
0.11.
We,
we
weren't
restoring
anything
that
had
a
controller
owner,
so
pods
weren't
getting
restored.
And
if
you
had
you
know
replica
sets
owned
by
deployment.
We
just
restored
the
deployment
and
let
you
know
what
the
API
server
logic
go
from
there
and
there
there
was
a
user
request
that
led
to
us
making
that
change.
But
we,
when
we
introduced
drastic,
we
did.
B
You
know
we
had
an
exception
for
rustic,
where
we
directly
restored
the
pods,
so
that
I
think
so
that
we
can
put
the
init
container
in
place
on
the
individual
pod
with
the
relevant
rustic,
backup
idea,
I
guess
so,
just
quickly
so
done
and
Scott.
You
both
mentioned
the
putting
the
annotation
on
the
pod
template
spec,
which,
which
annotation
is
that
the
rest
communication,
the.
B
I
G
E
I
And
and
the
reason
again
for
that
goes
back
to
this
issue
of
when
we
were
restoring
the
deployment
you
know
what's
happening
with
the
plumbing
config.
At
least
you
know,
we're
saying
it's
not
happening
doesn't
seem
happening
this
deployment,
so
with
deployment
configs
in
particular,
Valera
restores
at
the
pod
and
then
it
goes
through
restored.
The
deployment
config
that
a
planet
config
because
it
has
a
trigger,
was
a
big
changes
it
it.
I
You
know
it
launches
a
new
pod,
and
so
what
we
were
seeing
is
that
the
initial
pods
that
Valera
restored
is
immediately
then
deleted,
because
the
deployment
config
of
on
restore
sees
oh
I.
Haven't
you
know
this
is
this?
Is
a
change
resource?
It's
new
need
to
deploy
new
one,
it's
the
next
generation
and
then
that's
created
and
the
original
pod
is
deleted,
and
so
then
we
don't
have
that
annotation
anymore
and
putting
the
annotation
on
the
template.
I
Spec
seems
to
resolve
that,
but
we
were
concerned
there's
still
a
race
condition
there,
because
if
rustic
starts
to
restore
using
that
initial
pod
and
then
the
deployment
config
over
writes
that
with
a
new
pod
I'm,
not
sure
rustic
is
gonna
recover
from
that
or
not
or
fresh
sticks.
Gonna
see
it
didn't
finish
and
then
work
anyway.
I
I
think
it's
actually
adopting
the
pod,
but
I
think
what's
happening.
Is
that
it
does
it
off
the
pod
with
Dendi
the
trigger
the
config
change
trigger
on
the
deployment
convey
is
triggering
saying.
Oh,
we
now
have
a
change
in
this
configuration.
We
need
to
deploy
a
new
application,
no
controller,
a
new
pod,
and
so
it
is
adopting
the
pod,
the
symbol.
Immediately.
I
You
know
if,
if
the
deployment
config,
if
the
pod
gets
restored
via
rest
agrestic,
it's
finished
before
we
restored
the
deployment
config,
then
we
don't
care
that
it
overrides
it
with
a
new
one,
because
rustics
already
done
the
file
systems
been
updated,
but
again
I,
don't
know
if
there's
a
difference
and
either
on
the
restore
sigh,
how
whether
Valero
is
restoring
deployments
differently
than
deployment
can
mix
here
or
on
the
kubernetes
side.
If
you
know
the
triggers
are
working
differently.
I
B
A
B
I
just
had
one
from
the
men
Valero
repos,
agenting
who's
been
a
contributor
in
the
past,
had
another
PR
up
to
there's
a
bug
with
related
eristic
backups
of
persistent
volume
claims
where,
if
you
had
multiple
backup
storage
locations
configured,
it
wasn't
always
looking
at
the
correct
backup,
storage
location
when
trying
to
figure
out
what
the
rustic
snapshots
parent
was
and
remember.
If
this
was
a
resulting
in
just
errors
or
if
there
was
a
panic
that
was
happening
in
any
case,
Genting
fixed
the
bug.
So
thanks
a
lot
for
the
fix
and
I
do
know.
B
C
Yeah
we
haven't
been
doing
a
shout
out.
We
haven't
been
able
job
but
giving
a
shout
out
to
people
who
have
been
contributed
to
contributing
to
our
helm,
charts
but
will
change.
They
will
do
better,
but
all
of
those
peers
they're
closed
and
with
a
green
checkmark.
They
are
all
by
outside
contributors.