►
From YouTube: Velero Community Meeting/Open Discussion - Jan 14, 2020
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
the
weekly
Valero
community
meeting
slash
open
discussion
today.
We
have
a
few
things
to
want
to
tackle
and
we
want
to
gonna
do
a
deep,
deep
dive
into
the
Valero
CLI
revamp,
but
first
off,
let's
do
some
status
updates.
I'll
share
my
screen
per
usual,
so
you
all
can
see
the
agenda.
B
So
I
sort
of
connected
with
this
work
at
the
beginning
of
last
week,
I
think
or
sometime
last
week,
went
through
a
bunch
of
it
and
just
tried
to
sort
of
figure
out
what
was
going
on
with
the
code
generation
stuff
and
also
kind
of
try
to
figure
out
how
to
break
it
down
into
a
few
smaller
pieces.
So
that
wouldn't
just
be
one
giant
PR
with
all
the
changes
so
we're
making
some
progress.
B
So
I'm
gonna
take
a
look
at
this
and
there
are
a
bunch
of
different
ways
that
we
could
implement
this
I
don't
know
if
one's
necessarily
any
better
than
the
other,
but
it
shouldn't
be
too
complex
to
actually
add
the
code
to
do
this,
hopefully
get
that
done
and
move
on
to
another
issue.
So
that's
that's
pretty
much
it
for
me.
A
B
So
now
that
we
have
this
in
I
mean
we're.
You
know
we're
publishing
our
docker
images
as
Manifest
list,
which
means
that
you
know
under
the
covers.
They
can
support
multiple
architectures,
so
we
don't
currently
have
arm
building.
But
if
someone
wants
to
add
support
for
that,
all
the
kind
of
scaffolding
is
in
place
to
add
it.
So
it's
just
a
matter
of
of
now
following
the
existing
pattern
that
we
have
in
place
and
I.
C
Think
the
arm
conversation
might
be
really
useful
for
edge
locations
or
people
that
have
you
know,
they're
looking
to
more
and
more
ARM
architecture,
kubernetes
cluster.
So
that
might
be
if
someone
from
that
community
is
really
interesting,
that
maybe
that's
something
they
can
build.
So
that
makes
sense
yeah.
B
And
we've
had
community
members
interested
in
in
the
past,
so
my
hope
is
that
you
know
someone
someone
wants
to
pick
it
up
now.
I
think
you
know.
In
the
past,
it
may
have
come
from
folks
were
like
installing,
had
running
clusters
on
raspberry
pies
and
wanted
to
run
Valero
there,
but
but
yeah
you're
right
they're,
a
bunch
of
different
use
cases
for
it.
A
B
C
C
B
C
D
All
right,
Nolan
so
spent
a
bunch
of
time.
Yesterday,
looking
at
the
CRD
migration
issue
that
Duffy
Cooley
one
of
our
field,
people
brought
to
my
attention
before
our
break.
It
turns
out
it's
a
little
bit
more
serious
than
I.
First
thought.
First,
I
thought
it
was
just
a
weird
weird,
one-off
thing,
but
it
turns
out
there's
some
issues
with
how
we
back
up
see
RDS
on
once
one
sixteen
clusters
and
so
there's
a
couple
fixes.
D
We
need
to
implement
on
the
backup
and
restore
side
that
we've
got
documented
in
the
an
issue
and
Genting
has
proposed
some
some
things
that
are
they're
kind
of
related,
but
they're
not
they're,
not
going
to
be
fixes
for
generic
CDs.
His
changes
are
just
addressing
some
valero
CRD
settings,
which
would
be
nice
to
do,
but
they're
not
required.
D
Basically,
what
we
found
was
with
CR
DS.
The
API
version
that
was
being
generated
was
not
always
accurate.
It
was
being
keyed
off
of
sometimes
it
would
be.
V
1
beta
1,
based
on
some
hard-coded
values
when
it
really
should
have
been
V
1,
so
you'd
get
some
fixes
in
there
that
won't
hard
code
that
value
and
then
for
the
restore
side.
We
need
to
make
sure
that
we
restore
whatever
was
in
the
backup
correctly
instead
of
mixing
them,
which
is
what
what
was
causing
restore
errors.
D
And
I
think
that
summarizes
that
one
Steve
is
there
anything
you
wanted
to
add
to
that.
No
I
think
think
you
covered
it
pretty
well:
okay,
yeah,
so
yeah
we
need
to.
We
need
to
get
the
fixes
actually
written
up
for
this
and
then
test
them
to
make
sure
we're
doing
the
right
thing
and
then
get
v1
to
one
out.
D
I'm
still
not
sure
we
want
to
do
because
that
moves
our
minim
I
think
that
moves
our
VIN
minimum
version
up
to
116.
Excuse
me
kubernetes,
which
may
bump
us
up
too
much
but
I
think
the
fixes
we
were
talking
about,
fixes
everything
that
the
Steve
and
I
were
talking
about.
It
fixes
stuff
like
Prometheus.
It
fixes
cluster
API,
which
is
what
club
Duffy
was
running
into
and
it
would
fix
the
Valerio
Sierra
teas
that
are
that
were
breaking
when
Valera
restores
its
own
Sara
T's
into
a
cluster.
D
So
I
think
Jen
teens
pr's
work
for
Valero,
but
as
he
mentioned,
it
doesn't
necessarily
work
for
third-party
satis
that
aren't
included
in
Valero,
and
my
my
first
stab
at
this
fix
was
to
write
a
plug-in
that
processed
all
CRTs
and,
like
upward,
like
changed
the
perserve,
unknown
fields,
field,
but
I.
Think
if
we
get
the,
if
we
can
get
the
version
field
right,
then
I
think
that's
all
really
all
we
need
to
do.
A
D
We
we
don't
want
to
do
that
right
now,
not
on
the
Valero
CR
DS
like
the
on
116,
if
you,
if
you
give
it,
if
you
give
the
kubernetes
116
cluster
v1
beta,
1,
C
Rd,
it
will
behind-the-scenes,
convert
it
to
v1,
but
you
can
still
access
it
with
both
versions.
If
you
request
a
V
1
beta,
1
you'll
get
it
you'll
get
that
one.
D
D
D
B
B
I
don't
know
when,
but
because
of
the
conversion,
the
version,
the
conversion
logic
that
exists,
it's
sort
of
fine
if
we
continue
to
create
those
through
the
v1
beta
one
end
point
because
they're
they're
automatically
converted
there
is
some
different
validation,
depending
on
which
version
you
create
through,
but
but
yeah
I
agree
that
we,
you
know,
we
can't.
We
can't
drop
support
for
pre
116
clusters.
Yet
it's
that's
way
too
soon
and
we've
we've
never
been
that
aggressive.
With
our
our
version
support.
B
We
could.
You
know
we
could
add
code
to
check
which
API
versions
exist
in
the
cluster
that
bolero
is
being
installed
into
and
used.
Essentially,
the
server
preferred
version
when
we're
actually
doing
a
bolero
install.
That's
probably
the
you
know
a
more
appropriate
fix
here,
but
is
obviously
more
complex
code,
wise
than
than
just
kind
of
hard
coding,
one
version
or
the
other.
A
C
B
C
In
absence
of
a
support
statement,
people
should
not
expect,
and
obviously,
if
something
comes
comes
in
this
is
you
know,
there's
a
community
supported
projects
right.
So
it's
best
that
for
support.
If
we
can
do
it,
do
we
well
but
yeah.
We
couldn't
formalize
our
support
statement
as
well
and
and
see
if
we
can
make
it
basically
be
kubernetes
one,
for
example,.
D
But
I
also
say
that
with
a
giant
like
no
no
warranty
express
or
implied
like
I,
think
there's
there's
there's
complications
with
that
and
you
would
want
to
test
it
first
so
but
it
but
that's,
that's
a
an
option
to
try
yeah,
definitely.
D
And
then
the
the
next
one
is
for
CSI
work.
It
hasn't
been
a
whole
lot
of
progress
on
that
I
know.
Sheesh
has
been
kind
of
trying
to
get
started
on
on
CSI,
just
getting
an
environment
set
up
based
on
some
of
the
changes
we've
seen
to
the
external
snapshot
or
code
base.
Jing
is
not
on,
but
drivers
are
no
longer.
It
appears
at
least
that
drivers
are
no
longer
deploying
the
external
snapshot.
D
Er
are
the
snapshot
controllers
they
used
to,
but
now
with
the
the
2.0
code
base,
it
looks
like
the
recommendation
is
that
you
install
the
snapshot
or
yourself
at
least
for
the
time
being
so
I
think
the
next
step
here
is
going
to
be.
We
get
a
prerequisites
document
for
velaro
put
together
and
say:
do
these
things
first
so
install,
and
you
know,
okay,
get
your
kubernetes
cluster
running,
get
external
snapshot
or
2.0
installed
and
then
get
your
driver
and
the
driver
I'm
gonna
be
purposefully,
vague
there,
because
each
vendor
has
their
own
requirements.
D
D
E
So
we
can
I
think
just
jump
to
the
discussion
topics
I.
There
is
lots
more
to
think
about
as
far
as
the
potential
cell
line
movement,
but
I
think
this
this
that
I
listed
here
would
be
the
most
fundamental,
and
maybe
what
6/8
are
the
changes
as
well,
and
this
is
based
on
the
mostly
on
the
way,
I
think
about
the
system
in
what
I
think
when
I
know
what
make
it
easier
for
me
to
understand
intuitively
without
having
so.
The
purpose
here
is
to
how
can
we
make?
E
How
can
I
make
the
CLI
look
be
more
intuitive
so
that
users
wouldn't
have
to
rely
so
much
on
the
on
the
documentation?
It
definitely
works
now,
but
I
think
it
could
be
more
intuitive.
So
I
am
suggesting
three
things
here.
The
purpose
is
to
get
any
strong
opinion
either.
Yes,
we
love
this
or
no,
that
doesn't
sound
right,
because
what
I
really
have
to
do
is
write
up
and
write
up
any
concerns,
because
now
I'm
just
sort
of
gonna
wave
my
hands
a
little
bit
and
talk
about
it.
E
So
we
have
the
concept
of
provider.
That
is,
is
all
over.
The
system
is
on
all
of
the
documentation
in
it's
all
over
the
CLI
and
I
think
if
we
change
that
to
the
concept
of
the
plug-in
name
in
and
allow
the
plug-in
to
reflect
what
provider
that
plug-in
is
for,
for
example,
naturally,
the
plugins
that
we
maintain,
for
example
the
AWS
we
name
it
AWS.
E
So
it's
obvious
that
plug-in
is
for
AWS,
so
people
have
to
name
their
plugins
in
a
way
that
it
would
be
obvious
what
the
plug-in
is
for,
but
as
far
as
the
system
is
concerned,
we
would
not
refer
to
what
we
prefer
now,
it's
provider
we
would
refer
instead
to
the
plug-in
name,
I.
Think
eliminating
this
word
provider
will
make
things
more
clear.
It
will
make
it
so
we
understand
what
we're
really
I
mean.
Technically,
what
we
really
are
using
is
the
plug-in
name.
Is
we
just
name
calling
it
a
provider?
E
B
So
is
with
this
specific
with
it
specifically
before
the
field
that
no
one
mentioned
here:
the
speck
dot
provider
field
within
the
backup,
storage,
location
and
volume
snapshot
location.
Are
there
any
other
places
that
there
would
be
a
similar
change,
I'm
just
trying
to
to
make
sure
I
kind
of
understand
it.
E
Would
be
yeah
see
what
before
it
would
be,
I
would
change
her
everywhere
I
would
it
would
be
for
that
field?
Definitely,
and
also,
if
we
jump
ahead
to
the
turn
of
bullets.
I
think
I
forget
about
right
now,
when
we
we
do
an
install
I
mean.
Another
thing
is
that
I
would
like
to
separate
a
like
the
sticker
separation
between
commands.
There
are
conceptually
config
commands
and
group
those
that
right
now,
I
earn
I,
earn
the
install
comments.
That's
I'm
talking
about
the
second
bullet
now
group.
E
Those
are
there
are
Valera
config
command
and
nothing
that
I'm
talking
about
here
is
I,
don't
think.
Anything
here
is
necessarily
my
brand
new
britain
idea,
I'm,
mainly
grouping
I,
a
lot
of
ideas
that
other
people
have
talked
about
myself
included
but
I'm.
Just
this
is
a
compilation
of
things
things
that
we
talked
about
before.
E
So
no
I
don't
want
to
take
credit
for
any
of
this,
but
I
think
these
are
things
that
make
sense
so
commands
under
config
command
instead
of
bestow,
especially
because
when
I
think
about
an
install
is
a
one-time
thing
you
install
and
that's
it,
but
our
install
commands
essentially
works
as
a
what
I
think
of
as
a
config.
It
commands,
for
example,
can
install
the
lair
of
the
first
time
and
then,
if
I
want
to
update
any
of
those
those
configurations,
I
can
run
install
again
in
your
updates
to
meet
that
unexpected.
E
Because,
again
to
me,
install
is
one
thing
you
do
one
time
and
then
you
configure
reconfigure
things
use
some
other
commands.
That's
how
I
think
about.
Let's
see
Li
so
I
think
it
makes
sense
to
name
those
configuration
settings,
put
them
on
the
config,
so
I'm
like
making
that
a
second
case
here,
which
is
to
use
the
config
command
and
under
the
config
command
I,
would
not
have
that
flag
provider
because
he
actually
yeah
I
think
it's
hard
to
map
what
a
provider
is
actually
is.
E
So
what
we
are
actually
talking
about
with
a
provider
flag
which
I
actually
just
recently
figured
out
is,
is
only
the
default.
What
the
default
backup
storage
should
be
pointing
to
which
is
which
is
essentially
what
it
translates
into,
what
plug-in
to
use
so
I
would
not
like
to
have
that
any
flag
called
provider,
and
instead,
if
we
jump
to
the
third
bullet
and
I
know,
this
might
be
hard
to
follow,
because
it's
a
it's
a
bit
raw
but
bear
with
me
so
that
the
third
bullets,
what
I'm
proposing
is.
E
E
It's
right
there
not
on
the
screen
it
doesn't
when
I
highlight
it,
doesn't
yeah
that
so
because
so
it
will
name
it.
What
is
the
storage
plugin
and
then
it'll
be
the
name
of
the
plug-in
and
he
might
have
to
make
so
much.
It's
so
much
more
clear
what
is
happening
with
the
system
like
we
are
connecting
to
the
plug-in
and
the
plug-in
name
happens
to
be
to
give
me
an
indication
where
the
provider
is.
E
D
D
Yeah
I
agree
with
dropping
the
the
word
provider
and
just
swapping
that
out
for
plugin
I.
Think
that's
much
more
clear,
especially
because
in
in
all
of
our
field
names
in
code,
it's
that's
essentially
what
it
is
it
it.
It
doesn't
really
mean
anything
else
in
our
system,
so
I
think
in
terms
of
that
I
agree
and
having
a
separate,
config
command.
I
think
is
also
valuable.
I.
D
E
Can
I
address
that
because
the
answer
to
that
question
like
what
are
we
optimized
for
we
need
to
know
what
do
we
optimize
for,
because
knowing
the
answer
to
this
question
of
what
we
should,
we
optimize
for
majorly
will
dictate
the
choices
we
make
for
this
for
any
CLI
improvement.
My
opinion,
yes,
I,
am
sure
that
there
would
there
cases
that
people
just
want
to
have
a
quick,
an
ability
to
just
like
type
the
shortest
possible
line
in
the
install
manually.
E
I'm
sure
there
are
cases
like
that,
but
in
the
nature
of
automation
and
help
charts
I,
don't
think
it's
valuable
to
optimize.
For
that
I
mean
people
can
just
copy
and
paste
things
if
they
need
to,
but
they
should
be
out
amazing,
most
people
who
are
seriously
using
the
system
like
this.
They
will
be
automating
and
once
you're
automating
the
things
out
there.
If
it's
for
a
long,
you
really
doesn't
make
much
of
a
difference.
E
D
It's
not
even
a
short
and
the
install
command
with
configuration,
isn't
even
short.
It's
just
it's
one
command
versus
two,
it's,
but
it's
not
a
short
command.
It's
it's
a
long
life.
It's
it's
a
single
line,
but
it's
a
long
line
and
if
you've
really
cared
about
it
being
one
line,
you
can
just
put
ampersand
ampersand
and
you
do
falero
install
all
your
options
there
and
then
Andy
and
Valerio
config
and
make
another
long
one
liner,
so
yeah.
D
D
B
B
F
E
B
E
E
To
open
a
PR
with
a
with
a
design
proposal
for
these
three
bullets
here,
I'm
going
to
expand
on
it,
so
initially
I
just
wanted
to
see
to
see
if
there
was
any
reaction
to
this
to
the
direction
of
this,
so
basically
so
take
the
the
second
bullet,
for
example.
So
the
Valero
config
would
be
what
it
is
now
Valera
install
it's
just
separating
those
flags
to
to
live
under
the
Valera
config,
so
I
don't
think
there
is
a
roomful
contention
here,
because
we
may
just
shifted
the
facts
from
one
place
to
another.
E
B
So
one
is
is
so
if
we're
moving
to
splitting
out
install
vers
configure
one
issue
that
that
immediately
brings
up
that
we've
talked
about
before
is
that
right
now,
bolero
the
Valero's
server
when
it
starts
up,
assumes
that
there
should
be
at
least
one
backup,
storage
location
configured
and
it
tries
to
validate
this
and
if
it
doesn't
exist,
it'll
essentially
crash
loop,
so
I
think.
If
we're
moving
to
splitting
them
out,
we
need
to
think
about.
You
know
if
and
how
that
the
back
end
changes
like.
B
That's
one
thing
there
and
then
I
guess
as
far
as
the
CLI
I'm
just
wondering:
does
it
make
sense
to
have
a
single
command
that
covers
both
backup
storage
locations
and
snapshot
locations?
Should
it
be
two
separate
commands?
We
also
already
have
the
like:
falero,
backup,
location,
create
and
velaro
snapshot
location
create
commands.
So
I'd
want
to
figure
out
how
you
know
any
new
commands
overlap
or
overlap
with
or
replace
those
existing
commands.
B
E
E
E
E
To
go
directly
to
these
comments
of
your
Steve,
your
comments
was:
should
we
allow
users
to
arbitrarily
create
different
combinations
of
backup
and
in
snapshots
locations?
I
think
the
answer
to
that
is
yes,
so
that's
not
something
that
I
will
write
up
right
up
on
this
lonely
PR
together
with
this
stuff,
so
we
can
think
about
Orion
comment
on.
E
E
E
Thank
you.
So
do
we
allow
the
configuration
of
arbitrary
that
backup,
storage
in
volume,
snapshots,
combinations,
I
think
the
answer
there
should
be
yes,
because
I
can
be
working
with
sir.
You
know
backing
up
this
cluster
over
here
and
then
I
might
be
Wanna
I
might
want
to
backup
the
actual
store,
the
actual
backup
in
a
cluster
somewhere
else.
So
I
think
the
answer
should
be
yes,
yeah.
B
E
B
Like
we,
you
know
you
can
already
create
any
combination
of
the
SLS
and
vs
ELLs
in
your
server,
using
the
backup,
location
or
a
snapshot.
Location,
create
command
and
I.
Think
I
completely
agree
that
we
want
to
continue
to
support
that,
but,
as
far
as
adding
that
support
to
the
Valero
install
command,
specifically
I
think
we're
saying
we're
not
gonna
support
configuration
in
the
Valero
install
command.
E
B
Well,
I
brought
up
the
you
know,
thinking
through
the
back
end
and
whether
the
server
changes
to
not
expect
or
not
require
a
BSL
to
be
defined.
It
startups,
that's
one
thing
and
then
the
other
thing
is:
if
we're
adding
new
commands,
how
they
relate
to
the
existing
valera,
backup,
location,
create
and
snapshot
location
create
command.
So
you
don't
necessarily.
C
E
E
We
somebody
else
brought
this
up
if
way
before
even
joins,
and
we
talked
about
this
a
couple
times,
so
we
should
have
a
status
command
for
the
server
to
know
is
the
server
good
to
go
as
far
as
doing
backups,
which
means
you
know
with
the
is
there
at
least
one
backup
storage
locations
of
the
capsule?
That
is
valid.
Another
thing
that
I
thought
about
was
we
make
this
bigger.
E
Heavy
there
is
a
terrace
on
the
surface
here
there
is
a
starers
on
the
backup,
storage,
location,
CIT,
but
I
was
looking
at
it
and
it
didn't
tell
me
any
I,
don't
know
I
didn't
I
didn't
feel
like
it.
So
it
was
showing
me
yields
for
information,
but
I
think
we
should
we
could
the
the
lokay
start
location
and
involves
next
charts
location
that
would
say
okay,
this.
Actually,
that
would
not
work
at
any
rate.
I.
E
D
And
there
was,
if
I
remember
when
we
were
defining
those
locations,
I
think
the
status
was.
The
intention
at
the
time
anyway,
was
to
have
the
status
for
like
when
we
were
gonna,
do
replication
and
syncing
and
stuff
across
those.
That's
why
we
put
them
there
at
the
time
we
can
use
them
for
whatever
now,
but
that's
that's
where
why
we
put
them
there
at
the
at
the
time
when
we
were
making
them.
E
E
E
This
flag,
which
is
there,
is
a
comparable
one
for
the
snapshot
locations
too,
but
so
this
flag
here
is
under
the
server.
Ideally,
people
would
I
mean
I
would
like
to
have
it
so
people
could
set
these
under
the
config.
The
little
config
set,
which
one
which
are
the
locations,
are
going
to
be
the
default
anybody
knows
at
the
top
of
their
head.
If
it's,
there
is
any
restriction
that
this
is
no
sigh.
B
So
if
you're
saying
you
want
to
be
able
to
specify
it
through
the
config
command,
where
would
you
store
kind
of
store,
the
value
of
which
one's
the
default
would
up
become
a
CRD
field?
Are
you
proposing
making
that
a
CR,
D
fielder,
or
would
you
just
update
the
deployment
to
have
the
value?
Have
this
flag
with
that
value,
I.
E
D
I
would
agree
with
that.
A
note
on
implementation.
I'm
not
saying
this
is
the
way
I'd
prefer
to
be
done,
but
the
way
kubernetes
handles
storage
classes
like
this.
They
use
an
annotation
on
a
storage
class.
To
say
this
is
the
default
storage
class.
That
said,
I.
Don't
I,
don't
know
if
they
regret
that,
but
when
you're
in
a
cluster
and
you're
like
I'm
I'm,
making
a
persistent
volume
and
I
don't
specify
a
storage
class,
it
looks
up
one
with
an
annotation.
B
I
think
we
went
through
this
whole
conversation
when
we
originally
introduced
back
introduced
locations
to
Valero
and
there's
the
the
whole
issue
around.
You
know.
If
you
use
an
annotation
or
a
field
on
the
CRTs,
then
you
have
to
deal
with.
You
know
you
only
you
want
exactly
one
location.
Do
you
have
that
that
field
set
to
true
saying
I'm
the
default,
and
you
have
to
deal
with
the
case
where
none
of
them
have
it
or
more
than
one
of
them?
Have
it
and
now.
B
D
But
it
works
around
that
with
with
this
work,
if
we're
introducing
a
controller
and
a
new
command
may
be
possible
to
get
around
that,
but
just
throwing
it
out
there
not
saying
it's
a
good
idea
necessarily,
but
just
that
I
don't
even
know.
I'm
assuming
kubernetes
has
logic
that
helps
mitigate
that,
but
that's
also
more
logic
that
is
more
complicated
than
having
a
flag
that
naturally
restricts
it
to
one.
So.
D
B
Mean
I
think
you
know
no
matter
how
we
decide
to
implement
it
in
the
backend.
We
can
certainly
have
a
flag
or
some
command
to
specify
it
right
and
you
could
even
without
changing
the
flag
to
the
valero
server
command.
You
could
just
have
that
config
command
actually
go
and
update
the
valero
deployment
yamo
to
specify
this,
this
yellow
flag
so
like
it
doesn't
have
to
be
an
either/or
I.
Think
there's
what
the
front
end
looks
like
for
the
user
and
then
with
what
the
back
end
looks
like
and
they're
two
separate
things.
Yes,.
D
I
would
agree
with
that
yeah,
so
I
I
would
agree
that
the
the
command
should
exist
and
then
how
the
command
works.
We
can
decide
later
like
whether
it
updates
the
deployment
and
bounces
it
or
it
updates
an
annotation
or
it
set
some
other
something
else
that
we
can
hash
out
later,
but
I
like
having
a
config
that
we
don't
have
to
tell
the
user
to
go
mess
with
a
buncha
gamal
directly
themselves.
F
One
talked
a
little
bit
about
the
front-end
UX
of
the
Valero
CO,
like
big
thing
and
just
wanted
to
say,
I
hope,
it's
very
similar
to
how
coop
cuddle
command
lying
in
your
face
sets
the
config.
So
you
have
config
set.
You
have
config
you
and
if
the
UX
is
really
similar
to
the
cool
kettle
controller,
binary
config
I
would
be
very
happy
because
they
would
be
just
like.
Valero
would
be
following
the
same
pattern.
E
E
F
It's
like
being
able
to
switch
current
context
or
different.
You
know
backend
plug-in
providers.
However
you
we
want
to
call
that
but
being
able
to
switch
on
the
fly.
So
let's
say
I
want
to
write
restore
to
my
Azure
cluster
from
my
DCP
cluster,
so
I
have
to
change
my
backend
and
bla
bla
bla
bla
bla,
but
just
having
this
kind
of
interface
I
think
it's
a
good
building
block
to
kind
of
mirror,
because
a
lot
of
the
end
users
of
velaro
are
gonna
have
some
background
information
with
coop
cuddle
config.
D
D
B
Think
one
thing
we'll
have
to
keep
in
mind
here:
is
you
know
if
the
cube
config
or
the
cube
cube
CTL
config
command?
Most
of
these
are
kind
of
client-side
config
settings
right
that
affect
which
cluster
you're
connecting
to
with
some
of
the
Valera
stuff.
It's
actually
server-side
configuration
so
we'll
just
we'll
need
to
keep
that
in
mind
and
kind
of
make
sure
that
you
know
that
those
patterns
make
sense
when
we're
talking
about
a
server-side
config
that
affects
more
than
one
user,
but
I
definitely
think
taking
inspiration
from
this.
B
D
B
B
D
B
B
All
right
pulled
these
from
Maine
Valero
repo,
so
if
anyone
has
any
other
shoutouts,
they
want
to
throw
out
there
from
other
repos.
Please
do
so.
We
had
to
PRS
come
in
in
the
last
week.
The
first
one
was
another
one
from
Genting
to
basically
change
our
code
to
not
log
errors.
If
CPU
and
memory
requirements
aren't
specified
for
the
rest,
ik
restore
action
and
the
the
rustic
restore
helper
container.
So
it's
basically
changing
the
code
to
differentiate
between
requirements
that
aren't
specified
versus
invalid
requirements.
B
So
this
just
helps
make
the
logging
more
intuitive
and
not
have
error
messages
popping
up
for
things.
That
really
aren't
errors
so
appreciate
that
fix,
and
then
the
second
one
is
from
Pragya
prob
who
who
has
been
working
tirelessly
on
the
the
multi
arch
and
the
power
architecture,
support
for
docker.
So
we
finally
got
this
merged
last
week,
so
appreciate
the
patience
and
the
diligence
with
with
getting
this
push
through
thanks
a
lot.