►
From YouTube: Velero Community Meeting - Dec 21, 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
First,
let's
do
the
updates.
You
have
anything
to
update.
B
Yeah
first
is
fixed,
rested,
S3
backhand
bar
Bach
introduced
in
the
new
world
included
with
Valero
1.9.4,
and
the
second
is,
is
still
in
progress.
Atom
I
am
refactoring
the
restore
controller
and
that's
all.
A
C
B
The
I
think
the
design
is
already
approved
and
we're
is
ready
to
be
implemented.
A
Okay:
okay,
because
you
you
said
you
want
to
discuss
with
me
and
I
I
was
pretty
busy
with
some
other
stuff,
so
I
didn't
have
a
chance
to
look
at
it.
So
yeah
could
you
could
you
send
me
the
link
to
the
PRN
I
can
take
a
look?
Maybe
okay,
okay,.
A
Thank
you
and
for
me,
I'm
shouting
the
issue
on
my
side
for
1.11
candidates
and
also
a
full
specific
will
empty
value
and
arrow
handling
issue
in
barrels.
Plugin
framework
for
some
reason
in
some
plug
in
the
arrow,
is
not
transferred
correctly
to
the
barrel
code.
So
when
the
arrow
happens
in
some
of
the
plugin
code,
we
cannot
lock
the
arrow
and
debugging
that
issue.
In
addition
to
that
I'm
also
discussing
with
you
about
the
mover,
design,
PLC
and
that's
all
for
my
part
of
Scott.
C
Yeah,
so
a
few
PRS
out
there
now
the
backup
item
action.
V2
implementation
is
ready
for
view.
That's
actually
not
a
new
PR
I
had
a
draft
version
of
it
earlier,
but.
C
Updated
now
that
the
overall
design
for
that
has
been
improved,
and
so
that's
ready
for
view,
I
have
a
develop
plug-in
example.
I
have
a
PR
that
goes
along
with
that.
That
updates
the
ads
of
V2
plugin
to
the
Valeria
plug-in
example
to
test
with
it.
So
that's
still
draft
just
because
it
points
to
the
pr
Branch,
because
it's
because
that's
you
know
what
the
code
it
needs
is
not
in
Maine,
yet
so
the
other
new
PR
that
I
just
submitted
yesterday
5710.
C
That's
the
backup,
restore
phases
that
adds
the
new
waiting
for
plug-in
operations
and
waiting
for
plug-in
operations
partially
failed
to
the
backup
and
restore
list
of
valid
phases,
and
that
also
updates
the
crds
and
the
docs
appropriately
for.
E
C
And
oh
and
then
I
have
a
minor
update
to
the
design
PR.
This
is
relating
in
part
to
your
comments
before
basically.
E
C
Have
some
clarifications
on
cancel
operation.
C
Expected
item
operation,
Json,
I,
updated
that
to
include
status
information
and
then
a
couple
of
minor
fixes.
I
realized
that
my
operation,
progress,
struct
had
a
duplicate
field
in
it.
I
was
using
completed
for
a
Boolean,
yes
or
no
and
also
completed.
For
you
know,
a
number
of
number
of
items
completed
so
I
changed
one
of
those
to
uncompleted
and
the
other
change
was.
C
The
original
proposal
had
waiting
for
plug-in
operations,
partial
failure,
but
I
realized
looking
and
doing
the
pr
for
the
phases
that
the
existing
similar
phase
is
partially
failed.
Not
partial
failure
so
I
wanted
to
make
sure
that
those.
C
A
C
The
only
other
thing
is-
and
this
is
also
still
draft
I-
have
a
restorative
action-
implementation
PR.
That
was
also
updated
with
all
the
changes.
The
reason
it's
in
draft
is
that
that
right
now
that
depends
on
the
backup
item
action,
because
the
backup
item
action,
since
that's
the
first
V2
plug-in
that
also
has
some
infrastructure.
C
You
know
for
the
bills
to
make
sure
that,
because,
instead
of
using
a
new
directory
to
make
sure
all
that
makes
it
in
so
because
of
that,
the
restore
item
action
can't
be
merged
until
the
backup
item
action
was
done
first,
so
that's
the
only
reason
why
that
one's
in
drafts-
it's
it's
ready
for
view
in
terms
of
content.
So
if
you
want
to
look
at
it
comment
on
it,
that's
great.
It's
just
not
ready
to
approve
and
merge.
Yet
until
the
backup
item
action,
one
gets
done.
A
Okay,
so
I
I
see
you're,
making
a
progress
on
your
side,
but
if
you
feel
you
are
blocked,
you
should
feel
free
to
ping
me
or
ping
Jung
hoi
on
the
side.
So
we
can
take
a
look
quickly.
Also,
we
we
discuss
internally.
We
will
be
following
up
with
all
these
V2
changes
in
1.11
and,
unfortunately,
he's
done
with
covert.
So
maybe
this
part
is
slow.
A
little
bit.
I
think
he
will
reach
out
to
you
later
after
he's
recovered
and
yeah
review.
This
VR.
C
Okay,
that's
great
I
I'll
also
mention
on
this
scheduling
side
I'm
here
so
two
more
days
this
week
and
then
I'm
out
through
the
end
of
December
back
on
January
3rd.
A
Sure
yeah
we
all
I
mean
we
are
we
all
taking
the
last
week
of
the
year
off
so
yeah,
so
we'll
be
back
in
January.
C
Okay,
so
that
sounds
like
my
my
vacation
kind
of
matches
closely
to
your
team
anyway.
So
so,
basically,
you
know
right
now:
I'm
not
blocked
on
anything
I'm,
starting
to
kind
of
look
into
the
kind
of
the
next
steps
in
terms
of
implementing
controller
changes.
C
Obviously,
before
I'm
ready
to
submit
those
PRS,
the
ones
that
are
out
now
are
going
to
need
to
be
merged.
E
C
And
as
we
discussed
before
on
the
previous
week,
I
still
expect
to
get
the
volume
snapshotter
API
APR
out
there
in
a
relatively
soon,
but
it's
a
lower
priority
right
now,
because
it's
you
know
we
can
do
the
rest
without
it
or
it
can
be
in
there
that
can
kind
of
go
either
way
depending
on
scheduling
so
I'm,
not
focusing
yet
on
that
one.
A
C
Not
really
just
because
I
don't
think
that
we're
planning
on
updating
the
volume
snapshotters.
Yet,
ideally
you
know
once
all
this
is
done
and
the
API
is
available
and
the
controller
changes
are
made.
C
A
C
Well,
so
the
volume
snapshot
was
actually
the
core
of
the
original
design
that
Dave
put
in
place
that
we're
modifying
and
the
the
reason
for
volume
snapshotter
being
added
to
this
is
that
with
it,
when
a
volume,
snapshot
or
plug-in
creates
a
snapshot
and
Returns,
the
uploading
of
the
snapshot
to
AWS
through
gcp
is
happening
in
the
background
and
what
will
happen
if
you
immediately
restore
from
backup
after
creating
a
backup
with
snapshots?
Is
you
can
actually
hit
into
situations
where
snapshot's
not
ready?
C
Yet
so,
when
the
AWS,
for
example,
or
gcp
volume,
snap
shutters,
implement
the
the
feature
here?
Where
you
know
we
would
do
the
progress
that
can
check
on
whether
that
upload
is
done,
and
we
won't
then
move
the
backup
to
complete
it
until
it's
done
so
the
since
the
volume
snapshotters
already
do
the
uploading.
In
the
background,
the
impact
is
not
so
much
on.
You
know
implementing
anything
asynchronously.
C
A
C
The
past
myself,
if
you
do
a
backup
with
with
snapshots,
especially
for
large
files
systems-
and
you
then
immediately
restore
it's
gonna-
fail,
because
that
snapshot
won't
be
ready
to
use.
Yet.
C
I
I
don't
know
if
we
can
get
a
percentage
out
of
that.
I
do
know
I'm
pretty
sure,
because
because
again
I
was
when
I
ran
into
this
problem
in
the
past
we
didn't
end
up
fixing
it
in
Valero
at
the
time
Upstream,
but
there
was
a
way
to
determine
whether
the
snapshot
was
ready
to
use,
and
so
you
know
the
thing
with
the
progress
is
that
that
the
minimal
progress
implementation
for
something
like
this
would
be
hey.
D
C
Useful,
that's,
okay,
the
done
versus
not
done
allows
Valero
to
not
Mark
a
backup
as
complete
until
that's
happened.
A
So
you're
saying
there
is
some
API
called
to
tell
us
if
this
uploading
is
done
or
not,
but
we
just
don't
know
about
the
progress.
Yeah
I
think
that
would
be
good
enough
for
the
V2.
C
C
You
know
for
further
for
Valero
to
use
kind
of
the
sequence
there
is.
We
have
to
add,
update
the
API
definition
to
add
those
new
functions.
We
then
have
to
update
the
controller
to
call
those
functions,
and
then
we
have
to
update
the
plugins
themselves
to
implement
those
functions.
So
basically,
if
we
implement
the
API
and
the
controller
changes,
but
don't
yet
update
the
plugins
to
V2,
there's
no
change
to
behavior
from
currently,
but.
C
E
A
A
C
And
I
haven't
looked
at
this
recently
because
I
know
I
looked
in
into
this
when
I
first
ran
into
the
issue.
This
is
at
least
a
year
ago,
I.
C
A
C
To
the
volume
snapshot
aside,
right
now
is
kind
of
it's
still
in
kind
of
a
nice
to
have
category
and
we
want
it
there,
but
if
adding
it,
you
know
puts
the
released
timing,
you
know
at
risk,
then
we
can
defer
it
to
112.
C
If
we
don't
add
it,
it's
not
any
better
or
any
worse
than
the
current
behavior.
So
we're
not
we're
not
introducing
a
regression.
Nothing
gets.
You
know
messed
up
right.
A
C
Know
and
it's
even
okay
to
add
just
the
API,
for
example,
but
not
the
controller
part,
because
it's
all
incremental
again
you
do
that.
But
you
don't
do
the
next
step.
You
haven't
broken.
Anything
you've
just
made
a
smaller
task
for
later.
So
you
know
if
I
hit
a
point
where
I'm
blocking
on
something
else
and
I
can
put
that
in
place.
You
know
we
might
get
to
it,
but
at
the
same
time
the
focus
is
going
to
be
making
sure
it
works
for
backup,
item
action,
number
star,
item
action.
E
C
And
we
can
add
the
volume
snapshotter
for
it
later.
That's
not
a
problem,
and
that
will
just
be
something
on
the
112
roadmap
if
we
don't
get
to
it
in
111.
this.
This
may
be
one
of
those
calls
that
you
know
when
we
have
that
feature
freeze
in
January.
At
that
point,
we're
going
to
make
the
call.
Oh,
we
haven't
started
this
yet
we're
gonna
pull
it
out
of
scope
or
you
know
we
have
started
it.
C
Here's
what's
left,
it
looks
pretty
low
risk,
we'll
keep
it
in
so
I
think
that's
that's
the
time
when
we
can
make
the
final
call
as
to
whether
we're
pushing
this
to
112
versus
not
and
just
just
honestly,
given
the
how
much
time
is
in
the
schedule.
I
think
it's
very
likely
at
this
point
that
we
are
going
to
say:
hey
we're
not
going
to
get
this
in
111,
but
it's
okay
for
112..
C
It
doesn't
really
affect
data
mover
anyway
for
completeness,
we
want
it
and
it
does
solve
a
problem,
but
if
we
do
it
in
112
versus
11,
from
my
point
of
view,
that's
not
a
huge
difference
in
terms
of
you
know.
Certainly
Red
Hat
needs
again.
We
want
we
and
if
we
have
a
date
that
it's
going
to
be
ready
by
that's
great,
but
it's
it's
not
as
critical.
A
So
so
I
was
I
will
suggest.
We
focused
on
the
back
of
that
resources
and
to
verify
this
API
change.
If
that
works,
unless
merge
the
desire
of
volume,
snapshotter,
V2
and
implemented
by
calling
the
API
on
the
cloud
service,
do
you
think
that
flow
will
work.
C
So
so
yeah
yeah
and
again
I
think
I.
Think
I
I
can
confirm
that
you
know
before
I.
Do
any
work
on
this
I
I
think
confirming
that
there's
a
way
to
implement
it,
like
you
said
to
to
say:
hey,
is
this
done?
Is
it
not
done?
Are
we
waiting
because
at
that
point,
because
we
have
a
snapshot
idea
as
far
as
I
understand.
C
Now
and
again,
I
need
to
look
into
this,
because
that,
because
my
memory
is
a
little
fuzzy,
it's
been
a
while
it
was
as
simple
as
you
know
querying
you
know
this
is
this
SnapChat
already
ready
because
basically
I
believe
there's
a
status
on
the
snapshot
and
it's
like
pending
versus
right,
I,
don't
remember
what
the
actual
status
string
is,
but
I
believe
we
can
get
it
from
the
status
just
to
understand.
Oh,
this
is
still
uploading
or
oh,
this
is
ready
to
go.
C
That
should
be
all
we
need
for
that
minimum
progress
implementation
if
we
can
get
a
percentage,
that's
better,
but
it's
not
essential
and
that's
kind
of
part
of
why
we
made
that
we
made
that
operation
progress
struct
a
bit
more
flexible.
If
we
have
detailed
progress,
we
can
say
you
know
five
out
of
10
or
1000
out
of
whatever,
but
if
we
don't
have
detailed
information,
we
just
have
a
phase.
You
know
the
phase
is
uploading.
C
A
C
Again,
I
would
rather
do
it,
then
you
know
the
release
on
it.
So
you
know
it's
it's
a
lower
priority
from
my
own
kind
of
scheduling
of
Time
Versus,
some
of
these
other
tasks
like
the
the
new
phases
and
the
the
Json
file
and
the
file
upload.
Some
of
that.
C
So
you
know
if,
if
we,
if
there's
not
time
for
it
by
a
code
freeze,
then
obviously
it
slips.
But
if
there's
time
for
it
and
it's
gonna
work,
then
it
would
be
better
to
get
this
all
in
at
once.
Just
because
we're
implementing
that
way.
C
You
know
it's
just
kind
of
all
the
async
work
kind
of
together,
all
at
once
in
111.,
but
again,
if
we
can't
fit
it
in
due
to
sort
of
schedule
constraints,
that's
fine
and
that'll,
be
the
the
volume
snapshot
will
be
the
one
part
of
this
work
that
it
makes
perfect
sense
to
defer
to
112.
C
and
that's
going
to
be
fine.
If
you
I
I,
think
I.
Think
first
part
of
January
will
be
the
right
time
to
make
that
call
and
again
I
think,
there's
probably
there's
a
good
chance
that
we
will
want
to
defer.
Just
because
you
know,
there's
a
lot
of
things
that
need
to
get
reviewed
and
merged
and.
A
A
So
so
so
so
let
me
clarify
so
if
we
decide
to
refer
the
volume
Five
strata
V2
to
112,
shall
we
also
defer
merging
the
design
in
112
So
that
we
do
all
these
in
one
minor
release.
C
C
I
would
think
that
the
actually
I
thought
we
had
merge
that
already
I,
don't
remember
off
top
of
my
head.
The
design
PR
for
that
may
already
be
merged.
Okay,
so
I
can
check
but
and
I
think
the
design.
We
should
go
ahead
and
merge
if
we're.
If
we're,
if
we're
fine
with
it,
because
I
think
the
only
reason
we
would
defer
it
at
this
point
is
scheduling.
E
C
C
Yeah
it's
already
merged.
The
only
open,
pris
I
have
now
are
the
the
two
backup
and
restore
item
action,
API
implementations,
the
minor
updates
to
the
design
and
that
backup
restore
phases,
so
we've
already
merged
the
design.
Here
it's
only
a
question
of
what
what
I
haven't
done
yet
is
created
a
PR
for
implementing
that
API
for
volume,
snapshotter.
A
Okay,
so
so,
let's
defer
that
work
to
112
using
that
okay.
So
let's
focus
on
the
yeah.
C
We
get
to
get
again,
but
realistically,
let's
focus
on
the
things
that
have
to
be
here:
yeah.
E
C
Phases
and
I
know
there's
several
more
follow-on
tasks
that
you
know
have
to
get
done.
You
know
by
the
end
of
January,
beginning
of
February
in
terms
of
influencing
the
changes
to
the
controllers
and
all
of
that
and
that
that's
kind
of
gonna
be
where
the
bulk
of
the
work
is.
A
Yep
so
so,
I'm
also
curious
after
the
V2
has
been
merged.
I,
don't
think
we
need
to
update
all
the
existing
backup
by
connection.
C
No,
no,
no,
not
at
all.
One
of
because
one
of
the
features
of
the
plugin
versioning
is
that
when
you
create
a
new.
B
C
Version
under
the
a
package
plug-in
code
in
Valero,
there's
there's
a
there's,
an
adapter
that
gets
written
and
what
happens
is
that
Valero
pulls
the
V1
plug-in
out,
and
then
it
wraps
this
in
this
adapter
package
so
that
the
the
Valero
controller
gets.
It
gets
a
V2
plug-in
for
everything,
but
the
plugin
that
it's
actually
calling
through
the
grpc
might
be
V1
plug-in,
and
this
adapter
will
supply
those
missing
chains.
So,
for
example,
for
progress
and
cancel
those
don't
exist
in
V1
plugins,
the
adapter.
C
Will
you
know
in
the
case
of
cancel
it
just
returns?
You
know,
nil,
doesn't
do
anything
in
the
case
of
progress,
It's
going
to
actually
return
an
error
on
supported
operation
and
since
Valero's
controller
was
only
going
to
ever
call
progress
on
a
plug-in
that
returns
an
operation
ID
for
a
V1
plug-in
that
will
never
be
returned,
which
means
it'll,
never
call
it
so
right,
so
V1
plugins
should
be
100
functional.
That's
that
was
that
was
a
big
part
of
the
design
of
plug-inversioning
in
general.
C
Was
to
make
sure
that
you
know
you
don't
need
to
update
to
V1
plug
and
old.
Plugins
will
still
work
and
if
you
look
at
my
Valero
plug-in
example,
PR
that
adds
a
V2
backup
item
action
plugin
but
also
leaves
the
V1
plug-in
in
place.
C
If
you
actually
run
Valero
with
that,
you'll
see
the
then
again
the
the
plug-in
example
plugins,
really
just
you
know,
make
a
log
entry
so
so
that
you
can
see
that
the
plug-in
ran
and
when
you
run
it
you'll
see
that
the
V1
plugged
into
and
the
V2
plugins
both
run.
So
they
can
exist
side
by
side.
C
C
A
See
so
so,
by
the
way,
because
there
is
some
change
in
the
backup
controller
needed
to
handle
this
V2
backup
as
a
matter
and
restore
item
actions,
you
have
done
some
POC
internally
with
this,
your
existing
voting
stuff
to
verify
the
work
right
or
that's
also
something
we.
C
Need
to
learn
well,
we
haven't
really
done
anything
on
the
developing
side
with
this.
Yet
because
it's
not
going
to
be
functional
in
terms
of
you
know,
for
these
asynchronous
actions
to
actually
work
and
have
Valero,
you
know
hold
the
status
until
it's
done.
We
need
to
actually
have
the
controller
changes
in
place
and
this
this
backup
item
action,
controller,
just
updates
to
use
the
V2
API,
but
the
logic
is
still
the
same
as
before,
because
again
it's
a
phased
approach.
C
C
If
it
is
returned
and
then
you
know,
do
the
actual
async
operation,
so
the
the
right
now,
the
only
PLC
here
is
really
just
making
sure
that
this
refactoring
to
allow
for
v2
plugins
still
works
with
all
the
existing
V1
plugins,
because
we're
not
actually
changing
the
business
logic
of
the
controller
yet
other
than
using
V2
plug.
Instead
of
E1
The
Next
Step,
you
know
January
is
going
to
be
actually
to
modify
the
backup
controller
to
check
that
operationid
returned.
D
C
C
A
Yeah,
my
yeah,
when
we
are
reviewing
the
design,
yeah
I,
think
the
general
flow
will
work,
but
my
concern
is
like
so
in
some
of
the
details
like
we
need
to
pull
and
update
the
item
operation
right
based
on
in
the
object
store
or
whatever
performance
or
the,
how
that
impact
is
general
or
backup
controller
flow.
Okay.
So
so
so
at
the
time
the
111
is
released,
I
think
internally,
we
do
not
really
call
these
I
mean
we
do
not
really
need
to
implement
any
back
of
atom
action.
V2.
C
Exactly,
in
other
words,
the
logic
that
will
handle
those
those
those
operations
is,
is
in
the
Valero
controllers,
but
none
of
the
control
of
the
plugins
that
we're
releasing
is
part
of
Valero.
You
know
that
field
is
always
blank
which.
E
C
As
long
as
you're,
only
using
the
Valero
controllers-
that's
right,
Valero
plugins,
then
we're
never
gonna
actually
be
uploading.
Anything
because
you
know
the
list
of
operations
is
going
to
be
empty,
so
the
logic
is
going
to
be
there,
but
basically
those
you
know
if
blocks
or
those
Loops
are
going
to
be
skipped,
because
the
list
of
things
we
have
to
deal
with
is
zero.
You
know
is
empty,
so.
A
So
so
so
so
so
as
for
your
internal
plugin,
that
will
implement
this
way
to
a
Bia
plugin
apis.
Will
that
will
that
be
open
source?
Also
because
look
like
we
publish
a
new
API
and
we
should
have
something
as
a
Implement
reference,
so.
C
That
yeah
right
now,
every
every
we're
doing
is
on
GitHub
well,
most
of
it's
under
GitHub,
openshift,
actually
I.
Think
the
data
mover
is
under
it's
under
a
different
I.
Think
it's
under
github.com
Mig
tools,
I
think
I
have
to
get
back
to
you
on
that
one
I
forget
exactly
because
I
know
we
we
did
some
repo
moving,
but
all
that
all
of
that
work
is
in
publicly
available.
Github
repos
right
now
we're
not
using
any
of
this,
because,
basically
we
can't
do
any
of
that
work
to
implement.
C
You
know
the
new
plugin
apis
with
that
those
plugins
until
the
Valero
work
includes
the
controller
changes
at
least
get
merged
to
Main.
C
That's
kind
of
the
Valero
work
to
allow
the
plug-in
operations
to
work
at
all.
You
know
needs
to
be
in
place
first,
and
then
we
can
write
a
plug-in
that
makes
use
of
the
new
feature.
Yeah.
C
Yeah
I
mean
at
a
minimum.
We
can
point
to
that
and
say
this
is
being
done.
The
other
thing
we
can
do
is
if
it
makes
sense
again,
I
I,
don't
know
if
there's
some
way
of
pulling
out
a
kind
of
minimal
reference.
You
know
to
Valero
plug-in
example
that
actually
uses
this,
because
right
now,
most
of
what's
in
Valero
plug-in
example,
is
really
just
you
know,
printing
out
log
messages
and
in
the
execute,
and
it's
not
really
doing
any
functional.
C
You
know
plug-in
work,
it's
just
kind
of
showing
hey.
If
you
take
this
code
and
you
build
it
and
you
add
it
as
a
plug-in
it'll
run
and
then
it's
up
to
you
to
add
what
you
need
to
do
in
your
logic,
but
you
know
in
the
case
of
showing
with
Valero
111
what
you
can
do
with
this.
C
Certainly
we
can
point
to
that
example
of
saying
here's
a
plug-in,
that's
built
that
uses
this.
You
know
it's
it,
that's
a
plug-in
that
you
know
is
only
going
to
work
for
someone
if
they
have
all
sync
installed
and
are
you
know
using
all
those
components?
So
it's
not.
It's
not
a
standalone
plug-in
that
doesn't
require
infrastructure
around
it
because
that
integrates
in
with,
but
we
can
figure
out
what
makes
sense
there.
You
know
certainly
pointing
there
in
docs
to
say
here's
an
example
using
this
for
111.
C
You
know
we
can
do
that
and
it
makes
sense
to
come
up
with
a
you
know.
Smaller
example
plug-in
that's
more
Standalone
I'm,
just
not
the
thing
is
that
for
it
to
actually
demonstrate
this
is
a
this
is
an
operation
that
will
take
a
while,
and
it
will
show
that
the
the
backup
is
going
to
be
in
you
know
some
intermediates
that
that
waiting
plug-in
operation
State,
you
know
the
plug-in
would
need
to
do
something
external.
You
know
create
a
CR
of
some
sort.
C
Think
yeah
with
some
kind
of
time
stamp
and
just
have
a
plug-in
that
automatically
says:
okay,
the
operation
just
to
create
this
config
map
and
we're
going
to
Define
it
as
complete
when
the
config
map
you
know
time
staff
is
you
know,
five
minutes,
you
know
some
some
configurable
thing
to
say
you
know
so
that
so
that
you
know
it
would
be
a
very,
very
kind
of
rough
proof
of
concept
to
say.
C
E
C
C
C
Just
saying,
if
you
wanted
someone
to
be
able
to
test
this
out,
you
could
add
a
plug-in
example
of
something
that
fakes
it
just
so
that,
because
they
may
not
be
able
to
take
the
you
know
the
red
hat
example
and
use
it
in
their
cluster.
If
they
didn't
have,
you
know,
valsync
and
the
other
components
that
are
needed
for
that,
for
example.
But
if
we
had
a
plug-in
example
that
ran
like
that,
you
know,
then,
then
they
so
so
I
I,
don't
I,
don't
mean
this.
Instead
of
that,
I
think
you
could
do
both.
C
We
need
to
point
to
the
real
world
example
saying:
here's
an
actual.
You
know
project,
that's
using
this
new
API.
You
know
for
something
in
a
relevant
to
its
design,
but
you
could
create
a
plug-in
example
that
kind
of
forced
the
backup
to
go
into
that
state
for
a
little
while
and
then
kind
of
demonstrating
the
the
workflow.
A
Let's
do
that
and
yeah.
Thank
you
yeah.
So
that's
part
of
the
status
update.
Do
you
have
any
other
thing
we
want
to
mention
in
this
part.
A
Okay,
so
let's
move
to
the
discussion
topics
or
in
write
a
good
PR
about
you,
know,
clarifying
the
release.
Cadence
and
process
I
had
I
had
a
few
comments,
so
if
anyone's
interested
videos
also
take
a
look,
and
that
already
already
knows
your
thought.
A
In
addition
to
that,
I
have
something
I
want
to
discuss
with
you
Scott
it's
about
how
Valero
handles
metadata
during
restore
in
our
internal
product,
using
Valero
to
restore
some
internal
workload.
We
found
that
Valero
a
deliberately
threw
up
most
of
the
metadata
of
an
object
or
resource
during
resource.
A
So
but
I
know
it's
not
restoring
things
like
finalizers
management,
managed
Fields
are
these
by
Design,
or
is
that
because,
at
that
time
we
don't
put
that
a
lot
of
stuff
in
the
metadata?
So
the
developer
thought
it
should
be
good
enough
to
just
really
so
restore
like
name
or
label
right.
C
I
I
don't
know
I
I
don't
have
a
100
answer
on
that
I
know.
This
has
been
the
case
since
before
I
started,
working
on
Valero.
C
I
have
a
vague
memory
that
Dylan
may
have
had
a
conversation
with
Steve
or
one
of
the
other
earlier
developers
about
this,
a
while
back
Dylan's
not
available
for
the
call
now
but
I
think.
The
main
issue
is
that
there's
some
Fields
there
in
a
generation
everyone's
where
you
know
you
don't
want
to
restore
them,
and
so
the
the
kind
of-
and
that
was
the
question
of
do
you
want
to
list
all
the
things
that
you
don't
want
to
restore.
D
D
A
C
That
the
the
whitelist
approach
was
safer
because
that
way,
if
a
new
kubernetes
version
added
new
fields
that
we
don't
want
to
keep
you
know
that
that
prevented
new
changes
in
kubernetes
or
you
know
someone's
you
know,
for
example,
if
you're
on
openshift
there
might
be
additional
fields
that
that
a
base
kubernetes
cluster
wouldn't
have
that
again.
You
may
not
want.
C
There's
a
couple
of
things
we
could
consider.
There
may
be
certain
things
like
you
said:
finalizers
management
there
might
be
certain
fields.
We
want
to
go
ahead.
You
know,
as
a
simple
fix
for
now.
Just
add
to
that
list
of
the
small
set
of
things
we
wanted
to
to
include
I
wonder
if
we
wanted
to
have
an
optional
spec
field
kind
of
a
list
of
you
know
metadata
fields
to
keep
that
way.
If
someone
yeah
I
was-
and
it
was
I-
think
by
default,
we
still
want
to
be
careful
about
making
a
change.
A
Yeah
because
I
was
thinking,
maybe
we
should
switch
to
The,
Blacklist
or
block
list
approach
to
explicitly
tell
Valero
you
should,
by
default,
restore
everything
instead
of
some
certain
Fields.
So
you're
saying
we
should
stick
with
the
I'm
thinking,
yeah.
C
I
think
the
the
main
reason
I
I'm
I,
guess
I-
would
hesitate
on
kind
of
you
know,
switching
to
just
the
block
list
approach
is
that
I
just
don't
know
if
there
are
situations
in
certain
clusters
or
in
certain
you
know,
architectures,
where
there's
other
fields
that
are
not
standard,
kubernetes
Fields
that
you
also
don't
want
to
restore
okay.
C
I'm
thinking
we
might
want
to
do
consider
a
couple
of
things.
One
again
is
if
there's
certain
things
like
finalizers
that
we
know
we
always
want.
Let's
just
add
that,
but
we
also
may
want
to
consider
adding
a
spec
field.
C
You
know
which
will
provide
a
list
of
you,
know,
kind
of
a
list
of
metadata
fields
to
keep
that
will
allow
users
to
overwrite
or
override
default
behavior.
C
E
C
You
know
they
can
provide
a
list
without
finalizers,
but
if
they
want
to
add
some
other
fields,
you
know
custom
or
maybe
again,
these
are
things
that
in
some
version
of
kubernetes
they
are
using.
It
has
a
field
that
you
know
isn't
in
basic
base,
kubernetes
that
they
want
to
add
that
Valero
is
not
going
to
know
about
anyway.
A
E
A
Staff,
so
that
we,
by
default,
we
restore
everything
until
the
on
some
certain
cluster
digital
user
thinks
user
is
adding
some
customized
field
in
the
metadata
and
that's
problematic.
If
we
restore
it,
the
user
just
add
it
to
the
block
list
to
tell
Valero
hey,
do
not
restore
it
and
restore
everything
else.
Would.
C
That
be
I
mean
I
mean
we
could
even
take
the
approach
like
we
do
because
most
of
most
of
the
other
areas
where
Valero
lets
user
and
decide
what
to
you
know
like
with
resources,
for
example
or
namespaces.
We
know
we
have
the
include
and
the
exclude
list,
and
then
they
combine.
So
if
you
specified
exclude
list,
then
everything
else
is
included
specifically
include
list
that
nobody
else
is
excluded,
so
it
may
be.
If
we're
going
to
add
a
spec
field
for
this,
we
could
do
we
could
we
could
create
both.
C
You
know,
exclude
metadata
fields
and
include
metadata.
Fields
that'll
give
the
user
the
option
of
either
approach,
and
then
we
have
a
default
that
you
know
if
user
doesn't
specify
anything,
we
go
back
to
something
like
a
set
of
defaults,
and
we
might
want
to.
C
This
may
be
an
issue
where
again
I
guess
we
already
have
a
couple
of
issues
here,
a
minute,
but
maybe
a
more
General
issue
of
so
we
can
get
some
feedback
from
others
as
to
you
know
it.
If
there
are
certain
fields
that
we
know
need
to
be
excluded
or
included,
you
know
what
makes
sense
here
just
because,
unfortunately,
none
of
the
people
that
were
working
on
Valero
when
this
original
decision
was
was
made
or
still
here,
because
this
this
was
worked
out
well
before
I
started
working
on
the
project,
yeah.
A
So
so
in
when
you
support
the
like
oadp
or
your
product,
that
you
use
is
Valero,
is
there
any
requirement
from
the
user
requesting
like
they
should
restore
additional
fields
from
metadata
like
finalizer
management.
C
Off
the
top
of
my
head,
I,
don't
remember
seeing
that
we
had
an
issue
that
we
were
kind
of
discussing
this
on
I
could
ask
Dylan
or
shubham
if
either
of
them
had
run
into
this.
A
C
Yeah,
so
so,
and
that's
why
I
guess,
because
you're
getting
different
requests
from
different
customers
and
different
users,
I'm
kind
of
thinking,
there's
probably
two
tasks
here:
one
is
to
figure
out
whether
what
we're
doing
by
default
and
needs
to
be
modified.
You
know
adding
certain
things
or
whatever,
but
also
do
we
need
to
make
a
configurable
in
case
not
every
user
has
the
same
needs.
A
C
A
Yeah,
so
so
you
you,
are
you
also
because
this
this
one
is
really
I,
think
widely
used
when
there
is
since
for
some
CR
based
resources
or
objects,
because
when
you
create
a
CR?
Quite
usually,
there
are
a
lot
of
other
resources
created
after
that
and
they
create
their
own
reference.
If
that
one
is
not
restored
correctly,
it
really
breaks
the
relationship
of
the
resources
yeah.
C
Oh
yeah,
no,
definitely
and-
and
the
other
thing
is
that
some
types
can
figure
it
out
like
when
you
restore
you
know
a
deployment
and
it's
pod.
A
C
But
but
for
example,
I
I
do
I
think
in
some
cases
and
I
think
I
think
Damon
set's,
one
of
them
that
I
remember
again.
This
may
have
changed,
but
you
know
a
year
or
two
I
remember
there
if
he
restored
the
Pod,
it
wasn't
getting
me
on
a
reference
set
on
restore,
and
so
you
ended
up
with
this
pod
that
was
restored.
That
no
longer
was
connected
to
the
Damon
set
and
then,
of
course,
the
data
set
controller
would
recreate
the
new
pod.
C
So
you
end
up
with
duplicate
pods,
and
you
know
one
way
we
handled
that
on
the
red
hat
side
was
that
we
actually
have
a
plug-in
where
we
actually
in
most
cases
choose
not
to
restore
pods
with
owner
references,
because
you
know,
if
you
do,
if
you
restore
deployment
that
will
automatically
create
new
pods,
so
you
don't
need
to
restore
the
Pod,
and
unless
you
have
restic,
restores
or
post
restorative
hooks,
then
you
do
need
that
pod.
C
So
you
know
there's
some
logic
around
there
that
can
be
handled
in
plugins,
but
in
terms
of
owner
references
itself.
I
don't
really
know.
C
I,
don't
know
again
what
the
consequences
would
be
if
setting
them
like.
You
said
if
they
set
wrong
or
if
you
were,
for
example,
if
you
restore
something
with
another
reference,
but
you
don't
restore
the
thing
that
it
pointed
to.
You
know
that
could
be
a
problem.
Yeah.
C
E
C
C
There's
also
other
references
and
other
things,
even
that
aren't
pods,
that's
kind
of
a
more
General
thing
and
you
know
there's
other
reference
is
the
point
to
you
know:
custom
operators
that
we
have
no
idea
about
because
they're
not
we're
kubernetes.
A
Yeah,
because
I
was
thinking,
I
can
push
back
such
requirements
and
help
help
them
like
hey.
You
should
refine
your
controller
so
that
the
owner
reference
can
be
reconciled,
but
if
even
in
kubernetes
I
mean
classical
resources,
they
don't
reconcile
the
owner
reference.
It
may
be
really
tricky
because
we
really
don't
have
a
good
way
that
generally
how
a
Valero
can
handle
owner
reference
correctly.
That
will
require
a
lot
of
change
right.
C
A
I
think
we
may
yeah,
we
may
I
may
reach
out
to
you
or
other
maintainer
to
discuss
this
particular
field
in
the
future,
because
that's
become
more
and
more
controversial
here.
Whether
Valero
should
restore
it
or
not
internally,
but
currently
what
I'm
telling
them
is
that
you
should
allow
controller
reconcile
it,
but
they're
like
if
Valero
can
handle
that,
then
why
you
should
control
or
handle
it,
there's
some
back
and
forth.
A
C
I
I
guess
I
I,
don't
really
know
mainly
because
I
don't
know
it
like.
If,
if
we,
if
we
did
restore
them
in
Valero,
what
other
changes
we
would
need
to
make
is
and
again
I
don't
know
if
that
would
have
unpredictable
changes
in
other
controllers
too,
because
you
know
right
now
with
some
controllers,
if
you
don't
restore
on
a
references,
it
could
break
that
controller.
Well,.
E
C
C
In
you
know
various
environments
and
say:
okay
you're
just
going
to
make
a
local
change,
you
know
to
restore
it
and
see
what
happens
in
various
kinds
of
workloads.
It's
just
to
kind
of
kind
of
experiment
with
it
to
kind
of
as
a
proof
of
concept,
to
see
what
Valero
would
do
there
and
how
you
know.
Damon
sets
and
deployments
and
other
things
can
handle
that.
A
Yeah
but
I
think
you
know
letting
Bolero
restore
the
owner.
Reference
is
already
a
big
chunk
of
work,
because
Valero
will
need
to
figure
out
the
dependency
and
somehow
reorder
the
resources
during
the
restore,
and
you
need
to
create
resource
a
after
resource.
They
have
a
uid
somehow
set
the
uid
in
resource
B
and
so
that
resource
B
can
or
object
P
can
we
can
reference
the
resource,
like
correctly.
A
C
A
C
No
I
don't
remember
running
into
this,
but
again
I.
Think
part
of
that
is
certainly
on
the
pods
side,
because
our
approach
with
the
controllers
has
been
to
basically
with
Pods
at
least,
is
to
not
restore
pods
without
a
references
because
we're
going
to
let
their
controller
recreate
the
Pod.
So
you
know
we
have
a
pod
pod
control,
plug-in
stratum
action
that
basically
says.
If
there's
other
references
here
and
there's
no
rustic,
you
know
well.
C
If,
if
there
are
owner
references
and
we're
not
using
rustic
and
we're
not,
we
don't
have
poster
store
hooks
on
the
Pod.
Then
we
just
don't
restore
the
Pod
because
we'll
let
because,
if
you
restore
deployments
without
a
pod
that
that
the
deployment
controller
will
scale
that
up
to
the
right
number
of
replicas
and
create
new
pods.
C
But
you
know
again,
if
you
have
rustic
annotations,
for
example,
that
doesn't
work,
you
need
the
you
need.
The.
A
A
Okay,
if
there's
no,
let's
wrap
up
and
happy
holidays,
guys
Scott,
if
you
need
any
quick
review
or
responses,
feel
free
to
pick
up
something.
Okay,.
C
Well
again,
I
think
the
the
the
ones
that
are
ready
for
review.
It
would
be
great
if
you
know
we
could
get
those
reviewed
emerge
this
week,
the
or
at
least
you
know.
If
there's
comments,
then
I
need
to
make
changes.
That's
fine
tuna,
too,
but
the
back
of
item
action
API
that
so
there's
that
one,
the
oh
yeah
and
I
would
say
the
backup
restore
phases.
So
so
yeah
this
one
here,
that's
a
smaller
plug-in
that
should
be
relatively.
A
C
I'll,
do
the
design
is
good
to
get
reviewed
just
while
it's
still
fresh
on
our
minds,
because
we
reviewed
the
other
design
before.
But
that's
not
blocking
me
I
would
say
the
backup
out
of
action
and
the
and
the
new
phases
are
the
two
high
priorities,
because
those
are
the
things
that
are
gonna
block.
D
E
C
Restorative
action
will
become
a
higher
priority
after
those
get
put
in,
but
that's
you
know
it's
not
ready
to
review
yet
so
don't
worry
about
it.
So
just
those
two
are
the
ones
that
I
would
say.
If
we
can
get
enough
reviews
to
either
merge
this
week
or
at
least
get
comments.
If
I
need
to
fix
things,
you
know
either
one
that
would
be
great.