►
From YouTube: Velero Community Meeting - August 10, 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,
let's
start
and
hello,
everyone
today
is
august
10th.
This
is
the
community
meeting.
First,
let's
do
some
status
update
and
for
the
copier
integration
and
several
mobiles
has
been
submitted
on
words.
So
totally
speaking,
everything
is
on
track
for
now
and
for
191,
and
some
more
issues
have
been
included.
I
mean
easy
fixes
and
totally
there
is
none
fixes,
included
and
all
has
been
merged.
A
So
if
there
is
nothing
need
to
be
included
next,
one
on
one,
it's
hopefully
to
be
released
next
week
and
for
the
computer
refactory
and
it
is
still
ongoing
and
the
the
vsr
refactor
is
down
and
the
backup
single
refactor
is
in
progress.
A
Okay,
that's
some
more
status
and
for
the
individual,
individual
updates
and
daniel
is
on
the
vacation
from
today
and
well
we'll
be
back
next
monday.
A
Myself
is
still
working
on
the
copy
integration
items
and
some
prs
has
been
submitted
or
merged,
and
besides
that,
I've
also
worked
on
some
easier
checks
and
investigation.
Yeah.
Just
from
my
side
and
to
me.
B
So
191,
I
fixed
the
issue
that
is
about
a
backup
backup
with
restriction
that
has
multiple
bsl
and
is
being
merged,
and
I'm
doing
I've
done
the
pre-release,
the
191
r1
rc1,
and
we
will
probably
release
the
official
one
next
week
and
I'm
still
working
on
the
copy
of
file
system.
Uploader
integration,
one
pr
is
sub
medium
and
others
is
on
the
way.
Yes,
that's
from
me.
B
I
worked
on
two
191
issues:
one
is
to
fix
the
csi
migration
volume
past
one
month.
One
pass
and
the
other
is
to
make
the
csi
volume
snapshot.
Time
configurable,
and
I
also
working
on
some
customer
tickets
supporting
and
that's
all
from
my
side.
A
Okay
thanks
and
these
two
csi
issues
is
actually
by
important
faces
right.
So
if
any
anyone
is
interesting,
you
can
just
check
this
list
for
for
photos
to
issues,
and
then
these
fixes
and
gg.
A
Okay,
thank
you
and
scott.
C
Yeah
so
two
things
the
actually
I'll
start
with
the
second
one,
the
vsl
credentials.
I
revised
the
pr.
There
was
some
feedback
and
then
I
actually
noticed
some
recent
changes.
Well,
not
recent,
but
later
changes
for
the
bs,
the
backup,
storage
location,
credentials
worked.
It
modified
the
validation
and
also
there's
a
bug
fix
there,
and
so
I
I
realized
those
changes
really
needed
on
the
vsl
work
as
well.
So
I
revised
the
pr
based
on
later
changes
to
the
related
backup
storage
location
code.
That
was
updated.
C
There's
one
act
on
that
now,
so
I
just
need
the
second
review
item
action,
progress,
monitoring,
design.
I
went
through
that
added
a
section
to
the
end
because
it
was
pointed
out
a
few
weeks
ago
that
there
were
several
kind
of
several
initial
pr's
relating
to
dave's
prior
design
that
were
put
in
place
kind
of
in
preparation
for
the
full
implementation,
and
then
there
was
a
another
pr
that
implemented
kind
of
basic
functionality
that
was
open
but
never
merged.
So
I
looked
at
those
pr's.
I
added
some
comments.
C
Some
of
those
we
probably
need
to
revert-
and
you
know,
re
redo-
that
functionality
based
on
the
updated
design
there's
a
couple
of
them.
That
may
be
fine,
as
is,
but
I
added
some
comments
there
yeah
right
there,
they're,
showing
there
kind
of
linking
to
the
pr's,
is
relevant
for
that.
C
So
if
anyone
wants
to
go
and
look
at
those-
and
you
know,
comment
on
my
my
proposals
there
as
to
what
I
think
we
should
do,
but
basically
the
original
design
had
a
completely
new
plugin
plug-in
type,
and
you
know
the
the
way
we're
going
with.
This
is
because
we
wanted
it
for
regular
backup,
item
actions
and
also
restore
item
actions
is
kind
of
following
along
the
same
lines
that
dave
had
initially
proposed
for
the
volume
snapshot
plugin,
which
was
to
add
api
methods
to
the
existing
plugin
type.
C
So,
basically,
all
three
of
those
plugins
would
be
getting
new
new
methods
added
to
the
api
and
new
fields.
Added
to
the
execute
signature.
I
guess
on
the
response,
so
any
of
the
code
that
involved
creating
brand
new
snap
plugin
types.
We
probably
need
to
revert,
because
we're
going
to
be
basically
using
a
v2
of
the
existing
plug-in
types
simple
with
this.
C
Instead
and
again,
the
other,
I
think
other
ones
where
one
was
on
the
the
backup
phases
and
again,
in
that
case,
we
would
need
to
revert
that
and
then
add
an
equivalent
version
with
the
new
names
that
we
proposed
in
the
more
generic,
because
we're
going
beyond
just
uploads,
but
that
was
some
comments
there.
C
So
if
anyone
wants
to
go
back
and
review
the
overall
proposal
in
context
with
those
additional
feedback,
or
rather
for
proposal
bits,
because
that
was
that
was
pointed
out
before
that
we
really
do
need
to
address
you
know
any
existing
code
that
relates
to
this
since
we're
changing
a
design,
we
need
to
modify
that
existing
code.
In
addition
to
you
know
creating
the
new
implementation,
and
that
would
all
be
kind
of
combined
and
kind
of
one
set
of
effort
there.
C
A
Okay
thanks
and
we
know
that
you
know
dave's
prs
has
you
know
man,
many
of
them
have
been
merged
into
the.
C
B
C
You
know
this
is
a
new
plugin
type,
we're
not
making
new
plugins
type
now,
so
we
actually
probably
want
to
revert
this
pr.
This
change
and
replace
it
with
you
know
the
modification
in
the
v2
of
the
backup
item
action
and
the
v2
of
the
restorative
action
plug-ins.
Once
fung's
work
is
in
place
around
the
versioning.
A
C
Exactly
and
the
biggest
pr
is
actually
the
final
one
that
was
never
merged
so
that
they
had
a
pr
that
actually
implemented.
That
was
the
last
link
there.
You
know
kind
of
the
basic
functionality
since
this
wasn't
merged.
Yet
there's
no
need
to
you
know,
revert
or
change,
but
basically
this
pr
will
be
useful,
as
kind
of
when
writing
the
implementation
of
this.
C
Some
of
this
functionality
that
he
has
there
will
be
useful,
as
is
a
lot
of
it,
will
need
to
be
modified
based
on
the
change
in
design
again,
a
lot
of
that
around
the
fact
that,
instead
of
creating
new
plug-in
types,
we're
actually
modifying
existing
plug-in
types,
but
you
know
some
of
the
other
parts
of
what's
being
done,
there
are
still
relevant
and
they
just
need
to
be.
You
know.
The
same
code
needs
to
be
kind
of
refactored
into
the
new
design,
so
that's
still
useful.
It's
just
that.
C
Be
closed
and
then
a
new
pr
created
that
you
know,
based
on
the
the
you
know,
once
we
approve
the
new
design
and
we
have
the
versioning
for
the
for
the
plug-in
apis,
then
we
could
kind
of
go
along
with
kind
of
within.
D
So
I
updated
the
phase
one
here.
It
had
some
latest
comments
on
it
regarding
use
case
addition
and
removal
of
workflows
which
were
not
part
of
the
phase
one.
So
I
did
that.
I
need
some
acknowledgements
for
that.
Pr,
that's
it.
I
guess.
A
Okay,
so
so,
basically
speaking
the
physics
one
pr
is,
has
been
completed
from
your
side
right
so
and
so,
if
the
the
review
is
down,
we
can
merge
that
right.
B
A
Okay
and
what
about
the
odd
the
following
thing,
designed
like
a
phase
two.
D
B
B
C
My
pr
is
going
to
be
merged,
as
is
obviously
if
there
are
changes
from
now
to
the
you
know,
final
merge
that
might
require
you
to
make
some
changes
too,
but
you
know
I
think
at
this
point
it's
probably
worth
it's
probably
fine
to
start
working
on
it
kind
of
assuming
that
what
we
do
merge
will
be
close
to.
What's
there.
Obviously,
it's
not
finalized
yet
so
we
could
still
make
some
changes
at
this
point.
C
Yeah
but
but
but
to
your
point,
we
do
need
to
get
this
review
kind
of
done
for
this
and
finalize
because
also
to
you
know
so
we
can
start
implementing
it.
But
again
the
influencing
also
is
kind
of
gated
on
the
being
able
to
get
the
v2
for
the
you
know,
plug-ins
in
place.
D
A
Okay,
okay,
thank
you
and.
B
B
Okay,
I'm
working
on
adding
aks
to
nightly
pipeline,
so
all
in
tests
can
run
on
a
cast
environment
and
currently
there
are
some
in
in
test
field
field
and
I'm
looking
into
that
and
another
work
is,
I
add,
a
namesmith
mapping
to
in
test
this
test
case.
That's
all
from
my
site.
A
If
no
more
question,
we
can
go
to
the
discussion
topics,
so
the
first
one
is
from
shuba.
Please.
D
Yeah,
so
this
is
regarding
an
issue
which
we
are
seeing
on
openshift
411
now,
basically,
when
it
is
124.,
so
this
is
related
to
a
restoration
of
volume
snapshot
class
that
already
exists.
So
it's
not
reproducible
on
earlier
version,
because
there
are
some
changes
made
to
volume
snapshot
class
api
in
124.
D
So
the
restore
fails
with
the
logs
that
the
validation
of
admission
web
hooks
has
failed.
So
basically,
this
should
be
treated
as
already
exists,
warning
as
valero
control
controller
does
today,
but
because
the
create
call
is
not
getting
executed
itself
so
whether
controller
the
restore
controller
is
not
getting.
The
already
exist
error.
That's
why
this
is
getting
treated
as
an
error
and
not
as
a
warning,
thus
failing
the
restore.
D
So
I
wanted
to
discuss
on
that.
C
And
I
could
add
a
little
more
information.
I
don't
remember
the
specifics,
but
I
remember
hitting
a
very
similar
issue
a
couple
years
ago.
I
don't
getting.
C
I
don't
remember
whether
this
was
a
at
a
community
call,
or
this
was
you
know
something
on
the
openshift
side,
but
I
know
I've
seen
this
exact
same
failure
mode
before
so
I
think
we
probably
do
want
to
fix
something,
and
basically,
what
happens
right
now
is
that
in
the
restore
controller,
after
we're
done
with
the
plugins
and
everything
else,
valero
issues
the
create
api
call,
if
the
create
call
errors
out.
The
first
thing
we
do
is
check
to
see
if
it's
an
already
exist
error.
C
If
it
is,
then
we
just
compare
the
objects,
and
you
know
if
it's
we
either
warn
if
the
objects
are
different
or
if
they're
the
same.
We
don't
want
it
all.
It's
just
an
infill
log,
but
we
don't
air
anything
out.
But
if
it's
not
an
already
exist
error,
then
we
assume
there's
something
there
was
a
real
problem
and
then
it's
failure
so
what's
happening
here
is
because
with
most
controllers,
if
you
go
to
create
an
object,
the
first
thing
that
happens
is
you
know
the
controller
says
hey
this
thing:
does
it
exists
already?
C
If
it
does
we're
going
to
error
out
with
that
error,
if
it
doesn't
exist,
we
go
through
the
rest
of
validation,
but
there
are
apparently
some
controllers
and
the
the
volume
snapshot
class.
One
is
one
of
them
where
it's
actually
doing
some
preliminary
validation
before
it
even
checks
to
see
if
the
resource
already
exists.
With
that
name,
the
result
being,
we
should
be
getting
back
on
our
exist
error,
but
we
don't
because
it's
failing
an
even
earlier
validation
that
that
is
basically
complaining
in
this
case,
because
we
already
have
a
default
volume
snapshot
class.
C
Well,
you
know
the
default.
One
is
the
same
one,
so
they
already
just
are
really
should
cover
it,
but
because
there's
something
outside
of
valero's
control,
that's
giving
us
a
different
error
than
we
expect.
I
was
just
talking
to
shiba
about
this
before
the
meeting.
I
think
what
we
could
do
instead
is
when
valero
issues
that
create
call.
The
first
thing
we
do
is
always
just
check
for
already
exists
there.
C
If
we
get
that
error,
you
know
we
just
proceed
as
we
already
are,
but
before
we
assume
this
is
a
generic
error
and
we
just
error
out
the
second
thing
we
should
do.
If
it's
not
an
already
exist
error
is
to
do
a
get
call.
It
does.
This
thing
exist
already.
If
it
exists
already,
then
we
can
treat
this
as
if
it
returned,
it
already
exists
there
and
then
go
down
that
path.
I
think
this
would
be
a
relatively
straightforward
change
to
the
restore
controller.
C
It
wouldn't
be
adding
api
calls,
except
in
cases
where
there's
an
error
on
create
that's
other
than
our
exist
error.
So
in
the
normal
case,
where
we
just
created
the
object,
there's
no
change
in
api
calls
no
change
in
performance.
In
the
case
where
we
return
our
exist
error,
there's
no
change
in
performance.
C
We
have
an
additional
get
call
only
in
those
cases
where
we're
currently
erroring
out
anyway,
and
this
allows
us
to
not
error
out
if
in
this,
in
the
example
here-
and
the
problem
here
is,
this
is
going
to-
I
imagine
anyone
using
the
csi,
plug-in
and
kubernetes
124
is
going
to
see
this.
If
you
take
a
backup
with
the
volume
snapshot
class,
you
do
I
I
actually,
I
guess
we're
creating
that,
and
there
are
data
movers.
C
So
that's
probably
not
going
to
be
oh
he's
going
to
see
in
the
csi
controller,
but
anyone
who's
messing
with
the
volume
snapshot
classes
and
including
having
those
in
their
the
backup
is
going
to
see
this
and
kubernetes
124
and
the
change
there
is
that
if
there's
it
doesn't
allow
multiple
default
volume
snapshot
classes
and
if
we
were
actually
trying
to
restore
one
with
a
different
name.
This
would
be
a
valid
response,
valid
error.
The
problem
is,
in
this
case
it's
the
same
name.
It's
the
same
volume
snapshot
class,
we're
just
restoring
it.
C
C
I
actually
think
that's
should
be
a
relatively
easy
fix
with
minimal
performance
impact
and
if,
if
people
think
that
makes
sense,
then
you
know
we
can
on
our
side.
You
know,
propose
a
fix
there
and
you
know
go
through
review
and
all
that.
C
If
it
does
any
has
any
feedback,
I
know
we
initially
put
this
on
the
on
the
agenda,
not
knowing
what
was
going
on,
but
I
was
talking
to
shibama
about
this
about
10
minutes
before
the
call,
and
we
actually
figured
it
out
kind
of
right
then
so
you
know
we
just.
We
still
wanted
to
bring
it
out
because
it
is
going
to
require
changes
to
the
restore
controller.
C
But
it's
an
easier
discussion
now
that
we
actually
understand
what's
going
on.
A
And
yeah,
I
know
that
we
have
some
code
or
or
something
like
a
policy
for
the
already
seasoned
items
during
the
restaurant.
A
C
Get
to
that
because,
right
now,
what
happens
is
that
if
the
item
already
exists,
you
know
and
we're
and
we're
determining
that,
based
on
the
error
code
return,
you
know
if
it,
or
rather
the
air
type.
If
it's
an
already
exist
error,
then
we
either,
you
know,
then
we
check
that
policy,
but
what's
happening
here.
Is
that
we're
short
circuiting
that
and
we're
actually,
because
because
the
underlying
controller,
that's
responding
to
the
create
call
and
the
cluster
is
giving
us
a
different
error,
error
type
valero
doesn't
recognize
it
as
an
already
exists
error.
C
So
it's
just
failing
that,
failing
their
store
and
we
don't
even
get
or
partially
failing
to
restore,
we
don't
even
get
that
option
of
in
a
modifying
or
ignoring
so
what
I'm?
What
I'm
suggesting
is
that
if
we
get
an
error
back
on
the
create
call
and
the
restore
controller
in
the
store
operation,
it's
not
an
already
exists
there
before
we
assume
it's
a
generic
error
that
we
have
to
fail
from.
C
Let's
do
a
get
call
to
see
if
the
resource
already
exists
and
if
it
does,
then
we
can
treat
that
error
as
in
our
exist
error
and
go
down
that
path,
they're
using
the
resource
policy,
and
all
that
this
is
kind
of
a
separate
question
from
the
resource
policy,
because
we're
failing
before
we
get
to
that
code.
C
If
it
already
exists,
and-
and
we
use
this
new
code
to
recognize,
even
though
the
error
we're
getting
back
from
the
in
this
case,
the
volume
snapshot
class,
whatever
controller,
is
handling
that
you
know
creating
those.
B
C
If
it
does,
then
we
go
down
that
path
of
saying,
okay
for
this
type,
you
know
what
is
the
restore
policy
or
actually
are
we
just
doing
that
generic?
I
can't
remember
now
whether
we're
checking
types
for
that
or
not
well,
in
any
case,
once
we
know
that
it's
an
once,
we
learn
from
this,
get
call
whether
we
treat
this
as
an
already
exists.
At
that
point,
the
existing
code
around
the
existing
resource
policy
will
be
applied.
Yeah.
B
As
essentially,
we
got
a
similar
issue
for
autopilot
service.
There
is
a
summer
there
is
already
some
logic
to
handle
such
kids,
but
that
only
for
the
service
yeah.
B
C
Yeah
for
services,
we
actually
always
want
to
merge
those
and
what
what
I'm
talking
about
here
is
not
it's
not
a
resource
type
specific
code.
I'm
not
actually
saying
that
we
need
to
make
an
exception
for
volume
snapshot
class.
I'm
saying
anytime
that
we
get
back
an
error
from
the
recreate
call,
and
it's
not
an
already
exist
error.
C
We
need
to
then
do
a
get
call
to
see
hey.
Does
this
thing
already
exist
because
well,
we've
seen
now
at
least
two
cases,
one
that
we
see
right
here
and
another
one
that,
unfortunately,
I
can't
remember
the
specifics
of,
but
I
know
I've
seen
this
before,
where
we're
dealing
with
a
controller
which,
in
some
circumstances
won't
give
us
an
already
exist
error,
because
the
way
it
validates
it's
checking
something
else.
First,
normally
we
check
exist.
C
You
know
already
exists
first,
and
so,
if
it
already
exists,
you
get
that
error,
but
some
controllers,
for
whatever
reason
in
their
design.
They
do
some
other
validation
before
they
check
if
it
exists
already,
and
so,
if
those
validations
fail,
they
don't
even
get
to
checking
whether
it
exists.
They
return
that
other
validation
error,
the
create
call,
fails
and
right
now,
valero
just
assumes
hey.
This
is
an
area
we
can't
recover
from,
and
so
we
go
into
partial
failure.
C
But
what
I'm
saying
here
is
that
if
we
get
that
situation,
valero
can
do
a
get
call
on
that
resource.
You
know
name
and
if
it
finds
it
then
valero
can
assume
hey.
This
already
exists,
so
we
need
to
treat
this
the
same
way.
We
treat
in
our
exist
error,
which
is
you
know
we
either
ignore
it
or
we
try
to
patch
it.
C
And
then
you
know
we
don't
go
down
that
path,
so
this
is
basically
just
adding
one
more
condition
to
that,
because,
right
now
we
have
an
if
clause
that
says,
if
already
exists,
you
know
run
this
set
of
commands.
That
includes
this
set
of
statements,
which
includes
you
know,
checking
resource
policy
and
either
warning
or
patching,
and
all
that
I'm
saying
that
if
clause
needs
two
things,
if
I
would
exist,
error
or
you
know
or
get
call
showed
it
exists,
and
that
get
call
is
only
going
to
be
run.
C
If
error
is
returned,
that's
not
nil
and
the
error
is
not
an
already
exist
error.
So
so
there's
going
to
be
a
small
set
of
circumstances
where
we
have
to
make
an
additional
get
call,
and
then,
after
that
we
have
two
things
to
check
and
if
either
one
of
those
things
are
true,
then
we
go
down
the
path
of
checking
existing
resource
policy
and
warning
or
patching,
and
if
we
get
back
to
everything
doesn't
exist
so
in
the
norm.
C
A
And
two
questions
from
my
size:
it's
like
the
first
one
is
since
so
the
error
is
not
always
already
this
an
error.
So
it's
the
error,
a
fixed
one,
that
is,
we
can
have
some
opportunity
to
cut
it.
C
No,
it's
not
a
specific
error,
because
you
know
in
this
case
it's
an
error
for
volume,
snapshot
class.
It's
saying,
and
one
of
the
rules
in
kubernetes
124
is
that
you're
not
allowed
to
have
more
than
one
volume
snapshot
class
for
default.
So
that's
a
very
specific
error
for
a
very
specific
you
know
single
resource
type,
we're
not
going
to
be
checking
for
that
string.
We
know
we're
not
going
to
make
anything
specific
to
volume
snapshot
close
here.
C
What
I'm
saying
is
a
more
generic
thing
of
you
know
we
make
the
existing
create,
call
that
we
already
have
and
we
get
back
an
error.
That's
either.
You
know.
If
it's
nil,
no
error,
we're
fine.
If
we
get
an
error
right
now,
bolero
does
just
one
thing
which
deck.
If
it's
already
exists
there,
and
if
it's
not
exist
error,
we
treat
it
like
the
resources
existing
go
down
that
resource
the
existing
policy
path
and
any
other
error
we
air
out.
C
I'm
saying
we
need
to
intercept
that
in
the
middle
and
if
it's
an
error
returned
so
not
nil,
it's
not
an
already
exist
error
before
we
just
assume
that
we
can't
recover
from
this
and
we
error
out,
we
go
and
make
a
get
call
in
the
cluster
for
that
resource,
because
we
have
a
you
know,
we're
creating
something.
So
we
already
have
a
name
and
a
namespace
and
a
resource
type.
C
We
can
do
a
get
call
for
that.
If
that
returns
or
not
found,
then
it
doesn't
exist.
So
we
treat
the
error
as
a
genuine
error
and
we
error
out
just
like
we
do
now.
If
it
doesn't
exist,
then
we
know
that
that
resource
that
we
tried
to
create
exists
already.
So
we
need
to
go
down
the
existing
resource
policy
path.
You
know
the
code
that
already
exists
and
basically
treat
that
exactly
the
same
as
if
what
we
got
back
with
the
already
exist
error,
and
I
think.
C
C
Yeah,
I
think
I
think
so
and
then
and
again
we
can
review
that
there
as
well.
That's
okay!
I
just
think
that,
because
this
seems
to
me,
like
the
you
know,
and
maybe
someone
else
will
have
a
proposal
for
a
way
of
doing
it.
That's
a
bit
simpler,
but
I
think
this
is
probably
the
simplest
way
of
solving
it
because
it
doesn't
change
the
code
path
for
you
know
the
normal
successful
case.
C
It
doesn't
add,
you
know
we
don't
we
don't
want
to
always
do
a
get
call
for
everything
before
we
create
it,
because
that's
going
to
slow
things
down.
We
only
want
to
do
this
when
we
hit
an
error
and
we
want
to
limit
it
to
just
okay.
We
hit
an
error
and
it's
not
going
to
exist
error,
but
unfortunately
we
can't
predict.
Oh
it's
just
you
know
we
don't
want
to
make
a
special
case
fix.
It
only
works
for
volume
snapshot
classes
because
I'm
certain
there's
going
to
be
another.
C
There
will
be
another
case
just
like
this,
whether
that's
some
other
controller
and
some
it
might
even
be
a
crd.
You
know
that's
not
even
in
core
kubernetes
that
treats
errors
exactly
the
same
way,
and
this
fix
that
I'm
proposing
is
generic
enough,
that
it
doesn't
matter
whether
it's
core
kubernetes
or
a
crd
or
something
else
entirely,
because
we're
dealing
with
everything
at
a
generic
level,
which
is
the
way
you
know
as
much
as
possible.
Valero
should
be
doing.
C
You
know
we
have
a
special
cases,
for
you
know,
service
accounts
and
various
things
where
we
have
to,
but
if
we
can
fix
a
bug
without
resorting
to
a
special
casing,
that's
better,
because
that
that'll
fix
a
larger
class
of
bugs,
not
just
the
one
we're
seeing.
I
don't
want
to
fix
it.
Just
fix
volume,
snapshot,
classes
and
then
realizing
that
some
other
validation
gets
added
to.
C
A
C
C
That's
when
we're
going
to
make
this
change,
because
because
that
way,
you
know
if
you're,
restoring
5000
items
and
only
three
error,
three
items
that
are
out-
I
only
want
those
three
api
calls
extra,
not
five
thousand
extra
api
results.
A
Okay,
okay,
I
got
that
and
so
you
will
create
this
pr
right.
A
Okay,
so
anyone
else
have
any
questions
about
this
problem.
A
If
not,
I
I
think
I
need
to
move
some
a
little
back
for
the
status
so
because
I
see
found
it's
also
here
so
fun.
Do
you
have
any
updates
from
your
site
like
the
plug-in
washing.
C
B
B
Scott
have
given
me
enough
in
enough
pain
for
me
to
move
forward.
B
I
think
I
got
I
make
a
mistake
of
assuming
that
it
is
in
my
local
directory,
so
I'm
gonna
scott
just
gave
me
a
hint
that
I
can
simply
merge
my
code
in
and
then
try
to
use.
I
mean
not
much
my
good
morning,
not
in
my
private
branch
and
view
that,
instead
of
using
from
my
local
directory,
so
I
I
will
try
that
but
sorry
I
haven't
have
a
time
to
do
that.
Yet.
A
A
D
So
this
is
for
regarding
the
data
mover
feature,
so
we
from
red
hat
side.
I
would
like
to
do
a
demo
like
we
are
doing
odp
operators.
Tech
preview
feature
csi
data
mover,
so
this
demo
will
likely
bring
more
clarity
regarding
the
data
mode
design
that
we
want
to
propose
upstream
and
the
feature
that
we
are
targeting.
D
So,
regarding
this
demo,
does
it
work
like
the
24th
of
august
china,
time
and
23rd
august
us
time?
Maybe
you
could
do
a
demo
after
community
updates?
Well,
let
me
okay.
A
Okay,
so
this
this
is
currently,
this
is
the
the
modules
of
the
code
that
is
currently
running
with
oidp,
okay,.
C
We
basically
implemented
this
as
a
separate
controller
outside
of
valero
using
the
existing.
You
know,
valero
one
one:
nine
functionality
we're
hoping
to
bring
a
lot
of
this.
You
know
again
upstream
with
the
with
the
the
data
mover
upstream
and
then
not
need
this,
but
but
this
was
something
we
needed
to
get
done
for
customers
kind
of
right
now,
so
this
is
kind
of
an
interim
solution.
C
So
the
idea
was
to
demo
what
we're
doing
here
kind
of
outside
of
valero,
which
is
kind
of
pointing
us
and
which
was
also
based
on
the
csi
plug-in
as
well.
With
kind
of
you
know,
some
discussions
around
here's.
What
we're
doing
here,
we'd
like
to
you
know
some
aspects
of
that
are
directly
relevant
to
what
we're
going
to
posing
upstream.
Some
of
them
are
going
to
be
a
little
different,
but
this
would
kind
of
give
some
context
around.
C
You
know
where
we
think
things
are
going
with
the
data
mover
design,
for
you
know
in
the
once
in
time,.
D
Yeah-
and
we
would
also
like
get
some
like
to
get
some
feedback
as
well,
so
we
would
also
discuss
like
showcase
the
design,
the
crds
that
we
have
introduced
and
the
changes
what
we
are
doing
to
the
csi
plugin,
like
those
will
be
the
similar
changes
which
we
want
to
propose
in
valero
upstream
as
well.
So
that's
why
that
is
the
whole
point
of
this
demo.
A
So
what
is
the
time
so
we
want
to
do
that
after
the
community
meeting.
So
do
we
create
a
new
meeting
or
just
following
that.
C
D
Okay,
yeah:
we
can
do
that
as
well,
but
yeah
I
would
require
like
if
you
are
going
through
design
and
crds
and
demo,
then
at
least
15
20
minutes.
I
think.
C
D
D
C
Another
block
of
time
you
know
one
hour
later
that
way
if
we
run
over,
but
obviously,
if
the
regular
meeting
you
know
runs
out
in
time,
we
can
get
started
earlier,
and
so
we
may
not
need
the
extra
time.
A
Okay,
basically,
I
think
the
time
is
work
for
for
the
for
the
for
the
bidding
team
and
if
we
want
more
people
to
join,
maybe
we
can
just
ask
the
same
thing.
D
B
B
A
A
I
think,
apparently
this
to
me
in
this
meeting.
We
don't
have
problems
for
the
time
right.
B
I
think
we
can
do
this
on
on
the
time
that
proposed
the
basketball,
maybe
next
community
meeting
so.
C
Kind
of
at
the
end,
you
know
as
a
last
topic
of
the
meeting
and
if
the
meeting
it's
like
today,
it
sounds
like
we're
at
the
end
of
our
topics
and
we've
got
about
20
minutes
left.
If
we,
if
we're
on
the
same
time
frame
next
week,
then
we
should
have
enough
time
at
the
end
to
handle
everything.
Two
of
them
needs
to
bring
up,
I'm
okay
staying
a
little
longer
if
necessary.
You
know
if
you
know
past
the
end
of
the
meeting
as
well.
B
A
Yeah,
okay:
we
we
can
have
that
time
and
have
this
demo
at
that
time.
Okay,
thank
you.
D
A
Okay,
for
no
more
things
to
discuss,
I
think
we
can.
We
can
complete
today's
meeting
now
and
thank
you.
Everyone
have
a
good
day
and
good
night.
Thank
you.