►
From YouTube: Velero Community Meeting - May 25, 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,
good
morning,
good
evening,
welcome
to
the
community
meeting
in
the
beginning
time
zone
for
project
valero.
Welcome
back
for
folks
who
joined
kubecon
eu.
If
there's
any
interesting
topic
in
the
area
of
data
protection
feel
free
to
share
us
in
this
app
and
for
today's
status
update,
I'm
mainly
working
on
the
issues
and
prs
to
prepare
for
the
1.9
feature
complete.
A
I
think
there's
only
one
issue
left
the
4932
after
this
one
is
merged,
we'll
we'll
announce
the
feature
complete
for
level,
one
nine
and
after
that,
we'll
spend
around
two
weeks
to
do
some
manual
testing.
So
in
that
period
of
time,
we'll
only
accept
pr
for
the
bug
fixes,
targeting
one
nine
to
the
main
branch
and
after
that
we'll
take
our
c
and
cut
a
release
branch
and
then
any
new
pr
will
be
accepted
to
the
main
branch.
A
That's
the
status
from
my
side
and
the
general
status
for
the
future.
Complete.
B
B
B
B
C
A
So
how
about
yeah?
Let's
give
the
other
maintainer
some
time
to
review
the
design,
and
we
can
maybe
work
through
that
in
the
next
meeting,
so
that
that
one
probably
is
the
biggest
one
for
we're.
Gonna
do
for
the
next
release:
110,
I'm
gonna,
so
that
generally
we're
gonna
reuse.
The
crs
that
were
introduced
for
rustic,
we're
gonna
reuse,
the
repository
and
power
volume,
backup
and
resource
ers,
but
we're
going
to
make
them
work
for
both
red
city
and
copia.
A
And
so
for
110,
the
plan
is
we're
going
to
keep
both
copy
and
drastic
when
when
10
is
released
and
so
user
can
choose
either
a
copy.
Our
rest
gather
a
backup
repository
for
the
file
based
volume,
backup
and
after
that.
If
the
we
think
the
copia
is
in
good
quality.
The
cochlear
integration
is
in
good
quality.
We're
going
to
phase
out
the
rustic
support,
so
probably
in
1.11
or
1.12
valero
will
remove
the
support
horizon.
Currently.
Is
the
plan
right?
A
Yes,
yeah?
So
yes,
scott
and
phone
for
whoever
is
interested.
Please
take
a
look
at
this
pr
and
we
can
discuss
that
on
the
slack
or
the
next
community
meeting.
D
A
Anyone
else
has
any
status,
update.
E
Yeah
I
just
want
to
update
on
the
versioning
plugin.
So
thank
you.
Thank
you,
scott,
for
giving
me
a
tip
on
slack
about
the
prototype.
I
mean
the
proto.
I
was
able
to
move
on
and
still
still
have
problem
right
now.
I
think
I
I
chatted.
E
I
chat
with
scott
on
on
on
slack
about
it,
but
at
least
I
got
unblocked
for
now
and
then
I
was
able
to
continue
with
the
coding
the
rest
of
the
versioning,
so
hopefully
that
by
maybe
by
the
end
of
the
you
know
before
the
memorial,
I
can
get
some
of
the
code
that
in
some
state
you
can
so
that
I
can
test
it,
but
I
will,
I
think
I
agree
with
scott
that
I
will
not
merge
the
code
until
I
figure
out
the
the
proper
fix
for
the
proto
in
generatic
go
code
for
this
plugin.
E
So
I
would
that
is
an
update
for
now.
D
Yeah-
and
I
was
just
gonna-
add
to
that
with
the
thing
it's
the
thing
we
ran
into
is
that
previously
all
of
our
proto,
the
protobuf
code,
has
been
in
a
single
package,
a
single
directory,
and
so
the
includes
were
all
within
the
current
package.
So
there
were
never
any
issues
with
imports
and
part
of
moving
to
the
versioning
is
that
we
now
need
multiple.
D
You
know
separate
include
packages
rather
separate
packages
with
separate
include
paths,
and
that
means
you
know
setting
some
directives
around
this
and
we
definitely
need
to
get
that
worked
out.
One
other
thing
dave
had
mentioned
and
he
was
just
been
in
the
conversation
as
well
and
he
he
was
pointing
out
that
we're
on
a
kind
of
older
version
of
the
google
protobuf
code
and
then,
as
far
as
he
was
aware,
the
newer
versions
actually
support
multiple
include
pass
better.
D
So
there
might
be
some
value
in
upgrading,
but
his
concern
was.
It
would
be
a
big
change,
so
you
know
we
might
want
to
look
into
that,
but
if
we
can
get
it
working
without
a
major
change
to
that,
that
may
be
better.
D
On
the
other
hand,
now
that
we're
making
a
major
change
with
the
rearrangement
to
do
the
versioning,
if
we,
if
we
do
think
we're
going
to
eventually
need
to
upgrade
that
it
actually
might
be
better
to
do
that
all
at
once
since
we're
having
to
move
all
this
code
and
refactor
it
anyway,
it
might
be
worth
spending
a
little
bit
of
time
investigating
whether
moving
to
a
newer
version
of
the
protobuf
will
make
this
easier.
D
I
just
don't
know
how
extensive
those
changes
would
need
to
be,
and
something
else
related
here
too.
That's
a
challenge
with
the
current
code,
because
I
ran
into
this
with
one
of
the
changes
that
we
want
to
make
in
the
v2
for
the
restore
item,
action
that
to
fix
the
use
case
that
I
ran
into
a
while
back.
I
wanted
to
add
a
new
type
instead
of
just
the
self-defined
types,
there's
a
type
duration
which
google
has
a
package,
a
photo
definition
for
it,
but
including
that
is
complicated.
D
I
was
having
some
issues.
You
know
a
while
back
trying
to
do
that.
So
once
we
get
the
basic
b1
stuff
in
place,
we're
going
to
have
to
handle
some
of
these
challenges
too.
If
we
need
to
bring
in
you
know
any
third
party
definitions
like
that,
so
just
something
else
to
think
about
as
you're
going
to
this.
A
D
And
I,
and
I
certainly
can
can
kind
of
poke
in
and
you
know,
answer
questions
or
try
to
kind
of
work
through
some
of
this
with
you.
But,
as
I
understand
earlier,
there's
kind
of
two
things,
though:
getting
the
getting
the
code
generation
working
is
one
part
of
the
problem
and
he's
got
a
workaround
that
we
need
to
get
a
better
solution
around.
D
But
then
there's
the
rest
of
the
implementation
that
just
needs
to
work
with
the
go
code,
and
so
I
think
the
plan
was
that
fung's
gonna
move
in
the
direction
of
getting
the
rest
of
the
proof
of
concept
and
working
and
then
kind
of
double
back
and
fix
the
stuff.
And
at
that
point
I
would
suggest
looking
into
also
upgrading
it,
but
because
basically
there's
two
different
parts
of
the
problem.
There's
the
there's,
the
the
protobuf
stuff
and
the
code
generation.
E
I
would
suggest
create
like
a
separate,
accepted
task
or
separate
issue
to
work
on
refactoring,
the
the
the
protocol
and
the
control
of
the
protoc
and
then
why
I'm
continue
on
versioning,
with
whatever
hack
that
I
have
yeah
and
and
and
if
the
refactor
of
the
proto
and
protoc
was
done.
First,
then,
I
can
merge
that
into
my
my
burgeoning
branch
and
and
and
get
it
work
together,
so
because,
if
I
have
to
work
on
both
of
them
too
much
for
me
besides.
To
be
honest,
I'm
not
really
good.
D
And
I
think
it
makes
sense
like
you
said
just
because
it's
really
two
different
tasks
that
you
know
have
to
be
done
together,
but
because
everything
else
outside
of
the
code
generation
can
be
built.
On
top
of
you
know
the
kind
of
work
around
that
you
have
right
now:
you're
not
blocked
on
it.
You
can
work
on
the
rest
of
this
and
then,
if
no
one
else
has
done
this
at
the
end,
you
can
look
at
it
again.
D
As
I
said,
I'm
actually
hoping
that
I
might
be
able
to
look
into
this
a
bit
myself.
I've
done
a
little
with
it
with
this
in
the
past,
but
I'm
still
not
an
expert
at
it,
but
you
know.
Maybe
I
can
come
up
with
something
there
and,
like
I
said
I
can
build
something,
maybe
off
of
your
branch
and
then,
if,
if
it's
ready
before
you're
done,
we
can
merge
it
in
and
if
it's
not
because
none
of
this
is
one
nine
code,
it's
all
in
the
110
code
base.
D
We
could
refactor
this
after
your
work
is
done
as
well,
but
we,
but
I
think
we
both
agree.
We
were
talking
about
this
before
we
definitely
need
to
get
at
least
the
co-generation
stuff,
so
that
you
know
the
kind
of
hack
he
has
in
place.
Now
it
has
to
be
fixed
before
we
release
this
in.
You
know
110,
but,
as
I
said,
that
also
is
an
opportunity
to
investigate.
D
You
know,
because,
since
we're
having
to
move
all
this
code
and
refactor
it
all
now
anyway,
if
we
can
upgrade
it,
I
think
it'll
be
less
painful
to
do
it
as
part
of
this
process
before
110,
rather
than
you
know,
realize
after
110
is
out
that
we
still
have
some
problems,
because
we're
on
an
older
version
of
this
and
something
we
need
for
v2
needs
a
new
version
and
then
we're
going
to
have
to
refactor
all
the
stuff
again
and
rather
avoid
that.
A
D
E
D
The
core
functionality
of
the
you
know
the
of
the
plug-in
versioning,
because
there's
a
lot
of
go
code
in
the
valero
code
base.
That
has
nothing
to
do
with
photobus,
that's
needed
there
too,
but.
D
To
that
you
know,
I
can
start
looking
into
this
on
my
end
and
say:
hey,
you
know
what
does
the
upgrade
look
like
or
if
we
don't
need
to
upgrade?
What
can
we
do
to
make
this
work
better
and,
and
then
you
know,
maybe
dave
can
help
us
out
as
if
I
have
questions
or
whatever
you
know
something
like
that.
That
way,
you
know
he's
not
blocked
on
this,
and
he
can.
A
D
A
Yeah
yeah,
I
think
the
plugin
working
is
also
important
part
that
we're
gonna,
you
know,
contain
one
pen.
So
if
you
need
any
help,
just
feel
free
to
ping
us
and
yeah,
we
can
definitely
help.
A
Oh
okay,
yeah
anything
else.
I
think
scott,
you
wanna
yeah.
D
Just
a
quick
we,
I
proposed
shoe
bomb
as
a
another
maintainer
earlier
this
week
and
looks
like
that
got
the
appropriate
approvals
and
acts,
and
so
that's
got
that
was
merged.
So
as
of
this
morning,
I
think
is
now
a
valero
maintainer.
I've
submitted
some
follow-on
prs
to
add
them
to
the
reviewers.
For
the
you
know,
the
aws
and
other
plug-ins
as
well,
once
the
main
repository
thing
was
married
for
him,
so
I'm
just
going
to
say
congrats
for
that.
D
B
A
Yeah
thanks
a
lot
for
your
contribution
for
the
new
features
in
one
night
and
you're.
Looking
forward,
you
know
in
the
making
progress
in
its
data
mover
api
design
that
one
we
have
to,
I
think
currently
in
in
our
internal
discussion.
We
want
to
finish
that
design
and
do
some
poc
in
the
one
time
time
frame
so
that
you
know
by
the
end
of
year
already
next
year
we
can
have
this
defaulted
more
part
of
valero
to
ga
the
css
plugin
yeah.
A
So
I
think
thank
you
and
by
the
way
I
forgot
to
mention
one
thing:
dave
has
been
working
on
a
relatively
big
change
for
the
upload
progress
monitor.
There
was
some
back
and
forth
comments
on
his
pr.
I
think
it's
44
69.
A
Yeah,
this
is
a
wine
there's,
a
big
car
and
yeah.
There
used
to
be
a
lot
of
back
and
forth
in
the
implementation
design
and
in
the
end,
because
dave
is
traveling
for
the
kukan
eu
and
they
didn't
have
enough
time
to
finish.
Go
resolve
all
the
comments
before
they
fc.
So
we
decided
to
move
this
out
of
one
night
and
do
that
in
one
time.
A
But
my
question
is:
has
anyone
currently
in
this
meeting
was
involved
in
the
design
or
review
of
this
upload
progress
monitoring?
Because
that
since
the
design
was
approved
before
I
started
working
on
the
valero
product,
scotland
phong?
Were
you?
Do
you
have
any
impression
on
this?
One.
D
Yeah,
I
really
was
not
participating
in
that.
I
think
that
much
so
yeah
I
don't
have
a
lot
of
insight.
There.
A
Okay,
because
that
one
is
on
a
critical
path
on
the
data
mover,
because
the
user
has,
there
has
to
be
a
way
that
user
can
monitor,
which
pv
was
moved
to
the
target
via
the
backup
cr,
and
there
are
some
other
issues
related
to
this
opened.
A
A
A
So
in
the
next
before
the
next
community
meeting,
I
I'm
gonna
tentatively
try
to
propose.
You
know,
assign
him
as
a
maintainer
or
promote
him
as
a
maintainer
of
valero.
So
I'm
gonna
write
up
a
pr
you
there
any
concern
or
suggestions
before
I
write
up
the
pr
and
nominate
him.
A
Okay,
so
I
I
think
yeah,
I'm
gonna
write
up
the
pr
and
the
further
discuss
that
in
the
next
meeting.
Okay,
so
is
there
anything
else
anyone
wanna
talk
about.
A
Well,
if
not
we're
gonna
wrap
up
and
for
the
status
for
one
night,
we're
gonna,
you
know
update
in
the
sad
channel
so
stay
tuned.
Thank
you
guys.