►
Description
March 9, 2021
Status Updates - items working towards roadmap
nrb
Not a lot of progress on code items, mostly working on process stuff and internal builds.
bridget
BSL and Plugin PRs merged for multiple credentials
Restic PR now ready for review: PR 3489
Working on E2E test for multiple credentials
carlisia
Last week: community support + PR reviews of release blockers
This week: PR reviews + review of upload progress design + resolving support issue from last week (restore gets stuck restoring an nfs-pv using restic - (https://github.com/vmware-tanzu/velero/issues/3450)
dave
vSphere stuff
Updated ROADMAP.md with 1.7.0 items (https://github.com/vmware-tanzu/velero/blob/main/ROADMAP.md)
This week - community support
ashish
E2E tests flakyness:
Issue https://github.com/vmware-tanzu/velero/issues/3532
PR https://github.com/vmware-tanzu/velero/pull/3527
Restic upgrade:
https://github.com/vmware-tanzu/velero/pull/3528
Discussion topics
Eleanor Millman will be our new PM starting March 15, 2021
Nolan: Go over release-blockers for v1.6.0
Nolan: Velero Roadmap update for v1.7.0
We will be moving to date-based releases, probably close to Kubernetes release dates.
This would be a 4 month cadence, and give us more realistic timeframes; what do folks think about this?
No matter what timeframe we pick, we’ll be shipping what’s included at that time and only stopping for critical bugs.
Leave comments on https://github.com/vmware-tanzu/velero/pull/3551
Nolan: Working on a Velero vision for the future. Please leave a comment on this hackmd if you’d like to share your thoughts.
Contributor Shoutouts PRs
@jenting: Add jenting as reviewer
@jenting: Add jenting as reviewer
@jenting: [velero] Helm v2 deprecated
@jenting: [velero] Update chart maintainer
Contributor Shoutouts Velero Q&A
A
Hello,
everyone
and
welcome
to
the
valero
community
meeting
and
open
discussion
today
is
march
9th
2021
per
usual.
We're
gonna
kick
off
with
some
status
updates
and
then
just
dive
into
discussion
topics.
I
know
nolan
is
going
to
be
go
over
some
of
the
roadmap
updates
again.
So
let's
do
this
nolan
europe.
First.
B
C
Hi
everyone,
so
I
had
a
bit
of
an
interrupted
week
last
week,
had
to
take
some
unexpected
pto,
but
during
last
week
most
of
the
prs
I
had
for
the
multiple
credential
support
were
reviewed
merch.
So
thank
you
very
much
to
to
everyone
who
reviewed
those
the
rest.
The
support
for
multiple
credentials
for
wresting
is
now
ready
for
review
because
it
was
blocked
on
one
of
those
previous
prs.
C
So
that's
ready
to
review
and
I'm
currently
working
on
et
test
is
running.
I
think
it
has
just
passed,
so
I
will
open
up
a
pr
for
that
once
I'm
sure
that
it
all
works
as
intended,
and
then
that's
it
yeah.
I
think
so.
I
need
to
do
some
other
reviews
as
well,
but
I'll
try
and
catch
up
on
those
this
afternoon
and
tomorrow.
So
that's
it
for
me.
A
C
A
D
I
was
on
community
support
last
week
and
did
pr
reviews
for
some
of
the
release
blockers
and
this
week,
I'm
doing
more
pr
reviews.
But,
frankly,
I
want
to
focus
on
reviewing
the
upload
progress,
design
documents
and
I
also
have
to
circle
back
to
this
support
issue.
There's
another
issue
related
to
this.
D
D
E
A
D
E
Yeah,
so
let's
see
so
inside
baseball
stuff,
just
you
know,
be
scary
things
we're
looking
at
support
for
the
various
flavors
of
tanzu
on
supervan
wcp,
so
we're
working
on
getting
additional
support
for
that
and
I
went
ahead
and
updated
the
roadmap
with
the
stuff
for
one
seven.
So
it
looks
like
that's
been
merged,
but
it's
still
open
for
change.
So
if
people
have
suggestions
or
comments,
that's
quite
welcome.
At
this
point.
It
looks
like
nolan's
gonna
go
over
that
later
and
then
this
week
I'm
on
community
support.
E
F
Okay,
so
last
week
I
was
plumbing
our
aoe
tests
to
be
like
run
regularly
in
as
part
of
our
internal
release
pipelines
so,
and
I
noticed
that
our
retweet
tests
are
slightly
flaky.
So
I
opened
up
an
issue
for
us
to
address
that,
and
I
also
have
put
up.
One
p
appear
that
this
is
one
one
issue
that
I
saw
and
I
believe
frankie
is
working
on
another
one.
F
So
I
did
that
I
was
verifying
that
we
have
backwards.
Compatibility
like
you
can
you
can
restore
a
backup
that
you
have
taken
with
zero
nine
six,
which
was
the
older
version
of
rustic,
that
we
are
using
using
the
and
restore
using
the
newer
version
of
rustic.
So
I
have
that
all
documented
in
that
pr,
if
you
want,
if
folks,
want
to
take
a
look
and
sign
off
or
add
comments.
D
A
A
F
A
F
B
H
D
A
B
B
F
A
H
B
B
C
C
D
A
B
Cool
so
yeah,
I
suppose
we
net,
we
can
add
a
github
issue
for
tracking
that
I
don't
know
that
it
will
I'm
sure
our
process
has
usually
been
to
do
it
in
google
docs
first,
just
because
it's
a
lot
easier
to
do
it
to
collaborate
on
that
sometimes
and
leave
comments
but
yeah.
So
the
two
items
are
already
on
the
board:
the
ete
tests
we'll
get
to
release
blocker
tag
on
and
the
blog
post
issue,
underneath.
B
Okay,
cool
so
dave
link
it
above
and
I've
I've
linked
it
here
we
have
the
valero
roadmap.
Four
one
seven
defined
we're
we're
looking
at
a
bunch
of
stuff
here.
The
core
things
that
we
really
really
really
want
to
get
done
are
making
sure
that
valero
installs
well
with
carvel,
which
is
a
suite
of
tools
for
managing
deployments,
that
vmware
also
open
sources.
B
We
are
looking
to
define
a
more
complete
test
plan
for
bolero,
so
not
just
sets
of
end-to-end
tests,
but
like
parameters,
matrix
of
supported
versions
across
all
the
different
things,
which
include
like
hard
hard
definitions
of
kubernetes
versions,
vser
versions,
all
that
kind
of
stuff,
all
that
fun
stuff.
Four
dimensional
graphs,
getting
eventually
getting
scale
testing
in
there,
I'm
sure,
but
to
start
with,
I
think
we
need
the
version.
Eight
version
tests
this
this
next
one
is
kind
of
like
an
observability
issue.
B
We've
wanted
a
valero
debug
command
for
a
while
to
help
people
kind
of
see.
What's
going
on
in
their
clusters,
like
in
a
specific
example,
is
getting
data
for
restic
is
kind
of
annoying,
and
we
partnered
up
with
the
crash
diagnostics
team
here
at
vmware
and
crash
diagnostics
is
a
tool
that
lets
you
use
the
starlark
python
dialect
to
define
things
you
want
to
fetch
out
of
your
cluster,
so
this
is
used
with
like
happy
clusters
to
get
get
logs
for
all
the
supervisor.
B
B
So
the
idea
that
we're
currently
batting
around
for
this
is
to
include
crash
diagnostics
as
a
library
inside
of
valero,
and
then
our
crash
diagnostic
scripts
will
be
bundled
into
the
valero
binary.
So
gowin16
includes
provisions
for
doing
that
for
for
dumping
bits
into
your,
and
your
binary
kind
of,
like,
I
believe,
is
bin
data
was
the
older
library
that
did
it.
So
I
envision
we
get
the
valerio
debug
support
through
including
crash
diagnostics,
but
we'll
produce
a
design
document
talking
exactly
about
that.
B
Item,
I'm
gonna
pull
up
the
road
map
here
locally.
The
next
an
item
is
getting
csi
snapshots
to
ga
so
csi
snapshotting
snapshots,
I
believe,
g8
in
120
on
kubernetes.
It's
not
fully
implemented
across
all
drivers,
yet
for
things
like
aws
or
gcp,
but
we
want
to.
We
want
to
start
doing
more
testing
on
that
and
make
sure
valero's
support
is
ga
so
that,
as
folks
start
transitioning
the
clusters
from
the
built-in
drivers,
they
can
start
transitioning
to
the
csi
drivers
and
have
full
fuller
support.
B
So
we're
gonna
try
to
polish
this
up
and
we
have
a
csi
ga
tag
out
there
for
different
for
our
label
for
different
things.
So
we
will
be
grabbing
those
and
putting
those
into
an
implementation
plan
and
then
the
last
thing
in
our
core.
I
know
two
more
items
are
our
core
plan:
support
for
valero
plug-in
versioning.
B
B
B
B
B
D
E
Like
to
get
the
implementation
in,
we
should
be
able
to
finish
up
the
design
in
the
next
couple
of
weeks,
but
we
have
to
sketch
out.
You
know
what
needs
to
be
done
to
actually
implement
it,
and
we
really
have
to
get
scoping
for
the
core
items
for
how
much
time
those
are
going
to
take.
And
then
we
can
see
what
else
we
can
fit
in.
B
Yeah
plug
it
in
some
of
these
other
things,
plug-in
timeouts
is
gonna,
be
blocked
on
on
plug-in
versioning,
so
we
have
to
get
that
done
first,
getting
to
distribute
containers
as
a
base.
I
think
I
think,
will
be
a
smaller
amount
of
work,
but
that
will
be
really
helpful
for
us
to
give
fewer
false
positives
on
security
scans,
we're
going
to
design
multiple
cluster
support,
but
I
think
that's
going
to
be
a
long
running
item
that
will
span
multiple
releases
and
my
hope
is.
B
B
A
E
Well,
actually,
I
have
that
working.
What
we
really
need
to
do
is
test
it
in
all
the
configurations,
so
it's
really
dependent
on
the
you
know.
I
want
to
make
sure
all
the
plugins
work,
for
example,
with
you
know,
making
sure
we
get
the
right
libraries
in
place
for
them,
so
we're
going
to
get
the
ute
test
running
with
volume.
Snapshotting
then
we'll
run
my
branch
through
that
it's
like
a
three
line,
change
to
actually
put
it
in.
B
B
D
B
B
D
I
B
Yeah,
my
idea
would
be
we're
running
our
tests
against
all
these
released
versions
of
kubernetes
and
also
whatever's
in
maine
on
kubernetes.
So
we
have
early
signal
to
say:
hey,
there's,
breaking
changes
coming
but
getting
getting
to
you
know
within
a
week
two
weeks
of
kubernetes
releases
would
be
awesome
same.
F
B
Yeah,
I'm
just
looking
at
time
frames
right
now,
like
I'm,
not
necessarily
looking
for
this
question,
I'm
not
looking
at
support
matrix,
but
for
right
now
I
think
my
my
personal
input
is
a
four
month.
Cadence
is
nice
because
it
gives
us
a
little
bit
more
breathing
room
on
getting
these
things
done,
but
I
also
want
to
stress:
we
need
to
move
to
date-based
releases
because
I
don't
think
anyone
feels
good
about
where
we're
at
with
the
1
6
release.
B
We
said
it
would
be
done
in
january
and
we're
we
were
operating
in
a
well
we'll
get
everything
done
and
then
release
it,
but
I
kind
of
want
to
turn
that
on
its
head
to
get
people
bug,
fixes
faster
and
help
the
team
ship
and
get
people's
designs
out
there.
So
I
created
a
this
is
a
very,
very
bare-bones
skeleton
on
a
a
release,
schedule
document,
that's
pull
request
3551.
B
If
you
take
a
look
at
this
and
comment
on
it,
let
us
know
what
you
think,
but
from
a
very
high
level,
we're
looking
at
doing
an
enhancement
or
design
freeze
so
propose
what
you
would
like
to
get
in
and
then
we
have.
We
have
a
period
where
there's
a
cut
off
if
it
doesn't
get
in
it
at
this
point,
then
we're
not
going
to
implement
it.
Then
we
have
implementation.
B
We
will
have
a
feature,
freeze
and
pruning
of
the
backlog
to
say.
Okay,
this,
these
things
are
done.
Anything
else
gets
moved
to
a
patch
release
or
the
next
major,
depending
on
how
involved
it
is
or
what
it
is.
And
then
we
do
code
freeze
for
just
bug,
fixes
and
doing
pre-releases
and
then
finally
release.
So
this
is
very
high
level,
but
I
wanted
to
write
this
down
and
get
this
in
front
of
people
to
help
keep
us
accountable
to
it
and
we
can
work
on
exact
time
frames
and
dates.
D
C
H
Do
a
question
but
feel
free
to
defer
it.
If
I
just
don't
have
the
context
of
course,
I
understand
why
you
need
a
code
freeze
towards
the
end.
Is
there
a
reason
that
you
have
to
define
a
defi
as
design
freeze
before
implementation
starts,
or
could
design
perhaps
go
at
the
same
time
as
implementation?
H
B
Think
so,
but
I
so
I
think
the
design
cutoff
is.
These
are
the
designs
that
will
get
implemented
in
this
release,
and
I
think
if,
if
a
design
goes
past
that
date,
then
it
will
be
for
the
next
release.
So
you
can
certainly
design
a
feature
that
may
end
up
in
the
release
plus
one,
but
what
I'm
trying
to
do
with
this
is
to
get
a
get
a
defined
payload.
So
these
are
the
things
we
expect
to
actually
get
in
in
this
release
and
then
iterate
on
those.
B
B
They
have
their
kubernetes
enhancement,
proposals
or
caps,
and
if
your
kep
is
not
ready
by
the
cutoff,
if
it's
not
accepted,
then
it
gets
the
boot
and
you
have
to
wait-
and
this
is
just
to
help,
keep
momentum
and
not
not
tie
things
up,
I'm
open
for
revising
it
in
the
future,
but
I
think,
like
one
six,
we
had.
We
had
a
little
bit
of
a
delay.
B
B
B
H
B
Yeah,
like
I
don't
I
don't
envision
this
to
be
like
waterfall,
but
to
say:
okay,
we're
comfortable
enough
with
this
design
to
start
implementing
and
questions
that
come
up
during
implementation.
Of
course,
that
needs
to
be
addressed
and
something
may
slip.
I
I
don't
want
to
get.
I
don't
want
it
to
go
full
waterfall,
but
mostly
consensus
on
what
at
a
high
level,
what
we're
going
to
be
doing.
E
So
that
we
get
the
roadmap
for
the
major
features,
little
features,
we
can,
you
know
slip
in
until
fairly
late
in
the
process,
but
I
don't
want
to
have
like
re-architecture
like
a
pull
request
with
a
big
architectural
change
popping
up
late
in
the
cycle.
That'll
get
deferred
to
the
next
release,
so
we
want
to,
but
we
want
to
enable
our
community
to
make
you
know
to
propose
big
changes.
So
we
want
to
have
a
predictable
way
for
everybody
to
see
where
they
fit
in.
In
this.
D
Even
though
yeah
it's
not
going
to
be
we're
not
intending
to
do
what
a
waterfall
process,
but
it
really
helps
us
to
focus
on
what
design
documents
are
there,
that
we
need
to
be
reviewing
for
the
release
and
which
design
documents
are
there
that
we
can
queue
up
for
later.
For
example,
one
of
the
reasons
why
I
think
that
the
credentials
got
delayed
was
because
we
weren't
focusing
on
that.
We
weren't
prioritizing.
E
Yeah
and
the
other
thing
is
for
big
features
right.
We
want
to
be
able
to
break
ourselves
into
doing.
You
know
iterations
like
two-week
iterations,
but
what
we
need
to
do
up
front
is
get
up.
At
least
the
big
picture
t-shirt
sizing
of
how
much
work.
You
know
what
what
pieces
parts
need
to
get
done,
how
much
work
is
involved
with
that
is
that
going
to
fit
into
this
release?
E
So
that's
one
of
the
reasons
to
push
this
design
phase
for
big
features
up
front.
We
may
add
things
in
later.
You
know:
there's
it's
not
a
cast
and
stone
process,
but
I
think
the
idea
here
is
to
get
us
the
ability
to
execute
on
large
features
and
nail
those
down
early
on
in
the
cycle
so
that
we
know
how
much
work
they're
going
to
be.
H
B
I'll
also
just
say
I
linked
the
kubernetes
release
process
document
here.
Kubernetes
is
a
much
bigger
pro
project
and
they
have
they
have
stuff
like
you
can
get
an
exception
in
for
your
cap.
I
don't
think
we
need
to
do
that
right
now.
I
think
we
can
be
loose.
I
think
we
can
but
and
adapt,
but
I
want.
I
want
some
general
guidelines
on
this
to
say:
okay,
this
is
our.
B
Let
me
talk
about
some
of
this
late
last
year,
but
we
didn't
put
like
a
document
out
like
this
to
really
agree
on.
So
I
want
the
document
out
there
and
then,
like
carlesia,
said
we'll
basically
have
relative
timelines
to
say
you
know,
work
backwards
from
the
release
date,
and
these
are
the
windows
roughly.
You
know,
and
things
will
happen
like
end
of
year,
shutdowns
or
holidays,
but
give
give
something
some
kind
of
insight.
B
So
if
we
don't
have
any
more
on
that,
I'm
gonna
move
to
the
next
one,
which
is
much
higher
level
so
internally
we're
we're
working
on
a
valero
vision
for
the
future
internally.
This
is
very
focused
on
where
it
fits
into
the
products,
because
valero
is
a
vmware
originated
project,
but
we
are
looking
at
doing
things
like
splitting
out
components
of
valero
like
the
serialization.
B
These
right
here
are
a
very
rough
draft
of
vision,
statements
or
things
we
want
to
accomplish,
maybe
not
vision,
statements
but
goals.
We
want
to
enable
partners.
We've
got
people
from
red
hat
on
the
call.
We've
got
people
from
the
dell
on
the
call
we
want
to
make
valero
a
better
engine
for
you
to
get
your
work
done
and
we
also
want
to
deliver
core
features
ourselves.
B
A
B
Yeah
so
the
goal
there
would
be
to
say
our
our
long-term
goal.
You
know
if
we
could
have
everything
we
wanted.
Valero
would
be
running
in
every
kubernetes
cluster
and
we
that's
not
necessarily
valero
as
it
is
today
we're
for
an
example.
We're
envisioning
splitting
valero
into
like
a
serialization
engine,
which
is
the
thing
that
will
capture
all
the
snapshots.
It
will
capture
all
the
kubernetes
yaml
and
that
part
could
be
everywhere
and
then
having
a
layer
that
is,
policy,
scheduling,
dashboard
kind
of
stuff
which
would
be
swappable.
J
I
said
a
good
question
and
I
wonder
if
it
makes
sense
in
this
context
to
think
about
maybe
even
decoupling,
some
of
this
from
the
valero
server
pod.
You
know
some
something
along
the
lines
of
you
know:
cucutal,
backup,
little
restore
kind
of
thing
where
you
run
that
kind
of
stuff,
not
as
a
running
server
pod,
even
as
kind
of
one-off
operations.
J
So
I
don't
have
a
whole
lot
on
that.
I'm
just
one
of
the
things
that
we
were
thinking
about
is
even
talking
about.
Maybe
you
know
decoupling
some
of
this
from
having
having
to
have
a
running
server
kind
of
all
the
time,
for
you
know
occasional
use.
Even
obviously,
if
it's
your
backup
solution
that
you're
wearing
scheduled
backups,
you
still
need
the
server,
but
for
for
kind
of
one-off
use.
So
back
up
this
namespace
here,
restore
it
there.
It
might
be
interesting
to
be
able
to
run
some
of
this
client-side.
E
To
do
is
look
more
towards
putting
like
snapshotty
type
apis
into
the
various
components.
So,
like
you
know,
we
have
the
example
here
in
csi
volume
snapshots.
So
we
can.
We
can
write
a
cr
to
say
snapshot
this
volume
and
the
csi
driver
takes
care
of
it.
I'd
like
to
see
us
going
in
a
similar
direction
for
operator
driven
applications
and
even
the
kubernetes
api
server,
so
that
we
can
eventually
say
something
like
snapshot
this
kubernetes
cluster
and
it
goes
and
triggers
you
know:
csi
snapshots
volume
snapshot.
E
You
know
application
snapshots,
you
know
tars
up
all
of
the
ref,
all
the
resources
together
and
puts
it
some
place
that
we
can
access
as
a
snapshot.
So
you
could
say,
cube
cuddle
snapshot
this
cluster
or
this
name
space,
and
then
you
could.
You
know
copy
that
snapshot
someplace
else
or
restore
from
that
snapshot.
E
So
that's
kind
of
where
I
see
us
going
so
we'll
break
out.
I
don't
think
we're
going
to
pull
the
code
into
something
that
just
runs
client-side
because
ultimately,
we'd
like
to
have
the
api
server
actually
be
involved,
so
that
we
can
get
things
like
consistent
backups
of
kubernetes
resources,
so
that
the
you
know
the
api
server
actually
does
a
proper
snapshot
of
itself.
F
Yeah-
and
this
would
give
clean
extension
points
to
valero
and
like
storage
application,
vendors
don't
have
to
implement
whether
or
plugins
for
their
application
running
in
kubernetes
to
be
backed
up
if
they
already
have
a
way
to
back
their
back.
Their
application
up.
All
valero
has
to
do
is
like
identify
those
crs
and
like
trigger
those
trigger
the
backups
for
the
data
storage.
B
B
B
B
Yeah,
these
were
all
genting.
Who
is
our
external
maintainer.
He
was
adding
himself
to
the
rest
of
the
repositories
for
maintainership
something
we
forgot
to
do
so.
Thank
you,
genting,
aside
from
that,
he
updated
some
documentation.
I
believe
this
documentation
around
helm,
v2
deprecation,
so
helm
v2
was
deprecated
last
year
and
please
upgrade
if
you
can
but
valero
the
valero
chart
we're
trying
to
focus
on
helm
v3
from
our
current
standpoint,.
B
D
B
D
The
shout
outs
for
people
who
add
answers
to
our
q
a
section
and
there
is
a
link
that
title
has
a
link
to
that
to
the
exec
to
that
page
on
github.
Today,
I'm
only
dumping
a
screenshot
of
the
most
helpful
answers.
I
went
through
like
the
all
the
answers
on
the
first
page,
and
it
was
mostly
all
of
us
but
going
forward.
I
want
to
be
listing
answers
from
like
individual
individual
shout
outs
for
individual
answer
contributions,
but
we
didn't
have
anybody
from
outside
of
us
the
maintainers
anyway.