►
From YouTube: Velero meeting: new CLI revamp
Description
In this session we discussed the upcoming removal of the current `velero install`, and what could substitute it. A more intuitive CLI UX is in the works. PR: https://github.com/vmware-tanzu/velero/pull/2202
B
Yeah
I
mean
I
would
agree,
I
think
there
are
definitely
a
few
different
possible
paths.
There
I,
don't
know
I,
don't
know
which
one
makes
sense
yet,
but
certainly
we
can't.
We
can't
ignore
that
use
case.
I
mean
you
know
what
one
option
that
I
was
mulling
over
is
whether
we
should
just
have
static
yamo
for
the
baseline
install,
because
now
that
we've,
you
know
if
we
go
down
the
path
of
kind
of
making
configuration
a
separate
step,
there
really
are
far
fewer
permutations
of
that
baseline
install
like
it's.
B
It's
basically
just
a
matter
of
adding
any
of
these
optional
flags
to
the
deployment.
So
we
you
know
we
could
just
ship
static,
yeah
more
for
the
baseline,
install
and
say
you
know,
take
these
if
you
want
them
or
or
just
use
them
to
do
the
baseline,
install
and
then
have
commands
for
the
the
configuration
stuff
anyway,
I
don't
want
to
I,
don't
want
to
wrap
a
hole
too
much
down.
This
I
just
definitely
wanted
to
highlight
that
we
need
to
be
considering
this
use
case.
We
can't
ignore
it
as
we
go
through.
C
C
All
right
so
I
would
definitely
welcome
any
any
heads-up
for
pitfalls,
because
this
is
a
drastic
departure
from
the
way
the
CLI
structure.
What
structure
right
now,
if
this
is
civil
I,
think,
is
going
to
be
really
very
intuitive
for
the
users,
so
I
personally
am
liking
the
way
this
is
coming
out
so
I,
you
know,
haven't
I
mean
with
we
do
have
client
commands
and
server-side
server
commands
mixed
mixed
up
and.
C
A
I
guess
the
the
one
thing
I
would
ask
is
to
have
a
time
line
spelled
out
for
deprecation
as
we
move
things
around
I.
Think
the
even
acknowledging
the
downfalls
of
the
install
command
I
know
folks
are
using
it
in
scripts
and
stuff
and
I
don't
want
to
see
it
like
break
immediately
as
we
move
things
so
I'd
like
to
give
at
least
one
release
where
we
support
both
even
I
know
it's
gonna
be
messy,
but
so
some
indication
in
there
to
say
this.
A
C
One
thing
that
I
sort
of
got
creative
with
was
the
set
default
location.
So
if
we
look
at,
if
we
do
have
a
little
help,
we
will
have
no
sorry
if
we
do
have
the
letter
install
help
that
will
be
there
Eve.
There
are
three
flags
there
that
we
need
to
fulfill
to
put
for
that
default
location
to
get
created,
and
it's
a
the
bucket,
the
prefix,
the
plug-in
name
which
now
we
call
provider
and
there's
our
like
dangling
in
the
middle.
C
C
C
For
you,
but
if
there
is
a
plugin
that
will
map
to
the
plug-in
name
here-
and
this
is
something
that
would
definitely
rely
on
documentation
more
so
than
the
other
flags
they're
more
self
explanatory.
But
the
nice
thing
about
this
is
this:
take
one
flag
boom
takes
care
of
everything,
and
also
the
true
or
false,
for
the
snapshot
location
go
here
to
I.
C
A
I
think
I
think
by
making
that
by
making
the
snapshot,
location
true/false
you,
you
then
make
everything
in
there.
True,
you
then
make
everything
optional,
because
bucket
prefix
aren't
applicable
to
snapshot
location
like
I,
like
the
idea
of
having
a
like
just
give
me
the
default
command.
That
just
does
that.
A
B
C
B
C
C
A
C
A
So
that
way,
it's
clear
that
one,
it's
a
backup
location
instead
of
a
snapshot,
location
and
two.
It
does
the
default.
Switching
for
you
because
I
think,
if
we,
if
we
just
have
the
yeah,
so
it
would
you
it
would
be
similar
to
this
and
what
are
all
the
like
like
he
was
saying
all
these
things
could
be
strongly
typed
and
required,
but
we
could
make
it
default
and
do
the
server
update.
A
C
So
I
think
I
think
we
were,
you
were
bringing
up
is
actually
two
things.
What
you
get
about,
having
that
make
defaults
flag
when
you
we
are
creating
I
was
actually
checking
if
reason
and
a
half
that
cuz
I
that's
a
great
idea,
we
should
definitely
we
don't
have
that,
so
we
should
should
have
of
that.
So
we
win,
we
have
winner,
we
are
creating
a
hash,
but
then
there
are
a
bunch
of
configurations
that
we
also
have
to
import
now.
This
is
so
so,
let's
I'm
gonna
add
that
to
the
notes
later.
C
So
this
is
trying
to
address
the
intention
of
making
the
initial
setup
as
quick
as
possible,
and
that's
why
we
have
like
with
the
install
now
we
have
the
ability
to
do
like
a
default
location
for
them
automatically
as
long
as
they
pass
those
two
three
from
informations,
with
the
back
bucket
name,
prefix
in
the
plug-in
name.
So
if
we
get
there,
we
can
create
the
default
location
for
them.
So
this
is
what
this
is.
What
it
is
trying
to
address
now
I
could
also
so
I
could
do.
C
We
could
do
away
with
with
doing
this
and
just
requiring
required
so
few
things
we
can
do,
remove
this
completely
and
require
them
to
explicitly
say
the
location
from
scribes
instead
of
trying
to
give
them
a
hand
Wiki
and
keep
this
here
and
just
like
this,
but
I
don't
think
this
is
workable,
or
we
could
keep
this
here
just
with
the
one
set
default,
backup
location
and
then
do
nothing
or
set
a
sacrifice
to
to
get
the
input
to
find
out.
If
the
user
wants
to
set
up
defaults,
look
natural
location.
C
C
So
any
preference
I
think
I
like
keeping
this,
because
it's
sort
of
we
our
rehab,
it
might
be
handy
for
people
who
don't
we
don't.
We
won't
have
to
require
them
to
no
more
commands
more
flags
to
set
up
our
rights
with
just
these
three
things.
We
can
create
it
automatically
that
we
could
remove
the
snapshot
looking
into
a
false
and
put
that
into
a
different
set
flag,
different
yeah.
B
C
B
C
C
B
B
C
B
C
B
B
C
C
A
Ahead
that
one
all
I
was
gonna
say,
was
I
I.
Think
the
the
Valero
server
flag
is
fine,
the
the
flag
that
does
it
is
fine
and
all
the
all
I
think
that
the
client-side
one
should
do
is
go
to
the
the
deployment
and
it
if
it's
already
there
change
the
line.
I
put
the
name
in
and
if
it's
not
there
at
it,
but
the
I
don't
think
we
should
really
need
to
change
the
the
server
one.
So
that's
all
I'm
gonna
say
yeah.
B
B
C
C
C
All
right
so
for
default,
the
default
Becca,
app
storage
location
for
me
is
trivial.
I
super
understand
that
but
I'm
not
seeing
how
we
mapped
to
the
volume
snapshots
only
because
it's
there
multiple
of
them.
What
are
we
really
sitting
in
to
the
user
when
we
say
make
snapshots
location,
a
B
and
C
the
default
ones.
B
So
you
know
if
you're,
using
EBS
volumes
and
also
court
works
volumes
in
your
cluster
you'll
have
you
can
potentially
have
multiple
volume
snapshot
locations
for
each
of
those,
so
you
could
have
two
EBS
locations
and
two
port
works
locations,
and
so
the
user
should
be
able
to
say
to
specify
a
default
location
for
EBS
and
a
separate
default
location
for
port
works.
That
says,
when
I
backup
an
EVs
volume,
the
snapshot
should
go
to
this
location
and
when
I
back
up
the
port
works
volume,
it
should
go
to
this
location.
Okay,.
C
A
And-
and
that
was
in
preparation
for
replication,
so
we
can
write
it
too,
like
availability
zone
and
then
later
we
can
have
some
replication
logic
that
moves
them
around,
but
for
now
yeah
we
usually
usually
it's
copying
it
into
the
availability
zone,
you're
in
with
your
compute
nodes
and
then
later
on
down
the
road.
If
we
ever
get
to
the
replication,
we
would
copy
it
out.
Excuse
me
somewhere
else,
I.
A
So
for
your
your
question
about
turning
turning
a
default
on
or
off,
is
this
related
to
the
you,
the
dad
fetch
used
volume
snapshots
yeah
flag,
so
this
one
I
think
was
memory
serves.
This
is
this
is
mostly
for
rustic
users
who
were
using
rustic
and
not
volume
snapshots
at
all,
so
they
were
only
getting
file
level
snapshots
and
not
using
BBS
or
GCP,
or
you
know
they
were
on.
They
were
on
some
some
provider
that
didn't
have
a
Valera
plugin,
so
they
could
just
turn
that
functionality
off
and
not
even
worry
about
it.
C
B
Yeah
because
they
like
the
process
of
adding
a
plug-in
you're,
basically
you
add
in
an
it
container
and
then
you
potentially
create
a
secret
and
you
potentially
add
an
environment
variable
to
the
Valera
deployment.
You
might
also
add
service
account,
annotations
or
pod
annotations,
depending
on
the
method
of
authentication
you're
using,
but
all
of
that
stuff
happens
to
the
velaro
deployment
or
the
rustic
daemon
set
so
I
figured
you
know
the
command
for
adding
plugins
should
probably
capture
all
of
those
things
and
we'll
just
need
to
figure
out
exactly
how.
C
C
So
my
preference
is
everything
that
we
are.
Let's
say
we
shift.
We
end
up
shifting
comments
from
the
velaro
server
into
this.
Anything
that
gets
shifts
here.
I
would
not,
even
if
we
keep
the
commands,
so
we
can
use
it.
I
wouldn't
display
it
to
the
user,
so
I
would
prefer
not
to
have
to
your
commands,
have
a
one
command
in
two
different
places,
just
to
make
him
less
confusion.
C
A
Well,
I
think
the
server
needs
to
know
where
to
look
to
load.
The
plugins
is
I
think
what
I
was
getting
at,
so
the
server
needs
to
know
when
it's
starting
up
where,
where
to
read
when
the
init
containers
are
all
mounted,
it
needs
to
know
where
it's
where
those
binaries
are
so
I
think
it
needs
to
have
that
flag
still.
B
Mean
if
so,
if
you
change
that
to
something
other
than
the
default,
then
you
need
to
go
change.
Your
NIC
containers
docker
file
to
have
it
like
copy
its
plug-in
binary
to
a
different
location
and
change
the
Valero
deployment
to
have
a
different,
empty
durval.
You
more
mounted
into
a
different
location.
B
A
A
B
B
A
A
C
A
Think
that
makes
sense.
I
know
Dylan
Murray
from
Red
Hat
has
mentioned.
He
thinks
those
should
go
under
backup,
storage,
location,
which
I
think
that's
a
worthwhile
conversation.
I,
don't
know
if
I
completely
agree,
but
I'm
willing
to
hear
him
out
on
it,
but
I
think
plug-in
is
a
place.
To
start
I
mean
that's
probably
less
change
to
our
architecture
than
his
proposal.
C
B
C
I
I
wasn't
now
that
I
pointed
that
out.
It
makes
for
me
it
makes
sense
to
be
with
a
plug-in,
because
it's
necessary
for
that
plug-in
to
run
the
backup
location
is,
is
it's
an
abstract,
is
a
concept
where
we're
just
saying:
okay,
this
is
the
connector
between
what
you
like
your
backup
in
the
actual
connector
here.
So
this
is
just
this
handle
saying:
okay,
you
can
connect
here,
you
can
connect
there,
so
the
secret's
out,
in
my
mind,
definitely
goes
together
with
the
plug-in.
A
Yep
I
would
agree
with
that
I.
His
argument
was
that
it's
putting
it
all
in
the
back
of
storage
location
condenses
all
the
information
that
you
need
to
get
do
it
in
the
backup,
storage
location,
but
I
I
can
see
like
putting
it
all
with
the
plug-in
condenses
all
the
information
you
need
with
plug-in,
but.
A
I
would
I
would
say
more
of
it
needs
to
be
with
a
plug-in
than
it
needs
to
be
with
the
BSL,
and
you
need
the
deployment.
You
need
the
information
in
the
deployment
anyway,
because
the
whole
deployment
has
to
get
to
stuff
that
those
processes
need
to
get
there.
So
I
would
lean
towards
starting
with
putting
it
with
the
plugins,
because
that's
where
they're
at
now,
yeah.
A
B
And
I
would
so
I
would
also
throw
out
the
environment
variables
here
so
so
currently
we
we
basically
put
an
environment
variable
for
all
of
our
providers
base
velaro,
deploy
so
hope.
Mint
has
an
AWS
and
VAR
GC,
p1
and
azure
one
and
I.
It
would
be
really
nice
to
remove
that
and
basically,
as
part
of
flora
plug-in
add,
actually
you
know
specify
hey
and
I
need
to
add
this
environment
variable
with
this
value.
That
way,
we
wouldn't
have
to
have
them
hard-coded
in
in
bolero
itself,.
C
B
I'm
not
sure
that
I
have
a
strong
opinion
yet
on
whether
it
should
be.
You
know
like
a
single
command
or
multiple
ones,
but
you
know,
as
far
as
like
getting
a
plug-in
to
be
functional.
It's
adding
the
init
container,
it's
creating
and
mounting
the
secret,
and
it's
setting
that
environment
variable.
So
I
think
you
know
we
need
all
three
of
those
things
plus
some
annotation
stuff
and.
A
C
A
B
A
A
But
for
definitely
for
AWS
you
can
get
around
having
to
give
them
a
secret
file,
but
what
you
have
to
do
is
put
it
put
annotations
on
the
velaro
pod,
the
rustic
pods
and
any
other
pods.
You
want
to
have
access
to
those
resources,
so
it
has
to
go
on
all
and
it
like
Steve
said
it's.
It
really
is
required
by
the
pods
I'm,
sorry
by
the
plugins,
but
it
becomes
like
a
velaro
pod
level.
Thing
like
it
goes
on
the
velaro
and
rustic
pods.
C
B
C
B
A
C
A
A
But
in
terms
of
just
putting
it
on
there,
I
think
yeah
I
think
this.
This
meets
the
criteria
because
we
now
have.
We
have
default
limits
and
requests
for
the
CPU
and
memory,
so
people
can
tweak
that
if
they
need
to
and
yeah
the
rest
that
it
puts
the
puts
the
namespace,
it
puts
the
I
guess
I
guess
that
would
be
the
one
thing
if
they
wanted
to
put
it
into
a
different
namespace.
A
C
A
So
if,
if
they
wanted
to
install
velaro
into
a
different
namespace,
called
something
besides
velaro,
they
might
want
to
end
it
into
I.
Don't
know
backup
the
namespace
backup
that
might
be
an
optional
command
on
an
it,
because
I'm
assuming
an
it,
would
handle
putting
the
CR
DS
on
the
server
making
a
namespace
and
then
putting
the
deployment
in
the
namespace
yeah.
A
C
C
A
B
B
Mean
I,
so
I
think
we
want
to
support
the
functionality
like
the
lair
Owen.
It
should
support
doing
the
base
install
into
any
namespace
I'm,
pretty
sure
that,
as
it
is
already
like,
we'll
get
that
functionality
by
default.
Assuming
we
read
the
value
of
the
flag
in
it's
just
that,
since
every
velaro
command,
like
instantiates
of
velaro,
api
client
and
namespace
is
part
of
that.
This
flag
is
global
because
it
applies
equally
to
every
single
Valero's.
He
like
Ament,
yeah,.
A
B
C
A
And
I
even
forgot,
but
honestly
I'm,
not
sure
if
you
can
duplicate
it
with
the
way
Cobra
works.
I
know
I'd
have
to
go
reread,
but
I
think
I
think
Cobra
will
be
like.
Oh
you
already
added
it
or
something
like
that,
but
in
terms
of
functionality,
regardless
of
the
implementation
details,
I
think
in
it
should
let
you
specify
a
different
name
space
to
put
put
the
deployment
in
no.
C
I
think
you
definitely
worry,
because
it's
a
global
flag,
yeah,
it's
just
that
it
wouldn't
be
so
soft
document
to
this
before
it
using
the
CLI
to
students
find
out
what's
available,
I
mean
it's
under
the
global
flags,
because
yeah,
maybe
because
it
nate,
is
going
to
have
a
much
shorter
list
of
flags.
Maybe
people
who
own
miss
that
one
yep.
A
A
C
Was
gonna
look
up
how
to
change
the
namespace
I
totally
I.
Think
now,
I
will
I
will
remember
forever
see
what
else.
Ok,
so
I
think
it's
gonna
work
out
nicely
because
then
it's
going
to
be
installed
earlier,
then
till
they
were
in
it's
the
little
config
the
little
plug-in
a
little
rest.
They
can
create
backup,
stuff
and
then
so.
I
have
little
I
think
this
was
really
nicely.
You
might
have
it
at
least.
A
A
A
A
A
A
C
C
C
It
was
more
to
illustrate
like
hey.
This
user
only
has
one
two
three
four
steps:
these
other
user
has
even
less
than
that.
I
know
we
right
now.
We
can't
constrain
ain't
users
that
way
alright.
So
I
have
to
watch
this
video
again
for
the
discussion
at
the
beginning,
I
to
see
what
I
have
to
do
to
address
and
he
gets
ops
concern
yeah.
B
I
think
I
mean
I
think
now
that
we've
had
a
chance
to
kind
of
talk
through
all
the
flow
like
I
would
I
would
suggest
you
know
going
through
it
and
thinking
about
it
from
the
perspective
of
the
user,
who
doesn't
want
to
interactively
be
Madhi
modifying
stuff,
that's
already
deployed
in
the
cluster,
but
who
wants
to
generate
a
complete
set
of
Yam
all
that
they
can
check
in
to
get
and
apply
at
a
later
time,
I
think
for
the
for
Valero
in
it.
That's
very
it's
very
clear
that
you
can
do
that.
B
If
you
do
it,
you
know
dry
run,
oh
yeah!
Well,
you
get
your
yeah
mo
and
you
can
check
it
in
to
get,
but
for
some
of
the
later
steps
around
plugins
and
config
and
stuff.
It's
still
not
clear
to
me
how
that
will
work
for
those
users,
so
I
would
I
would
just
suggest
trying
to
think
through
that
and
think
about
what
the
options
are
there.
B
There
are
a
few
complexities
like
part
of
it
is
you
know
so
like
with
a
with
valera?
Essentially,
how
do
you
generate
a
Valero
deployment,
yeah
mol?
That
includes
all
the
plug-in
information
that
you
need,
so
the
Indic
container
and
any
secrets
mounted
and
any
annotation
set?
How
do
you
get
to
that
point
through
you
know
this
new
set
of
commands,
mm-hm.
B
Without
actually
applying
it
to
the
cluster,
yeah
and
I
I
feel
like
we
may
end
up
needing
a
separate
path
for
those
users
like
maybe
it's
just
two.
You
know
two
parallel
paths
that
don't
that
aren't
aren't
the
same,
but
I,
don't
I,
don't
know
yet
I
just
want
to
make
sure
we
continue
to
think
about
it
and
don't
ignore
those
users,
yeah.
A
There's
this
way,
there's
helm
and
then
there's
customize,
where
the
plugins
become
like
a
layer
on
top
of
the
base,
so
that
what
we're
providing
and
generating
in
the
plug-in
repos
is
not
something
that
you
cube,
can
keep
CTL
apply,
F,
it's
keep
CTL,
apply,
K
or
customizing,
and
that
that
would
layer
on
top
of
your,
your
your
valaria
or
deployment
I,
don't
know
exactly
what
that
looks
like
that's
kind
of
spitballing
but
I.
Think
despite
the
maintenance
burden,
that's
probably
the
path
of
least
resistance.
A
B
A
That's
not
as
bad
and
I
still
think
we
can
put.
We
can
work
on
some
release
tooling,
to
make
that
more
automatic
for
incrementing
things
and
stuff,
like
that,
but
yeah
I
think
we're
gonna
end
up,
at
least
for
the
time
being.
We're
gonna
end
up
with
three
distinct,
three
distinct
ways
of
doing
this
at
least
and
customized
I.
Think.
C
C
A
C
A
C
A
A
Yeah
they
unfortunately
there's
helm,
was
kind
of
crowned
for
a
little
bit,
but
now
like
because
cube
CTL
merged
customized
support
in
it's.
It's
that's
now
getting
traction
and
we
don't
want
to
completely
isolate
those
those
folks
by
building
our
tools
in
such
a
way
that
we
make
it
really
hard
to
do
dry,
run,
output.
C
B
C
B
And
I
think
yeah
like
having
the
ability
to
get
to
raw
yam,
oh
I,
think
is
important
and
that's
that's
kind
of
what
the
nature
of
my
other
comments
were
about.
I
think
we
can't
totally
get
away
from
yellow
sto
has
a
CL
is
do
CTL
that
has
a
install
command
that
allows
customization
of
things
using
like
a
dash
dash
set
flag.
That's
kind
of
similar
to
helm,
but
SEO
is
also
super
complicated
and
probably
way
more
complicated
than
velaro
is,
but
anyway
be.
You
know,
interesting
reading.
B
If
you
want
to
look
more
at
that
and
then
cert
manager
is
actually
has
a
very
similar
flow
to
what
we're
talking
about.
As
far
as
first
you
install
the
base,
and
then
you
configure
in
this
case
issuers,
which
are
essentially
like
backends
for
issuing
certs,
so
they
have
the
two-step
like
first
you
install,
but
it's
not
yet
usable
until
you
then
go
configure
an
issuer.
B
They
still
they're
using
raw
yamo.
I
think
to
do
that
stuff,
but
definitely
interesting
to
see
that
they're,
using
kind
of
a
similar
to
two-step,
install
and
configure
process.
So,
anyway,
that's
what
I
looked
at
this
morning
out,
but
throw
a
few
notes.
But
you
know
I
think
it's
helpful
to
try
and
draw
inspiration
from
other
tools
where
we.
A
B
A
Gonna
ask
about
that
if
either
of
you
had
encountered
tools
like
that,
specifically
to
say
sir
manager
specifically,
but
with
that
specific
characteristic
that
there's
a
base
system,
that's
not
really
useful
until
you
put
some
other
back-end
on
top
of
it,
because
I
think
that's
the
the
property
that
makes
our
our
approach
a
little
bit
more
complicated
as
compared
like
contour
needs
and
envoy.
But
that's
to
my
understanding.
That's
the
one
requirement!
A
A
C
B
I
agree
and
that's
you
know
from
the
beginning,
like
we,
we
asked
at
the
very
beginning
of
the
project.
We
asked
Joe
beta
for
help
on
this,
and
you
know
basically
recommended
that
we
go
with
kind
of
cute
control
patterns
which
are
very
much
like
the
command
is
the
action
and
then
flags
are
modifiers.
B
A
C
I
like
that
too,
because
you
have
two
verbs
to
action
and
you
shouldn't
have
to
think
you
know,
which
is
because
it
makes
no
sense
which
one
should
come
first,
it
just
two
random
verbs.
All
right,
thanks
in
this
yeah
I,
will
highlights
in
a
better
way
what
would
be
removed
from
we're
in
that
any
more
comments.
I
really
appreciate
this.
It
was
super
useful
and
we
went
way
over
time.
So
thanks
so
any.