►
From YouTube: Velero Community Meeting - March 1, 2023
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
Okay,
hello,
everyone.
This
is
well
our
community
meeting,
March
the
first.
So,
first
of
all,
let
me
make
some
overall
status
update
for
way
one
eye
point
with
1.9:
we
have
created
another
patch
with
1.96
February,
24th
and.
A
We
have,
we
are
planning
to
create
the
new
patch
with
1.10.2
and
we
have
created
one
RC
release
and
but
we
are
still
trying
to
collect
trying
to
collect
more
candidates.
So
if
you
have
anything,
you
want
to
add
to
this
patch,
please
nominate.
A
The
next
Point
it's
the
FC
Target
by
the
end
of
next
week.
So
let's
try
to
merge
all
the
PRS
that
is
for
wave
1.11
by
that
time,
that
is,
for
the
overall
status
and
for
personal
update.
Myself
is
working
on
with
one
part:
11
PR
reviews
and
also
I'm
preparing
the
design
PR
for
a
validate
movement
platform
as
I
and
zoom
in.
B
For
me,
I
have
released
the
Valero
one
196
and
it
is
many
books
on
figure,
some
CVS
and
second
I'm
doing
the
code
backup
volumes
by
resolve
policies,
that
is
from
my
site.
C
D
I'm
mainly
working
on
some
PR
reviews
for
one
night,
but
thanks.
Okay,.
A
E
I'm
going
to
switch
the
paste
image
to
a
new
version
of
this
Choice
that
has
no
SSR.
This
will
reduce
our
effort
to
charge
the
CVS
a
second
I'm
I'm,
real,
some
PRS
yeah.
That's
all.
F
From
I
said,
I
add
two
and
in
test
cases
and
the
first
one
is
note,
Port
preservation
and
the
second
one
is
changing
PVC
storage
class
test.
That's
all
from
my
side.
G
H
Yeah
so
several
updates
to
the
the
back
of
my
Dimension
V2
controller
work,
mostly
in
response
to
the
meetings
last
week,
where
we
made
some
kind
of
designed
last
minute,
design
changes
that
we
read
to
I've,
also
updated
the
design
docs
and
the
pr
both
for
the
API
and
the
overall
feature
to
include
that
change,
and
then
some
additional
bug
fixing
as
a
result
of
testing
with
real
backups
and
plugins.
H
So
just
the
only
other
thing
with
this
is
that
we
need
to
get
this
reviewed
as
quickly
as
possible,
because
I
also
have
to
do
the
restore
side
which
is
going
to
be
smaller
than
this,
but
I've
been
holding
off
and
starting
that
because
it's
going
to
depend
on
some
of
what's
in
there
as
well
as
any
changes.
You
know
that
we
agreed
to
so
that
once
that's
approved
and
merged,
the
restore
should
be
relatively
quick.
H
I
would
hope
to
implement
and
review,
because
basically
the
logic
and
that's
going
to
be
kind
of
a
subset
of.
What's
on
the
on
the
backup
side,
a
little
bit
a
lot
of
very
similar
changes.
But
we
won't
have
to
worry
about
the
finalize
or
updating
tarballs
or
any
of
that,
because
we
don't
have
that
on
the
restore
side.
So
it'll
be
simpler.
D
H
Yeah,
priority
is
kind
of
I
mean
we
have
priority
already
exists
there,
so
you
know
basically
any
anything
that
we
add
to
Valero
core
that
uses
this
feature
we'll
need
to
adjust
the
priority
appropriately
and
any
user
or
developer
that
builds
async
plugins
on
top
of
Valero
that
aren't
Upstream,
for
example,
what
we're
doing
in
an
ODP
we'll
have
to
manage
that
in
our
own
installations
as
well.
So
but
again,
that's
going
to
be
no
different
than
any
other.
H
You
know
restore
it
because
right
now
we
already
have
to
worry
about
like
if
you
have
custom
plugins,
even
if
they're
synchronous,
plugins,
you
know
those
restore
order,
issues
matter
and
the
restore
priority
and
the
new
feature
we
added
and
I
think
it's
110.
It
might
have
been
one
nine
I
forget
nothing
to
add
the
beginning
and
the
ending
priority
list.
The
kind
of
the
low
priority
high
priority
will
give
us
more
flexibility
there
as
well,
but
again,
I
guess.
H
The
main
point
is
that
the
restore
will
be
a
simpler
PR
than
this
it'll
have
fewer
changes,
but
at
the
same
time
it
kind
of
depends
on
some
of
these
changes.
So
I
really
don't
want
to
start
that
until
this
is
merged,
so
we
don't
have
merge
conflicts
and
all
that,
so
that's
the
hope
is
to
get
this
kind
of
finally
approved
and
updated
any
additional
changes
relatively
quickly.
A
Yeah,
so
so
it
means
for
this
PR
five,
eight,
four,
nine
and
the
exactly
the
the
conflicts.
Everything
is
ready
for
more
right,
yeah.
H
Well
well,
I
mean
when
there
are
a
result
of
the
conflicts.
As
of
now
there
were
some
conflicts.
Oh
I
guess
I
should
point
out.
There
is
another
potential
for
conflicts
and
that's
going
to
be
I
noticed,
there's
the
backup
controller
refactories
controller
runtime,
depending
on
whether
this
is
merged
first
or
that's
merged.
H
First,
you
know
there's
going
to
be
some
merge
conflict
dealing
with
that
for
the
second
PR
to
get
merged,
because
since
this
code
is
changing,
backup
controller
and
that's
refactoring,
backup
controller,
which
everyone
gets
emerged
first,
the
other
PR
is
going
to
have
to
be
modified
again
to
deal
with
the
rich
conflicts
but
I'm
hope
I'm,
hoping
that
should
be
relatively
straightforward
because
even
though
the
same
code
is
changing
and
so
there'll
be
merge
conflicts,
the
context
is
going
to
be
obvious
as
to
the
kinds
of
differences,
so
it
should
be
relatively
easy
to
deal
with
that
conflict.
H
H
But
I'm
doing
that's.
My
spiritual,
complex
but
rebase
conflicts
to
have
to
rebase
to
Maine.
Oh
okay,
yeah
yeah
I
made
some
changes
today.
The
usual
clock
changed,
it
was
already
made
up,
and
the
other
controllers
I
realized
that
my
new
controllers
had
that.
So
I
had
to
change
that
as
well.
H
So
yeah,
okay,
I,
have
a
new
PR
up
today.
This
is
not
connected
to
any
of
the
asynchronous
work,
but
it
is
connected
to
the
V2
work.
H
When
we
built
the
restore
item
action
V2,
we
included
two
things
from
previously
approved
design.
One
was
the
asynchronous
changes
and
the
other
was
an
additional
return
field
and
API
method
to
facilitate
waiting
for
additional
items,
returned
and
restore
plug-ins
to
be
ready.
H
This
was
an
issue
we
created
a
long
time
ago.
Actually
that's
been
open
for
a
long
time
because
we
couldn't
resolve
it
until
we
had
plug-in
versioning.
The
design
docs
previously
approved
the
API
changes
are
already
in
so
the
restorative
action.
Api
changes
are
actually
in
this
PR,
really
just
modifies
the
controller
side.
H
So
it's
a
relatively
small
PR
because
of
that
and
the
only
other
thing
is
that
I
do
need
to
make
one
additional
change
and
Emily's
PR.
That
adds
the
resource
timeout
that
we'll
get
you
in
later.
I
need
to
use
that
timeout
in
this
PR,
so
I
have
I.
Have
a
fix
me
comment
that
I
need
to
update
to
use
that
timeout
once
it's
merged.
A
D
H
Yeah
I
believe
that's
already
on
this
111
scope
and
I
think
we
had.
Some
things
were
depending
on
on
the
red
hat
side,
for
our
release
is
based
on
111,
so
the
Hope
was
that
we
were
I
mean
it
was
kind
of
if
I'm
wrong,
but
I
think
we
do
need
this
for
our
111
right.
H
Along
that
as
well,
but
basically
one
advantage
to
that
plug
I
mean
once
that
gets
merged,
that
that
prevents,
because
my
original
version
of
this
additional
items
PR
that
I
had
again
two
years
ago
that
I
that
we
ended
up
never
merging,
because
we
didn't
have
plug
conversioning
I,
actually
added
a
new
timeout
field
for
this.
But
it's
actually
a
perfect
use
of
that
resource.
Timeout.
That
Emily
is
adding
anyway,
so
having
her
PRN
means
I,
don't
need
to
add
a
new,
a
new
configuration
field
for
this.
For
this
functionality.
H
On
on
my
side,.
A
Okay
sounds
slot
and
well
Cloud
basketball
finish
to
take
the
left
and
then
they'll
turn
to
the
new
ones
and.
H
H
Just
just
just
one
more
comment
about
my
availability
because
again
we're
trying
to
go
back
and
forth
on
this
I'm
available
tomorrow
and
then
the
last
two
days
of
the
week
I
am
out,
but
then
back
on
Monday.
So
just
keep
that
in
mind
as
you're
expecting
for
responses
from
me
both
for
this,
and
also
for
PR
reviews.
H
That's
it
for
me:
yeah
yeah,
I'm
done
yep.
Okay,.
A
Okay,
that's
for
the
item
update
so
discussion
topics.
We
have
one
from
Harmony
so
time
to
Emily.
E
A
I
Oh,
you
can
open
up
the
pr
oud.
Okay,
it's
just
a
server
setting
timeout.
So
basically,
there
were
places
in
the
code
base
where
we
had
hard
coded
some
timeouts,
so
in
case
of
large
scale
backups
and
restores.
We
were
facing
issues
in
multiple
places,
so
this
PR
caters
to
that
problem
and
gives
the
flexibility
to
the
user
so
that
the
user
can
configure
it
and
then
we
might
not
face
such
issues,
so
I
think
shown
as
well.
We
actually
discussed
about
this
prior
to
this
PR
as
well.
H
H
I
think
it
was
for
crd
processing.
D
Okay,
so
so
so
yeah
I
can
have
something
sorry,
I
haven't
had
a
chance
to
look
at
this
VR,
but
I
mean
already.
It
was
one
minute,
but
you
you
increased
the
default
to
10.
so,
but
but
but
I
think
one
minute
should
be
okay
for
most
of
the
cases
right.
I
H
For
the
resource,
timeout
I
think
that
was,
it
was
five
I
think.
Was
it
before
the
sphere
yeah.
F
H
I
think
that's
that's
still
an
open
question.
Should
it
be
five
or
should
it
be
ten?
You
know
I,
don't
think
there's
if,
as
long
as
it's
configurable
I
think
what
we
choose
for
the
default
is
not
going
to
be
necessarily
a
hard.
You.
H
Because
again,
if
you
make
it
five,
for
example,
is
the
default.
Then
users
can
bring
bump
out
of
10
or
bring
it
down
to
one
I
know
we
specifically
had
problems
when
it
was
one,
and
so
we
moved
it
up
to
five
I.
Don't
really
have
a
strong
opinion
as
to
whether
we
should
make
it
ten
versus
five
I
I
think
what
part
of
that
was
that
there
were
more
than
one
places
where
Emily
had
kind
of
conversion
said:
hey
we're,
gonna
use
the
same
resource,
timeout
and
I.
H
Think
some
of
the
examples
we're
using
one.
Some
are
using
five.
Some
are
using
ten
and
so
ten
was
kind
of
the
catch-all
to
make
sure
we
weren't
breaking
anything.
You
know
it
might
make
sense
to
bump
it
back
down
to
five.
That
may
be
something
we
can
change
later
or
maybe,
if
there's
someone
that's
you
know,
I
I,
don't
again,
I,
don't
have
a
strong
opinion
as
to
what
it
should
be
is
the
default,
but.
H
Of
the
concerns
was,
we
didn't,
want
to
add
a
whole
bunch
of
new
configuration
settings
that
would
be
confusing
to
users,
so
we
wanted
to
try
to
consolidate
this
and
to
say:
okay,
we
just
want
to
you
know
and
again.
This
is
where
the
resource
timeout
part
came
in,
because
there
were
several
several
areas
where
this
is
relevant
and
again
my
the
new
PR
that
I
just
discussed
for
additional
items
on
restore
I'm
planning
on
using
the
same
resource
timeout
there
as
well.
H
I,
don't
know
if
you
had
any
context
on
why
we,
why
we're
using
10
Now
versus
five
I
think
it's
because
at
least
one
of
the
timeouts
that
were
replacing
previously
at
10.,
yeah
I,
see
the
repo
and
share
would
use
10.
I
It
looks
like
a
repo
insurer
but
I
think
even
I.
Don't
have
a
strong
opinion.
If
you
want
that
to
be
updated
to
some
other
value
Daniel,
you
could
you.
D
H
Yeah
yeah
I
mean
I
mean
you
know.
We
need
to
have
a
default
that
way.
Users
don't
have
to
provide
it,
and
then
the
question
just
is
going
to
do
is
the
default
five
versus
ten?
Since
it's
configurable,
that's
not
a
huge.
You
know
it's
not
hugely
important,
I
guess,
because
users
could
always
change
it.
H
You
know
if,
if
they're,
seeing
things
or
timing
taking
too
long
to
time
out
that
they
really
want
it
to
be
shorter,
they
can
configure
it
and
then
obviously,
if
they're
hitting
timeouts
that
are
too
short,
they
can
increase
it.
Five
might
make
sense
as
kind
of
a
middle
ground
there.
But
again
you
know,
since
it's
configurable
you
can
basically
we
can
have
recommendations
on
the
install.
Let's
say
we
think
users
can
just
leave
it
as
default.
A
So
what
that
means,
this
timeout
will
use
for
any
internal
operations
to
create
a
resource
in
whatever,
under
whatever
contact
right,
because
here
right
now,
I
see
some
in
this
timeout
using
different
context.
Contacts
like
creating
the
backup,
repo
CR
and
creating
some
warm
examples.
Crs
right.
H
The
intent,
the
intent
is
that,
because
the
the
the
the
sorts
of
use
cases
where
we've
run
into
users,
failing
with
the
different
with
the
lower
numbers
it
tended
to
be,
you
know,
clusters
with
very
busy
API
servers.
H
That's
just
one
example
where,
if
that's
your
reason
for
hitting
timeouts
too
soon
and
wanting
to
mop
it
up,
you're
running
that
risk
for
any
time,
you're
creating
resources
or
deleting
resources,
we
actually
have
a
separate
resource
term
at
any
time
out
that
we're
not
touching
here
that
we
could
consider
in
the
future
consolidating
into
a
single
parameter
or
not,
I
mean
I.
Think
it's
because
it
already
exists.
You
know
getting
rid
of.
It
has
backwards
compatibility
issues.
H
I
just
mentioned
that
as
an
example
that
we
were
trying
to
say,
you
know
we
don't
want
to
have
a
separate
configurable
timeout,
with
a
different
name
for
every
possible
resource
that
we're
going
to
be.
You
know
we
want
a
crd,
timeout,
repo
insurer,
timeout
and
all
that.
So
if
we
just
have
a
resource
timeout,
that's
generally
used
for
creating
resources
waiting
for
updates
that
kind
of
thing
on
resources.
H
It's
mostly
related
to
the
API
server
performance
and
the
cluster,
so
in
general
it
makes
sense
that
if
you
want
that
to
be
larger
than
defaults
for
one
value,
you
probably
want
it
larger
than
the
thought
for
these
other
ones
as
well.
That
was
the
list
of
thinking
behind
doing
this,
so
that
we
didn't
have
to
add
a
bunch
of
new
configuration
values
that
needed
to
be
documented
separately
and
all
that
to
try
to
make
it
as
easy
as
possible
for
the
end
user
to
deal
with.
H
Oh,
my
cluster
is
being
slow
and,
as
a
result,
Valero
backups
are
failing,
because
they're
hitting
timeouts
and
and
there's
not
really
a
problem,
but
I
need
the
timeout
to
be
a
bit
larger.
Well,
they
can
just
update
their
Valero
deployment
with
this
resource
timeout
set
to
a
larger
number
and
restart
it.
A
So
yeah,
partly
let's
talk
about
all
these-
are
the
functional
operations
are
related
to
the
performance
of
the
API
server
and
for
another
part,
for
example,
like
this
one,
the
timeout
these
lines
to
wait
for
the
backup
repository
CR
to
get
into
the
Reddit
status,
ready
state
so
also
for
so
it
doesn't
only
mean
that
we
need
to
create
a
cumulated
object
from
the
ipso,
but
we
need
to
wait
to
validate
the
the
the
connection
right,
the
backup
story.
So
so,
partly
it
depends
on
the
ipsr.
H
That's
true
and
that's
one
that
you
could
argue
should
have
been
a
separate
parameter.
Maybe,
but
again
we
were
trying
to
balance
that
out.
I
I
would
say
at
this
point:
let's
deal
with
the
single
parameter
and
then,
if
we
find
out
later,
we
need
additional
parameters.
Maybe
we
need
one
specific
to
that.
H
H
You
know
because
it's
easier
to
add
parameters
later,
because
even
if
we
don't
make
it
separate
because
right
now
this
is
hard
coded
to
five
minutes,
not
configurable
at
all,
so
we're
changing
something.
That's
not
configurable
to
something.
That's
configurable,
along
with
a
few
other
things,
so
that
that
may
not
be
perfect,
but
at
least
it's
easy
for
the
users
to
to
tweak
it.
If
we
decide
later
based
on
you
know,
users
putting
issues
in
saying
hey.
This
is
not
sufficient.
I
really
want
this
to
be
a
different
value.
H
You
know,
then,
we
can
consider
adding
a
separate
value
for
just
refiner,
but
I
think
at
this
point
that
might
be
Overkill,
because,
let's
just
try
not
to
create
you
know
too
many
parameters
just
because
that
makes
it
harder
to
configure
and
document,
and
all
that
you
know
if
users
are
hitting
it
and
saying
Hey
I
want
this
to
be
a
different
number
and
here's
my
use
case
that
demands
it.
Then
we
can
respond,
and
you
know
add
that
as
we
need
to.
A
H
To
right,
that
is
true,
so
if
yeah
yeah
and
then
that
would
be
a
good
example
where
you
know,
if
we
actually
hit
cases
where
the
reproducture
needs
to
be
a
large
timeout,
but
setting
it
to
be
that
large
for
everything
else
is
causing
problems.
That
would
be
the
use
case
to
say,
let's
add
another
one,
but
I
think
we
need
to
see
that
kind
of
use
case
happening
before
otherwise.
H
You
know
we
could
create
a
separate
configurable
value
for
every
single
time
out
in
the
system
and
there
might
be
10
new
ones
that
we're
going
to
add,
but
if
there's
no
user
demand
for
that,
no
need
for
that.
Then
we're
adding
in
a
maintenance
difficulties
without
a
clear
benefit
yeah,
but
we
can
add
those
later
again.
H
The
resource
assignment
is
intended
to
be
relatively
generic
and
absolutely
generic,
because
we
still
have
10
things,
it
doesn't
cover,
but
I'd
say
relatively
generic
and
then,
if
we
need
very
specific
timeout
values
for
single
use
case
scenarios,
we
can
add
those
later
without
deleting
this.
You
know
we
would
leave
this
alone
at
a
new
repo
insurer,
timeout
and
then
just
change
that
line
of
code
to
use
the
new
time
out
instead
of
the
old
one.
H
But
this
this
at
least
gets
rid
of
the
hard-coded
value,
where
there's
absolutely
no
way
for
a
user
when
it's
set
to
time
times
five
a
minute
for
five
times
minutes
here,
there's
no
way
for
a
user
to
change
that
value
without
recompiling
Valero
and
making
their
own
image.
A
Yeah,
so
it's
inside
once
it's
it's
merged,
so
it's
added
and
it
can
be,
could
be
marked
out
for
for
any
operations.
We
need
to
try
to
use
this
one
inside
the.
H
Line
right
right
exactly
unless,
while
we're
writing
that
new
feature,
we
we
say
this
isn't
not
appropriate
and
here's
the
reasons
why
it's
different,
but
that
that's
why,
for
example,
for
the
pr
that
I
just
posted
today
around
additional
items.
Why
I,
even
though
my
original
PR,
that
I
had
put
together
that
was
never
merged,
had
a
separate
timeout
value?
I
realized
that
way.
H
I
have
this
new
resource
timeout
that
we're
trying
to
get
merged,
and
this
is
another
example
of
that
kind
of
resource
where
in
most
cases
it
makes
sense
to
use
the
default
or
the
same
value
rather
as
the
other
ones.
So,
therefore,
the
pr
that
I
submitted
for
that
today
does
not
have
a
new
configuration
parameter
added.
E
I
That's
it
like
we,
we
just
want
this
to
be
in
111,
so.
A
Okay,
anything
else.
We
want
these
cards
Institute.
D
So
I
believe
me
has
pinned
you
about
his
desire
regarding
the
volume
filter
policy
right.
You
guys
have
any
comment
on
that
or
I
mean
I
believe
it's
making
some
tweak
to
that
PR
today
or
tomorrow
and
after
that
I
I
think
we
are
okay
with
approval
from
you
guys
right,
Scotland
football
yeah.
H
Yeah
I
think
I
I,
think
I.
Think
I
did
comment
on
that.
I
haven't
acted
here
yet,
but
I
said
this,
so
it
was
still
kind
of
in
progress,
but
I
don't
have
any.
You
know.
You
know
strong
opinions
that
at
this
point
so
I
think
once
it's
ready
to
review.
Let
me
know
and
as
I
said
I
could
tomorrow,
I
should
be
able
to
review
it.
Otherwise
I'll
I
can
review
it.
H
Back
the
the
other
one
with
the
the
cluster
and
namespace
resources,
I
reviewed
that
earlier
and
then
makes
comments.
I
did
see
that
it
was
updated,
so
I
need
to
go
back
and
I
will.
Probably
I
should
be
able
to
review
that
again
tomorrow
and
hopefully
get
that
get
that
an
approval.
H
H
Okay,
yes,
exactly
yeah
yeah,
yeah,
I,
I
reviewed
it.
There
was
one
issue:
I
saw
that
I
commented
on
that's
been
resolved
already.
I
didn't
see
any
other
problems
when
I
looked
at
it,
but
I
will
go
and
give
that
another
review
tomorrow.
E
I
I
had
when
I
went
through
the
design,
I
I
found
it
useful
like
we
yeah,
we
do
need
the
filtering
based
on
volumes
and
as
fine
with
it.
But
I
I
had
read
some
comments
from
Ivan
I
think
he
wasn't
on
board.
I.
Think.
D
Yeah
I
think
I
think
I
talked
to
Ivan
in
another
community
meeting
and
he's
probably
okay
to
at
least
we
move
on
with
the
one
by
Ming
and
I.
I
also
told
him
that
his
design
regarding
extend
resource
filter
with
field
selectors,
probably
should
be
done
by
extending
the
the
policies
or
proposed
by
me
and
I,
think
he's
kind
of
okay
but
yeah,
but
the
one
that
he
proposed
is
really
a
bridge
change.
So
we
I
currently
don't
think
we're
gonna
do
that
in
the
very
near
future.
I
That
can
act
as
an
extension
in
later
release
right.
D
But,
but
that
I
I
call
it
opinion,
is
that
that
should
be
done
by
extending
the
inform
the
data
of
the
config
map
proposed
by
me
instead
of
adding
more
Fields
into
the
backup
filter,
because
because
what
he
proposes
is
a
break
change
to
shun's
design,
which
is
already
merged.
A
Okay,
another
thing
from
my
side
is:
we
are
going
to
create
the
available
in
data
moment.
Pr
I
mean
PR.
So
if
we
have
any
more
comments
or
requirements
on
it,
we
can
still
add
some
included
the
current
design
Dock,
and
we
will
hope
that
we
can
address
as
many
of
these
comments
or
requirements
for
in
the
initial
design.
Pr.
A
Okay,
that's
it
any
other,
any
other
things.
A
If
not
I
think
we
can
think
of
here
thanks
for
joining
the
meeting
have
a
good
day
and
a
good
evening.
Thanks.
Thank.