►
From YouTube: Velero Community Meeting/Open Discussion - June 9, 2020
Description
June 9, 2020
Status Updates
ashish:
Allowing all pod volumes to be backed up using restic by default, without requiring annotation on the pod. PR 2611
Exclude: host path volumes, volumes mounting default service account tokens and volumes excluded through “exclude” annotation
Review and discussion of the volume snapshot progress proposal
Focussing on internal build setup.
steve
on community support this week
updating & testing a community-contributed PR to support aad-pod-identity for Azure (https://github.com/vmware-tanzu/velero/pull/2602, https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure/pull/51) (thanks @gitirabassi for the code!)
log a warning instead of an error if an additional item doesn’t exist during backup (https://github.com/vmware-tanzu/velero/pull/2595)
nrb
More reviewing on reporting progress on volume snapshotting
https://github.com/vmware-tanzu/velero/pull/2610
Plan to follow up on KubeBuilder PR review this week
Also want to follow up on the restore hooks PR
Can other maintainers look at the tagging scripts PR?
Been doing work on some internal projects the last week
carlisia
BSL resource conversion to kubebuilder PR is ready for review: https://github.com/vmware-tanzu/velero/pull/2561
Wrapping up new BSL controller, just need to add tests
Discussion Topics
Vishnu:
Thanks to maintainers for review comments on this PR https://github.com/vmware-tanzu/velero/pull/2543. Would like to discuss on next step and pending items from me related to this PR.
steve: finalize naming & CR lifecycle (who creates?)
Phuong:
We would like to propose a change to allow caller to specify an order to backup items of the same type. More generic than https://github.com/vmware-tanzu/velero/issues/1917 which only for PVC.
In backup spec, have a map of type to strings of specific names (e.g. PVC - names of PVCs)
Next step - submit a design doc PR based on https://github.com/vmware-tanzu/velero/blob/master/design/_template.md
steve: restore hooks design PR
@marccampbell will you be able to address open comments/questions?
Contributor Shoutouts
@cblecker - when creating a backup from a schedule, allow a default name (https://github.com/vmware-tanzu/velero/pull/2569)
@vitta - Thanks for being super responsive on PR 2543!
A
A
B
So
currently
you
need
to
annotate
your
pod
spec,
either
in
your
deployment
or
wherever
your
pod
spec
is
coming
from
to
how
all
Yume's
used
by
your
pod,
backed
up
by
realistic.
Now
we
are
like
inverting
the
server
or
allowing
folks
to
invert
the
selection
of
volumes
for
resting
backup,
so
I
have
a
PR
out
to
do
that
and
of
course
the
PR
excludes
like
host
path.
B
Walliams
and
the
volume
is
mounting
the
service
accounts
and
also
the
volumes
that
users
have
set
up
to
exclude
from
let's
take
backup,
so
I
I
have
a
PR
all
for
that.
So
if
you're
interested
please
to
take
a
look
and
add
some
comments,
other
than
that
I've
been
looking
at,
the
volume
snapshot
progress
proposal
that
Vishnu
has-
and
there
were
some
discussions
about
that
last
week-
other
than
that
I'm
focusing
on
some
internal
build
set
up
here
here
at
be
aware.
So
that's
pretty
much
week.
C
Everyone
so
I'm
on
community
support
this
week.
The
last
few
days
worked
on
a
couple
of
things.
The
first
one
is
a
an
enhancement
to
the
Azure
plug-in,
which
also
required
a
change
to
lower
core,
but
this
is
to
support
a
ad
pod
identity
which,
for
those
of
you
who
aren't
familiar,
it's
kind
of
like
cube
I
am
in
AWS
world,
but
this
is
Frasier.
C
So
we
had
a
community
member
who
submitted
a
PR
for
this
probably
two
months
ago,
but
it
was
a
little
bit
out
of
date
and
needed
some
conflicts
resolved.
So
I
just
got
this
updated
and
got
it
tested
in
an
azure
environment
and
everything
looks
good.
So
the
the
PR
that
went
into
Flair
core,
which
was
for
rustic
support,
has
already
been
merged
and
the
one
for
the
plug-in
is
it's
just
waiting
for
another
review
and
merge
and
beyond
that,
I
also
tackled
an
issue
that
we
had
around,
basically
not
logging,
a
an
error.
C
If,
if
you
have
an
additional
item,
that's
returned
from
a
plug-in
during
back
up,
but
that
item
doesn't
exist.
So
this
this
came
up
yeah.
We
saw
it
in
a
couple
of
different
scenarios,
but
a
common
one
would
be
that
you
have
a
pending
pod
in
your
cluster
and
it's
pending,
because
the
PVC
that
it's
supposed
to
use
doesn't
actually
exist
in
the
cluster.
C
So
maybe
it's
a
Mis
configuration-
or
maybe
it's
just
a
timing
issue,
but
previously
Valera
would
actually
a
backup
of
that
pod
would
would
end
up
in
a
partially
failed
state
because
it
would
flare
would
try
to
go
back
up
that
PVC
and
it
wouldn't
exist
in
the
kubernetes
api.
So
it
would
log
an
error.
So
we've
had
a
bunch
of
discussions
on
this
item
and
agreed
that
it
doesn't
really
make
sense
to
log
in
error,
but
a
warning
would
make
sense.
So
I
changed
this
code,
you
to
just
do
that.
So
now.
C
D
C
And
I
think
we
all
kind
of
and
with
input
from
the
community
for
sure
agreed
that
you
know
it's
not
really
Valera,
it
doesn't
make
sense
for
Valero
to
fail
backups.
If
there's
a
Mis
configuration
in
the
cluster,
we
should
just
capture
what's
there
and
notify
the
user
in
a
kind
of
a
non
non-fatal
way,
yeah
other
than
that
you
know
miscellaneous
reviews
and
such
but
those
the
main
items
for
me.
E
Progress
for
backup
restore
operations-
I
won't
go
too
deep
in
now,
because
Vishnu
is
on
the
call
and
has
that
for
a
discussion
item
just
to
say,
I've
been
thinking
about
that
and
reviewing
that
and
then
it'll
Stephen.
If
you
should
have
been
looking
at
that
as
well.
Also
last
week,
I
put
up
a
PR
for
logging,
an
error
when
there
was
a
misconfigured
schedule.
E
E
If
you
provide
a
hook
timeout
and
don't
have
units,
it
will
still
do
the
it
will
still
refer
to
the
30-second
timeout,
but
now
it
will
log
a
warning
and
say:
hey
I
couldn't
purse
the
the
timeout
you
provided
and
then
see
coming
up
this
weekend.
Well,
I
want
to
get
a
deeper
looks
at
the
cute,
builds
or
PR.
That
Carly
has
been
working
on
and
also
follow
up
on.
E
The
restore
hooks
PR
that
mark
Campbell
has
been
working
on
and
then
also
a
request
for
the
other
maintainer
x'
to
look
at
the
tagging
scripts
PR.
So
this
was
a
PR
I
put
up
last
week
to
automate
our
release
a
little
bit
more
so
that
it
takes
hopefully
less
time
to
generate
a
release
and
less
of
the
decision-making
is
just
in
Docs.
So
it's
a
whole
should
mostly
be
automated,
but
there's
a
few
things
in
there.
G
B
G
G
A
D
D
Oppress
us
covenant
yeah,
that's
right!
That's
what
I
was
looking
for
adhered
to
the
offenses
covenant
and
be
free
to
express
by
the
way,
I
want
to
say
one
thing.
Last
week
we
had
17
folks
on
the
Valero
call
we
have
21
today,
amazing,
you
know
like
thank
you
all
for
attending.
Thank
you
all
for
your
support
and
contributions
to
this
project.
H
H
C
H
C
Yeah
I
mean,
if
you
know
folks
have
opinions.
You
know
I
basically,
since
since
we're
talking
about
adding
new
API
types,
I
do
just
want
to
make
sure
we're
thoughtful
about
that
and
are
happy
with
the
the
new
API
types
that
we
come
up
with,
because
those
are
harder
to
change
than
internal
code
going
forward.
So
I
had
a
few
more
thoughts
here.
I
mean
you
know.
My
eye
level
comment
is
that
I
think
the
direction
makes
sense,
and
so
it's
just
a
matter
of
nailing
down
exactly
what
the
API
looks
like.
H
E
B
A
I
Hi,
my
name
is
Omar
with
the
DMC
data
protection
I
on
virtual
machine
and
Cooper
net
for
the
last
five
years,
so
I
mean
in
a
book.
We
are
doing
backup
and
restore
for
cubanelle
application,
and
we
run
into
situations
where
we
have
to
backup
entity
resource
it
in
a
specific
order.
For
example,
you
have
a
cluster,
you
know
the
master
is
late
and
we
have
to
stock
up
it
in
a
specific
order
and
I
also
found
some
other
people
also,
as
you
can
see
on
that
request,.
I
I
So,
for
example,
if
I
want
to
order
PVC
back
up
a
PVC
in
specific
order,
I
would
that
the
mapping
between
the
PVC
string
and
other
way
upstream
each
other
element
of
the
array
of
the
string
will
be
the
name
of
that
PVC,
so
that
when
we
do
back
up,
we
will
specifies
we
will
see,
realize
this
entity
in
that
specific
order,
if
there's
nothing
specify
at
all,
then,
which
is
who,
as
normal
order,
that
whatever
the
US
a
daily
Cabana
a
guy
returned.
So
that
is
my
proposal.
I
C
I
think
it
sounds
reasonable
at
first
glance,
I
mean
it.
You
know
it
sounds
like
this
will
be
an
an
optional
new
API
field.
So
for
folks
who
don't
have
a
need
for
this,
it's
essentially
no
change
for
them,
and
it's
really
just
often
behavior
in
the
for
the
use
cases
that
are
needed
so
yeah.
It
sounds
reasonable
and
look
forward
to
seeing
that
that's
on
duck.
C
J
Yeah
we
could
take
another
pass
of
that
I
think
to
the
biggest
issues.
Right
now
were
whether
or
not
the
adoption
is
gonna
work
for
the
pods
and
then
also
I
saw
that
Ashish
was
pushing
for
unique
containers
or
some
sort
of
free
restored
hook.
So
I
guess
kind
of
wanted
feedback
from
the
contributors
on
which
way
to
go
on
those
main
issues.
B
Otherwise,
like
the
application
would
probably
need
another
restart
at
which
point
the
pod
Mary
look
at
and
we
might
lose
the
rest
of
the
action
and
performed
by
the
restore
hooks.
So
that
was
my
thinking
with
behind
proposing
that,
and
also
because
we
are
in
adding
this
new
restore
books.
We
might
also
add,
like
a
policy
or
something
as
to
Bent,
to
run
this
restore
books.
B
D
Generally
agree
with
Ashish,
especially
around
the
fact
that
if
you
are
gonna
restoring
to
restore
before
and
and
rad
Nansen
hooks
before
the
app
gets
I've
been
running
right.
There's
you,
then
you
get
into
race
conditions
and
situations
where
you
have
an
application,
that's
consisting
on
multiple
services
and
depending
on
each
other.
It
could
get
us
into
some
trouble.
Troubling
situations
are
hard
to
double
troubleshoot.
So
I
generally
agree
with
those
recommendations.
C
Just
on
the
issue
around
the
pot
adoption
I
started
to
spend
some
time
on
this,
but
I
didn't
get
too
far
into
it.
I
got
distracted
on
some
other
things,
but
I
guess
my
you
know
my
kind
of
working
assumption
is
that
we're
relying
on
this
behavior
for
rustic,
and
it
seems
like
for
the
vast
majority
of
users,
this
works,
okay
and
so
I
think
I'd
be
sort
of
inclined
to
to
be
okay,
relying
on
it
here
as
well,
and
you
know
if
longer
term,
we
see
that
we
need
to
make
a
change
here.
C
D
And
I'm
drew
and-
and
if
you
know
from
your
mark
like
do
you
guys-
have
a
timeline
for
basically
driving
some
some
of
these
changes?
Let's
say
that
we
get
everything
buttoned
up
and
you
have
a
complete
idea
of
what
you
want
to
build,
maybe
by
the
end
of
this
week,
people
it's
even
possible,
like
you
know,
you
know,
you
know
when
you
might
be
able
to
allocate
resources
to
get
this
done.
I'm.
H
For
a
need
kind
of
thing
like
in
between
contributor
and
the
maintenance,
we
can
have
some
kind
of
a
reviews
for
some
models,
kind
of
thing
we
can
vote
on
somebody
who's,
not
like
they're
much
but
just
but
the
kind
of
you
should
be
able
to
for
a
particular
area.
That's
just
like
what
that's
one
of
the
thought
on
shielded
the
team.
E
A
No
I'm,
yeah,
you're
you're
right
I
think
we
talked
about
having
an
intermediate
step
between
contributor
and
maintainer,
but
not
specifically
having
a
specialized
area
outside
of
the
plugins.
So
if
you
are-
and
you
can
easily
be
a
maintainer
of
a
plug-in
which
would
be
a
specific
area
of
Alera
so
other
than
that
I
think
a
reviewer
/
approver
or
whatever
we
end
up,
calling
that
intermediate
role
would
be
for
most
of
velaro,
of
course,
but
everyone
has
subject
matter,
expertise
in
certain
areas,
so
I
think
kaliesha.
A
G
Yeah
I
think,
as
we
get
to
know
people's
work,
we
would
know
what
their
expertise
lies.
So
if
we
had
group
of
people
who
would
not
yet
the
maintainer
is
forbid
that
reviewer
sort
of
wrong
now
one
thing
that
we
discussed
for
is:
we
could
we
could
add
this
intermediary
role,
but
we
first
have
to
identify
some
people
to
fulfill
those
that
row
and
I
just
have
that
role
there
with
no
one
listed
under
it.
G
So
I
guess
what
we
need
to
see
is
so
that
were
what
be
specifically
for
for
people
who
are
no
yet
maintenance,
but
they
are
reviewing
PRS.
They
are
reviewing
issues
and
helping
I
was
just
a
little
first
pass.
So
I
guess
we
need
to
see
that
or
identify
people
who
have
been
doing
that
I
guess
both
things.
E
E
G
F
A
A
C
I
was
basically
on
point
to
this
and
say
notionally
we're
targeting
you
know,
August.
We
tend
to
not
be
specific
date
driven.
So
you
know
we
sort
of
true
off
an
amount
of
scope
that
we
think
will
take
us
about
two
months
and
then
we
essentially
go
until
it's
done
and
ship,
but
what
the
target
is
around
August
Thanks.
B
C
A
F
B
B
B
E
B
C
Previously,
you
were
you're
required
to
explicitly
name
the
backup,
so
this
PR
enabled
basically
an
automatically
generated
backup
name,
which
just
I
think
takes
the
schedule
name
and
appends
a
timestamp
to
it,
so
that
the
user
has
one
less
thing
to
type
when
they're
creating
a
backup.
So
thanks
a
lot
for
the
PR
here
and,
let's
see
I,
don't
actually
remember
if
this
got
shipped
in
1.4
or
if
this
will
be
a
1.5
item.
No.