►
From YouTube: Velero Community Meeting - November 9, 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
Okay,
hello,
everyone
today
is
November
9th
treated
below
committee
meeting
and
first
let
me
update
some
status
so
for
1.9.3
we
are
planning
to
grades,
as
they
told
today
on
November
9th,
because
we
have
adopted
the
new
method
to
scan
cves
and
so
we
need
to,
and
so
we
need
to
fix
more
CVS.
A
That
is,
we
have
scanned
both
ways,
so
we
need
to
fix
them,
and
particularly,
we
want
to
compile
radic
neurotic
by
ourselves
to
with
the
with
the
newer
co-library,
so
that
we
can
fix
quite
some
of
the
cves,
and
that
means
we
need
to
adopt
the
new
make
method,
and
that
takes
some
time.
So
we
decided
to
create
rc2
for
1.94.3
and
currently
in
most
work
has
been
done
so
without
we
will
be
able
to
create
attitude
today
and
for
1.10.
A
What
about?
And
we
also
plan
to
release
last
event
today,
and
but
we
will
decide
whether
we
need
to
shape
all
the
tangents
in
1.9.3
directly.
If,
yes,
we
may
need
to
take
some
time,
maybe
one
or
two
days
to
wait
for
the
changes
already.
If
not,
we
will
directly
cut
the
branch
today.
A
Okay,
that's
the
our
status
personally
I'm
working,
110
and
I
also
make
some
preparations
like
to
release,
notes
and
document
the
changes.
That's
on
my
side
for
personal
update
and
the
next
one.
Please.
B
A
Okay,
thanks
and
Jimmy.
C
Yeah
first
I'm
doing
the
one
thing
in
the
193
manual
test.
Second
I'm
enabled
depend
about
for
security
issue.
Check-In
fix
third,
releasing
one.
Nine
three
rc2,
which
many
focus
on
Golden
runtime
CV
fixed
by
bump
up,
go
down
the
room
to
118
and
we
compile
Valero
and
rustic
by
a
new
higher
dollar
version.
Yeah.
That
is
from
my
side.
A
D
Yeah,
so
the
the
main
thing
that's
still
open
is
that
async
action
plug-in
design.
There
were
some
comments.
Last
week,
I
responded
to
those.
In
some
cases,
I
made
modifications
to
fix
some
of
the
problems
identified.
There's
one
open
question
still
I
believe
it
was
Daniel
that
suggested
he
thought
there
was
some
confusion
because
one
of
the
fields
in
the
operation-
progress
of
X2
fielders
to
integer
fields
to
as
items
completed
and
items
to
complete.
D
So
there's
a
you
know,
total
amount
done
and
total,
like
the
amount
done
this
so
far
in
the
total
amount
done
and
I.
Think
part
of
the
confusion
is
it's
kind
of
up
to
the
plug-in
what
those
numbers
like
the
units
are
because
if
you're
doing
a
you
know,
if,
if
we're
talking
about
a
PV,
then
you're
probably
talking
about
bytes
or
kilobytes,
or
something
like
that.
D
But
if
it's
some
other
kind
of
plug-in,
it
might
mean
something
completely
different,
so
Daniel
had
suggested
instead
of
having
those
two
fields,
we,
you
know
to
say:
okay,
five
out
of
10
or
300
out
of
5
000
done
just
have
a
string
field
where
the
plugin
would
provide
that
you
know
in
a
user,
visible
text
that
you
know
we,
so
you
could
say
three
kilobytes
out
of
1.2
gigabytes
completed
or
something
like
that.
D
D
The
only
disadvantage
to
the
string
approach
is,
it
means
Valero
is
not
going
to
be
trying
to
parse
that
string.
So
you
know
we're
not
going
to
be
reporting
percentages.
The
users
we
just
need
to
read
the
in
the
string,
but
that's
probably
okay.
D
So
if
anyone
else
has
any
opinions
as
to
whether
they
prefer
the
weights
in
the
design,
dock
or
they'd
rather
take
Daniel's
suggestion
and
use
a
string
field
instead
of
those
two
Fields
and
just
include
that
on
the
review,
and
we
can
kind
of
figure
out
what
makes
sense,
I'm
open
either
one
I
don't
really
have
a
strong
opinion,
so
kind
of
whatever
the
consensus
is
is
fine
for
me
on
that
particular
question.
A
D
These
are
numbers
for
us
for
a
single
item,
so
you
know,
for
example,
if
this
is
a
data
mover,
backup,
item
action,
where
you
have
a
three
gigabyte
volume
that
we're
you
know
that
we're
uploading
to
cloud
storage
from
the
data
mover
these
fields
would
be
showing
you
know
two
kilobytes
out
of
three
gigabytes
completed,
and
so
those
numbers
are
in
the
context
not
of
the
overall
backup,
but
in
you
know,
in
other
words,
it's
progress
for
a
single
item.
Action,
not
progress
for
the
backup
as
a
whole.
So
we
don't.
D
We
don't
currently
have
any
reporting
for
that
anyway,
so
this
will
be
new
recording
anyway.
So
you
know
at
the
most
we'd
be
showing
you
know
some
information
for
each
item,
so
we
could,
in
theory,
just
display
those
strings.
D
I
I
don't
know
that
the
percentages
would
matter
that
much
because
we
can't
necessarily
aggregate
them
across
all
of
the
items
anyway,
because
the
units
might
not
be
the
same
because
you
know
you
might
have
one
item
action,
that's
a
volume,
item,
action
and
so
we're
talking
about.
You
know
gigabytes
of
data
involved
here
and
you
might
have
another
item
action.
That's
completely
different
action
that
you
know
where
those
numbers
mean
something
else
so
I
don't
know
that
Valero
would
be
aggregating
these
numbers
anyway,
it's
more
likely.
D
So
so
I
don't
know
that
there's
a
huge
Advantage
either
way.
But
the
context
here
is
that,
when
the
plug-in,
when
Valera
calls
back
to
the
plug-in
to
say
Hey,
you
know
give
me
progress
as
it's
done.
What
matters
really
to
the
Valero
controller
is
not
that
that
status
field
Valera
just
wants
to
know
the
Boolean.
Is
this
done
or
not,
and
was
there
an
error?
If
it's
done
and
there's
an
error,
we
move
the
backup.
You
know
that
then
we
log
that
as
an
error
on
the
backup
partially
failed.
D
If
it's
done,
there's
no
error,
then
it's
completed
and
if
it's
not
done,
then
we're
then
we're
still
in
that
state
of
you
know
waiting
for
from
plug-in
operation.
So
the
the
actual
progress
Fields.
D
D
So
so
I
don't
know
that
it's
a
huge
important
question.
You
know
from
Valero,
but
if.
E
D
E
A
Yeah
yeah,
so
so
the
question
is:
if
we
have
a
place
that
to
show
the
the
percentage
for
a
backup,
but
if
we
have
multiple
in
parallel
backup
item
actions.
So
how
do
we
calculate
the
entire
percentage
so
because.
D
Yeah
and
I
don't
even
know
that
we
would
need
to
or
want
to
calculate
that
because
again
I
don't
think
we
can,
because
we
could
have
different
kinds
of
backup
or
plugins
anyway.
So,
even
if
we
have
those
integer
numbers,
I
don't
think
we
can.
It
wouldn't
be
really
meaningful
to
add
all
those
things
up,
I
think
at
the
Valero
backup
level.
All
we
really
care
about
is
how
many
actions
are
completed
versus
not
completed,
and
so
we
so
that,
and
for
that
information
we
just
need
that
Boolean
field.
D
This
is
something
that's
probably
going
to
be
embedded
in
a
log
somewhere
or
in
a
status
field.
It's
not
something
we're
going
to
be
adding
up
over
the
whole
backup,
because
I
don't
think
that
would
be
very
meaningful
to
an
end
user
as
a
number.
A
Yeah
you
play
focus
on
the
data
more
scenarios
only
for
the
bi
or
I.
So
if
you
users
have
five,
for
example,
five
gbo
data
to
backup
and
that
will
that
scattered
in,
for
example,
10
volumes
and
that
will
take
a
for
example
half
an
hour
or
we
have
one
TV
of
data
that
will
take
one
one
hour
right
so
users.
Well,
it's
a
good
idea
to
show
a
percentage
for
users
right.
D
And
that
was
kind
of
my
thinking
of
keeping
the
values
as
they
were,
but
but
Daniel
was
concerned
that
it
would
be
confusing
to
users
if
we,
if
we
left
it
that
way,
another
possibility,
I
didn't
mention
it,
and
then
the
NPR
is.
If,
if
the
objection
was
hey,
I,
don't
know
what
these
numbers
mean,
because
it
might
mean
bytes
in
this
plugin.
It
might
mean
something
completely
different
in
another
plug-in.
Another
thing
we
could
do
is
add
a
third
field
which
would
be
like
a
description
field
or
a
unit
field.
D
So
we
could
say
what
are
these
means
because
we
have
two
integer
Fields
saying
total
and
completed,
and
then
we
can
have
another
field
of
saying
you
know
what
is
this
thing
what's
the
unit
and
that
would
be
bytes,
for
example,
for
data
mover,
and
it
might
be
something
else
that
might
be
you
know,
I,
don't
know
number
of
something,
I
just
don't
know
because
I,
don't
we
don't?
We
don't
really
have
in
a
ready-made
use
cases
for
this
other
than
right
now.
D
Data
mover
and
volume
snapshotters
and,
in
those
cases
we're
talking
about
volumes
where
bytes
make
sense,
but
you
know
we
intentionally
made
this
flexible
enough
so
that
you
know
if
someone
wants
to
make
a
plug-in
for
actions
that
are
moving
some
other
kind
of
data.
That's
not
volume
data
it
might.
There
might
be
a
different
unit
of
measure
that
makes
sense
there.
So
what
we
could
do
is
leave
those
fields.
D
You
know
items
completed
and
items
total
or
whatever
those
are
and
add
a
third
field
that
says
items
unit
which
allows
the
plug-in
to
specify
what
this
means
that
way.
If,
if
we
decide
to
aggregate
them
from
a
Valero
point
of
view,
we'd
only
aggregate
them
if
those-
if
if
they
were
all
the
same.
D
D
So
that's
another
thing
we
could
do
is
leave
the
two
Fields
there.
You
know
as
integers
and
then
just
add
a
new
field
to
that
struct.
That
will
clarify
what
it
is:
we're
measuring.
D
It
was
items
completed
and
items
and
I
think
he
thought
it
was
confusing,
because
we
also
use
items,
for
example,
to
refer
to
resources,
kubernetes
resources-
and
in
this
case
they
are
not
Cuban
industry
sources
which,
because
we're
we're
in
the
data
mover
we're
moving
bytes
we're
moving
data
in
on
a
volume.
So
the
progress
for
a
volume
is
not
the
number
of
kubernetes
resources,
we've
moved,
but
the
amount
of
data
we've
moved.
F
Yeah
I
think
generally
in
the
design.
We
want
to
make
this
background
operation
by
bia,
generic,
so
by
generic
for
a
generic
operation,
the
progress
may
be
represented
in
different
ways
right.
They
may
be
represented
in
bytes
in
unit
in
items
or
maybe
the
progress
cannot
be
represented
by
just
two
numbers.
So,
given
we
want
this
flexibility
to
make
the
operation
generic
we
have,
we
should
also
provide
a
flat
flexible
way
to
let
users
decide
how.
D
They
represent
it,
I
mean
if
we
did,
if
we
did
that
and
just
got
rid
of
the
two
numbers
and
then
just
use
a
string
that
that
would
that
and
then
I
think
in
the
data
mover
use
case.
What
that
would
mean
is
the
data
mover
instant?
So,
for
example,
if
you
had
you
know
10
megabytes
out
of
three
gigabytes
completed
with
the
integers
you
would
put
in.
D
However
many
bytes
those
you
know
amounted
to
in
those
fields,
but
with
a
string
you
would
just
generate
the
string,
that's
human
readable
that
says
10
megabytes
out
of
3.0
gigabytes
completed
and
that
would
get
logged
or
put
on
a
status
or
something,
and
that
would
just.
C
D
F
I
I
would
I
would
say
that
would
be
the
string
of
protein
still
possible.
For
example,
we
can
document
that
you
need
to
represent
the
string
as
a
Json
and
if
you
want
Valero's
controller
to
parse
it
correctly,
but
Json
has
to
be
in
a
certain
format
so
that
for
the
data
over
case,
we
can
pass
the
string
in
pass
the
Json
screen
in
the
backup
controller.
So
Bolero
is
still
you
know
able
to
do
the
calculation
for
data
mover
for
other
generic
operations
that
the
level
does
not
understand.
F
D
D
Think
if
we
want
to
calculate
this,
I
think
we
want
to
it
might
be
better
to,
or
it
maybe
even
make
leave
the
integer
Fields
there,
but
leave
them
as
optional,
so
that
so
a
plug-in,
that's
not
going
to
make
a
calculatable
progress
can
use
a
string
field
that
will
never
be
parsed,
and
so
maybe
we
leave
both
fields.
D
D
I
think
that's
right,
so
maybe,
instead
of
items
completed,
we
can
say
bytes
completed
bytes
total
and
then
we
have
a
description
and
then
make
it
clear
in
the
API
definition
that
you
know
the
bytes
part
is
optional
and
if
it's
an
integer
that
you
leave
blank,
it
just
shows
up
as
zero.
But
you
know
it
won't
show
up
zero
out
of
zero.
Valera
knows:
okay.
If
the
total
is
zero,
it
means
we're
not
parsing
this.
D
It's
not
something
that
the
plug-in
is
supplied,
but
you
know
we
have
an
integer
descriptive,
so
we
have
a
string
description
of
putting
a
progress,
description
or
something
which
will
allow
the
plugin
to
describe
in
a
human
readable
way,
what's
been
done,
what's
left
whatever
so
so.
In
that
case,
I
think
sounds
like
if
we're
agreeing
on
that
I
think
that
means
there's
two
changes
to
the
current
design.
One
is
that
we
change
the
names
of
those
fields
to
say
bytes
instead
of
items
to
make
it
clear.
D
A
second
would
be
to
add
a
description
field,
so
a
plug-in
could
choose
to
use
the
description
field
instead
of
the
the
bytes
Fields.
Does
that
does
that
work.
F
I
think
that
worked,
but
personally
I
prefer
the
Json
approach
but
yeah
I.
Think
all
the
other
guys
comment.
D
Yeah
I'm
just
thinking
I
guess
I
can
approaches
that
you
know.
If
all
we're
doing
is
the
bytes.
You
know
parsing
for
for
the
data
mover
and
volume
snapshotter
case
I
think
that's
adding
parsing
overhead
that
we
don't
need
to
add
when
it's
just.
F
E
D
F
I
understand
but
but
the
Json
approach
you
can,
you
know,
extend
to
other
cases
once
they
emerge
right.
I
mean
we
just
write
some
code
in
Valero
to
try
to
pass
the
data
in
a
different
way
to
you
know,
understand.
What's
going
on,
but
yeah
I
don't
have
a
very
strong
opinion.
I
think
either
will
work.
D
E
D
I
left
it
the
the
the
design,
but
hopefully
we're
at
the
point
now,
especially
now
that
I
know
we're
going
to
be
doing
the
we're
going
to
be
making
that
110
release
Branch
this
week.
D
Merged
once
we
have
the
one
timber
release
round.
C
D
Hopefully,
once
we
get
this
resolved
and
figure
out
kind
of
an
agree
on
what
we
want
this
to
look
like,
maybe
we
can
be
at
a
point
where
we
can
finalize
this
and
say:
okay,
this
is
approved.
These
follow
one
designs,
the
plug-in
versioning
API
designs
should
be
easier
to
review
Once.
This.
F
D
Is
approved
because
it's
basically
just
the
the
the
Proto
buff
code
and
kind
of
design
for
what
each
one
looks
like
so
I
think
those
should
be
relatively
straightforward,
but
let's
focus
on
getting
the
the
main
one
merged
first
and
then
we
can
look
at
the
others,
because
you
know
any
changes,
for
example,
that
I'm
making
to
this
operation.
Progress
that
we're
talking
about
that's
going
to
change
those
design
PRS
as
well,
because
you
know
that's
where
this
is
spelled
out
in
more
detail.
Yeah.
E
D
Yeah
and
I
I'll
just
mention
it
briefly.
We
again
we
don't
need
to
go
into
it
yet
because
again,
this
this
kind
of
follows
on
from
the
other,
but
I
now
have
two
PR's
out
there:
draft
PR's
for
what
the
implementation
would
look
like
for
the
backup
item,
action
for
startim,
Action,
B2
and
again
those
are
going
to
change
with
any
changes
in
the
designs,
so
they're
not
really
ready
for
review
or
merging.
Yet.
E
There's
the
only
item
I'm
working
on
for
OSI
Miller
is
the
content
manual
testing,
yeah.
A
So
that's
all
for
the
update.
So
are
there
any
discussion
tablets
today.
A
A
Okay,
if
not
I,
think
we
can
finish
off
here
today,
so
Santa
Clara
have
a
good
day
and
a
good
day
evening,
thanks.