►
From YouTube: Velero Community Meeting - August 24, 2021
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
Hello,
everyone
and
welcome
to
the
valerio
community
meeting,
slash
open
discussion
today
is
august
24th,
I'm
jonas
roslin
I'll
be
your
host.
Tonight
we
get
a
bunch
of
attendees
if
you
haven't
added
your
name
to
the
attendee
list.
Yet
please
do
so
we're
going
to
kick
off
with
some
status
updates
and
then
dive
into
discussion
topics
and
then,
lastly,
per
usual,
we'll
have
some
contributor
shoutouts
with
that,
I'm
going
to
start
with.
B
Yeah
I
have
some
updates
for
the
tr
for
various
invitations.
I
resolved
all.
First
of
all,
thanks
for
the
review
by
a
bridget
and
dave,
I
resolved
all
their
comments
on
the
brilliant
gave
me
the
approval
pending
for
their
full
song
video.
Hopefully,
this
vr
can
be
emerged
after
david's
bad.
After
that,
I
will
write
up
another
pr
to
update
the
design
proposal
accordingly,
because
they
have
some
latest
suggestion
to
change
the
behavior,
and
I
will
write
up
another
pr
for
the
android
test.
B
D
Oh,
I
think
I
noticed
that
earlier.
I
think
it's
because
you
re-requested
a
review
like
like
a
few
seconds
after
I
approved
it,
so
I
think
it
dismissed
that
I'll
approve
it
again.
E
C
Yeah,
the
first
item
framework
is
I'm
working
on
to
improve
the
stability
and
second
item
is
to
move
the
base
image
to
destroys,
which
contains
less
all
libraries
and
os
related
spotify
and
which
means
it
could
it
contain.
It
contains
less
vulnerability.
C
A
I
got
one
question,
so
there
are
other
projects
and
they're
also
looking
at
moving
their
base
image
to
something
else.
Perhaps
distro
less.
Have
you
run
into
any
specific
issues
with
changing
the
the
base
image
here.
B
B
A
Great
thank
you.
Venkai
next
up,
bridget.
D
Hi
everyone-
I
don't
have
a
huge
amount
to
report
last
week-
was
spent
doing
kind
of
internal
work,
but
I've
been
kind
of
gradually
trying
to
make
my
way
through
the
pr
review
backlog.
So
we
had
a
session
last
week
with
the
team
to
try
and
get
through
some
of
the
pr's
see
I'll,
be
continuing
with
that
and
trying
to
get
that
number
down.
D
I
also
finally,
apologies
for
kim
phong
waiting,
but
I've
pushed
his
branch
to
the
vmware
tons
of
valero
repo,
so
he'd
start
work
on
implementing
the
new
plug-in
versioning
changes.
So
that's
not
on
the
vmware
upstream
repo.
So
we
can
start
to
collaborate
on
that.
So
I'm
gonna
be
starting.
D
Some
changes
there,
oh
fong
you're
on
the
call
excellent
sorry.
I
didn't
have
the
full
list
up
so
yeah,
so
that
branch
is
not
up
there,
so
we
can
start
contributing
on
that
together.
A
Thank
you.
Any
questions,
comments
for
bridget.
B
Yeah,
as
for
the
pr
3855,
the
design
of
this
plugin
working
yeah,
you
can
also
need
some
review.
D
Yeah,
I
I
am-
I
have
some
I
I
need
to
make
a
change
based
on
on
some
comments,
so
I'm
gonna,
I
need
to
address
a
as
a
priority,
so
I'll,
try
and
get
that
done
before
next
week.
Sorry
for
keeping
everyone
waiting.
A
A
F
Right
well,
that
roadmap
is
really
the
one
that
I
presented.
I
presented
it
quite
a
long
time
ago,
and
it
just
took
me
forever
to
get
the
get
it
merchant
to
get.
It's
all
on
me
with
git
errors.
In
short,
it's
just
clarifying
when
we
had
kind
of
staffing
changes.
We
wanted
to
rethink
what
we
were
gonna
release
in
one
seven,
and
so
this
is
just
this
is
just
making
official
what
we've
been
talking
about
for
a
while.
F
So,
as
you
can
see
here
in
the
upper
part,
the
lower
part
well
here
in
the
upper
part,
basically
we're
describing
what
we
are
still
hoping
to
get
into
one
seven.
F
F
So
please
think
let
let
us
know
if
there
are
particular
things
that
you
were
hoping
to
see
in
one
eight
and
perhaps
jonas
you
can
tell
me,
but
perhaps
maybe
next
community
meeting
would
we
want
to
devote
a
little
time
to
one
eight
or
maybe
not
next
community,
maybe
in
two
community
meetings,
something
like
that.
Yeah.
A
For
sure,
for
sure,
do
you
want
to
put
that
on
the
agenda
for
mid-september
or
so
perfect.
F
Perfect
that
sounds
great,
so
yep
and
just
to
clarify
again,
we
actually,
maybe
maybe
one
of
the
engineers-
can
make
sure
I'm
correct.
I
believe
we're
aiming
towards
late
september
for
one
seven
and
I
believe
one
eight
will
be
about
three
to
four
months
after
that
so
late
december
early
january.
Something
like
that,
but
don't
hold
me
to
those
dates.
Yeah.
We
haven't
really
discussed
it
as
a
team,
so
just
as
you're
thinking
for
one
eight
think
about
in
the
next.
F
A
A
I
presented
this
to
the
team
last
week,
so
the
gist
of
it
is
essentially
that
valero
is
very
popular
and
very
much
used
within
the
kubernetes
ecosystem.
A
I
showcased
a
ton
of
new
adapters
of
the
lero
within
the
past
six
months,
but
I've
done
announcements,
blog
posts,
documentation
and
so
on
for
how
to
utilize
bolero
in
their
cloud
environments
or
in
their
products.
Super
super
cool.
I'm
going
to
share
a
list
of
a
bunch
of
articles
here
in
the
notes
later
on.
A
We
also
saw
that
we
had
33
different
organizations,
contribute
to
valero
within
the
past
six
months
and
roughly
200
contributors
in
total
for
issues
prs
and
actual
code.
So
a
ton
of
contributions
really
fun
to
see
the
community
is
absolutely
rallying
behind
valero
here.
So
it's
a
really
really
cool
city.
We
did
find
a
few
things
that
we
wanted
to
improve
on,
and
one
of
those
is
to
have
a
proper,
getting
started
guide.
A
Another
thing
that
we're
also
going
to
do
is
to
look
into
the
these
new
adopters
and
find
out
how
they're,
using
bolero
get
their
feedback,
and
things
like
that
so
I'll
be
working
with
eleanor
on
that.
As
my
plan
to
get
their
feedback
in
especially
now
for
1.8
would
be
super
nice
and
then
I'll
be
more
involved
as
well.
A
You
might
have
seen
that
I
kind
of
dropped
off
a
little
in
slack
and
so
on,
because
I
was
ramping
up
my
team
members
to
do
other
community
efforts,
but
I'll
be
dedicating
more
time
to
valeno
too
yeah.
That's
that's
the
gist
of
it.
Super
quick,
just
explanation,
everything
looks
really
good.
Valero
is
definitely
poised
for
a
bright
future.
G
Hi
everyone,
I
might
not
have
met
some
people
on
the
call.
Let
me
quickly
introduce
about
myself,
rafael
brito.
I
work
for
office
of
cto
work
with
frankie.
We,
we
love
valero.
We
have
dash
by
the
hips
with
alero
we're
doing
some
great
stuff
here
at
vmware,
doing
a
lot
of
migrations
and
and
that's
why
we
are
proposing
a
new
hooks.
G
I
really
wanted
to
have
the
design
ready
for
today,
but
I
end
up
seeing
that
is
a
little
bit
more
than
I
I
planned.
But
let
me
let
me
just
state
the
the
problem,
or
we
shouldn't
say
problem,
but
the
opportunities
right,
what
we
are
having
and
and
what
we
are
proposing,
how
to
solve
it.
So
basically,
valero
is
a
backup
and
restore,
as
everybody
knows,
but
time
goes
by.
Valerie
is
really
the
migration
framework
as
well
right
when
I
say
migration.
G
G
So
very
well.
What
we
see
the
opportunity
here
is
creating
hooks
plug-in
hooks,
not
differently.
What
we
have
today,
which
is
are
triggered
by
resource
selectors
inside
of
the
restore
and
with
inside
of
the
the
backup.
But
what
are
we
talking
about?
It's
hooks
before
the
backup
starts,
and
one
use
case
is
when
you
do
rustic.
If
you
want
to
quench
the
application,
that's
a
great
opportunity
to
do
right
there
before
you
do
the
backup.
G
Of
course
there
is
the
pod
hooks.
I
even
bring
that
we
continue
to
use
that,
but
we
observe
that
not
everybody
takes
advantage
of
that.
So,
if
you
want
to
create
like
this
hook
before
backup,
then
you
can
evolve
a
custom
plug-in
that
then
scales
down
your
application
same
thing
for
post
backup
hook,
for
example.
If
you
want
to
restore
this
workload,
is
one
example
and
same
analogy
for
restore
you
want
to
do
a
pre-restore
hook
in
a
post,
restore
hook.
G
I'm
not
suggesting
this
pr
to
do
those
plugins,
I'm
just
proposing
the
hooks
for
now.
The
time
goes
by.
We
build
the
plugins
and
if
it
makes
sense
we
can
open
source
as
well.
Those
plugins
another
example
of
those
hooks
is
you
know,
eventually
you
wanna,
let's
say
before
you
restore
you
wanna
double
check
the
size
of
the
cluster
right
you
can
oh
say
the
class
is
not
big
enough
for
my
restore.
G
Then
you
can
invoke
this
plug-in
to
cluster
api
and
expand
the
cluster,
so
you
can
really
do
wonders
once
we
have
those
hooks
in
place
and
and
have
the
alert
part
of
the
not
be
the
orchestrator,
but
at
least
be
the
glue
between
those
those
actions.
Of
course
you
can
do
all
this
outside
of
the
lure
having
the
hooks
gonna
empower
put
this
under
the
umbrella
of
the
laurel
to
trigger
those
events.
Does
it
make
sense.
B
I
think
it
makes
sense,
have
you
discussed
it
with
dave
yeah?
I
have
also
had
this
feeling
that
this
may
be
put
out
of
valero.
It
should
also
work
so.
B
Could
you
explain
why
I
mean,
in
your
proposal
at
least,
explain
why
the
current
hooks
cannot
help
you
and
why
you
think
this
should
be
part
of
larrow.
G
Absolutely
so
imagine,
let's
do
the
use
case
number
one
which
is
breast
tech.
I
wanna
quench
the
pods
so
today
the
backup
action
backup
item
action
right.
It
happens,
doing
the
backup.
So
at
that
point
at
that
point,
my
backup
already
serialized
created
the
tree
of
my
objects,
should
take
the
backup.
G
So
if
I
want
to
shut
down
the
application,
my
application
at
that
point
inside
of
the
backup
is,
is
already
running.
I
cannot
just
say:
hey,
shut
down
my
application
kill
my
pod
make
replica
eco0
and
restart
the
application.
I
don't
think
it
can
do
that
today
and
plus
I
like
to
do
this
plugin
to
run
once
per
backup,
not
per
item,
because
today
you
have
to
specify
what
item
you're
going
to
invoke
the
the
the
so
I
don't
want
to
run.
G
E
Yeah,
I
was
going
to
say
I
think
that
last
point
about
this
is
per
backup
or
per
restore,
not
for
resources.
Actually,
I
think
the
key
difference
here
from
the
other.
It
might
be
worth
making
it
clear,
even
in
the
title
or
the
heading
just
because
I
think
that's
a
big
difference
that
I
know
when
I
first
read
the
top
of
that.
I
wasn't
thinking.
E
Oh
okay,
we're
talking
about
her
backup
and
as
you
described
it,
you
know
the
goals
here,
then
that
became
clearer,
but
I
think
because
this
is
a
completely
different
kind
of
hook
and
a
different
kind
of
plug-in
because
instead
of
working
on
an
item-
and
then
you
work
on
the
next
item-
it's
working
as
a
whole.
Here's
a
set
of
things
that
we
want
to
do
before
we
start
backing
anything
up
and
then
here's
the
set
of
things
we
want
to
do
at
the
end.
G
Exactly
oh,
oh
I'll
change,
the
the
lingo
my
I
promise
the
design
going
to
be
much
better
written
the
verbiage,
you're
going
to
put
more
color
on
a
couple
use
cases,
and
but
the
the
the
really
the
goal
of
this
is
just
create
the
hooks
right,
not
not
putting
capability
beyond
the
hooks.
D
So
with
with
your
intention
with
this,
are
you
imagining
where
the
the
items
or
the
the
resources
that
you're
going
to
be
operating
on?
Is
that
something
that
would
be
configured
at
in
the
backup
like,
for
example,
adding
new
fields
to
the
backup,
spec
to
say,
quiesce,
everything
or
like
scale
down
all
of
like
a
specific
set
of
items?
D
Because
I'm
just
thinking
about
the
kind
of
the
current
item
action
plug-ins
that
we
have
they're
kind
of
they're
they're
fixed
in
terms
of
like
the
the
the
resources
that
they
operate
on
and
the
selectors?
D
G
On
my
plan
is,
there
is
an
interface,
let's
say:
pre-backup
action
would
be
the
interface
you
just
receive
the
backup.
You
register
a
plugin
that
to
be
executed
after
the
object.
Backup
is
new,
but
before
is
in
progress.
F
G
E
E
Was
going
to
say
yeah,
I
think
if
we
use
the
quest
as
kind
of
an
example,
you
would
register
that.
I
imagine
if
you
want
to
run
it
as,
as
you
know,
this
plug-in
is
registered,
which
means
any
backup
will
run
this
action
and
then
the
quest,
plugin
itself
would
just
say:
okay
for
all
deployments,
let's
iterate
over
them
all
the
deployments
in
the
backup
set
replicas
to
zero.
E
Whatever
I
imagine,
if
a
plug-in
needed
input
from
the
user,
you
could
write
it
in
a
way
that
the
plug-in
would
then
read
from
the
say.
G
Yes,
no
and
then
the
plugin
will
be
reading
the
annotations
like
say,
for
you
know,
for
oracle
database.
Don't
do
that!
Something
like
this
right,
but
the
point
being
is
executing
this
before
the
backup
is
in
progress,
because
once
it's
in
progress,
I
have
my
three
of
objects.
Serialized
should
take
the
backup.
G
I
want
to
take
some
actions
prior
that
I
want
to
close
my
I
want
to
scale
down
my
workload.
That's
one
use
case.
There's
another
use
case
of
running
staging
pod.
That
conveyor
crane
does
very
well
right.
We
have
we
don't
back
up
or
from
pvcs
and
pvs.
E
That's
an
example
right
now,
conveyor
cranes
you
mentioned,
you
know
we
do
both
of
those
things:
the
sage
pods
and
the
quieting
as
separate
steps
that
our
you
know,
application
that's
built
on
top
of
valero
does
before
we
even
create
the
valero
backup.
So
if
these,
if
these
hooks
were
in
place,
we
might
be
able
to
move
some
of
that
functionality
out
of
our
application
and
into
alera
plug-in,
for
example,.
G
Yeah,
philosophically,
I
think
the
more
capability
as
long
it's
sensical
as
long
as
the
scale
is
maintainable
the
more
capability
we
give
to
valero.
We
avoid
this
intelligence
on
top
and
and
goes
back
to.
My
initial
point
time
goes
by.
Valero
is
not
only
a
backup,
restore
it's
a
migration
data
mover
as
well,
so
we
we
gotta,
add
those
hooks
to
make
that.
D
H
D
Oh
thanks,
I
was
just
gonna
say
I
think
it'd
be
really
worth
having
a
discussion
with
dave
about
this,
because
I
know
he
has
a
lot
of
ideas
in
terms
of
the
astrology
project
that
he's
been
looking
at
for
valero,
and
I
you
mentioned
specifically
like
the
oracle
database
example.
D
I
think
those
are
the
types
of
use
use
cases
right
that
he's
trying
to
address
with
that
project
in
terms
of
having
some
logic,
that's
specific
to
your
particular
application,
so
that
it
knows
how
to
back
itself
up
and
then
that
would
be
triggered
by
valero
that
application
would
perform
its
own
backup
operation
and
then
return
the
result
to
valero,
but
again
that
I
don't
know
like
what
the
but
the
timeline
is
for
that,
so
that
this
might
be
a
a
way
to
address
that
need
in
the
meantime,
so
I
think
it'd
be
worth
having
yeah.
G
B
G
And
and
then
of
course,
if,
if
whatever
capability,
I
look,
how
is
the
capability?
I
don't
look
the
component.
So
if
this
capability
brings
over
to
australia
makes
a
lot
of
sense,
then
we-
and,
as
always
in
my
in
the
team,
that
I
am
a
tech
lead-
we
are
not
only
proposing
requesting.
We
are
volunteering
to
do
the
hallway
right,
the
design,
the
implementation
and
so
on,
and
we
might
fork
a
velro
with
this
with
this
capability
before
going
to
upstream.
H
I
actually
interested
in
this
because
I
actually
use
a
similar
thing
that
I
have
to
build
on
my
own,
but
my
my
question
here
is:
can
we
so
the
similar
idea
that
we
often
use
is
using
the
annotation
hope
you
know,
and
that
will
be
more
flexible,
that
we
can
put
it
on
many
different
type
entities
right?
H
We
we
want
only
to
hook
it
at
the
very
beginning
of
the
backup
and
the
very
end
of
the
backup
right.
This
kind
of.
Similarly,
one
of
the
applications
that
I
I
think
I
would
have
is
something
like,
for
example,
disable
balancing
miserable
load
balancing
between
a
cluster
of
applications.
I
have
a
bunch
of
note
that
actually
missing
data
between
them
and
if
you
want
to
before
you
run
the
backup
you
want
to
disable
this
load
balancing
right.
So
this
is
one
example.
H
My
my
question
is:
is
that
for
this
one
right
can
we
do?
Can
we
make
it
more
more
flexible
instead,
like
it's
almost
like
the
idea
of
of
of
the
the
the
annotation
hook,
but
is
for
example,
if
I
have
two
applications
right,
I
want
to
do
you
know
disable.
H
I
I
want
to
do
some
pre-hook
before
this
back
up
this
application
and
and
after
back
up
that
application,
I
want
to
enable
you
know
that
whatever
again
right,
so
these
of
the
the
thing
is,
if
I,
if
I
cannot
do
that,
then
I
have
to
run
two
separate
backup
commands
request,
one
for
this
application
and
the
other
one
for
vacation.
So
if
you
do,
if
you,
you
know
kind
of
make
it
flexible.
H
G
Absolutely
so
so
the
pre
backup
I
action
would
receive
the
backup
object
as
an
input.
So
inside
of
the
backup
object,
you
have
your
selectors,
their
namespace
or
the
resources
you're
backing
up
right,
so
the
hook
will
be
just
a
gateway
for
your
plugin.
Your
plugin
will
come
in
and
execute
before
the
backup,
and
then
inside
of
that
you
can
write
your
own
plugin.
Let
me
see
what
I'm
backing
up
on
backing
up
my
application
very
important.
Oh,
if
then,
you
can
create
a
config
map
for
your
plugin.
G
That,
oh,
if
is
that
my
application
very
important.
Let
me
shut
down
my
my
my
load
balancer,
and
then
you
can
write
the
same
plugin
or
different
plugin
after
the
backup
you
read
the
config
map
and
then
re-enable
my
my
my
load
balancer.
So
this
design
here
is
not
about
the
plugins
capabilities
you're
going
to
build,
but
actually
the
hooks
that
can
enable
power,
empower
you
to
write
those
plugins
because
then
you
can
do
whatever
you
want.
Yep.
Thank
you.
You're,
going
to
research.
H
G
G
If
it
makes
sense
on
the
design,
I'm
writing
already
the
design,
but
I
have
so
many
use
cases
for
this
right.
I
told
about
the
migration.
Migration
is
an
atomic
operation.
You
do
a
backup,
the
backup
must
be
completed,
then
triggers
are
restored
on
a
different
cluster
and
must
be
completed.
So
this
is
a
migration
operation.
It's
an
atomic
one
using
those
hooks.
We
can
cascade
those
those
events
without
needing
a
controller
on
top.
B
Yeah,
I
think
it
makes
sense
but
yeah.
My
only
concern
is
that
it
may
make
valero.
You
know,
grow
more
and
more
complicated
yeah
and
it
sounds
to
me
at
least
the
pre-backup
hook
sounds
like
we
can
achieve
the
same
goal
by
using
like
kubernetes
admission
web
hook
or
some
web
hook
mechanism,
but
but
yeah
I
will
I
I'm
I'm.
You
know
waiting
for
the
proposal
and
we
can
discuss
together
and
make
decisions.
B
B
Yeah
yeah,
this
is
sorry
a
pretty
please
link
to
the
click,
the
link
to
the
issue
yeah.
B
This
is
an
issue
I
want
to
discuss
with
you
guys,
because
we
see
this
is
a
particular
issue
we
saw
when
we
are
back
up
and
restoring
a
cluster
that
has
some
customized
controllers
and
when
you
restore
a
cr,
if
there
is
a
controller
operator
running
when
the
cr
is
written
to
suv,
the
output,
the
code
in
the
operator
should
may
be
triggered
and
that's
not
expected,
because
when
we
are
doing
a
restore
so
in
this
particular
issue,
it
may
be
resolved
by
allowing
user
to
customize
the
order
in
which
the
resources
are
restored.
B
We
can
restore
the
cr
first
and
restore
the
controller,
the
pod
for
the
controller
at
last,
so
that
the
controller
will
not
be
triggered
when
the
cr
is
being
restored.
But
when
you
think
of
it
a
little
bit
more,
the
whole
mechanism
is
still
problematic.
B
What
if
we
are
restoring
the
cr
to
an
existing
cluster?
Where
is
the
controller
to
handle
the
creation
of
the
cr?
So
I
want
to
kick
off
some
discussion,
especially
with
scott,
because
I
know
your
work
for
red
hat
and
you
use
operator
extensively.
B
So
what's
your
ideas
regarding
you
know,
handling
such
situation?
How
do
you
bypass
the
code
of
operator
when
you're
restoring
the
cr.
E
Yeah,
unfortunately,
operators
is
one
of
those
areas
we
really
haven't
resolved
yet
and
I'm
not
very
interested
in
in
the
question
here.
But
but
you
know,
I
think,
on
our
side.
We
don't
really
have
a
good
solution
yet
either
for
for
this,
so
I
really
haven't
you
know:
we've
been
dealing
with
kind
of
workloads
kind
of
at
the
application
level,
with
with
migrations,
we
really
haven't
done
a
lot
yet
with
migrating
and
backing
up
operators.
E
H
I
believe
I
have
raised
similar
questions
I
think,
a
few
weeks
ago
about
when
I
restore
an
operator
related
namespace
in
openshift,
and
I
didn't
think
the
the
answer
at
that
point
was
that
there's
no
right
now,
there's
no
solution,
but
come
back
to
that.
I
think
was
in
this
is
for
the
restore
data
path,
but
in
the
backup
data
path.
H
There
is
a
feature
that
I
developed
back
like
last
year
that
allow
the
user
to
re
specify
the
order
of
a
specific
part
to
restore
so
that
you
can
allow
to
so,
but
that
that
feature
is
only
you're.
Not
you
can
you
can
specify
both
the
type
of
resource
and
within
that
time
you
can
specify
which
port
to
restore
first.
So
this
this
type
of
feature
have
not
been
implementing
in
the
restore
site,
because
that's
why
I
haven't
thought
about
a
user's
case
for
the
restore
side.
H
H
The
the
idea
is
that
the
implementation
behind
that
is
that
when
we
do
backup,
we
collect
all
the
item,
and
then
we
based
on
that.
That's
that
that's
the
order
result
we
reorder
them.
We
sort
them
in
that
specific
order.
Then
we
run
the
backup.
H
So
when
the
backup
running
it
will
be
executed
in
the
order
that
we
sorted
so
that
I
think
we
can
do
a
similar
thing
in
the
restore
side,
and
I
think
that
might
be
needed
for
restoring
such
thing
as
operator
namespace,
the
namespace,
when
a
part
is
listening
to
is
some
kind
of
an
operator
listening
to
the
the
another
type
or
another
part.
So
if
we
restore
one
resource
type,
it
might
affect
the
other
one.
H
So
that's
kind
of
the
thing
that,
let's
I
think,
let's
kickstart,
that
that
that
project
for
the
restore
order
in
the
restore
side.
B
But
my
point
is
even
we
allow
even
the
valero
provide
the
flexibility
for
user
to
customize
the
ordering
in
which
resources
are
restored.
H
Weeks
ago,
I
think
scott,
or
someone
raised
an
idea
of
running
some
kind
of
api
command
before
before
executing
restore
of
that
specific
type.
For
example,
if
before
we
actually
restore
a
type,
we
run
an
api
command
to
disable
these
operators
that
operate
on
that
resort
and
then,
after
we
restart,
we
enable
back
these.
These.
You
know
operators
or
something
like
that.
I
think
scott
or.
E
E
There's
a
couple
things
I
would
say
to
that.
One
is
that
if
we,
if
we
were
gonna,
go,
get
down
that
route,
this
new
hook,
type
we
were
just
talking
about-
might
be
a
way
of
doing
that
disable.
You
know
the
kind
of
a
pre-restore.
E
You
know
this
pre-restore
hook
and
disable
it
and
then,
but
the
other
thing
that
this
would
probably
depend
on
the
operator
because
disabling
the
operator
creating
a
bunch
of
crs
and
then
re-enabling
the
operator.
The
operator
might
see
these
new
crs
that
it
didn't
know
about
later
and
then
act
upon
them,
which
you
may
or
may
not
want.
E
I
mean
that's,
but
I'm
not
sure
if
I
mean
being
able
to
disable
and
enable
the
operator
could
help
you,
but
that
depends
on
how
the
operator
behaves
when
it
sees
new
crs
when
it
starts,
because
it
may
be
configured
to
look
for
all
new
crs
that
were
created
while
it
was
down
and
deal
with
those
yeah.
C
E
Don't
know
that
there's
an
answer
there
other
than
again
modifying
the
I
mean,
but
it
may
depend
too
on
what
you
want
to
do,
because,
depending
on
the
operator,
you
may
want
the
operator
to
act
upon
these
cr's
that
you
create,
and
then
you
may
not.
I
mean
that's
it's
kind
of
hard
in
the
abstract,
because
there's
an
operator
that
exists
that
you
don't
control.
That's
you
know.
G
G
Now,
the
if
this
cr
it's
a
cluster
level
object
that
it
can
imply
that
gonna
impact
the
entire
cluster.
Now,
if
the
operator
expects
a
cr,
a
namespace
cr,
the
first
thing,
in
my
mind,
is
like
write,
a
plugin
triggering
or
those
cr.
So
you
don't
have
those
clash
but
then
again
you're
giving
this
burden
to
the
user.
The
user
must
know
how
to
you
know,
do
a
plugin,
for
example.
Nobody
you
can
count
in
both
hands.
G
People
can
write
a
valero
plugin
now
what
be
kind
of
interesting
if
we
debate,
if
we
come
up
with
a
standard,
valera
notation
on
those
crs
right,
annotation
valero
restore
equal
through
right.
It's
a
standard
annotation,
regardless
on
the
metadata,
regardless
of
the
cr,
then
makes
a
a
standard
for
other
operators
like
trigonomeore
those
crs
that
come
from
bellerop
yeah.
E
I
mean
here's
an
example
that
we
ran
into
on
the
on
the
you
know:
openshift
side,
that
wasn't
of
operator,
but
it's
the
same
kind
of
ideas
that
with
openshift
we
have
the
notion
of
a
build
config
and
then
a
build
like
so
which
basically
will
build
images
for
you
and
when
we
were
originally
doing
these
migrations,
we
were
migrating,
the
old
builds,
and
so
you
had
an
application
running,
and
you
know
you
had
say
10
iterations
of
your
build
when
you
migrate.
These
build
resources
into
the
new
cluster,
it
was
kicking
off.
E
10
builds
for
old
things
that
we
don't
need
anymore.
We
ended
up
just
solving
that
by
excluding
the
build
resources
because
we
didn't
need
them,
but
but
there's
an
example.
E
Know
you
know
when
you
create
this
resource,
you
know
if
we
had
been
able
to
annotate
that
build
as
valero
restored
and
we
had
the
ability
to
modify
the
controller
that
acts
upon
the
builds
to
say
hey.
This
is
a
restored,
build
object
from
a
backup.
It
doesn't
need
to
be
rerun,
you
know,
but,
but
that
requires
application
or
operator
support,
to
understand
these
annotations
and
to
do
something
with
them.
B
G
E
B
G
Oh
argue
the
first
thing
that,
as
a
community,
we
should
think
about
stamp
those
crs
with
a
standard
and
valera
notation
and
then
and
then
divulge
to
cube
builders
they'll
be
a
great
sdk
of
the
world
and
and
work
with
their
community.
Like
listen,
yeah,
you
know
ignore
those.
E
D
E
E
Yeah
and
and-
and
I
think
you
know
figuring
out
what
that
is
and
whether
the
standard
is
you
know
pointing
to
an
existing
label
or
may
creating
a
new
one.
You
know
valero
is
not
really
in
charge
of
what
what
applications
and
operators
do
with
those
labels.
But
if
we
can
publish
anything
we
restore
we'll
have
this
label,
then
it's
been
up
to
the
operator
or
the
controller.
G
E
Point
of
view
it's
hard
to
distinguish
those
two:
they
kind
of
look
alike
and
sometimes
for
some
applications.
They
are
alike
we
want
to.
You
know
when
you
restore
a
deployment
from
backup,
you
want
to
create
the
pods,
and
you
want
to
do
all
that,
just
like
it
was
new,
but
for
other
crs
you
may
want
to
do
something
different
if
it's
restored
versus.
If
it's
a
newly
created
resource.
B
And
bridgette
you're
saying
that
it
is
a
default
behavior
that
all
the
resources
restored
by
belarus
will
have
a
special
annotation.
D
Yeah
yeah
there
there
is
a
section
during
the
restore
flow
where,
where
we'll
apply,
I
can't
I
think
it
is
an
annotation
or
a
label.
I
can't
remember,
but
I
think
that
we're
already
applying
that
kind
of
information
to
resources
as
they're
being
restored,
so
I
don't
think
it
would
be
a
significant
impact.
I
don't
have
it.
I
don't
imagine
having
a
negative
impact
to
change
that
behavior
so
that
if
we
decide
to
pick
a
standardized
label,
then
that
we
can
advertise
to
operator
authors.
B
Okay,
so
to
summarize
so
we
may
solve
this
problem
by,
as
this
issue
mentioned,
allowing
customer
customize
the
order,
in
addition
to
that,
we
can
trigger
some
command
on
the
api.
Server
live
level
to
disable
the
operator
and
third,
we
can,
you
know,
publish
the
valet
label
to
let
to
move
the
the
burden
to
the
operator
developer
to
handle
this
situation,
so
I
think
the
property
cover
all
the
cases
yeah.
B
I
I
I
think
I'll
discuss
with
the
you
know
the
writer
of
the
issue
and
the
double
check,
exact
towers
of
the
issue,
but
it
seems
yeah
we're
in
good
shape.
In
terms
of
you
know
this
problem,
you
know
easier
than
I
thought.
Thank
you
guys
for
the
greatest.
A
D
Yeah
we
might
have
done,
but
lars
has
has
created
quite
a
few
of
these
pr,
so
it
might
have
been
a
new
one
since
then,
so
he's
been
catching
quite
a
few
of
the
areas
where
we've
been
not
handling
errors.
So
thank
you.
Lars.
A
Thank
you
so
that
that
about
rounds
it
up.
Thank
you.
Everyone
for
joining
today's
valero
community
call
have
a
fantastic
rest
of
the
week.
Everyone
see
you
all
next
week.