►
Description
March 2, 2021
Status Updates - items working towards roadmap
bridget
Multiple credentials support
Adding docs and E2E test
Need one more approval on PR 3442, this will unblock PR 3489
nrb
Not a lot of progress on roadmap last week, dealing with internal TKG builds
ashish
Working on making e2e tests as part of our release pipeline.
dave
Discussion on upload progress monitoring
Working on reviewing outstanding feature backlog
Discussion Topics
What was the outcome/progress from last week’s discussion topics?
Findings for what happens when a resource is in multiple API groups when processed by a custom plugin - new documentation merged in #3498
v1.7.0 rough roadmap
Velero debug support, based on crashd
Trying to get CSI snapshot support to GA
Plugin versioning
Snapshot upload progress
Manifest data structure
Distroless container base image to reduce attack surface
Velero Carvel installation
More detailed test plan; get more thorough in what we’re actually looking for out of tests
Contributor Shoutouts (PRs and Discussions)
@codegold79: Update in-code documentation to show resources can be specified with group name
@slavina-rumenova: Adding check if disk description is empty
@justbert: Add documentation around minimum required permissions
@tareqhs: [velero] customize client-qps and client-burst
@peterekhator: [velero] feat: add nodeselector for restic
@cyril-corbon: [velero] feat: add annotations for velero deployment and restic daemonset
@codegold79: [Velero] Add velero component label and update docs
A
Hello,
everyone
and
welcome
to
the
valero
community
meeting,
slash
open
discussion
today
is
march,
2nd,
2021
or
march
366
2020,
depending
on
how
you're
counting
so
welcome
everyone
to
another
march.
We
we
hope
this
one
will
be
a
little
less
stressful
than
the
last
march
we
had.
Today.
We
got
some
status
updates,
we'll
see
if
we
get
some
discussion
topics
and
then
we
have
a
ton
of
awesome
contributor,
shout
outs.
So
let's
get
started
with
bridgette.
B
Hi
everyone,
so,
for
the
last
week
I've
been
continuing
to
work
on
multiple
credential
support.
I
think
I
have
most
of
the
code
changes
in
place,
but
the
focus
is
getting
the
docs
and
et
tests
written.
I
was
slightly
blocked
and
interrupted
this
week
due
to
some
internal
build
issues
that
we
had
now,
which
nolan
has
mentioned
as
well,
but
I
already
carlysi
has
already
done
some
reviews
on
the
existing
pr's
that
are
there
so
there's
one
in
valero
which
she
is
approved.
B
B
C
B
Yeah
it's
in
draft
because
there's
no
point
in
reviewing
it
until
the
other
one
goes
in
because,
but
I
figured
that
if
there
were
changes
required
on
the
the
earlier
one
they
would
they
would
cause
changes
in
this
one
as
well.
So,
rather
than
getting
people
to
review
this
one
as
well,
I
mean
they
can
in
case
there's
something
else,
but
I
figured
it'd
be
best
just
to
get
the
other
one.
In
first.
C
Yeah
so
last
week
I
did
not
get
a
whole
lot
of
progress
on
upstream,
as
bridget
mentioned,
we
were
both
looking
at
some
internal
tkg
build
issues.
Basically,
tkg
is
getting
ready
for
its
1.3
release
and
we
had
to
make
sure
all
the
valero
repos
were
up
to
snuff
in
our
build
that
took
a
couple
days,
so
I
did.
A
C
D
D
A
E
D
C
Infrastructure-
and
I
am
speaking
with
the
tkg
release
team-
to
get
that
set
up
so
that
we
can
have
one
pipeline
that
feeds
into
github,
but
that's
really
early
days
and
they're
they're,
not
quite
ready
with
all
the
networking
permissions
and
things
like
that.
There's
yeah
certain
certain
things
they
need
to
be
on
the
internal
network
for
and
they
don't
want
to
expose
the
internet.
So.
A
E
So
one
of
the
things
that
we've
done
in
the
past
so
like
the
vsphere
plug-in,
has
internal
test
infrastructure.
That's
triggered
by
updates
to
github.
So
any
new
changes,
for
example
that
come
in
any
pull
requests
actually
get
run
through
the
tests
automatically
and
the
output
of
the
test
is
returned
to
github.
E
So
I
think
that's
the
direction
we
want
to
go
in
now.
You
know
the
the
infrared
to
like
spin
up
a
cluster
all
that
stuff.
That
actually
requires
things
like
credentials,
which
I
don't
think
we're
ever
going
to
put
public,
because
that
means
that
you
could
use
our
credentials
to
spend
money.
So
we're
not
going
to
do
that.
We
will
try
and
make
as
much
of
this
stuff
available
like,
for
example,
tkg
is
open
source,
and
so
if
we
can
build
things
that
work
around
tkg,
someone
else
can
use
their
credentials
to
run
things.
E
A
E
F
G
E
The
plug-in
you
can
just
push
another,
you
know
you
can
just
you
know,
push
a
change
to
your
pull
request
and
it
reruns
the
tests,
but
also
it
should
be
very
easy
to
run
these
tests
locally
or
in
a
cluster
of
your
own,
so
that
that
would
really
be
the
goal.
Is
you
should
be
running
the
test
before
you
submit
the
full
request,
so
there
shouldn't
be
any
surprises.
C
C
E
Yeah,
what
might
be
interesting
is
look
at
things
like,
for
example,
we'll
be
testing
against
the
resources
and
and
clouds
that
we
target,
but,
for
example,
we're
probably
not
going
to
set
up
an
openshift
cluster
to
test
against.
But
if
that's
something
that
red
hat
was
interested
in
doing,
I
don't
see
why
we
couldn't
tie
that
into
our
github
pipeline,
so,
for
example,
rem
tests
against
the
visa.
You
know
the
the
vmware
set
of
tests.
Let's
kick
off
a
set
of
tests
in
red
hat
infra
and
pull
all
the
results
back
together.
D
E
C
B
G
F
F
E
E
C
Yeah,
the
earlier
plan
was
to
take
valero,
install
and
kind
of
split
it
up
and
deprecate
the
literal
valero
install
command,
but
we
would
still
have
some
sort
of
installer
that
would
place
bits
in
there
and
let
you
configure
I'm
actually,
I
put
an
item
in
for
the
roadmap
discussion
on
like
what
we're
currently
thinking
on
that.
But
the
tldr
right
now
is
to
to
make
it
based
on
karvel,
which
is
a
another
vmware
open
source
project.
There's
other
other
people
here
at
vmware.
C
Working
on
that
kind
of
thing,
so
it
probably
will
be
a
wrapper-
is
what
I'm
envisioning
right
now,
but
we're
kind
of
looking
for
ways
to
reduce
the
number
of
ways
to
install
it
while
still
giving
everybody
the
options.
So
if
we
have,
if
we
have
a
carnival
way
and
a
helmway,
that's
probably
pretty
dang
good.
So
yes,
we're
we're
going
to
whatever
whatever
the
new
thing
is,
whether
it's
the
literal
string,
valero
install
or
something
else
that
will
be
part
of
the
end-to-end
testing
for
how
it
gets
installed.
F
C
A
E
Yeah,
so
we
had
a
a
really
good
discussion
last
week
on
the
upload,
progress
monitoring,
and
so
that's
good.
So
I've
got
to
take
that
feedback
and
get
some
research
to
do,
and
some
updates
to
the
doc
and
some
thinking
about
different
paths
to
take
there
and
then
this
week,
yeah
working
on
that
working
on
going
through
and
just
reviewing
all
the
feature,
requests
and
trying
to
start
marking
down.
A
C
Yeah,
so
I'm
going
to
get
some
links
here,
just
one
second.
So
the
first
item
I
have
on
here-
I
think
folks-
may
have
heard
us
talking
about
a
valero
debug
command,
and
there
is
an
issue
for
this.
I
don't
have
a
number
off
the
top
of
my
head,
but
this
is
also
something
valero.
Support
really
wants.
So
all
right,
not
the
layers
vmware
support.
So
we
have
this
big
list
of
commands.
C
You
can
run
to
do
troubleshooting
and
things
like
that,
but
internally,
here
at
vmware
we
have,
I
guess
not
internally
as
part
of
the
tanzu
open
source
portfolio.
We
have
this
crash
diagnostics
program
and
what
this
is
is
a
runner
for
starlark
which,
if
you're
familiar
with
basil
or
bazel,
the
build
engine,
it's
a
dialect
of
python
that
google
made-
and
this
basically
allows
you
to
run
local
commands
and
grab
the
the
output.
C
So
we
can
do
things
like
valero
debug
or
I'm
sorry,
valero
version
to
grab
all
the
versions
of
valero
we.
It
has
functions
in
there
to
automatically
grab
stuff
out
of
the
kubernetes
system.
You
can
also
run
commands
directly
against
the
nodes
themselves.
If
you've
got
them,
so
we
were
looking
at
valerio's
debug
we're
going
to
write
it
and
then
realized
crash
d.
Does
everything
we
want
so
why?
Why
reinvent
the
wheel
so
we're
thinking?
We
have
a
star
script
already
and
we're
thinking
with
one
seven.
C
C
The
next
item
we're
really
heavily
considering
this
this
one,
maybe
a
little
bit
more
controversial
or
not
done
in
170,
but
getting
valero's
own
csi
snapshot
support
to
ga
with
kubernetes.
I
believe
it
was
120
csi
snapshotting
is
now
ga
in
kubernetes,
so
we're
going
to
try
to
do
some
more
polishing
and
move
valero
closer
to
ga
on
snapshot
support
next,
a
big
one
that
we're
having
some
other
design
like
we're.
C
Having
at
least
three
other
designs
stack
up
behind
this
one
is
getting
plug-in
versioning
done
and
by
the
way
this
is
not
in.
This
is
not
necessarily
in
priority
order
right
now.
This
is
kind
of,
as
I
thought
of
them
so
plug-in
versioning,
allowing
valero
to
provide
version
info
about
the
plugin
api
and
allowing
plugins
to
say
this
is
the
plugin
api.
I
support
that
way.
C
C
Okay,
the
next
thing
is
snapshot
uploading
progress,
so
this
is
a
design
that
dave
was
just
talking
about
where
we
can
upload
snapshots.
In
the
background,
this
is
particularly
useful
for
on-prem
scenarios
like
vsphere,
I'm
sure
if
there
was
a
step
driver,
it
could
use
that
as
well,
but
we've
already
got
a
design
out
for
that.
C
C
C
E
C
Nice
cool-
and
these
are
these-
are
like
the
google
distro
lists,
so
we
don't
have
to
it's
not
just
plain
scratch,
because
just
plain
scratches
include
stuff
like
time,
zone
data
or
search
search,
certs,
and
you
etsy
password
that
kind
of
stuff.
So
it's
it's
a
it's
disturbless,
but
it's
still
like
unixy,
not
it's
not
just
scratch,
which
is
basically
a
tarball
that
docker
can
install
and
going
back
to
the
valero
install
discussion.
C
We
are
looking
at
ways
to
use
carvel
for
valero
installation.
Part
of
the
reason
I
mentioned
we
wanted
to
do.
A
wrapper
command
was
so
that
folks
didn't
have
to
install
all
of
carvel
we're
gonna,
but
we're
gonna
work
with
the
carvel
team
and
some
other
folks
here
at
vmware.
To
make
sure
this
we
can
install
valero
without
having
to
install
like
carvel
on
your
own,
like
a
local
command.
A
E
C
C
If
folks
were
familiar
with
that,
so
this
this
stuff
was
adopted
by
vmware
and
we've
got
a
it's
got
a
whole
suite
of
utilities
for
doing
kubernetes,
building
and
installation
and
templating
and
stuff
like
that
and
I'll
take
I'll
do
one
more
item,
then
we
can
open
up
for
questions.
Something
dave-
and
I
were
talking
about-
is
also
making
a
more
detailed
test
plan
that
enumerate
this.
This
is
separate
from
the
actual
tests
themselves,
but
just
saying
a
document
that
says
this
is
what
we
test.
C
This
is
the
matrix
we
test
of
kubernetes
versions,
kubernetes
versions
to
valerio
versions,
to
whatever
dimension
we
need
to
put
on
there,
but
getting
a
lot
more
specific
on
what
we
need
to
test
and
like
what
scale
like
how
many
objects
we're
generating
and
how
many
volumes
are
backing
up
and
things
like
this.
So
we
want
to
get
better
at
polishing
that
up
so
that
folks
can
rely
on
valero
as
an
enterprise
solution.
C
C
F
E
Right
that
was
pretty
much
just
an
artifact
of
the
way
the
tests
were
written
first
round,
and
I
was
going
to
take
that
out
except
that
for
frankie's
stuff
right
now
that
relies
on
a
feature,
flag,
yep
and
so
until
the
feature
flag
is
gone,
we're
gonna
need
to
install
and
uninstall
to
run
the
the
resource
version
group
api.
So
that's
why
it's
doing
it
for
the
moment
long
term
you're
right.
It
should
be
like
before
the
suite
it
should
install
valero
and
then
do
a
bunch
of
stuff
and
then
uninstall.
D
F
B
B
F
D
I
get
that
point,
but
the
test
writers
are
going
to
be
different.
The
tests
that
you
write
may
kind
of
conflict.
The
tests
that
I
may
write,
or
somebody
else
may
write
so
that
kind
of
that
would
require
some
level
of
coordination
and
and
like
especially
with
things
like
feature
flags
to
test
different
modes
of
weather
or
it
it.
D
E
E
The
test
they
may
leave
hanging
around
is
also
bad,
so
I
think
we
should
look
at
probably
having
an
option
for
both
and
doing
runs
where
valera
gets
installed,
always
where
valero
gets
installed
most
the
time
with
a
flag,
maybe
for
certain
tests
that
say
no,
I
absolutely
positively
need
a
clean
environment
or
I
need
a
feature
flag.
So
therefore,
I
need
to
have
it
installed.
Uninstalled.
Those
are
all
welcome
additions
and
you
know
ideas.
I
think.
D
Yeah,
I
think
the
way
we
have
it
right
now
is
is
good,
giving
giving
everyone
the
flexibility
of
either
choosing
whether
to
be
preserved
throughout
the
running
of
the
tests
are
like
we
installed
before
and
after
each
test.
I
think
what
what
we
have
is
good
in
from
my
perspective,
but
happy
to
stand
corrected.
F
Yeah,
I
think
I
was
just
gonna
advocate
for
something
kind
of
what
dave
is
saying,
which
is
do
something
similar
to
what
kubernetes
does,
which
is.
You
know
you
have
some
tests
that
are
cereal
and
you
have
some
tests
that
are
paralyzed
and
the
serial
tests
need
to
be
run
one
after
the
other,
but
the
paralyzed
test
could
be
running
any
order,
and
that
would
be
probably
how
I
would
advocate
that
we
would
do
that.
E
F
F
C
C
This
suite
is
installed
with
this
set
of
arguments
and
we
want
to
run
it
in
a
purposely
entangled
way
and
we
can
also
so
we
could
say
install
this
with
this
set
of
flags
and,
and
things
run
all
these
tests
inside
of
that,
so
we
can,
we
can
group
it.
We
should
be
able
to,
I
hope,
to
say
this.
Suite
is
installed
with
this
set
of
components
and
flags,
and
this
other
suite
is
installed
with
this
other
set
and
this
week
we
wipe
it
every
time
and
do
it.
C
F
F
E
So
vis-a-vis
the
roadmap
itself,
so
I
think
we
want
to
start
getting
in
a
little
more
formality
in
terms
of
the
stages
of
when
things
go
in
so
like
we're
at
the
point
right
now
where
we
really
reckon
you
know
like
if
there
are
community
planned
features
and
so
forth,
this
is
a
great
time
to
bring
them
up
and
say:
hey.
You
know,
we'd
like
to
get
this
into
the
one.
E
Seven
release
get
it
onto
the
roadmap
here
we're
going
to
have
a
I'll
publish
out
where
what
the
different
phases
of
the
release
process
are
going
to
be,
but
we
will
have
a
point
in
time
where
we
say
you
know
what
that
feature
is
not
on
the
roadmap.
Thank
you
for
your
pull
request.
That's
going
to
go
into
the
next
release,
so
we're
going
to
try
and
get
some.
You
know
control
over
or
you
know
just
you
know
some
structure
around
when
things
come
in
and
make
that
make
everybody
aware
of
when
that's
happening.
E
C
Yep
and
kind
of
to
dave's
point
we're
thinking
about.
So
it's
it's
no
secret.
We've
we've
delayed
one
six,
a
bunch.
So
in
order
to
kind
of
fix
that
going
forward,
I
think
we're
going
to
look
at
establishing
a
date
and
having
that
date,
be
it
cut
off.
If
stuff
is
not
complete
by
that
date,
then
it
just
goes
in
the
next
one.
It
goes
in
a
patch
release.
You
know
it
does
not,
so
we
can
get
better
about
shipping
consistent
releases.
C
D
A
D
C
So
I
so
dave-
and
I
are
really
trying
to
get
a
meeting
with
our
manager-
that's
basically
been
kicked
around
for
a
bunch
of
different
reasons.
Last
week
we
were
going
to
meet
about
this
last
week
and
I
was
really
hoping
to
have
something
much
much
firmer
by
today,
but
we
had
the
the
build
issues
that
came
up.
I
want
to
give
a
little
buffer.
I
would
really
want
the
roadmap
to
be
pretty
much
finalized
by
the
end
of
march.
If
not
sooner
I
mean
that's.
C
That,
admittedly,
is
a
long
time,
but
just
based
on
how
things
have
been
going
I'll,
also
say
march
15th
we
have
a
new
pm
joining
the
team,
so
that
will
help
us
get
a
little
bit
more
structure
around
this.
But
I
would
say
if,
if
you
have
something
you
want
to
contribute
to
valero
in
the
v17
timeframe,
please
let
us
know
on
slack
github
discussions
make
an
issue
some
something
like
that,
raise
it
to
our
attention.
C
A
C
C
Okay,
so
for
the
contributor
shoutouts
got
a
bunch
from
frankie
and
I
did
not
organize
them,
but
I'm
going
to
do
the
first
and
then
and
the
last
one.
So
this
first
one
was
documentation
about
the
selection
criteria
when
you,
when
you
define
a
and
applies
to
function
on
your
plugins,
so
this
just
says
make
sure
you
use
a
fully
qualified
name
for
disambiguation
and
the
other
one.
C
That
was
the
discussion
topic
from
last
week
and
this
change
makes
the
the
helm
chart
closer
to
how
valero
install
works.
So
we're
kind
of
we
had
two
sets
of
labels
for
the
helm.
Chart
did
one
and
and
valero
installed.
Another
this
make
sure
that,
at
the
very
least
they
have
the
component
equals
valero
label
on
both.
So
thank
you
very
much
frankie
for
both
of
those
changes.
They're
super
helpful.
C
This
next
one
was
from
slovena,
and
this
was
in
order
to
prevent
gcp
disks
from
being
marked
partially
as
failed
as
partially
failed.
So
this
basically
makes
snapshotting
on
gcp
a
little
bit
more
reliable
and
at
the
very
least,
giving
us
more
information,
but
it
passes
down
valero
tags
and
yeah.
It's
a
change
specifically
to
gcp,
not
to
the
rest
of
valero.
C
C
This
one's
from
turak
tarek
tarik
on
the
helm
chart
and
the
qp
the
client,
I
believe
it's
queries
per
second
and
burst
rate.
This
allows
for
more
tuning
of
those
via
the
helm
chart,
and
these
are
this
is
helpful
because
there
are
some
performance
issues
that
you
can
run
into
on
the
kubernetes
api
server,
where,
if
your
gps
and
burst
rate
are
too
low,
it
will
report
errors
in
finding
resources.
So
this
this
allows
for
better
scaling
and
for
better
tuning
for
your
particular
api
server.
C
I
think
these
are
mostly
helm
charts
this
one.
I
did
not
get
a
chance
to
look
at
before
the
meeting,
so
I
think
this
excuse
me
is
to
ensure
placing
no
rustic
on
the
correct
nodes
on
the
rustic
damon
set,
rather
than
just
throwing
it
everywhere.
So
thank
you
very
much
peter
and
then
finally,
another
helm,
chart
edition
looks
like
cyril
added
the
ability
to
annotate
all
of
the
valero
components,
the
especially
the
deployment
and
daemon
set,
which
it
can
be
helpful
depending
on
how
your
deploying
environment
looks.