►
From YouTube: Velero Community Meeting - Oct 1, 2019
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
and
welcome
to
this
week's
community
meeting
slash
open
discussion
meeting.
We
haven't
really
set
a
specific
name
for
this
yet,
but
the
goal
of
this
is
essentially
to
move
the
community
meetings
that
we
have
held
by
week.
Two
before
we
move
to
a
monthly
community
meeting,
and
then
we
want
to
have
these
open
discussion
meetings
instead
and
we're
moving
them
to
become
weekly.
A
A
Maybe
even
do
you
do
some
deep
dives
into
the
codebase
and
more
things,
so
the
plan
for
these
meetings
is
essentially
to
be
a
more
open
format
than
the
community
status
updates
and
bring
out
more
communication
into
the
public
instead
of
behind
locked
doors.
So
we
want
to
be
as
public
as
possible
with
all
the
discussions
that
we
that
are
going
on
around
the
Bolero
project,
so
we're
trying
to
be
as
open
and
transparent
as
possible.
So
that
is
essentially
the
reason
for
this.
A
A
So
you
can
all
see
this
and
if
you
have
any
any
questions
or
any
concerns,
please
just
type
them
into
the
the
hacking
D
and
then
we
can
cover
them
or
if
you
have
any
questions
that
you
would
rather
speak
to
just
unmute
yourself
and
use
that
mic.
So
here's
the
MD
and
I
will
be
sharing
my
screen,
so
you
can
see
what
I'm
talking
about.
A
B
Start
since
I'm
first,
so
this
last
last
two
weeks,
I've
been
doing
a
lot
of
investigation
on
our
CI
good
chance.
We're
gonna
move
off
of
Travis
on
to
github
actions
whenever
those
become
GA
and
also
redoing,
some
of
our
some
of
the
logic
in
our
make
file
or
revisiting
some
of
it,
so
that
we
can
potentially
speed
things
up
there
and.
B
B
We've
also
been
looking
at
adding
support
for
a
plugins
flag
on
the
velaro
install
command
as
carly
CA
will
talk
about
removing
some
we're
removing
the
entry
cloud
provider
plug-ins
out
of
tree,
and
we
need
a
way
to
install
those
and
preferably
in
one
one
step.
So
I've
been
looking
at
that
and
figuring
out
what
kind
of
fall
out
there
might
be
from
making
that
change.
A
No,
it's
it's
perfectly
fine
talking
about
this,
so
we
are
moving
bolero
over
to
a
new
github
organization
so
that
new
github
organization
is
gonna,
be
VMware.
Tons,
ooh
and
Carlie
has
written
an
awesome
blog
post
about
this.
That
will
be
posted
right
well
this
afternoon,
essentially
so
we'll
link
to
it
in
the
doc
shear
will
share
it
in
the
slack
Channel
and,
of
course,
on
Twitter
and
everywhere
else.
You
can
find
information.
So
yes,
big,
thank
you
to
Carly's
here
for
taking
that
on
and
making
sure
that
the
communications
work
really
well
yeah.
C
And
thanks
so
many
people
that
post
as
well
so
team
efforts
yeah
and
since
we
are
moving
organization,
we
looked
into
making
structural
changes
that
we
were
thinking
about
making
anyway,
and
we
thought
that
this
was
a
perfect
timing.
So
what
we
are
going
to
do
is
extract
the
AWS
in
Google
Cloud,
plugins,
that
we
are
currently
in
trees.
C
We
are
extracting
them
and
they
each
going
to
have
their
own
repo,
and
it's
also
going
to
be
in
this
new
github
organization,
and
so
what
I've
been
working
on
sites,
the
blog
post
announcing
all
of
this
is
I,
did
some
dark
reorganization,
mainly
the
install
section
I
think
is
I'm
really
happy
with
the
way
it
is
now
because
it's
got
obvious
entry
links
like
if
you
want
install
with
the
link
is
there
if
you
want
to
uninstall
the
link
is
right.
There
I
mean
there
is
still
up
for
review.
C
There's
a
PR
open
right
now.
Anybody
can
review
anybody
besides
that,
the
core
team,
of
course-
and
so
that's-
that
in
also
the
tables
for
the
plugins
I,
think
the
provider
is
I.
Think
it's
more
obvious.
What's
a
provider?
What's
a
plug-in:
well,
it's
not
a
plug-in,
and
so
besides
that
I'm
also
doing
extracting
the
plugins
from
the
coracle
codebase,
there
is
also
a
PR
for
that.
I
need
to
update
it
with,
especially
with
the
new
path
for
the
new
github
organization.
D
All
right
looks
like
I'm
up
next
yeah.
The
last
few
days,
I've
been
working
on
a
few
different
things:
I've
got
a
PR
merged,
so
we've
had
some
a
number
of
kind
of
revisions
to
our
backups
Inc
controller,
which
is
the
code
that
is
essentially
continually
polling.
The
contents
of
your
object,
storage,
buckets
and
making
sure
that
any
backups
that
exist
in
those
buckets
are
reflected
as
custom
resources
in
the
cluster
that
you're
currently
running
in.
D
D
So
you
can,
you
know
if
you
want
to.
You,
can
turn
that
down
to
five
seconds
one.
Second,
although
I
probably
wouldn't
recommend
that
short
of
an
interval,
but
so
I
think
this
is.
You
know
it's
a
little
bit
more
intuitive
a
little
more
user
friendly
and
you
have
more
direct
control
over
how
often
that
runs
so
that
that's
been
merged
in
the
master
and
will
be
released
in
1.2,
and
then
yesterday
spent
a
lot
of
time
doing
some
experimentation
with
rustic.
D
So
I've
been
doing
some
experimentation
just
to
kind
of
try
and
figure
out
what
it
might
look
like
if
we
move
to
that
model,
so
right
now,
I'm
trying
to
implement
just
a
prototype
of
a
volume
snapshot
or
plugin
that
uses
rustic
behind
the
scenes
to
actually
backup
and
restore
the
contents
of
those
volumes
so
planning
to
continue
working
on
this
for
a
few
more
days.
I,
basically
just
want
to
get
something.
D
I
would
say
in
terms
of
moving
to
this
model,
the
primary
one
being
that
if
we
move
to
this
model,
where
rustic
is
a
volume
snapshot
or
you
would
no
longer
be
able
to
back
up
things
like
empty
durval,
Yume's
or
any
other
kind
of
POD
volume,
that's
not
a
persistent
volume
so
anyway,
more
discussion
to
come
on
that,
but
I'm
going
to
continue
working
on
that
for
another
few
days
and
I
think
that's
about
it
about
it.
For
me,.
A
D
It's
a
good
question,
I
mean
so
I
guess
the
short
answer
is
I'm
I'm,
not
exactly
sure
what
the
use
cases
would
be
for
backing
up
something
like
an
empty
durval.
You
my
mean
you
know.
Empty
doors
are,
are
kind
of
by
definition
intended
to
be
temporary.
Scratched
space
that
should
be
throw
away
should
be
ephemeral,
and
so
you
know
if
you,
if
you
do,
have
a
need
to
back
up
that
data
they're
there.
D
D
E
D
B
E
Yeah
that
sounds
good
and
then
one
more
thing
is
so
you
know
looking
at
the
backup
sink
period.
Is
there
a
use
case
where
you
could,
for
example,
backup
story
location?
You
could
specify
a
backup
sink
Peter
so
that,
for
example,
if
I
have
some
backup
few
locations
that
I
don't
need
them
to
be
synced
in
that
frequently
using
the
global
backup
sink
Peter
for
the
server.
E
Would
it
make
sense
of
let's
say,
backup
three
locations
define
their
own
sink
periods
so
that
that
way,
I
can
control.
If
I,
if
I
have
some
story,
location
that
I
don't
need
them
to
be
synced,
let's
say
at
all,
then
I
could
use
that
to
tell
whether
or
not
to
you
know
like
sync
them
using
their
own
specified
backups
and
periods
yeah.
D
We
we
could.
We
could
certainly
support
that.
We
could
look
at
you
know
having
we'd,
probably
have
a
config
field
on
the
backup,
storage
location,
pipe
that
would
have
a
you
know.
A
custom
sync
interval
for
an
individual
location,
definitely
something
we
could
add
it.
It
doesn't
exist
right
now.
I
will
I
will
say
that
you
know
by
by
default
when
the
each
time
the
sync
controller
runs.
D
If
it's,
if
it's
looking
at
a
location,
that's
already
fully
reflected
in
the
cluster,
the
backups
in
the
book
it
already
matched
what's
in
the
in
the
cluster,
essentially
all
it's
gonna
be
doing
is
executing
its
one.
Api
call
against
the
object
storage
system
to
to
list
all
the
contents
of
the
bucket,
but
it's
a
single
API
call
and
then
it'll
do
the
difference.
Ii,
there's
no
change,
so
you
know
it's
essentially
what
I'm
trying
to
say
is
that
it
it
doesn't
take
a
lot
of
work
for
each
iteration
and
so
okay.
E
E
D
A
All
right
awesome,
so,
let's
move
into
some
of
the
discussion
topics
here
you
talked
a
bunch
about
rustic
here,
Steve,
so
I
think
it's
a
good
segue
into
rustic
project
health.
D
E
D
The
the
handful
of
maintainer
and
we've
noticed
that
in
the
last
few
months,
I
would
say
essentially
starting
at
the
beginning
of
the
summer.
The
pace
of
merges
has
dramatically
slowed
down.
I've
only
been
a
handful
of
commits
since
since
I
think
the
end
of
May,
and
so
you
know
we
were
certainly
as
a
team
given
our
dependency
on
the
on
the
tool,
a
little
bit
nervous
about
what's
going
on
in
the
community
and
whether
it's
gonna
be
continued,
whether
it's
gonna
continue
to
be
maintained.
D
You
know,
I,
said
that
they've
they've
been
very
busy
both
in
their
day
job
and
also
in
their
personal
life,
moving
houses
and
so
they're
they're
planning
to
come
back
and
spend
more
time
on
rustic
later.
This
fall
after
that
all
clears
up,
but
at
the
moment
there's
just
not
enough
time
for
this
person
to
spend
on
it.
So
you
know
I
I.
Basically,
just
wanted
to
raise
this
for
awareness,
so
everyone's
aware
of
it.
I
do
think
you
know
long
term.
We
need
to
continue
to
think
about.
G
Let
me
just
ask
you:
what
are
the
alternatives?
Let's
just
suppose
that
rustic
disappeared
from
the
universe
in
a
quarter.
What
could
you
fall
back
to
his
CSI
snapshots
and
the
app
chaos
in
the
long
run,
a
potential
replacement,
or
is
there
some
feature
of
rustic
that
would
still
not
be
covered
by
those
yeah.
D
I
mean
I
think
a
long-term.
You
know
we
we
definitely
we
want
CSI
to
be
a
kind
of
a
primary
use
case.
The
rustic
offers
that
you
know
that
potentially
CSI
providers
don't
is
that
if
you're,
if
you're
on
a
storage
platform
that
doesn't
have
snapshot
support,
you
can
still
use
rustic
to
do
file
level
backups.
D
So
there
you
know
there.
There
are
also
other
tools
out
there.
I
mean
rustic
is
not
the
only
file
level
backup
tool
that
exists.
So
you
know
we
could
consider
integrating
a
different
tool.
If,
if
we
wanted
to
go
that
route,
but
I
do
think
that
you
know
CSI
snapshots
or
the
existing
snapshot
plugins
that
we
that
we
already
have
are
kind
of
our
preferred
approach
to
taking
backups
I'm.
G
B
D
G
It's
just
sort
of
a
clue
that
they
don't
are
willing
to
invest
in
its
use
with
kubernetes,
so
I
can't
see
how
a
user
would
choose
to
use
that
type
of
storage
in
the
shorter
run.
Obviously,
it's
different.
If
the
alternatives
became,
you
know
commit
resources
to
either
resting
or
CSI
snapshots.
I
think
I
would
tend
to
vote
for
it
going
to
CSI
snapshots
rather
than
rustic.
If,
if
you
can't
do
both
yeah.
D
B
Sorry
go
ahead,
I
was
gonna,
say
the
one.
The
one
thing
I
see
that
rustic
does
that
CSI
won't
is
cross
provider
since
you're
operating
at
the
file
system
level
there
may
maybe
someone
will
get
clever
with
CSI
and
offer
of
that
functionality.
There
I
haven't
looked
at
the
survey,
results
I,
don't
even
know
who
asked
about
that
about
moving
around
between
providers
well.
G
B
G
B
G
And
like
I,
say,
I
think
at
this
stage
it's
people
kicking
around
an
API
and
once
again
a
lot
of
the
existing
storage
solutions
already
support
those
scenarios.
It's
just
took
they
they
tend
to
have
proprietary
implementations
and
the
idea
is
to
put
in
place
some
scaffolding
so
that
you
can
go
through
a
universal
API
to
get
to
that
functionality
they're.
Actually
there
there
is
even
a
camp
that
has
an
interesting
form
of
it.
G
G
So
they
attempt
to
keep
a
shadow
copy
of
a
storage
volume
at
some
remote
location
synchronously,
and
they
tend
to
be
super
expensive
storage
solutions.
But
there
are
some
apps
that
demand
those
and
those
kinds
of
people
probably
want
a
different
API.
When
you
get
down
to
it
and
I
can't
say,
I've
attended
all
those
meetings
to
know.
You
know
what
direction
that's
headed.
A
B
B
There's
a
field
on
the
persistent
volume
claims
called
data
source
I,
think
that
was
moved
to
beta
with
116
and
I.
Think
there
was
discussion
about
maybe
changing
that,
maybe
not
going
to
beta
right
before
116.
Excuse
me,
it
was
had
a
feature
cut
off
and
there's
gonna
be
some
more
discussion
on
finalizing
that
design.
So
it
could
all
move
forward
to
beta.
B
Forget
the
day,
the
Monday
before
cube
con,
there's
gonna,
be
a
face-to-face
with
sig
storage,
so
we're
planning
on
being
there
to
give
our
input
we
have.
We
have
the
proof
of
concept
that
Valero
was
using
as
it
stands
like.
There's
some
minor
modifications
to
that
that
we
would
have
to
make
nothing
earth-shattering
but
yeah.
We
would
like
to
to
see
that
get
to
beta
before
doing
a
whole
lot
more
with
our
CSI
integration.
A
B
Yeah,
so
this
one,
this
one
was
a
question
I
had
for
the
core
team
and
I.
Guess
anybody.
So
we
have.
We
currently
have
this
design
doc
process
where
we
pried
up
a
design
document.
Some
of
these-
it's
really
detailed.
Some
of
these
it's
less
and
I,
was
wondering
for
increasing
understanding
in
the
overall
team
and
flushing
it
like.
B
Maybe
fleshing
out
I,
mean
any
sort
of
uncertainties
if
it
makes
sense
for
somebody
who
did
the
design
doc
to
not
necessarily
do
the
feature,
but
have
somebody
else
go
and
do
that
it
might
slow
velocity
down
a
little
bit,
but
it
might
also
lead
to
better
designs
and
implementations.
So
yeah
that
put
that
context,
I
guess
and
the
question
stand.
So
it
should.
Should
we
make
that
a
policy
or
is
that
something
that
would
just
be
on
a
case-by-case
basis?
Or
is
it
not
a
good
idea.
D
I
guess
in
my
mind
you
know
I
think
I
think
there's
definitely
potentially
value
in
in
doing
that,
or
at
least
having
folks
collaborate
on
things.
I,
don't
know
that
I
would
necessarily
do
it
as
a
policy
I
mean
it's
especially.
You
know.
Our
team
is
not
that
large
and
it
can
be
a
little
bit
tricky
I
think
to
have
that
as
like
a
blanket
policy,
but
you
know
I
I
could
definitely
see
value
in
doing
it.
I
mean
I.
D
B
B
B
Yeah
I
don't
know
that
I
was
necessarily
addressing
specific
problems
and
I
also
realized
some
of
these.
Some
of
the
designs,
for
instance
the
CSI
integration
and
the
proposal
you
have
for
moving
the
backup
stuff
to
work
or
pods
a
backup
logic
to
worker
pods.
Those
would
probably
require
multiple
people
implementing
anyway,
so
it
may
be
less
of
an
issue.
B
D
I
mean
I
think
it's
probably
a
good
idea,
at
least
like
you
just
said,
you
know
at
least
have
the
option
for
kind
of
once
the
designs
been
approved,
not
just
automatically
assume
that
whoever
wrote
the
design
is
going
to
be
the
implementer.
You
know.
Sometimes
it
may
work
out
that
way,
but
but
we
should
have
the
option
to
mix
and
match
there.
C
C
One
thing
that
I
think
when
they
see
this
question
is:
if,
if
we
are
writing
a
design
document
that
somebody
else
going
to
use
to
implement,
that
document
will
need
probably
to
be
more
specific
and
we
have
been
trying
not
to
go
so
deep
in
the
weeds
with
the
design
document,
because
we
don't
want
to
be
stuck
for
whole
week.
Writing
details,
we've
been
talking
and
the
documents
have
been
high
level
higher
level
for
the
purpose
of
just
like.
Let
us
address
the
edge
case,
I
mean
so
far.
C
The
purpose
of
the
design
document
has
been.
Do
we
have
a
very
good
idea
of
what
this
is,
but
not
necessarily
to
specify
everything
specify
some
of
the
train
out
the
changes,
but
now,
like
explain-
and
we
do
that
through
discussions
and
as
the
project
maybe
grows,
it
might
be
that
we
each
will
specialize
in
an
area
and
there
might
be
more
efficient
than
everybody
trying
to
understand
the
details
of
every
area.
Unless
you
know
there
is
a
time
that
we
need
to
so
it's
just
I'm
thinking
about
trade-offs
and
not
so
much.
C
G
C
Think
it's
more
Stephen.
The
question
here
is:
how
deep
do
we
go
into
the
design
dock
we
are.
We
are
very
much
an
agreement
that
we
should
have
I
think
maybe
I'm
speaking
for
everybody.
We
should
have
to
sign
documents.
I
agree
with
you,
it's
very
useful.
We
should
never
assume
that
we're
always
going
to
be
able
to
be
in
the
same
meeting.
At
the
same
time,.
C
G
Me
suggest
this
guideline
I,
think
that
it
would
be
a
mistake
to
insist
that
you
don't
start
work
until
you
get
every
little
tiny
detail
resolved.
That's
crazy,
that's
kind
of
waterfall
think
that
takes
where
projects
take
forever.
However,
if
you
resolve
some
of
the
major
issues
like
you
know,
how
am
I
going
to
keep
this
information?
Is
it
a
key
value?
Store?
Is
a
database
book.
You
know
just
give
an
example
of
something
that
got
resolved.
G
You
know
the
equivalent
functionality
that
you
desire,
then
so
you
need
to
you
need
the
tighten
down
the
spec
for
things
you've
decided
on
so
that
in
theory
any
developer
could
meet
the
spec,
but
for
things
that
aren't
resolved
yet
just
leave
them
out
of
the
document
or
maybe
better
yet
just
point
out
that
these
aren't
resolved
yet,
and
maybe
even
that
you've
decided
to
leave
this
detail
up
to
the
developer
at
the
time
they
do
the
work,
but
just
make
a
statement
that
that's
that
that's
what
we've
decided
to
do
here.
I.
C
G
It's
just
that
you
need
to.
You
need
to
draw
a
firm
line,
not
a
not
this
wide
gray
line,
but
black
and
white,
that
this
would
visit
me
what
we've
decided
to
build,
or
this
wouldn't
and
you
need
some
of
those
to
be
a
decent
design
spec,
but
it
doesn't
have
to
cover
every
little
detail
you
know
kind
of.
If
you
were
building
a
car,
you
can
make
a
statement
that
I
want
a
v8
engine
instead
of
a
v6,
but
you
don't
have
to
identify
the
specific
model
of
spark
plugs
to
be
used.
G
Yeah
I'm,
the
document
could
grow,
I
mean
maybe
you
can
write
down
some
black
and
white
rules
and
go
with
it
start
building
stuff
out
and
a
lot
of
times.
Realistically,
as
you
build
it,
you
realize
you
need
to
make
a
decision
here.
It
may
be
kick
that
back
up
to
the
document.
It
is
nice
when
these
documents
actually
end
up
being
as
built
documentation,
so
that
future
maintain
errs,
have
a
have
have
a
means,
other
than
reading
a
bunch
of
source
code,
to
figure
out
how
the
thing
is
put
together.
G
D
Yes,
no
I'm
just
linked
to
the
docs
we
have
so
we
have
some
some
general
information
on
docs
and
then
we
also
have
done
a
series
of
training
sessions
that
we
have
some
recordings
of.
What
I
don't
think
those
are
currently
posted
publicly
anywhere,
but
there
shouldn't
be
any
reason
that
they
that
they
can't
be.
We
may
just
need
to
do
some
editing
on
them,
but
I
would
say
those
are
good
places
to
start.
D
C
Yes,
so
we
so
that's,
that's
the
entry
points.
There
is
a
resources
link
that
people
can
find
the
videos
of
demonstrations,
and
we
also
just
we
are
improving
our
install
section,
so
I
I,
like
I,
think
it's
early
I
think
it's
a
more
intuitive
like
it
is
the
same
content
that
we
had
before
we
just
organizing
it
better,
and
just
please
tell
them
to
give
us
feedback.
Okay,.
G
Yeah,
since
these
are
developers,
you
know
it's
a
little
different
from
onboarding,
a
user,
so
I
get
I.
Think
starting
points
are
even
things
like
telling
them
that
this
meeting
exists.
For
example,
and
you
know
what
the
standards
are
for,
how
you
go
about
proposing
an
enhancement
who
you
know
kind
of
there's-
maybe
excess
formality
over
in
kubernetes
in
this
regard
for
a
small
project,
but
those
kinds
of
things.
C
C
C
That
start
contributing
page
it,
the
intent
of
it,
is
to
be
like.
Okay,
here's
how
you
start
on
body,
so
the
link
to
the
community
page
is
there
the
link
to
the
resources?
Is
there
that
I
just
mentioned
the
heads,
videos
and
demonstrations
of
Alero,
which
is
very
useful
to
know
so
absolutely
like
yeah?
If
they
ask
us
questions
we'll
try
to
improve
that
documentation,
you're
right,
we
should
have
an
onboarding
for
develop
an
onboarding
for
users,
and
the
embody
from
developers
is
definitely
under
their
contribute
section
in
the
documentation.
G
G
G
To
be
an
attempt
to
have
a
developer
meeting,
even
if
it's
not
formal,
but
at
cube
con
I'm
guessing
there
might
be
a
few
people
there.
I
know.
I
saw
in
these
schedule
that
there's
a
red
hat
presentation
on
kubernetes
back
up
so
they'll
have
at
least
a
couple
people,
and
it
might
be
interesting
to
have
a
get-together
yeah.
C
C
G
A
Want
to
make
sure
that
people
get
lunch,
I
think
we're
getting
a
little
off
topic
here.
So,
let's
move
back
to
the
discussion
topics
list.
Thank
you
so
much
Steve
for
for
all
your
input
on
the
on
how
to
get
started,
contributing
to
Valero,
really
really
appreciate
it.
Okay,
kaliesha
your
ask
regarding
the
other
plugins
flag,
yeah.
C
So
the
feature
that
no
one
is
working
on
we're
thinking
you
we're
gonna,
have
the
install,
do
everything
in
one
shots
and
that's
why
we
were
adding
the
plugins
flag
but
I'm.
Just
in
this
we
went
back
and
forth
a
knife
at
some
point
said
it
should
be
required,
but
now
I'm
thinking,
maybe
we
shouldn't
make
it
required,
because
we
have
this
other
issue
number
one:
nine
one
zero,
which
is
extra
down
the
on
a
different
note,
different
contexts
in
that
in
this
hack
MZ.
C
We
are
taking
ahead
and
we
might
be
changing
the
way
plugins
are
installed
so
I'm
thinking
if
we
make
it
required.
We
change
the
interface
of
the
installed
now
and
then,
if
we
change,
then
we
might
be
potentially
changing
the
again.
So
to
avoid
out
all
of
that,
we
would
avoid
changing,
making
so
much
changes
to
the
install
interface
if
we
just
to
make
it
required,
but
I
also
don't
want
to
buy
shadownet.
So
much
think.
B
D
Yeah
I
would
I
would
I
mean
you.
You
definitely
need
to
have
an
object,
store
plug-in
in
order
for
Valero
to
start
up
and
given
that
we're
kicking
all
of
those
out
a
tree
like
the
lair
will
be
non-functional
until
you
add
at
least
one
plug-in
that
has
an
object
store.
So
from
that
perspective
I,
would
you
know
I
would
lean
toward
making
it
required
for
now
I'm
in
it.
D
You
know,
I
think
we
could
definitely
revisit
it
down
the
road
with
that
other
issue,
but
for
now
you
know
if
we
don't
make
it
required
we're
just
setting
the
user
up
to
have
issues
that
they're
gonna
have
to
diagnose,
like
we
make
all
the
other
required
fields
for
backup
storage
locations
required
on
velaro
install
like
buckets
required
providers
required.
So
you
know
in
my
mind
it's
kind
of
consistent
with
that
yeah.
B
D
D
We
released
that
as
of
1.0,
we
made
a
number
of
changes
to
plugins
and
we're
doing
continuing
to
do
that
now,
with
removing
plugins
out
of
tree
and
we've
had
questions
around
you
know
should
Valero
be
able
to
start
up
even
if
there's
no
backup,
storage,
location,
configured
so
I
think
we
do
want
to.
You,
know
kind
of
step
back
and
look
at
all
these
different
questions
and
issues
collectively
and
see.
D
If,
if
there
are
changes,
we
want
to
make
to
just
how
a
user
goes
about
installing
and
configuring
velaro,
so
you
know
I
would
definitely
say
anyone
in
the
community
who
has
thoughts
or
opinions
on
this.
Please
feel
free
to
add
comments
here
and
and
we'll
hopefully
be
able
to
pick
this
up
and
look
at
it
in
the
coming
releases.
B
There's
and
there's
the
velaro
install
command
and
there's
a
home
chart
and
making
sure
those
are
on
parity
hasn't
been
I.
Don't
think,
we've
done
a
great
job
of
that,
but
also
like
the
velaro.
Install
command
started
as
a
way
to
get
rid
of
the
AML
manifests
and
provide
like
an
easier
thing
for
our
QuickStart
to
use.
But
we
found
that
people
are
relying
on
it
and
looking
for
something
that's
more.
B
More
flexible
because
it
it
does
the
the
simple
case
pretty
well,
but
once
you
get
outside
of
that
it,
it
doesn't
do
a
great
job
and
you're
you're
relegated
to
editing
a
mole
or
something
like
that
so
I
for
one
would
appreciate
feedback
on
what
people
expect
out
of
it.
Are
they?
Are
they
expecting
it
to
be
like
a
like?
I
want
to
do
all
the
flies
that
Valera
can
do
under
the
install
command,
and
we
just
add
all
those
flags
or
is
it
something
simple?
And
then
we
edit
the
mo
or
yeah.
D
Yeah,
because
it's
definitely
at
a
certain
level
like
just
having
a
single
CLI
command,
that
has
every
possible
permutation
of
configuration,
options
gets
a
little
bit
unwieldy.
You
know
there
are
definitely
arguments
to
be
made,
for
you
know,
moving
to
using
a
config
file
or
moving
to
having
it
be
an
interactive
process
where
you
can
actually
have.
You
know
yes,
nose
and
different
branches
of
configuration.
Just
slapping
everything
on
to
the
one
command
as
flags
at
a
certain
point
gets
unwieldy,
so
yeah,
which.
C
B
B
B
E
B
Yeah
I
will
love
to
see
systems
that
rely
on
Valero
as
a
component,
not
use
Valero,
install
and
actually
use
there's
the
install
package.
If
that,
if
that
doesn't
do
the
job,
then
we
should
probably
fix
that,
but
that's
that's
related,
but
separate,
I
think
from
the
install
command,
which
is
a
slightly
different
experience,
but
yeah
I
think
with
regards
to
making
it
interactive,
my
preference
would
be
we
can
make
it
interactive,
but
optional,
optionally,
interactive,
okay,.
E
I've
seen
that,
at
least
from
from
what
we're
working
on
it
Valero
the
preference
for
that
for
the
CLI
the
install
command-
is
that
it's
very
easy
to
use.
You
know
you
just
run
the
Valero
install
and
it
deploys
everything
for
you.
So
it's
very
easy
to
use
and
that's
why
it
is
that
leaning
towards
using
it
and
trying
to
make
it
do
the
work
you
want
in
our
experience.
B
E
B
So
this
this
I
think
we've
had
some
people
ask
about
this.
I
can
find
there's
a
there's,
an
issue
for
like
making
plugins
that
are
like
helm,
aware
or
something
like
that
and
Steve
Wang
mentioned
the
app
PSN
kept
that
is
going
on
in
cig
apps.
So
this
is
probably
more
future
looking
as
in
like
next
year
at
the
earliest
late
next
year
since
earliest,
but
this
was
more
like
a
this
came
up
in
a
discussion
between
nan
and
myself
and
talking
about
making
velaro
smarter
around
application
definitions.
B
So,
instead
of
saying,
hey,
I
want
to
have
to
specify
a
namespace
and
all
these
other
things.
What
if
velaro
could
be
pointed
at
some
app
specification,
whether
it
be
a
helm
release
or
the
app
CRD
that
Sega
apps
is
discussing,
and
from
that
it
would
find
the
whole
tree
of
things
to
back
up.
So
it
would
go
find
the
deployment.
Do
we
find
stateful
said
TVs
all
that
kind
of
stuff
I,
don't
know
that
there's
a
there's,
there's
home
releases
but
I
think
the
cig.
B
Well,
two
years
ago,
the
taught
this
idea
of
velaro
app
backup
templates
but
I
guess
in
summary,
some
way
having
application
developers
communicate
to
Valero.
This
is
the
whole
totality
of
what
you
need
to
back
up
the
app,
and
these
are
the
steps
that
needs
to
happen
in
is
I,
think
some
an
interesting
place
that
we
could
take
Valero
I,
don't
know
that.
There's
anything
actionable
on
it
today,
because
I
think
it
require
a
bunch
of
structural
changes
to
how
things
get
added
like
resources,
but
yeah.
B
It's
something
I
just
wanted
to
put
in
people's
ear
and
and
have
them
think
about.
So
maybe
it
started
at
a
signed
document
yeah.
That
definitely
could
be
the
next
step.
I
think
for
us.
It's
also
potentially
at
some
at
some
point,
may
be
engaging
with
cig
apps
on
the
application
cup,
but
I
don't
know
with
timing
on
how
that's
going
to
work.
I.
Think
right
now,
so
the
CSI
is
CSI
sports
more
immediately
relevant
but
yeah
longer-term.
Maybe
we
we
start
discussing
with
se
gaps
on
how
we
might
use
that
I.
D
Would
think
we
would
probably
need
to
support
kind
of
multiple
different
approaches
here,
so
you
know
allowing
users
to
use
some
some
kind
of
app
concept,
whichever
whichever
one
we
end
up,
choosing
to
specify
what
to
backup,
but
also
you
know
using
the
existing
backup,
spec
or
something
similar
to
it,
so
that
they
have
multiple
different
paths
for
specifying
it,
because
you
know
it's
ads.
Are
that
not
everyone
will
be
at
least
not
in
the
in
the
medium
term
would
be
using.
D
B
This
would
be
I
would
think,
since
it's
a
it
would
be.
A
big
change
like
we'd,
have
to
keep
helpful
arrow
words
now
and
then
had
this,
so
bridging
that
we
absolutely
would
need
a
design
doc
on
how
about
how
we
bridge
that
and
how
we
keep
both
and
but
I
also
do
think
doing.
It
would
require
some
redesign
of
velaro
logic
such
that
it
knows
what
the
root
of
the
the
object
graph
is.
A
D
Yeah
sure
no
I
looked
through
the
commit
log,
I
hope,
I,
hope,
I
didn't
miss
anyone,
but
we
had
a
PR
submitted
from
spiff
CS
to
fix
the
logging
when
we're
doing
backups
of
additional
items.
So
this
would
be
like
taking
a
pod
and
backing
up
the
PVC
and
PV
that
it
uses.
We
had
some
issues
with
the
log
in
there
that
made
it
kind
of
unclear
to
the
user.
What
was
going
on
so
appreciate
that
PR
to
fix
that
issue
definitely
makes
things
much
more
clear
both
for
users
and
for
the
development
team.
A
Thank
you
so
much
everyone
for
for
joining
and
if
you
have
any
other
questions
or
if
you
want
to
keep
on
continuing
the
discussions
here,
please
join
us
in
slack
and
of
course
up
on
github.
If
you
have
any
issues
or
if
you
want
to
do
any
design
documents
or
or
PRS,
please
head
over
there
and
with
that,
thank
you
all
and
have
a
fantastic
rest
of
your
week.