►
From YouTube: Velero Community Meeting/Open Discussion - Feb 18, 2020
Description
Feb 18, 2020
Agenda
-------
Status Updates
[steve]
returning from 4-day weekend
on community support this week
[carlisia]
Have yaml files that get installed with kustomize working
Had a meeting to go over kutomize and questions:
Next step: getting updates to be patched w/ kustomize
Need to catch up with PR reviews today
[nolan]
Two CRD proposals up on PR https://github.com/vmware-tanzu/velero/pull/2264
Returning to CSI testing with Ashish this week
[ashish]
making progress on the velero plugin for CSI
PRs to switch to go modules
PR incoming for the backup flow.
Release from plugin repos to switch from nobody:nobody to nobody:nogroup. Current beta release of Velero is incompatible with the existing releases of the plugins in certain linux distros.
Discussion Topics
------------------
[steve] v1.3.0 status
need to finalize approach for https://github.com/vmware-tanzu/velero/pull/2264
[m2] Discuss cleanup request https://github.com/vmware-tanzu/velero/issues/1977
[m2] Update on custom CA support https://github.com/vmware-tanzu/velero/pull/2259
A
All
right
so
welcome
everyone
to
the
weekly
Valero
community
meeting
today
is
Tuesday
February
18th
thanks
a
lot
for
joining
everyone.
I'm
gonna
go
ahead
and
share
the
agenda
and
we'll
get
started
with
some
status
updates
and
just
a
reminder,
while
I'm
doing
that
that
this
will
be
posted
on
YouTube
afterwards
for
for
public
viewing.
A
A
The
point
person
for
community
support
this
week,
so
mostly
gonna,
be
spending
my
time
over
the
next
day
or
two
just
catching
up
with
all
the
goings
on
in
slack
and
github
and
hopefully
checking
in
on
the
PR
that
no
one
has
around
CRD
backup
and
restore
which
we'll
get
to
more
in
a
bit.
So
that's
that's
about
it
for
me,
in
this
section,
so
I'll
pass
it
off
to
curly
SIA.
B
But
it's
not
working
out
pasted
here
later
and
I
also
placed
a
link
to
the
YouTube
video
that
we
recorded
for
that
meeting
on
the
issue
actually
on
the
PR
I'm
on
the
Windows
machine
right
now,
it's
don't
anyway.
The
place
is
right.
There
is
just
not
working,
so
that
is
how
so
I
gather
the
cr-z
is
cleaned
up.
They
deploy
fine
with
customize
and
excuse
me,
my
next
thing
is
to
get
it
to
get
the
deployment
patched.
B
So,
for
example,
if
I
have,
if
I
do
a
little
in
it,
install
the
server
deployment
and
then
if
later,
when
I
want
to
do
add
a
plug-in,
for
example,
that
is
to
patch
the
deployments
so
right
now,
if
I
just
run
the
plug-in
CIT,
the
cr-z
that
would
install
the
plugins,
it
was
just
overwrite
an
appointment.
That's
there
so
I
put
customize
has
a
feature
to
patch,
and
hopefully
everything
is
going
to
work,
so
I
need
to
test
that
and
I
need
to
catch
up
with
PRS,
because
I
sort
of
neglected
PR
reveals
less.
C
C
Excuse
me
and
I've
got
a
PR
up
with
two
proposals
for
getting
those
CRTs
there's
two
fixes.
The
quick
summary
of
them
is
the
first
one
well
going
in
order
that
they
are
on
the
PR.
The
first
one
retains
the
version
one,
but
adds
the
missing
fields
that
API
server
complains
about
it.
Just
it
just
adds
the
keys,
but
it
doesn't
populate
them,
so
it
adds
the
schema
to
start
scheming,
appeals,
but
doesn't
actually
build
a
schema
for
you
and
then
the
second
one
changes.
C
The
version
feels
to
be
one
beta
one,
but
keeps
the
extra
fields
that
got
added
in
the
up
conversion
of
the
upgrade
webhook.
So
it
has
part
of
the
upgrade
to
be
one.
Kubernetes
adds
some
fields
like
the
versions
list
and
that
PR
has
like
a
diff
of
what
what
comes
out
of
the
one
API,
it's
still
compatible
with
me,
1
beta
1,
so
it
won't
be
exactly
what
was
submitted,
but
it
will
be
restorable.
C
So
as
far
as
my
testing
goes
both
of
those
those
proposals
work
in
terms
of
restoring
so
that
they
both
unblocked,
if
you
that
Genting
had
reported
mostly
looking
for
feedback
from
the
core
team
and
others
as
to
which
one
is
preferable
so
far,
Genting
and
Steve
have
preferred
the
changing
to
v1
beta
1
and
not
keeping
the
1
version.
So
the
rest
of
the
week
has
been
some
internal
stuff
and
working
on
reviewing
the
install
work.
That
release
has
been
working
on
and
then
this
week,
I
hope
to.
D
C
She's
just
been
doing
more
of
it,
so
I
should
probably
defer
to
him,
but
really
it's
been
making
sure
that
the
Valero
CSI
plugin,
that
we
have
now
works
with
host,
pastor,
I
host
path
driver,
since
that's
the
only
one
that
supports
the
v2,
API
s4
snapshotting
currently
and
then
in
implementing
our
work
stream.
We
have
several
issues
that
we
need
to
get
it
to
beta
level
support,
because
we
know
the
the
current
plug-in
is
proof-of-concept
lovable.
So
we
need
to
there's
several
fixes.
We
need
to
make
on
it.
A
A
Fixative
merits
getting
a
second
beta
out
for
folks
to
test,
so
we
can
plan
on
doing
that
and
we
had
one
or
two
other
small
fixes
that
have
gone
in
since
we
released
the
first
beta
so
we'll
get
to
push
all
those
out
into
beta
and
get
a
little
bit
of
testing
on
it
before
we
move
on
with
the
1.3
release,
all
right.
Moving
on
to
Ashish.
E
Plugin
for
Valero
I
kind
of
I
have
a
environment
that
I
can
setup
that
with
like
no
problems
using
kind
and
the
necessary
CSI
driver
controllers
and
all
the
necessary
parts
and
the
right
order.
I
have
verified
that
the
CSI
workflow
kind
of
works
now
I'm,
just
kind
of
going
back
and
reading
up
on
Nolan's
initial
design
that
he
had
the
backup,
workflow
kind
of
makes
sense.
E
I
have
a
few
questions
around
some
of
the
field
names,
but
everything
was
pretty
straightforward,
so
I'm
probably
going
to
be
able
to
get
that
into
a
PR
sometime
today
or
tomorrow,
and
then
start
start
working
on
the
restore
workflow.
So
that's
that's
the
idea
at
least
for
for
me,
the
other
stuff
is
I,
have
a
PR
to
switch
to
go
modules.
I
didn't
see.
Another
I
didn't
see
before
I
kind
of
made
progress
on
this.
E
There
was
another
PR
to
do
the
same
thing,
but
there
was
some
some
areas
where
the
uglier
PR
did
not
address.
That
was
around
like
making
sure
the
agro
module
files
are
up
to
date
and
stuff
like
if
you
are
making
a
change
and
then
you
introduce
a
change
to
the
go
mod
and
go
some
and
you
forget
to
check
it
in
that
will
kind
of
break
the
build
for
other
people
who
don't
have
that
same,
updated,
go
module
files,
so
that
will
I
also
have
that
verification
built
into
the
CI.
E
A
So
I,
just
on
that
last
thing,
I
think
we
can.
You
know
we
can
definitely
cut
a
release
of
those
I
think
that
issue
is
isolated
to
a
specific
environment.
It's
not
a
general
issue.
It
works
yeah.
They
were
trying
on
on.
You
know
AWS
as
your
GCP,
but
you
know
no
harm
and
cutting
her
Elise
to
fix
it
for
that
specific
environment,
yeah.
E
A
E
Those
have
been
updated
to
use
the
V
1
beta,
1
API
guys,
but
there
it
is
like
super
experimental.
There
was
a
lot
of
some
things.
It
kind
of
works
in
certain
flows.
It
president
right
work
always
and
also
it
doesn't
back
up
the
the
backups,
don't
regenerate
the
the
volume
snapshot
class
and,
like
the
other
volumes
natural
objects
that
we
also
want
to
back
up,
which
are
essential
for
the
validity
of
the
backup
and
also
for
like
the
backup
and
restore
to
work.
E
A
A
E
A
C
A
A
I
would
hope
that
we'd
be
able
to
release
the
1.3
release
roughly
a
week
after
that
beta
comes
out.
So
you
know,
I
think
the
current
timeline
probably
looks
like
the
1.3
release
coming
out
next
week-
probably
the
second
half
of
next
week,
and
hopefully
with
the
beta
in
the
next
day
or
two.
The
second
beta.
D
Sure,
as
you
guys
know,
I'm
only
able
to
attend
the
first
half
an
hour
of
these
calls.
So
I
know
that
last
week
we
let
me
start
on
the
last
item.
The
customs
here
support
from
Dylan
and
raha
ting
I
know
the
the
ticket
is
there
and
Nolan
and
Steve
and
and
others
have
started.
Commenting
on
that.
Is
there
an
update
on
basically
setting
on
what
the
design
will
look
like
before
the
implementation
starts,
or
are
you
guys
still
something
that
you're
a
new
team
over.
A
D
A
D
D
You've
heard
that
from
a
few
folks
in
the
community
already
that
this
is
problematic
for
some
of
their
scenarios
for
different
reasons,
so
I
see
this
kind
of
s,
not
one
issue
but
like
three
different
issues.
The
first
issue
is:
what
happens
when
you
find
a
part
that
already
exists,
but
you
also
need
to
restore
it.
And
what
do
you
do?
There
is
velaro.
D
So
you
know,
all
of
those
things
are
super
important
and
you
know
and
I
see
that
there's
a
need
for
all
of
these
at
different
customers.
My
viewpoint
is
I.
Think
that's
something
that
we
should
discuss
and
obviously
see.
If
everyone
agrees
is
that
we
should
do
a
couple
of
things.
The
first
one
is
put
a
new
flag
in
Valero
so
that
we're
no
restoring
if
the
pot
already
exists
or
an
artifact
already
exists.
It
allows
us
as
well
era
to
override
it
rather
than
don't
touch
it,
which
is
what
we
do
today.
D
I
think
from
a
from
a
functionality
standpoint,
that's
something
that
other
backup
tools,
I've
seen
over
the
years
do,
and
some
of
them
actually
went
to
that
silently.
But
the
thing
will
offer
the
operator
of
Valero
the
opportunity
to
make
a
decision
on.
What
does
you
wanna
do
this?
You
wanna
stay
with
a
consistent
system
based
on
the
time
of
backup
or
a
mixed
system,
where
you
have
some
items
from
before
restore
and
some
items
after
restock,
which
my
opinion
might
be
a
little
bit
more
dangerous.
D
So
so
that
was
number
one
recommendation.
The
second
one
is
when
we
restore
into
an
in-space
that
already
exists,
items
that
we
haven't
touched
and
items
that
already
pre
existed,
potentially
spit
out
a
Yama's
script,
that
someone
can
execute
to
delete
those.
We
don't
delete
them
automatically
as
velaro.
That's
not
the
responsibility
we
take,
but
we
can
actually
identify
all
the
items
of
Valero
did
not
touch
in
the
namespace.
If
someone
wanted
to
clean
it
up,
they
could
do
that
on
their
own
by
executing
the
script
and
I
think
Nolan
kind
of
recommended
something
similar.
D
C
So
I
think
the
facility
for
doing
that
exists.
So
thinking
about
the
restore
code,
we
definitely
log
something.
When
we
say
we
see
hey,
we
try
to
restore
this
so
I
guess.
Let
me
back
up
there's
a
couple
different
cases.
We
try
to
restore
something
and
it's
already
there,
so
we
can
recognize
that
what
we
don't,
what
Valero
currently
doesn't
really
have
any
way
of
knowing
about
is
when
something
is
already
in
the
cluster,
but
not
in
the
backup,
because
we
don't
do
a.
C
We
don't
query
kubernetes
at
this
point,
so
god,
okay,
so
the
only
the
only
way
we
get
currently
get
information.
Is
we
take
its
it's
recorded
as
JSON,
but
it
could
be
a
more
whatever
we
take
a
document
out
of
the
backup,
give
it
to
kubernetes
api
server
and
it'll,
say:
hey
it's
already
there,
and
so
we
record
that
and
in
the
log
we
don't
say,
hey,
what's
everything
in
the
in
the
namespace?
What's
everything
in
the
server
we
could.
D
C
We
could
use
the
we
could
use
a
flag
that
we
get
passed
down
where,
if,
if
you
specified
this
flag-
which
I
think
is
kind
of
like
a
variation
on
this,
where
we
say
instead
of
just
logging
it
we
say
when
is
it
when
you
get
a
thing
saying
it
exists
already,
instead
of
just
logging,
it
delete
it
and
then
recreate
it.
I
think.
That's
we
more
realistic,
I,
don't
know
exactly
what
that
flow
would
look
like,
though,
and
there's
also
the
issue
of
finalized
errs
and
cascading
deletes
that
make
it
tricky
yeah.
A
We'll
also
will
need
to
think
about
you
know
with
with
deletions
what
does
it
mean
as
far
as
dependent
items?
So,
for
example,
if
you
know,
if
you're
trying
to
restore
a
PV
and
it
already
exists
in
the
cluster
and
you
try
to
delete
that,
PV
it'll
probably
be
deleted
by
the
object
and
use
protection,
which
means
you
know,
we
can't
actually
delete
the
PV
without
first
deleting
the
pod,
that's
using
it
and
then
the
PV
C,
and
so
you
know
that
scenario
gets
it's
complicated
quickly.
A
So
we
definitely
need
to
have
kind
of
a
general
strategy
for
how
to
deal
with
those
kind
of
chains
of
dependent
items.
In
this
scenario,
yeah
absolutely
I
mean
I.
You
know
I
I've
kind
of
always
said
that
in
concept
I,
like
I,
think
this
feature
request
makes
sense.
I
I
would
like
to
have
this
feature.
I,
just
you
know
want
to
make
sure
we
take
the
time
to
think
through
these
the
kinds
of
nuances
of
these
scenarios.
A
It
also,
you
know,
gets
like
it's
relatively
straightforward
when
you're
talking
about
the
backup
or
restore
of
either
a
single
namespace
or
a
or
the
whole
cluster,
but
when
you
start
mixing
in
label
selectors
and
excluded
resources
and
custom
resources
and
various
things
like
this,
that
Valero
allows
you
to
filter
on.
It
gets
much
more
complicated
to
know
kind
of
what
needs
to
be
cleaned
up.
D
E
Yeah
I
will
I
was
just
going
to
say
that
if
we
are
going
to
have
a
slide,
is
it
I
think
it
makes
sense
to
have
a
fly
enabled
from
the
client
answer
and
get
that
flag
passed
through
to
the
server
to
allow
like
to
do
this
on
a
per
request
basis,
instead
of
like
one
general
mode
of
operation?
That
is
that
the
program
started
in
so
I
think
we
for
that.
E
A
Yeah
I
I
agree
that
you
know
this
should
be
something
that
you
can
change
the
behavior
of
on
a
quest
basis.
I
would
think
it
would
just
it
would
be
new
API
fields,
probably
on
the
restore
object
so
yeah
we
would
set
those
fields
just
like
we
do
any
other
fields.
Basically,
flags
that
you
specify
through
velaro,
restore
create
just
correspond
to
fields
on
the
on
the
restore
custom
resource.
D
A
D
I
wasn't
sure
so
everybody
would
have
helped
you
right,
because
you
can
run
what
if
we
will
identify
the
items
that
but
potentially
would
trigger
an
exception
or
a
problem
in
the
bag
up
and
then
give
them
the
option
to
clean
them
up
and
adapt.
When
you
could
walk
the
dependency
three,
because
you
would
tell
them
explicitly
we're
gonna
go
ahead
and
delete
this
part.
This
class
is
persistent
volume
because
they're
there,
including
the
restore
okay.
D
G
E
So,
okay
I'm
a
new
kid
so
far
in
certain
flavors
of
Linux,
the
group,
nobody
does
not
exist
and
because
of
which
Valero
fails
to
start,
and
so
for
that
reason
we
updated
the
user
as
which
the
program
runs.
Nobody
belonging
to
no
group
in
in
the
Valero
image
when
we
build
the
Valero
image
and
test
it.
Does
that
answer
your
question
I'm
not
sure
yeah.