►
From YouTube: Velero Community Meeting - March 8, 2022
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
Hello
good
morning
and
good
evening
to
folks
this
is
tuesday
march
8th
in
the
evening
or
wednesday
march
9th
in
the
morning,
depending
on
where
you
are,
this,
is
the
valero
community
meeting
and
open
discussions?
So
without
further
ado,
looking
down
we've
got
march,
8th
looks
like
daniel
has
a
status
update
is
daniel
here.
A
Oh
daniel,
I
see
you
do
you
want
to
give
your
oh
he's
still
connecting
to
audio.
A
B
Oh
sorry,
I
was
setting
up
my
audio.
A
No
problem
take
your
time.
Let's
see
if
I
have
any
updates.
C
Okay,
I'm
I'm
preparing
the
rc
builder
for
one
to
one
and
we
have
summer
bugs
and
cvs.
Hopefully
we
can
make
the
ga
list
early
next
week
and
I'm
also
doing
some
fix
some
box
targeted
on
one
line.
D
So
we
tested
the
rc
172
fine.
So
if
you
want
to
go
and
tagging
it
with
ga,
that's
fine.
A
B
Yeah
last
spring,
I've
been
reviewing
some
design
prs
like
existing
resource
policy,
and
I
also
bring
the
plugin
versioning
design
back
for
review
by
scott
and
phone,
and
we
can
discuss
that
later.
I
see
phone
add
that
to
the
discussion
topics.
In
addition
to
that,
I'm
doing
some
investigation
on
the
csi
plugin
mainly
testing
it
on
the
public
cloud.
I
think
next
step
in
the
next
meeting.
B
I
think
hopefully
there
will
be
a
list
of
issues,
we're
gonna,
go
through
them
and
talk
about
the
things
we're
gonna
work
on
before
we
announce
ga
for
our
adoration
data.
A
Thank
you
for
the
update.
Do
people
have
any
questions
for
daniel,
obviously
the
plug
and
versioning
stuff?
We
can
wait
a
moment
till
we
get
to
fong's
discussion
topic,
but
any
other
questions.
D
So
so
for
that
right,
our
assumption
is
all
those
cvs
apply
only
for
the
rustic
binary,
because
that
is
the
older.
A
D
So
the
question
was,
we
found
a
cves,
but
I
think
it
was
daniel's
update
that
this
is.
These
are
all
belonging
to
the
resting
by
all
right,
because
that's
using
the
older
one
right
yeah.
So
with
that
assumption,
I
think
172
is
good.
D
F
Yeah
yeah,
so
I
have
two
topics.
One
of
them
is,
I
think
we
both
talked
about
last
week,
but
I
want
to
find
it
out
that
I
did
some
up.
I
did
some
research
additional
research
on
this
office
and,
if
you
scroll
down
all
the
way
to
the
end,
is
my
latest
command
on
it
and
this
week
in
which
is
saying
that
I
did,
we
currently
have
the
internal
plug-in
backup
for
backup,
and
in
that
we
already
for
every
single
time.
We
see
a
part
we're
going
to
collect
all
the
resistant
volume
frame.
F
F
Theoretically,
the
quality
class
and
same
thing
similar
for
the
restore
yeah.
I
think
we
can
also
do
the
same
thing
there,
so
I
think
for
this
chain.
I
think
we
can
we
can
get
it
done.
You
know
just
within
the
next
release,
because
I
think
the
chain
might
be
small,
maybe
just
a
few
lines
of
code
chain
in
the
action
dot
draw
for
backup
and
similarly
for
the
action
that
goes
in
the
restore.
F
If,
if
you
guys
think
that
is
also
a
good
idea,
I
think
we
can
go
ahead
and
and
stop
you
know
implementing
it.
What
do
you
guys
think.
G
Yeah,
I
would
I
already
commented
on
the
issue,
but
my
thinking
is
that
we
are
originally
there
was
the
earlier
discussions
already
said:
hey,
we
think
the
way
to
do
this
is
with
you
know,
a
backup
item
action
and
then,
basically,
you
discover
that
we
already
have
a
backup
item
action
that
does
something
very
similar.
We
just
need
to
do
the
same
for
one
additional
resource
type,
so
it
seems
to
me
that
it
would
be
a
lot.
G
It
would
make
a
lot
more
sense
to
just
add
one
section
to
the
execute
for
this
existing
backup
item
action
rather
than
creating
a
whole
new
one
and
registering
it
and
have
a
separate
thing
to
be
processed.
I
mean
this
would
also
you
know,
because
there
would
be
less
code
execute
as
well,
because
we're
already
running
this
for
every
pod,
and
it's
just
one
more
thing
and
also
over
time.
If
there
are
additional
resources
that
we
realize
that
pods
depend
on,
this
would
be
the
place
to
add
those
as
well.
F
F
All
right,
so
that's
that's
good,
okay,
so
the
second
issue,
I
think
we
daniel
and
scott,
are
all
here.
I
think
we
can
start
talking
about
the
valero
versioning
versioning
right,
so
I
I
did
reveal
it
and
I
approve
it.
Scott
also
approved
the
desire
right.
If
there's
anything
else,
you
can
do
on
that.
One
daniel.
B
Yeah,
I
think
I'm
gonna
tweak
the
wording
to
explicitly
point
out
that.
B
G
I
mean
just
let's
just
be
clear,
though
the
plug-in
writer
does
not
have
to
adapt
every
plug-in.
It's
that
when
you
update
the
api,
it's
the
right,
the.
When
we
create
the
new
version,
the
adapter
will
be
included
and
at
least
if
it's
a
backwards,
compatible
version.
We
say:
okay
version.
Two
is
going
to
add
this
new.
You
know
function
to
the
interface,
but
the
adapter
is
going
to
provide
a
default
implementation
of
that
for
just
as
an
example.
So
the.
A
G
E
A
G
B
G
Adapters
do
the
best
they
can
and
in
some
cases,
it'll
be
fine
and
in
some
cases
I
just
again
as
an
example
of
the
change
that
that
I
was
hoping
to
make
with
this
for
restore
item
action
with
you
know
the
waiting
for
additional
items,
the
adapter
would
basically
always
return.
True,
saying
we're
good.
There
will
be
no
waiting
so
that
that's
the
kind
of
change
that's
easy
to
adapt
to.
There
may
be
other
changes
where
it's
not
as
easy
and
the
plugins
might
be
degraded
in
some
way.
B
Yeah
yeah,
so
so
I
think
next
step,
I'm
gonna
do
some
refinement
to
tweak
the
wording
in
the
design
make
it
ready
for
review.
So
you
need
to
you
know
phone
links
guys.
You
may
need
to
approve
again
to
make
sure
that
design
is
merged
and
we
want
to
discuss
what
we
want
to
deliver
in
version.
One
nine
time
frame.
F
After
the
design
coming
in,
I
plan
to
start
implementing
for
what
dell
emc,
which
is
a
backup
item
for
bbc,
so
we
I
want
to
implement
that
first
because
of
course,
I'm
I'm
combat
company
so
yeah.
I
have
to
be
a
little
bit
selfish
there.
So
I
we
need
that
first,
so
we're
gonna
try
to
implement
that
first
and
if
scott's
interest,
he
can
also
implement
other
something
that
he
is
interested
in.
G
The
one
that's
the
one
I
was
talking
about
the
the
weight
that
there's
basically,
the
change
that
I
want
to
make
is
adding
a
single
function
to
the
restore
item,
action
interface
and
that's
the
kind
of
weighted,
the
waiting
for
off
things
to
be
ready,
and
so
that
should
be
relatively
easy
to
add
as
well.
In
the
same,
you
know
basically
the
same
time
you're.
You
know
when
you
add
the
the
timeouts
that
you
need
to
get
into
the
interface.
This
could
be
another
function.
B
Yeah,
but
there
are
some
groundwork
needed
in
the
framework
and
we
need
to
move
all
the
files
so
so
so
so
how?
How
do
we
proceed?
I
think
we
create
a
new
branch
and
work
on
it
together,
yeah
I.
G
F
Things
I
agree
with
that:
yeah.
Okay,
let's
work
together
on
that
one.
One
thing
I
want
to
point
out
here
is
the
responsibility:
one
thing
that
breaks
right
when
when
I
mean
when
we
have
the
versioning
chain
that
break
the
interface
who
responsible
to
fix
it,
so
we
want
to
spell
down
that
if
the
vendor
of
the
block
in
provide
the
old
version
and
when
we
update
to
the
new
version,
is
it
up
to
the
vendor
to
update
to
update
their
plug-in
to
work
with
the
new
version?
F
G
Well,
I
mean
I
mean
just
just
as
a
practical
concern.
We
can't
update.
You
know
plugins
that
aren't
in
the
valero
upstream
repo,
because
we
don't
have
as
a
community.
We
don't
have
commit
rights
to
someone
else's
plugin.
You
know,
obviously
you
know
if
it's
a
red
hat
plug-in.
I
can
work
on
that
one,
but
you
can't
you
know
so
whoever
is
maintaining
a
plug-in
is
going
to
be
the
one
responsible
to
update
and
create
a
new
version.
You
know,
valero
is
only
going
to
be
maintaining
things
that
are
under
the
valero.
A
So
just
so,
I
understand,
we've
got
the
sorry,
my
window,
we've
got
that
list
of
plugins
and
who
maintains
them.
It
sounds
like
it'll.
Just
want
stack
plug-ins.
A
Basically
I
mean
it's
the
same
list
here,
so
we
agree
that
basically,
the
ones
under
valera
supported
plug-ins.
These
are
the
ones
that
the
valera
team
maintains
that'll
continue
going
forward
and
likewise
the
community
supported
providers.
These
are
the
plugins
that
we're
talking
about
correct
well,.
G
Yeah
I
mean
what
we're
talking
about
with
this
change.
Is
you
know
the
plug-in
interface
itself?
Could
change.
So
you
know
we
might
have
a
v2
of
the
restore
item,
action,
plug-in
interface
and
the
adapter
that
we're
talking
about
will
should
allow
a
legacy
plug-in
to
still
work,
but
with
some
you
know,
default
functionality,
so
in
other
words,
to
update
that
restore
item
action
plug-in
anyone.
That's
it
like,
for
example,
you
know
you
know
basically
what,
if
there's
a
community,
provided
you
know
plug-in
that
implements
that
plug-in.
G
G
The
adapters
we're
talking
about
are
basically
kind
of
the
best
effort
approach
to
say
we
want
to
make
sure
we
do
everything
we
can
in
the
valero
side
to
still
work
with
the
old
plug-ins.
But
you
know
if
there's
a
major
change
to
the
interface.
That
adds
something
that's
essential.
You
know
for
operation,
you
know
that's
you
know,
then
it
would
be
up
to
the
communities
divided
and
you
know
whoever
is
maintaining
that
plug-in.
G
If
there's
an
impact,
they
would
have
to
fix
it
but
again
with
adapters,
and
I
know
for
the
changes
that
fung
and
I
are
talking
about
at
least
for
this
first
iteration
of
new.
You
know
interface
changes.
These
aren't
the
kinds
of
things
that
should
break
other
plug-ins
because
other.
A
Great
anyone
want
to
say
anything
else
about
valero,
plug
and
versioning.
Before
we
move
on
to
tigers,
such
things.
E
Hi
guys,
so
this
is
my
first
discussion
topic,
so
I
don't
know
what,
if
it's
gonna
be
like
the
right
way
to
say
things,
but
I
just
wanna.
So
so
we
are
looking
into
like
we.
So
so
someone
told
us
that
they
have
like
an
ex
by
backup
because
they
said
in
ttl
like
time
to
live
right
and
the
backup
has
failed
validation
and
they
don't
care
that
it
failed
validation
because
it
expired
already.
E
So
they
wanted
this
backup
to
disappear
like
every
other
ttl
backup.
So
they
were
wondering
if
we
could
just
delete
it
anyway,
because
it's
already
x5
instead
of
current
behavior,
which
is
acknowledging
that
it
expired
and
just
leaving
it
in
the
log.
But
the
object
still
stays
in
the
kubernetes
resource.
G
G
I
mean
that
basically,
so
normally,
when
a
backup
expires,
valero
will
delete
the
backup
contents
in
the
backup,
storage
location
and
then
remove
the
kubernetes
resource,
and
if
the
backup
is
not
valid
because
either
the
the
backup
storage
location
is
gone
or
it's
inaccessible
or
whatever
right
now,
it
sounds
like
we're
just
leaving
it
there,
and
I
can
imagine
a
use
case
for
that,
for
example,
a
user.
G
You
know
if
they,
if,
if
the
backup
storage
location
is
inaccessible
or
we
deleted
it
accidentally,
but
there's
this
you
know
backup
somewhere
taking
up
gigabytes
of
space
and
if
valero
just
removes
it
it
goes
away.
They
may
not
know
that
so
that
that
may
be
a
reason
to
keep
the
footprint
functionality,
but
on
the
other
hand,
in
the
case
where
it's
already
been
cleaned
up,
you
know
the
the
bucket's
gone
anyway,
bolero's,
never
getting
rid
of
these
things.
G
Now
it's
cluttering
up
the
valero,
you
know
backup
list,
so
I
can
kind
of
see
use
cases
either
way,
but
that
that
case
of
let's
just
leave
it
around
forever,
because
we
can't
find
this
underlying
storage,
maybe
an
edge
case.
That
may
not
need
to
be
the
default,
I'm
not
sure,
but
I
just
wanted
to
point
out
that
I
could
see.
I
could
see
arguments
either
way.
G
G
It
may
be
that
we,
the
initial
functionality,
was
this
and
someone
put
an
issue
in
saying:
hey
this
inaccessible
backup
just
gets
deleted
from
valero,
and
then,
when
we
fix
the
you
know,
the
connection
to
aws
or
whatever
it
doesn't
get
cleaned
up,
because
you
know
the
kubernetes
resource
is
now
gone.
H
Yeah,
I'm
thinking
that
that's
probably
the
the
thinking
behind
it
and
but
we
do
have
like
a
backup
delete
request.
G
H
E
G
Okay,
so
the
deletion
request
so
so
so
manually
deleting
it
may
still
work,
we're
not
sure,
and
then
I
guess
the
other
question
is:
is
this
something
that
might
make
sense
as
an
optional
setting
to
say?
Hey,
I
don't
you
know
we
just
want
to
delete
things
that
you
know
that
are
expired
regardless
of
validity.
I
can
see
a
reason
why
some
people
may
not
want
this
behavior,
but
if
this
is
a
question
of
you
know,
some
users
want
x
and
others.
G
Why
do
we
want
to
make
this
configurable
rather
than
saying
hey?
You
know
you
have
to
manually
delete
these
things.
Yeah,
I'm
not
really
sure,
but.
B
G
I
suspect
that
delete
still
works,
but
I'm
not
sure
I
mean
you
know
if
you,
if
you,
if
you
do
you
know
valeria
backup,
delete
which
creates
the
deletion
request
for
a
backup
where
the
you
know,
the
the
backup
storage
location
is
invalid.
That
may
still
delete
it.
I'm
not
sure
I
haven't
tried
it
myself.
Recently,
yeah.
B
I
I
I
personally,
I
inclined
to
the
implementation
that
you
know
if
the
manual
deletion
works.
I
think
we're
probably
okay,
because
we
are
allowing
user
to
do.
If
we
expose
the
configuration
scott
you
mentioned,
we
are
allowing
user
to
configure
it
in
a
way
that
may
cause
them
trouble
in
the
future,
but
they
are
not
fully
aware
of
the
situation
they
may
get
into
right.
B
B
B
I
mean
I
mean
if
we,
for
instance,
if
we
make
this
a
new
default,
people
may
get
into
the
situation
that
the
backup
is
removed,
but
the
storage
is
still
taken
by
the
backup
right
and
the
people
are
not
aware
of
it
by
merely
you
know,
checking
valero
if
we
expose
this
configuration
and
people
may
set
this
configuration
which
may
cause
trouble
for
them
in
the
future.
B
So
I
don't
want
to
expose
a
configuration
like
this,
because
you
know
when,
when
the
user
said
this
configuration,
they
may
not
fully
aware
the
impact
of
it.
G
Yeah
I
mean
I
it's
part
of
this
challenge
here.
Is
that
there's
really
different
there's
several
things
that
can
cause
a
backup
to
get
in
the
state,
and
some
of
them
are
the
dangers.
For
example,
you
know
a
temporary
network,
you
know,
availability
issue
with
with
the
backup,
storage
location
could
cause
this,
and
that's
the
case
where
you
definitely
wouldn't
want
to
be
cleaning
this
out
and
you'd
want
to
wait
till
the
storage
was
back
online
so
that
you
could
delete
things
properly.
G
G
That
might
make
sense,
especially
if
we
can,
if
we
can
distinguish
certain
cases
I
mean
I
don't
know
how
many
different
cases
the
current
you
know
code
distinguishes
that.
Does
this
logging,
but
again,
I
think
the
three
I
can
think
of
right
now
is
the
the
the
reference
backup
source
location
doesn't
exist
at
all
in
valero,
because
someone
deleted
it.
That's
one
case
another
case
is
you
can't
find
the
backup?
I
G
And
I
think
in
the
the
backup
social
location
is
inaccessible.
That's
that's
a
fairly
obvious
one.
You
don't
want
to
be
deleted.
I
think
I
think
if
you
can
access
it
in
the
backup,
it's
not
there,
because
you
know
someone
cleaned
out
the
bucket
there's
a
case
where
it
should
be
safe
to
delete
if
the
backup
storage
location
doesn't
exist.
That's
a
little
bit
of
a
more
iffy
case
because
I
I'd
be
inclined
to
say
that's
safe
to
delete
because
valero
no
longer
has
a
way
of
referencing
that
storage
at
all
anymore.
G
B
B
So
what
do
you
guys
think?
Do
you
agree?
If
that's
the
case,
I
think
we
can
continue
doing
some
discussion
and
the
investigation
offline
to
push
forward
for
this
situation.
I'll
add
some
common
to
the
issue.
Yeah.
G
Yeah
yeah,
I
would
say,
to
investigate
basically,
let's
we'll
take
a
more
granular
approach
of
it.
You
know
looking
at
the
currency,
the
current
use,
you
know,
scenarios
that
cause
the
logging
and
moving
on
and
not
deleting
and
then
just
once
we
get
a
list
of
the
different
scenarios
that
valero
is
currently
considering.
Let's
decide
for
each
of
those,
what
the
right
answer
is-
and
you
know
I
think
so
I
think
some
of
those
it'll
be
obvious,
we'll
all
agree
on
and
there's
other
ones
that
might
require
follow-up
discussion.
A
G
Oh,
I
mean
that
that
yeah,
that's
the
issue
we
were
talking
about.
I
think
we
were
talking
about
kind
of
you
know
details
around.
In
other
words,
I
I
think
what
we're
kind
of
leaning
towards
not
doing
exactly
what
that
issue
is
proposing,
but
possibly
taking
more
granular
approach
of
doing
some
of
that.
But
not
all
of
that-
and
we
just
need
to
continue
discussion
on
the
issue
to
kind
of
nail
down.
B
G
B
Add
a
comment
yeah
to
describe
this
equation.
A
Great
thank
you
for
bringing
this
as
a
topic.
It
is
to
you
next.
J
A
A
J
So
as
an
action
item
for
this
design,
pr
updated
if
the
command
line
updates
with
the
whatever
whatever
is
needed.
Regarding
the
implementation
details
of
a
new
flag
for
existing
business
policy
investor
cli,
then
I
also
updated
it
with
the
unrelated
proposal
goals
that
what
we
are
not
going
to
do
in
this
design,
and
I
would
like
to
know
whether
we
are
like
whether
the
team
is
okay,
with
going
ahead
with
approach
number
one.
B
B
G
I
think
that's
worth
bringing
up.
I
know
I
I
know,
and
I
had
some
discussions
around
this
offline
as
well.
I
think
I
would
I'm
inclined
to
agree
that,
let's
just
simplify
it
just
to
basically
what
we
were
describing
is
the
update
all
functionality.
That
should
just
be
the
update
and
and
basically
I
don't
think
we
really
need
a
case
where.
J
G
Don't
update
the
you
know
the
labels.
G
Yeah
yeah,
I
I
so
basically
I
think
I
think
we're
kind
of
all
agreeing
that
makes
sense.
I
think
the
one
thing
missing
is
the
bpr
itself
hasn't
been
updated
for
that
yet
or
is
it?
I
haven't.
J
I
was
just
waiting
if
everyone
is
in
agreement.
I
would
just
update
the
design
with
the
yeah.
This
will
come
got.
G
It
okay,
so
it
sounds
like
we're.
Only
all
three
of
us
are
on
the
same
page
there,
as
if
anybody
else
has
a
comment
you
know
before,
but
but
it
sounds
like
right
now
we're
all
agreeing
that
we're
going
to
get
rid
of
the
separate
update
and
update
all
immersions
into
a
single
behavior.
J
G
And
I
I
did
want
to
say
one
other
thing
about
the
the
sort
of
you
know
scenario
sort
of
the
approach,
one
versus
two
versus
three.
I
I
think
all
of
us
are
kind
of
agreeing
that
the
simpler
approach
to
set
a
single
policy
for
the
entire
restore
is
what
we
want
to
do
here
with
the
idea
that,
if
we
eventually
needed
to
take
that
more
granular
approach
described
in
that
combined
approach,
three
that
could
be
following
functionality,
for
you
know,
valeria,
111
or
whatever
sometime
in
the
future.
G
This
doesn't
and
the
approach
one
is
kind
of
the
most
friendly
towards
that
kind
of
follow-on
enhancement
anyway.
So,
let's
start
with
the
simpler
thing
that
can
be
built
on.
If
we
ever
need
that-
and
we
may
never
need
to
go
to
that
point
so.
J
K
So
I'll
update
the
pr
then
yeah,
I
think
online.
B
Yes,
yeah
yeah.
E
B
Some
comments
regarding
this
pr,
so
are
you,
okay,
with
this
agreement.
I
Oh
yeah
yeah,
so
here
yes,
the
below
one
to
below
one
and.
I
Okay,
so
so
the
thing
is
like
you
know,
we
want
our
users
to
delete
the
deprecated
resources
that
has
been
deleted
since
the
last
backup
time,
and
that
means
so
so
users
will
leverage
our
labels
to
check
which
resources
are
deprecated,
so
the
things
like.
Finally,
that
is
our
label
to
tell
users
you
can
delete
this
resources
and
what
it
sounds
like.
So
the
point
here
is
what,
if
we
failed
failed
to
update
the
label,
what
will
do
with
that?
I
G
Yeah
yeah
and-
and
I
actually
that
I
think
that
was
a
really
important
point-
that
I
thought
we
needed
to
respond
to
and
what
I
proposed
that
shabam
added
to
his
approach
here
is
basically
the
way
we
should
approach.
That
is,
if
you,
if
the
update
of,
if
the
attempt
to
update
a
label
fails,
we
should
log
that
not
as
a
warning
but
an
actual,
restore
error
that
way.
If
the
user
sees
their
restore
failed,
they
would
could
go
and
look
and
see
what
happened
and
I'm
distinguishing
the
labels
from
everything
else.
G
You
know
if
you're
updating
a
resource
and
you
couldn't
update
something
because
something
that
was
immutable
changed,
that's
a
warning
and
then
we
then
attempt
to
just
update
the
label,
but
if
all
you're
trying
to
do
is
update
a
label
and
that
update
fails,
I
mean
that
should
be
a
very
rare
event.
But
if
it
does
happen,
we
should
just
fail
to
restore
we
should.
If
the
label
update
does
not
succeed.
G
B
G
I
Okay,
so
I
just
want
to
say
that
you
know
with
this
change
of
the
design
we
have.
You
know
slightly
yeah
change
of
the
design
and
we
finally
have
a
case
that
will
fail
that
restore
job
or
the
restore.
So
if
that
is
acceptable,
I
think
it's
fine
to
me,
but
I
don't
know
whether
I
in
this
case
we
felt
the
result.
It's
okay
or
not.
G
Yeah,
I
I
actually
think
in
this
case
it's
safer
to
fail
the
restore,
because
it's
like
you
said:
if
you
don't
fail
to
restore,
you,
could
have
a
user
doing
a
label-based
delete
that
ends
up
deleting
all
those
resources
that
you
know
that
we
couldn't
have
hit
labels
on,
and
that
would
be
disastrous
for
the
user,
whereas
if
it
failed,
they
have
to
go
and
look.
And
if
you
know,
then
they
say:
okay,
my
restore
failed.
G
The
only
failures
related
to
these
label
updates
the
only
real
impact
on
the
user
at
that
point
is
it's.
They
now
know
it's
not
safe
to
delete
by
label
anymore
and
and
again
if
they
choose
the
none
policy
where
we
don't
update
resources
that
exist
already.
That's
that's
the
you
know,
preserved.
G
Behavior
then,
we
won't
be
failing
anything
because
we
won't
be
attempting
to
update
those
labels.
B
G
Yeah,
I
mean
I
mean
that's
exactly
right,
the
the
action,
because
when
you,
when
you
fail,
you
know
when
you
create
an
error
on
a
restore,
you
have
a
message
you
put
there
and
that
message
needs
to
say:
you
know:
valero,
restore
label,
update,
failed,
you
know
and
maybe
an
additional
sentence.
You
know,
don't
don't
use
valero,
restore
labels
for
deletion
or
something
like
that
again.
G
That
our.
G
Keeping
track
of
which
restore
you
know
which
resources
are
update
up
to
date,
based
on
the
restore
right
is
now
invalid
because
of
this
error,.
B
B
Clearly,
point
out
this
scenario:
in
this
design
and
yeah:
we
explain
yes,.
G
A
G
Wants
to
use
this
feature
as
a
means
of
identifying
what
they
want
to
delete,
we're,
providing
that
valero
is
obviously
not
going
to
be
deleting
it
for
the
users
and
the
user
doesn't
need
to
delete
it
if
they
don't,
if
their
workflows,
don't
require
it,
but
we're
enabling
them
to
delete
based
on
labels
with
this
and,
as
a
result,
these
kinds
of
errors
that
we
need
to
call
out
for
them.
If
you
see
these,
you
need
to
not
delete
based
on
labels
until
you
investigate,
because.
A
J
B
Right
yeah,
I
probably
feel
that
we
providing
the
selector
and
selectors
plural,
as
the
parameter
is
really
confusing.
J
But
then
it
would
preserve
your
existing
belarus
behavior
as
well
as
add
a
new
behavior
to
valero
right.
You
cannot
actually
support
or
clause
with
the
existing
valero
behavior.
B
Yeah
yeah
yeah
yeah,
I
understand,
but
but
I
think
as
a
tool
or
cli
too.
If
I,
if
I
you
know,
add
the
help
option
and
see
a
selector
and
selectors
up
and
that
that
that
really
doesn't
look
very
good.
So
I
think
if
we
first,
I
I'm
a
little.
I
think
I'm
a
little,
I'm
not
very
sure
if
this
is
really
needed.
B
So
if
this
is
really
needed,
can
we
you
know,
make
the
current
selector
to
support.
B
You
know
different
settings
so
that,
like
we
can
support
the
in
semantic.
So
we
can
say
you
know
dash
l
x
in
a
b
c.
So
so
that's
also
implement
the
or
semantic
right.
G
What
I
don't
know-
and
should
I
maybe
or
maybe
actually,
if
dylan
may
know
more
with
this
in
terms
of
the
actual
user
running
into
this
with
the
limited
or
functionality,
because
I
know
n
would
provide
or
for
a
single
you
know,
label
like
this
label
is
one
of
these,
so
that,
but
it
would
not
provide
you
know
a
label
where
it's
where,
for
example,
you
could
say
you
know
where
component
is
valero
or
name
is
foo,
that
kind
of
or
would
not
be
supported
by
the
n
clause.
B
J
B
Yeah
yeah,
I
understand.
Maybe
there
is
a
limitation
in
the
kubernetes
implementation
that
or
is
not
supported
very
well,
but
I
think
what
I
really
hope
we
can
do
is
we
extend
the
supported
value
of
the
existing
selector
parameter
instead
of
introducing
a
selectors
which
will
coexist
with
selector,
and
this
is
really
confusing
so
so.
G
Are
you
saying
we
should
consider,
instead
of
just
using
standard,
kubernetes
selectors
come
up
with
our
own
extension?
That's
not
standard
kubernetes!
Here
I
mean
that's,
because
that
would
be
the
only
way
we'd
be
able
to
do
that.
That
might
be
confusing
too
for
users
that
are,
you
know,
expecting
kubernetes
syntax
to
work
here.
G
There's
another
possibility,
I'm
wondering
is
that,
and
maybe
this
might
help
some
of
the
confusion
is
if
we
consider
the
multi-value
one
kind
of
an
advanced
option
that
you
know
you
can,
if
you're
manually,
creating
the
valero
backup
cr,
you
can
add
it
in
there.
But
maybe
you
don't
expose
this
in
the
cli
yeah
in.
G
This
is
kind
of
an
advanced
user
situation
that
would
only
be
supported
if
you're
manually,
creating
that
valero
resource,
and
we
just
no
don't
expose
this
in
the
valero,
create
cli
yeah.
B
G
There
is,
you
know,
precedent
and
kubernetes
doing
similar
things
where
they
had
a
single
value
field,
and
then
they
added
a
multi-value
field
because
they
needed
it.
For
example,
kubernetes
it
oh
yeah,
the
the
service
has
a
cluster
ip
field,
and
then
they
added
a
cluster
ips
field,
which
is
multiple
values
yeah,
but.
G
B
G
They
had
the
same
problems
that
they
they
needed,
multiple
values,
but
they
didn't
want
to
break
backwards
compatibility
and
they
decided
that
you
know
it
was
better
to
be
for
it
to
look
slightly
confusing
than
for
them
to
break
backwards.
Compatibility
in
ways
that
would
actually
break
users
who
were
you
know,
were
using
these
values
before,
because
the
one
advantage
of
this
approach,
as
opposed
to
just
creating
a
new
api
version
and
getting
rid
of
it,
is
that
any
existing
valero
backup.
G
You
know
the
definition
you're
using
with
the
single
value
parameter
will
still
work,
doesn't
need
to
change.
This
provides
an
optional,
an
option
because
we're
basically
adding
because
right
now
the
selectors
already
have
you
know
you
can
specify
included
namespaces
and
you
can
specify
included
resources
and
excluded
resources,
and
so-
and
you
have
the
label
selectors,
and
this
provides
kind
of
we
already
have.
You
know
four
different
things
we
can
select
on,
and
this
is
adding
kind
of
a
fifth
one
that
would
be
optional
to
use.
B
Yeah
I'll
take
another
look
at
the
api.
I
think
not
imposing
it
on
the
cli
yeah
yeah
make
things
a
little
better,
but
yeah
yeah
yeah.
G
The
thing
is,
I
would
just
be
careful
about,
is
that
you
know
I
understand
the
concern
about
you
know
possibly
making
confusing,
but
you
know
I
wouldn't
want
to
tell
a
current
valero
user
that
we're
not
going
to
we're
not
going
to
make
valera
do
what
you
need,
because
some
future
user
that
isn't
even
using
valero
yet
might
be
confused
by
it,
and
I
think
we
need
to
be
careful
about
that.
Maybe
we
can
document
things
properly.
G
I
just
you
know
it's
one
thing
that
we
want
to
make
things
as
clear
as
possible,
obviously,
but
I
think
eliminating
functionality
that
we
have
current
users
that
want
because
it
might
confuse
somebody.
I
think
we
need
to
be
careful
about
that
too,
because
you
know
yeah.
G
G
Everything
just
works,
the
same
as
it
did
before,
but
if
you
read
the
new
documentation
that
we
would
need
to
produce
around
this
as
to
how
to
do
it
and
what
it
means,
this
gives
you
some
options
as
well
and
again,
because
there
are
other
examples
of
communities
where
they
have
things
that
you
know
you
have
something
with
a
single
value
and
a
multi-value,
and
they
both
co-exist
as
long
as
we
describe
in
the
api
documentation
what
the
two
of
them
mean
together,
you
know,
because
you
know-
and
so-
and
in
this
case,
what
we're
saying
in
the
in
the
design
here
is
because
these
multiple
parameters
that
we
already
provide,
you
know
included
namespaces
and
included
resources
next
leader,
basically
right
now,
every
single
one
of
those,
if
you
specify
it,
it
must
be
met,
which
means.
A
G
G
So
normally
a
user
would
not
want
to
specify
both
because
you,
you
know,
if
you're
specifying
both
that
would
be
confusing,
but
if
you
do
specify
both
they
both
have
to
evaluate
to
you
know,
select
it
wouldn't
be
it
wouldn't
be
an
error
to
select
both
it
just
wouldn't
be
something
that
you
know
would
normally
be
the
most
efficient
way
of
doing
something.
B
Yeah
yeah
and
eleanor
I
just
want
to
give
a
heads
up
that
this
will
require
some
significant.
I
mean
I
I
won't
say
significant,
but
this
will
require
some
change
in
the
documentation,
because
if
we
change
the
api
and
we
we
need
some
yeah,
I
think
there
should
be
some
clear
example
like
when
the
value
is
set
as
this
and
what
will
happen.
B
A
A
And
by
the
way,
if
you're
not
quite
sure
what
to
do,
then
we
can
talk
with
abby
and
we
can
have
you
kind
of.
If
you
give
us
the
information
abby
can
put
it
in
so
do
your
best
to
pair
the
docs.
If
you
find
that
you
have
questions,
then
we
can
do
a
separate
pr
but
be
thinking
about
the
docs
as
you
do.
It
good
call
out
daniel.
A
G
As
well,
and
also
the
you
know,
the
the
probably
even
more
so,
but
I
I
actually
the
other
thing
we
were
talking
about
with
the
plug-in
versioning.
That
obviously
needs
to
be
pretty
prominent
in
our
plug-in
documentation
as
well.
Once
that
gets
implemented.
A
Now,
by
the
way
I
do
see,
we
have
only
10
minutes
left
and
I
I
know
that
young
hue
had
some
stuff
to
present,
although
it
could
wait
till
next
week
or
two
weeks
he
had
said
so,
we
can
either
pause
this
conversation
if
we
feel
like
we're
basically
done
or
we
can.
Basically,
I
want
to
do
a
time
check.
Shall
we
go
on
to
young
way
or
shall
we
keep
going
with
this.
J
Just
one
thing
daniel:
could
you
just
comment
on
the
pr?
If
you
think
we
are
good
with
this
like
after
you
take
a
look
at
it,
another
look
at
it.
It
would
be
great.
A
Great
excellent,
oh
okay!
I
didn't
okay
and
now
for
the
last
yonkoy
and
ming
have
this.
So
I
can
put
it
here
so
yeah
go
for
it.
I
Okay,
I
let
me
you
know
for
this
document,
you
quite
long
and
let
me
give
some
brave
instruction
to
the
document
so
that,
if
you
are
you
twisted,
you
can
check
this
offline
and
the
purpose
of
this
comparation.
I
mean
decent
copia
and
the
rhetorical.
Is
you
know
we
first
of
all,
we
we
I
mean
with
our
office
some.
You
know
quite
some
issues
you
create
incredibly
from
radic
and
especially
the
performing
issue.
I
And
the
second
point
is
you
know,
along
with
the
enrollment
heuristic
and
no
a
moment
with
a
where
arrow,
and
we,
you
know,
have
more
requirement
to
the
to
the
right
to
the
you
know,
repository
or
something
like
that.
Not
only
you
know
to
back
up
the
file
system,
and
so
we
we
made
this
comparison
from
the
architecture
level
from
the
feature
level
from
the
implementation
level
and
also
down
some
some
tests.
I
And
here
I
want
to
only
point
out
the
at
essential
point
that
as
a
conclusion,
first
of
all,
as
I
just
mentioned-
even
even
though
it's
quite
a
long
story,
but
I
will
make
it
brave,
like
you
know,
we
want
to
back
up
every
kind
of
data
and
then
write
to
a
report
server
and
then
leverage
the
take
one
advantage
of
the
benefits
like
the
deduplication
dedupe
compression
encryption,
as
well
as
many
other
things
from
the
repos
server,
not
only
like
the
currently.
I
I
Data
mover
but
also,
like
you
know,
a
report
server,
because
if,
if
you
move
down
to
the
next
page,
you
can
see
that
from
the
architecture,
the
the
very
top
level
is
like
a
file
system
in
enumerator,
that
is
to
traverse
the
file
system.
And
then,
after
that
we
have
a
data
processor.
I
We
want
to
call
it
the
data
processor
because
we
want
it
to
work
for
every
kind
of
data,
but
and
and
at
the
bottom
it
is
the
block
repository
something
like
that.
Both
ready
rating
and
copier
have
the
same.
You
know
architecture,
and
so
so.
I
The
first
problem
is
how
we
can
if,
for
example,
if
we
back
something
not
from
file
system
how
we
can
integrate
with
with
the
the
radical
copia,
we
know
how
to
integrate
integrate
with
copia,
because
if
you
see
the
bottom,
the
second
pic
diagram,
we
can
see
that
we
can
read
the
the
data
from
every
anywhere
and
write
it
directly
to
the
c
content.
I
Addressable
object,
storage
yeah
this
place,
but
for
resig
we
don't
know
how
to
do
that
because
yeah,
if
we,
if
we
do,
if
we
do
do
it
from
you,
know
the
file
saver
level.
I
just
have
a
look
at
the
first
first
diagram.
If
we,
if
we,
if
we
do
it
from
the
file
server
level,
we
we
cannot
do
that
because
we
are
not
handling
any
file.
I
We
are
handling
any
kind
of
data
stream
from
in
from
things
like
this
blog,
but
if
we
do
that
from
the
the
the
the
the
broader
server
or
repository
server
level,
what
will
miss
the
functionality
like
variable
tanki
and
something
that
had
already
been
the
same
file
saver?
So
that
is
the
first
concern
we
have
for
the
you
know
for
the
or
our
point
for
the
comparison.
I
That
is
from
the
architecture
level
and
the
second
point
that
that
is
from
the
feature
level
and
we
can
go
to
the
next
page
filter
level.
For
the
feature
level
we
can
see
both
reticle
and
kobia
have
many
features,
but
one
key
point:
we
want
to
point
out
that
russia
don't
have
compression
and
we
treat
comparison
as
an
important
part
of
the
report
server.
I
I
mean
the
backup
report
server
because
it
is
another
important
way
to
reduce
data,
that
is,
for
the
feature
level
and
and
and
the
later
things
you
know
the
next
page.
The
later
things
is
like
you
know,
from
the
implement
implementation,
we
analyze
the
implementation
of
the
both
and
we
we
see
that.
The
conclusion
is
that
we
cannot.
We
cannot
say
copy
is
overwhelmingly
better
as
an
implementation,
because
you
know
for
some,
but
it
has
some.
You
know,
try.
I
It
is
trying
to
fix
some
problem
or
it
is
trying
to
give
some
alternatives
alternatives
to
to
fix
the
problem.
For
example,
the
the
the
important
thing
we
have
found
out
is
that
you
know
the
first
thing,
the
for
the
foul
catch,
or
I
I
mean
after
the
reticle
copyright
the
data
out
and
do
the
chunk
and
what
russia
will
do.
I
Is
it
first
save
the
data,
any
data
it
read
out
to
a
local,
temporary
temple
file
and
then
read
the
file
and
transfer
it
to
the
backend
storage
that
will
double
the
I
o
and
it
will
signify,
can
play
impact
that
the
ielts
input
or
any
you
know,
factor
of
the
I
o.
That
is
a
very
important
thing
that
we
can.
We
can
see
and
that-
and
we
don't
understand
why
russia
does
like
that.
But
that
is
a
fact,
and
another
thing
is
that
about
the
maintenance
and
the
purge.
I
That's
something
like
you
know,
along
along
the
way.
The
running
of
the
repository
we
have.
We
may
have
do
often
indexes
or
often
blocks
and
and
the
copier
automatically
do
this
maintenance,
for
you
know
for
every
24
hours
of,
for
it
actually
has
two
policies
and
it
is
automatically
run,
but
for
copyright
manually.
That
is
something
like
you
know.
If
there
is
not
automatically
you
know,
you
know
scheduler
we
will
have,
we
will
have
to
use.
I
You
know
users
about
how
to
use
a
more
repository
capacity
and
will
have
ba
or
worse
or
bad
repository
performance,
and
another
thing
is
for
the
maintenance
is
copier.
Addressing
will
lock
down
the
entire
repository
during
the
maintenance
or
data
purge.
That
is
something
we
cannot
accept
because
it
is,
it
will
take
a
very
long
time
to
do
the
maintenance
and,
along
that
time
people
will
not
be
able
to
use
the
repository.
I
That
is,
you
know
the
two
things
that
we
may
think
radical.
Our
copyright
is
better
than
arrested
and
for
other
things
we
we
see
that
you
know
copia.
Neither
copia
and
rasul
is
doing
the
best,
for
example,
for
the
index
management.
I
mean
the
index
search
and
the
index
catch
first
of
all.
I
First
of
all,
for
the
entire
catch,
copyright
is
give
a
letter,
is
you
know,
doing
all
the
cutting
all
the
index
in
the
memory,
and
we
all
know
that
the
memory
is
not
enough,
not
a
lot
enough,
along
with
you
know,
running
reports,
how
many
data,
so
how
many
indexes
that
is
not
enough
and
for
the
copier
I
I
I
for
copia
it
is,
I
think
it
is.
I
I
But
that
is
still
not
good
good
enough,
because
because
because
the
best
way
is
you
know
to
store
the
indexes
apart,
I
mean
the
hardest
part
in
the
memory
and
there's
some
code
part
in
the
in
on
the
on
the
disk,
that
is,
for
the
index
cache
and
for
the
index
search
and
drastically
doing
the
search
in
a
linear
way.
That
is,
we
have
one
ampere
for
counter,
for
you
know
what
one
one.
I
One
million
of
you
know
that
inducts,
the
reticle
searches
one
by
one
until
you
find
a
a
missed,
a
matched
one
or
it's
fine.
I
It
doesn't
define
to
the
end,
but
and
on
the
other
hand,
the
rest
of
copyright
is
doing
it
in
a
in
a
binary
research,
and
we
know
band
research
is
better
than
the
linear
search,
but
it's
still
not
good
enough,
and
we
may
we
may
have
very
lot
of
in
that
saw.
So
it
means
that
the
best
way
to
introduce
the
more
sophisticated
algorithm
and
this
data
structure
to
handle
this.
So
for
this
part
they
say
that
neither
neither
copy
and
and
and
the
rest
is
good
enough.
I
That
is,
that
is
for
the
implementation,
and
you
can
see
the
very
big
part
of
this
documenting
about
the
implementation
and
now,
let's
go
to
the
end
of
this
document,
and
we
see
some
tests
so,
according
to
the
our
funding
of
the
implementation,
implemented
a
little
a
little
bit
down
to
the
next
stage,
yeah,
the
next
page,
okay.
So
accordingly,
we,
according
our
analysis,
analysis
about
the
implementation.
I
We
have
designed
some
test
cases
and
for
sure
that
we,
you
know
because
of
the
limit
of
the
dataset,
and
we
don't
have
a
natural
dataset.
I
mean
from
the
production
environment.
We
we
we,
we
created
some
datasets
ourselves,
so
you
know
the
data
is
limited
and
our
you
know
time
and
the
resource
is
limited.
So
we
we.
I
So
it
is
not
a
sophisticated,
you
know
task,
but
we
still
want
to
indicate
something
from
the
test
result
so
that
we
can
have
our
judgment.
I
So
the
first
of
the
first
thing
is
like
you
know:
we
found
that
sometimes
jurassic
welsh
well,
how
they
sometimes
arrested,
will
show
unexpected
behavior
or
unstable
behavior,
especially
regarding
to
the
memory
usage.
If
you,
if
you
see
the
memory
using
for
each
each
of
these
cases,
sometimes
the
memory
usage
is
very
high,
but
we
don't
understand
it
is
not
the
original
original
value
we
don't
decide.
What
is
it
doing?
That
is
the
first
thing,
and
another
thing
is
for
the
test
case.
I
If
we
have
a
look
at
the
test
case
test
case
for
4.2,
actually
we
can
see
that
that
is
for
sure
that
is
the
the
data
set
is
deliberately
created.
So
that
is
only
to
show
us
why
the
compression
works,
and
you
can
see
that
we
we
have
disabled
the
duplication
from
the
data
set.
That
is,
we
didn't
deliberately
make
some
data
set
and
the
duplication
cannot
work,
but
the
the
content
of
the
the
file
is
indeed
compressible.
I
So
we
can
see
that
for
for
the
one
tb
of
data
and
after
the
compression
is
enabled
we
have
very
less,
you
know
the
first,
maybe
the
first
role
and
we
have
very
large,
very,
very
small.
You
know
part
of
the
data
in
the
in
the
repository
that
is
for
the
compression,
and
I
know
we
all
know
that
the
conversion
you
know
this
is
a
double
wall,
a
double
double
ad
world
and
sword,
and
you
know
for
one
thing:
to
reduce
the
data.
I
As
for
another
thing,
it
will
consume
very
large
cpu
and
if
we
treat
if
we,
if
we
have
look
at,
have
a
look
at
the
case
wait
a
minute.
I
would
look
at
the
case
history.
We
will
see
that
we
will
the
note
that
the
later
one,
oh.
I
I
We
will
see
that
there
is
not
any
effect
for
the
data
data
reduction,
but
kovia
has
you
know,
consumed
more
cpu
that
that
the
the
the
case
that
the
case
that
the
conversion
is
disabled
and
the
second
row
is
the
same
copier
without
that
compression
is
not
enabled
okay
and
more
cpu
and
more
time
right.
I
So
that
is
for
the
testing
performance
testing
and
for
sure
that
the
testing
is
not
again,
it's
not
not
enough,
very,
very
limited,
but
that
I
think
that
is
what
we
can
do
at
present
and
yeah.
I
That
is
all
the
points
we
we
have
found
and
I
think,
if
you
are
interested,
you
can
check
this
talk
offline,
and
so
this
is
a
conclusion
I
have
mentioned.
The
most
point
during
you
know
just
know.
So
maybe
we
can
discuss
this
according
to
this
conclusion
later
on
next
meeting.
A
Yeah,
thank
you
so
much
for
this
walking
us
through
the
dock,
and
I
know
that
you
say
the
testing
is
is
less
than
desired.
Perhaps,
but
I
really
love
seeing
these
data
points.
I
think
this
is
very
cool.
I
would
suggest
just
because
we're
over
time,
and
also
it's
it's
a
long
dock
with
a
lot
of
information
in
it.
A
Let's
have
everyone
read
through
it
over
the
next
two
weeks
and
in
two
weeks
when
we're
back
again
in
the
this
time
for
the
community
meeting,
then,
let's
make
sure
we
have
an
agenda
item
to
talk
through
these
conclusions
and
kind
of
see
if
folks
see
if
we
can
align
around
whether
we
should
move
to
copy
in
a
future
release.
Does
that
work
for
folks.
A
Oh,
I
think.
G
A
A
Yeah
and
it
has
to
be
hungry,
why
don't
you
try?
I
don't
know
if
you
can
try
just
for
a
moment
let's,
since
we
have
tigers,
we
have
non-vmware
folks
here
to
tell
us
if
they
have
access.
What
we
should
do
for
sure
is
is
once
we
kind
of
finish
tweaking
this.
We
should
eventually
probably
move
this
to
the
wiki,
but
we
can
talk
about
that
later,
but
this
is
great.
A
I
guess
oh
sorry,
I
was
waiting
to
see.
If
sorry
I
was
well,
I
wasn't
younger,
I
was
making
it
public
now,
I'm
I'm
not
sure.
A
You
know
we
could
do
actually.
If
one
of
you
can
try
by
like
using
an
incognito
window
and
try
using
like
a
gmail
account,
then
you
can
test.
It
sounds
good.
What
we'll
do
is
if
we
can't
make
it
public,
we'll
put
it
on
the
wiki,
but
let's
have
a
go
team
in
beijing.
If
you
can
try
to
make
it
public
one
way
or
the
other
and
then
like
post
on
valerodev
that'd
be
great
scott.
Did
you
have
anything
to
say
or
last
thoughts.
G
A
Okay,
so,
as
I
said,
please,
everyone
take
a
look
at
this
if
you
can't
get
access
by
tomorrow,
north
american
time,
please
ping
us
and
I
think
we'll
have
a
really
good
discussion
in
two
weeks.
So
thanks
everyone
have
a
wonderful
night
morning,
depending
on
where
you
are
bye.
Hi,
bye,.