►
From YouTube: Velero Community Meeting - Jan 24, 2023
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
A
The
community
manager
for
Valero
and
I'll
be
facilitating
this
meeting
with
that
I'm
gonna
send
the
link
into
the
chat
to
our
community
community
meetings,
notes
feel
free
to
add
yourself
into
the
notes,
if
you
feel
like
it
and
add
your
topics
for
discussion
and
so
on,
I'm
going
to
share
that
hope.
You
can
see
my
screen
I
make
it
a
bit
smaller,
so
it
can
fit
around
screens
alrighty,
so
Scott
go
ahead.
I
think
you
have
a
lot
of
updates
so.
B
Yes,
so
everything
here
is
kind
of
related
to
the
larger
epic
of
the
asynchronous
plugin
operations.
That's
one
of
the
big
big
features
for
111
I
got
two
PR's
reviewed
and
merged
last
week.
One
of
them
is
the
Adam
operations
Json
format.
This
is
kind
of
what
we
store
in
the
BSL
to
track
asynchronous
operations
and
current
status
and
the
other
is
the
API
update
V2
for
the
restore
item.
Action
I
also
have
one
PR,
that's
still
out
for
review.
B
It's
not
it's
not
on
the
critical
path,
it's
just
in
the
blur
plug-in
example.
But
basically
this
PR
implements
the
V2
API
for
the
backup
item
action.
So
there's
a
V1
and
a
V2
plug-in
in
the
plug-in
examples
with
this
PR.
It
doesn't
do
anything
with
the
new
apis
yet
because
we
don't
have
the
controller
work,
but
it
just.
B
It
shows
that
you
can
register
in
V1,
W2,
plug
and
and
they're
both
picked
up
by
a
controller
looking
for
v2
because
of
the
adapter
I
will
at
some
point
need
to
do
equivalent
for
the
restore
item
action
as
well
for
this.
So
but
anyway,
that's
this.
So
it
would
be
good
to
get
this
merged
before
I.
Do
that,
but
it's
not
blocking
anything
else
in
the
main
repo,
because
nothing
else
depends
on
this
directly.
B
The
main
thing
I'm
working
on
this
week
is
I've
started
working
on
the
backup
controller
work,
no
PR
yet,
but
this
is
going
to
implement
the
logic
to
actually
track
those
actions,
upload
them
at
the
end
of
the
backup
and
then
check
on
them.
You
know
on
subsequent
backups
kind
of
that's
kind
of
the
bulk
of
the
functionality
on
top
of
the
apis
for
the
backup
side,
once
that's
done,
the
other
big
thing
that
we
need
for
111
is
the
restore
equivalent
that
pretty
much
covers
the
bulk
of
this
work
aside.
B
B
Another
basing
team's
off
this
week
when
they
get
back
with
this
plugging
example.
But
again
it's
not
it's
not
blocking
me.
So
there's
no
urgency
to
pull
anyone
out
of
holiday
or
anything
else.
You
know
that
it's
fine
to
wait
till
next
week
and
I
I
hope
to
have
at
least
a
draft
version
of
that
PR
by
next
week.
Hopefully
maybe
you're
ready
for
review,
but
in
any
case
there'll
be
something
I've
submitted,
but
I
just
started
working
on
that
yesterday.
So
I
don't
have
anything
posted
yet.
A
B
I'm
not
so
I'm
not
waiting
on
anyone
right
now.
You
know
critically.
A
Nice,
okay,
yeah,
by
the
way,
the
the
folks
from
Beijing
they
most
probably
won't
be
back
all
of
them
next
week,
because
today's
their
celebration,
the
lunar
year,
yeah
and
most
of
them,
they
are
taking
like
a
second
the
second
week
off
as
well.
Okay,.
B
B
Yeah
I
think
so
I,
just
as
long
as,
if
is
anybody
going
to
be,
there
is
going
to
be
pretty
much
everyone
gone
next
week.
C
A
B
A
D
A
Side,
thanks
for
those
of
you
who
doesn't
know
the
I
it
press
tour
is
our
organization
of
journalists
that
are
going
from
office
to
office
and
talking
to
different
companies
and
their
employees
about
different
projects
and
and
products.
And
so
they
asked
me
if
someone
from
our
side
can
join
and
that
is
going
to
be
in
the
Silicon.
Valley
and
rum
was
super
nice
to
to
take
that,
and
that
should
happen
on
26th
right.
D
A
A
Yeah
and
on
the
related
topic
for
like
Bolero
presentation
into
the
public
I
was
asked
by
the
guys
from
robust
to
death.
If
we
can
do
a
session,
they
have
like
a
a
YouTube
channel
called
100
tools
or
100
kubernetes
twos,
or
something
like
that.
So
we're
currently
in
the
making
of
that
session
with
Valero.
It's
like
a
five
to
ten
minutes
short
video
by
Valero
and
like
to
show
off
a
little
bit,
but
once
once
I
have
something
about
that.
I'll!
E
You
so
yes,
so
the
first
PR
is
like
a
long
running
PR,
just
bringing
it
up
again
for
review.
Scott
has
already
reviewed
it,
and
it's
pending
one
more
review
been
a
while
so
I
just
kind
of
keep
pushing
it
in
every
meeting.
If
we
can
get
it
reviewed
and
get
it
checked
in
yes,
so
yeah
I'm
just
pushing
this
for
a
review.
If
someone
else
can
review
it
as.
A
Push
it
again:
okay,
that
doesn't
look
good
I'll,
try
to
catch
him
on
his
back
on
location,
okay,
okay,
you
figure
this
out
yeah.
E
Thank
you
and
the
second
one
is
the
proposal
that
I've
just
raised
a
PR
for
and
wanted
to.
Maybe
we
can
discuss
this
in
the
call
itself
or
we
can
leave
it
for
offline
review,
so
the
problem
is
basically,
as
of
today,
the
CSI
plugin.
It
picks
up
the
volume
snapshot
class
by
the
label
or
I
think
it's
the
label
or
annotation
on
the
one
you
structure
class.
It
is
like
any
backup
that
you
do
in
the
cluster.
E
It
will
fetch
the
fetch,
the
volume
snapshot
class
with
that
particular
label
and
just
pick
the
first
one
and
use
it
for
the
backup.
So
for
people
who
want
to
take
backup,
let's
say
they
want
different
schedules
or
different
backups
covering
different
aspects
of
their
cluster
and
they
want
to
use
different
volume
snapshot
classes
for
those
parts.
They
can't
do
it.
E
As
of
now,
it's
like
a
global
setting
in
some
sense,
which
is
used
by
all
backups
across
which
is
a
limitation
in
some
sense,
and
we
need
a
way
where
we
can
kind
of
say
for
this
backup
use
this
particular
volume
snapshot
class.
That
is
kind
of
scope.
One
of
the
this
this
whole
proposal-
and
the
second
is,
if
you
go
very,
very
fine,
grained
and
very
nitty
of
it.
Someone
might
come
and
say
that
they
want
to
want
to
for
a
particular
PVC.
E
They
want
to
pick
a
particular
volume
snapshot
class
that
is
now
again
a
niches
requirement,
but
the
first
one
is
a
top
level,
one
where
you
say
for
a
particular
backup.
I
want
to
use
this
volume
snapshot
class,
so
I
have
covered
three
proposals
and
at
a
top
level
the
first
approach
is
through
annotations.
You
provide
certain
values
through
annotations.
Second
approach
is
I
mean
the
second
approach
is
not
something
I
I
know
not.
The
community
will
agree
with,
but
just
for
the
sake
of
completeness.
E
The
second
approach
is
by
adding
certain
CSI
specific
variables
in
the
backup
contracts
or
the
regular
Valero
contracts,
but
I
I
understand
that
we
don't
want
to
really
bloat
up
the
contracts
with
plug-in
specific
details,
so
not
really
pushing
too
hard
for
it,
but
just
for
the
sake
of
computers.
We
have
the
second
approach
and
the
third
approach
is:
we
introduce
some
generic
variable
generic
piece
in
the
contract
through
which
we
can
pass
plugin
specific
things.
E
So,
for
example,
in
volume
snapshot
classes
we
we
need
a
way
to
pass
the
names,
so
it
could
be
a
generic
property
bag
where
you
can
send
in
bunch
of
parameters
which
the
plugin
knows
how
to
under
and
in
what
way
to
honor.
So
this
approach
can
kind
of
further
accrue
to
other
plugins,
for
example,
the
storage
class
mapping.
That
I
believe
is
also
modeled
as
a
plug-in
today,
but
even
storage
class.
It
takes
a
config
map,
but
that
config
map
again
is
a
global
setting.
It
is
like
whatever
is
there
in
the
cluster.
E
It
will
pick
the
first
one
and
use
it
kind
of
thing.
So
even
all
I'm
saying
is
this.
This
thing
could
kind
of
make
it
more
deterministic
in
what
in
what
way
the
plugins
can
consume
extra
information,
whatever
we
need
to
pass
to
them.
For
now.
This
is
like
for
volume,
chapter
classes.
You
can
basically
pass
in
the
parameters
or
perhaps
you
can,
let's
say,
pass
in
the
reference
to
a
config
map
which
the
the
plugin
can
use
for
the
duration
of
that
particular
backup.
E
So
yeah.
These
are
three
top
level
approaches
and
like
we
can
float
it
offline
for
review.
Yeah
I'll
pause
here.
B
Yeah
I
admit
we'll
have
another
review,
the
kind
of
mentioned,
the
the
only
one
that
I
think
we
specifically
probably
don't
want
to
do.
Is
that
second,
one
where
we.
B
Spec,
the
The
annotation
again
is
the
easy
way
to
do
it.
That's
the
way
most
of
the
plugins
that
take
config
right
now.
The
the
generic
property
back
approach
is
also
kind
of
interesting
and,
in
fact,
we're
already
doing
something
similar
for
the
for
the
storage
plugins.
Like
the
you
know,
the
CSI,
you
know
a
lot
of
a
lot
of
the
parameters
you
know
needed
for
S3.
For
example,
in
a
way
we
have
a
config,
a
spec.config
which
is
just
a
map.
B
That
is
a
way
to
provide
plug-in
specific
configuration.
So
it
might
make
sense
to
add
that
to
backup
item
action
similar
to
what
we're
doing
with
the
object
store
plug-in
that
that
would
be
a
plug-in
API
change.
So
you
know
it
would
be
like
a
V3
plug-in
API
for
a
backup
item,
action
and
restore
item
action.
B
Annotation
is
a
quick
fix.
You
can
just
do
that
by
modifying
the
CSI
plugin
itself.
At
any
point,
there's
no
API
changes
associated
with
it.
That
would
be
in
a
relatively
small
amount
of
work
that
could
be.
You
know
done
you
know
at
any
point.
B
B
That
allows
us
to
make
these
kinds
of
API
changes
so
that
that's
kind
of
I,
I
guess
you
know
in
terms
of
one
two:
three
one
is
easy:
two
we
don't
want
to
do
and
three
is
long
term
more
valuable.
But
it's
also,
you
know
more
involved
work
because
it's
modifying
core
Valero
to
add
a
feature
that
all
plugins
might
make
use
of.
E
B
Could
do
both
you,
you
could
do
the
The
annotation
approach
initially,
if
it's
something
that
was
an
immediate
need
with
the
longer
term
design
kind
of
saying
hey.
We
really
want
this.
You
know
really
our
support
plug-in
configuration
because
it's
going
to
be
better
for
all
plugins,
but
we
need
this
now
for
CSI
and
once
The
annotation
part
is
done.
I'm
sorry,
once
the
V3
apis
are
out
and
available,
then
you
could
deprecate
the
annotations
in
the
CSA
plugin
and
move
to
that.
So
one
and
three
could
both
be
done.
B
One,
you
know
one
would
be
a
now
thing
and
three
would
be
a
longer
term
thing.
That's
another
possibility.
B
I
don't
know.
Do
you
have
any
other
thoughts
on
this.
D
I,
like
the
config
parameters
approach
as
well.
Okay,
similar,
it
would
be
similar
to
what
we
do
for
annotations,
but
yeah
I
agree.
It
shouldn't
be
plug-in
specific
and
we
should
keep
a
longer
term
view
of
V3
plugin
implementation
as
well.
Yeah.
B
Know
this
is
something
like,
oh
as
soon
as
possible.
We
want
this.
Then
it
might
be.
You
know,
The
annotation
approach
could
be
done
and
without
modifying
or
below
it's
just
a
plug-in.
You
know
PR,
probably
not
even
a
separate
design.
I
mean
I'm,
not
sure,
because
this
is
just
in
adding
a
adding
a
small
feature
to
an
existing
plugin.
B
But
you
know
if
it's
something
that
you
know
it's
more
of
a
long-term
need
that
can
wait
than
going
through
the
the
plugin
API
change
approach
might
make
more
sense,
but
just
know
that
that's
something
that
obviously
wouldn't
be
starting
until
after
111
when
it
would
be
released,
I
mean
the
design
could
happen.
B
You
know
obviously
start
earlier,
but
the
implementation
wouldn't
be
until
post
111
over
any
I
mean
that's
probably
true,
even
for
the
CSI
plugin,
but
I'm
just
saying
the
CSI
plugin
would
be
a
relatively
small
change
that
you
know
if
PR
could
be
submitted
at
any
point
and
depending
on
you
know
how
it
was
reviewed
that
might
be
earlier,
but
the
certainly
the,
but
even
that
could
be
post.
You
know
111,
but
you
know
it
could,
but
the
big
change
was
is
kind
of
a
major
change
that
would
help
all
the
plugins.
B
In
fact,
there
are
other
plugins
that
would
probably
start
using
it
as
soon
as
you
had
it
available,
but
that
would
that
would
be
a
longer
development
cycle
to
get
to.
E
Hey
one
third
Squad,
so
I
mean
I.
I
might
not
be
very,
very
well
versed
with
the
plug-in
API
as
such,
but
how
I
see
it
is
right,
like
the
backups,
the
whole
backup
of
CR
the
contract
itself,
the
the
whole
crd
itself
right
that
is
available
to
the
plug-in
right.
Can't
the
plugin
just
query
that
particular
field
in
the
CR
and
get
those
values.
Or
do
we
really
need
to.
B
E
E
B
B
Right
I
was
overthinking
that
it
wouldn't
actually
be
a
plug-in
API
change,
because
we
already
have
the
backup
CR
passed
in
and.
A
E
B
E
B
Api
change,
it
would
just
be
a
crd
change
and
a
backup
API.
F
B
So
yeah
you're
right,
it's
not
quite
as
big
as
I
was
thinking.
Originally,
we
still
need
to
go,
probably
have
a
design
PR
for
it,
because
it
does
change
the
backup
and
restore
API,
I'm
sure.
B
E
Folks
are
also
inclined
to
the
third
approach
and
amongst
it,
I
think
you
folks,
who
I
mean
do
you
I,
have
two
approaches
as
part
of
the
third
approach
right
one
is,
we
explicitly
say
we
will
pass
references
to
config
Maps
which
extend
like
plugins
can
like
people
can
preset
and
provide
reference
to,
and
this
again
approaches
more
of
a
you
just
pass
a
random
dictionary,
random,
app
kind
of
thing
or
I
mean
even
the
second
approach,
I
kind
of
dig
a
little
bit
deep.
E
If
you
see
right,
the
structure
is
more
like
you
have
a
map
to
like,
on
the
left
hand,
side
you
kind
of
have
what
plugin
is
it
for
on
the
right
hand,
side,
then
you
can
have
more
bunch
of
key
value
pairs,
so
I
mean
I
can
raise
a
design,
PR
digging
deeper
on
the
second
approach,
and
maybe
there
we
can
discuss
what
contracts
make
sense
or
not.
Is
that
okay
or.
B
Yeah
one
thing
I
think
it's
probably
worth
looking
at,
because
I
mentioned
that
the
object
store
plugin
already
uses.
This
I
was
thinking.
Since
you
mentioned
it
was
not
an
API
change,
it's
not
part
of
the
API
itself,
but
the
object
store,
plug-in
uses
the
backup,
storage
location,
the
backup.
C
E
Correct?
Which.
B
Then
provides
the
plug-in
specific
data.
I
think
I
think
that
approach
probably
makes
sense.
Obviously
it
wouldn't
go
in
the
BSL.
It
would
go
on
the
backup
in
this
case,
but
basically
you
know
so
the
BSL
has
spec.config
here
we
might
have
backup,
you
know
spec
dot.
You
know
plugin.
D
B
B
Know
that
we
need
anything
more
than
backup
automation,
restore
item
action
at
this
point,
but
I'm
just
thinking,
let's
make
it
specific.
So
if
you
did
that
instead
of
creating
a
separate
config
map,
just
create
a
field
spec
dot,
Bia
config
for
backup
by
interaction
config
and
that's
going
to
be
a
map
on
the
backup
and
then
once
you
pass
that
back
up
into
the
actions
themselves.
D
E
Correct
right,
so
basically
it
will
be
a
map
from
plugin
type
to
its
own
map.
Each
plugin
will
have
its
own
map
in
some
sense
right
number.
B
B
Something
similar
there.
It
makes
sense
since
it's
in
precedent
and
then
we
could
treat
it
in
a
similar
way.
E
B
E
E
Math
and
that
map
would
be
a
string
to
string
map.
So
if
you
see
the
example
that
I've
put
here,
that's
exactly
like
that's
kind
of
what
I
was
talking
about.
If
you
see
the
last
example
name,
valero.io
CSI,
it's
the
hyphen
properties,
Line
120
onwards,
cool
I,
think
I.
Think
we
we
have
at
least
some
consensus.
I
can
raise
a
more
specific,
like
I,
can
just
update
this
PR
to
be
more
specific
on
the
approach
yeah.
E
Thank
you
yeah!
That's
it
I
mean
just
wanted
to
discuss
this
any
any
other
thoughts.
Please,
let
me
know
I
can
take
that
into
consideration.
A
E
So
it's
actually
marked
on.
So
it's
all
one
one.
It
translates
to
one
two
three
in
the
actual
one,
when
you,
when
you
preview
it.
B
C
Sure
yeah
thanks
yeah
hi
everybody,
For
Those,
whom
I
have
haven't
spoken
to
before
my
name
is
Ivan
Sim
I'm,
a
software
engineer
at
Dell,
yeah
I'm,
just
hoping
to
like
get
some
advice
from
this
group
regarding
some
scenarios
that
we
have
seen
out
in
the
in
the
fields
from
users.
C
I
know
like
I'm
having
some
ongoing
discussions
and
proposals
going
on
related
to
the
scenarios
that
I've
seen
but
I'm
just
hoping
to
get
like
an
up-to-date
advice
from
the
group
here.
C
Regarding
these
two
particular
issues
here,
the
first
one
being
like
what
do
we
have
any
general
guidelines
around
like
backing
up
crds
where,
like
you
know,
the
CRS
are
not
like
I'm
created
in
the
Target
namespace
and
what
what
I
mean
by
that
is,
like
my
understanding
is
like
I'm,
currently
like
a
Valero,
like
you
know,
with
the
include
class
of
resource
set
to
Auto
or
now
like
it
would
try
to
back
up
crds
with
CR
instances
created
within
the
namespaces
right.
C
So
what
we
have
seen
now
in
the
field
is
like
when
users
try
to
back
up
like
namespace
with,
for
example,
operators.
C
The
Operators
themselves
might
not
create
specific
CRS
between
their
namespace
right,
but,
as
you
can
imagine,
like,
The
Operators
would
have
informers
and
client
go
that
require
the
crd
to
be
applied
and
deployed
to
the
Clusters
they're
doing
restore.
Then
the
operators
will
fail
and
not
come
come
up,
because
the
backup
does
not
have
the
crd
included,
because
the
CR
was
never
the
CR
instances
were
never
created
within
the
namespace
of
the
operator,
so
I
just
want
to
get
a
sentence.
Another
again.
Recent
issues
about
it.
C
I
just
want
to
get
a
sense
of
like
do.
We
have
any
general
guidelines
around
like
how
to
deal
with
that
scenario.
It's
like
and
stuff
like
that.
B
Yeah
I
was
looking
at
those
two
links
you
had.
I
probably
should
mentioned
the
the
one
about
the
include
exclude
and
cluster
scrub
base,
which
is
first
because
that's
an
active
design
proposal
that
that's
actually
going
to
be
happening
soon.
So
the
way
things
work
right
now,
as
you
mentioned,
is
that,
if,
if
include
clusterscope
is
set
to
Auto,
then
the
only
thing
you
pull
in
are
those
that
are
specifically
relevant
to
what
you're
backing
up.
B
So
that
would
mean
crds
for
the
CRS
that
we're
backing
up
PVC
PVS
for
the
PVCs
are
backing
up.
So
one
thing
you
can
do
right
now
is,
if
you
set
include
cluster
resources
to
true
that
pulls
in
all
cluster
script
resources,
and
you
can
also
exclude
types.
If
there's
certain
things
you
don't
want,
you
know
that's
not
particularly
flexible,
which
is
why
we
had
this
new
proposal.
B
The
one
thing
we're
going
to
get
with
this
new
proposal
with
the
latest
iteration
on
the
design
is
for
the
cluster
Scopes
resources.
The
default's
still
going
to
be
include
things
as
relevant,
but
if
you
list
resources
specifically
in
the
include
clusterscope
resources
field,
which
is
one
of
the
new
fields
for
those
resource
types,
only
we're
going
to
include
everything
and
then
for
the
ones
not
listed
we're
still
doing
the
bring
it
as
needed.
B
So
right
that
would
so
I,
don't
know
if
that
meets
your
use
case.
That
obviously
would
be
pulling
in
cids
that
not
only
you.
A
C
Yeah,
so
sorry,
so
for
sure,
like
this
design
proposal
here,
where
they
include
and
exclude
like
enhancements,
it's
highly
relevant
to
us
and
it
will
solve
our
problems,
I
think
well
at
least
actually
I'm
getting
80
there.
I
think
that's,
as
you
already
mentioned,
like
part
of
it,
is
now
like,
at
least
according
to
this
proposal.
It
will
pull
in
all
the
crds
and
then
like
so
if
like,
if
you
can
imagine,
if,
like
the
users,
have
two
or
two
operators,
they're
going.
B
Right
exactly
yeah,
that's
that's
why
I
mentioned
and
there's
other
proposal
that
you
mentioned
I.
Guess
it's
a
pre-existing
issue
for
for
a
proposal
to,
in
addition
to
the
namespace
and
type
based
selection,
adding
a
kind
of
name-based
resource
selection,
I
I
think
there
has
been
a
lot
of
interest
in
that
over
time.
B
It's
it's
complicated
to
do
it
right
in
a
sense
that
we
also-
and
we
need
to
make
sure
that
the
any
new
selection
criteria
we
add
kind
of
merges
nicely
with
the
other
selection
criteria,
and
you
know,
for
example,
what
they
when
we
with
this
include
cluster
scope,
resource
change
that
we're
looking
at
proposal.
B
Really
the
new
scheme
was
more
flexible
that
separates
out
namespace
and
clusterscope
resources
is
not
really
compatible
with
the
old
scheme.
So
the
way
we're
handling
that
one
is
saying
you
know
we
have
validation,
say
either
you
either
do
the
new
way
or
the
old
way
you
can't
really
mix
them,
but
I
think
with
the
named
resource
inclusion,
that's
not
really
an
option.
You
know
this.
B
Would
this
would
be
kind
of
in
addition
to
the
other
selection
rules,
so
we're
going
to
have
to
be
very
careful
about
how
do
you
handle
you
know
you
list
some
resources
and
if
those
are
resources
that
otherwise
aren't
included-
maybe
maybe
you
you
add
them
in,
but
what,
if
they're
explicitly
I
mean
there's
just
a
bunch
of
edge
cases
that
you're
going
to
have
to
be
careful
about
defining
I
I
had
already
made
some
comments
on
that
issue
about
some
of
those
things.
B
G
Is
so.
C
G
This
case
right,
I'm,
just
thinking
so
what
so
Scott
was
saying.
We
can
explore
this
more
or.
A
F
G
B
Existing
issue-
you
know
that
was
submitted,
there's
been
some
discussion
on,
but
there
hasn't
really
been
any
recent
discussion
on
it.
That
may
be
worth
having
others
in
the
team
kind
of
look
at
the
proposal
and
also
comment
on
it,
and
you
know
we
can
kind
of
see
where
this
fits
into.
You
know
needs.
G
And
yeah,
so
we
were
like
thinking
right
like
what
we
had
in
the
other
proposal,
maybe
an
additional
option.
So
we
have
these
four
options
right
for
this
new
proposal
and
additional
option
which
lets
users
specify
by
type
and
name
it-
maybe
a
comma
separate
list
of
type
Fuller
name.
So
that
gives
right
that
gives
completion
in
the
sense
we
can
pick
up
based
on
types,
but
if
there
are
any
overrides.
B
A
B
I
mean,
for
example,
it's
pretty
obvious
if
you
say
you
know,
if
you
have
a
list
of
say
two
resource
types
to
include,
and
then
you
have
some
additional
things
to
include
by
name
only
that's
not
listed
in
the
first.
Then
we
just
add
those
in
there.
But
for
example,
what
if
the
user
says
they
have
an
explicit
exclude
of
a
certain
type?
Does
that
mean.
D
B
Don't
include
anything,
you
know
that
this
is
where
I'm
I'm,
saying
again,
we
just
have
to
be
careful
about
defining
the
you
know
the
way
that
users
specify
this
in
a
way
that
that's
clear
that
you
know.
So
we
don't
end
up
with
these
contradictions
in
the
config
that
you
know.
Oh
wait
a
minute.
This
says
include
this,
but
it
says
exclude
this
explicitly.
You
know
which
one
wins.
We
just
have
to
make
sure
we're
clear
in
the
documents
how
the,
how
that's
validated
and
how
it
works
in
practice.
G
B
G
G
B
If
everything
and
again,
the
other
issue
is
that
Mrs,
shubham
and
I
can
comment
now,
but
the
the
rest
of
the
maintainers
are
on
holiday
this
week,
I
think
when
they're
back,
we
could
bring
this
up
again
at
say
one
of
the
yeah
I,
don't
know
if
you're
available.
In
the
other
time
meetings.
B
C
Yeah
that
that
sounds
good,
yeah
I
think
definitely
like.
We
have
taking
a
look
at
I've
already
look
at
this
proposal
at
plus
the
one
with
the
the
filter
by
name
issues
or
proposal,
I.
Think
like
as
Scott
you
pointed
out
like
you
know,
it
sounds
like
the
interest,
for
these
features
are
growing
but
like
there
are
some
Edge
Corner
cases
that
we
made
to
consider,
especially
in
ensuring
like
backward
compatibility.
C
There
are
no
surprises
there,
but
yeah
I
think
I
can
we
can,
you
know,
come
to
the
next
community
meeting
or
wait
for
people
to
come
back
from
vacation.
Meanwhile,
like
I'm
sure
that
we
can
also
I
also
have
some
thoughts
about
this.
This
proposal
here,
maybe
I,
can
get
some
comments
on
that
if
it
is
still
open
to
comments
and
feedback
and
stuff
like.
B
That
yeah
yeah
go
ahead
and
comment
on
this
one,
because
this
isn't
going
to
urge
and
again
these
are
all
things
that
we're
trying
to
get
the
design
worked
out
now,
so
we
can
start
work
on
them.
You
know
after
111,
because
you
know
this
is
not
going
to
be
in
scope
for
111
in
any
case,
but
we
want
the
design
worked
out
so
that
we're
ready
to
work
on
you
know
develop
on
it.
Yeah.
C
B
I
would
say
it
does
sound
like
we
should
probably
I
mean
kind
of
wrap
up
this
design
without
the
kind
of
named
resources
and
then
kind
of
do
the
name
treat
the
name
resources
as
an
ad
and
otherwise
things
get
too
complex
with
you
know,
one
huge
change
all
at
once,
so
I
think.
If
you
have
comments
on
this
particular
proposal,
that's
great.
B
You
know
if
your
feedback's
always
welcome,
but
I'm
thinking,
it's
probably
best
to
think
about
the
named
resources
as
an
add-on
to
this
once
this
is
approved
so
that
we
can
kind
of
focus
on
what's
different
and
what
changes
rather
than
trying
to
go
back
and
think
about
the
entire
thing.
All
at
once.
C
Okay,
yeah,
that's
fine,
I
think
like
yeah,
breaking
it
up
into
like
relatively
smaller
bite-sized
pieces,
easier
to
chew
on,
but
yeah
again
just
wanted
to
take
you
off
just
showing
you
diligence
again,
one
of
the
things
that
we
can.
You
all
hear
me:
oh
okay,
so
it's
all
in
US,
probably
okay,
so
anyways
yeah.
So,
like
you
know,
we
definitely
need
to
explore
like
existing,
like
options
such
as
using
label
selectors
and
stuff,
like
that.
C
I
think,
like
the
challenges
with
using
labels
alone
is
like
for
one
of
the,
like
the
the
sure
scales
of
some
of
our
customers
or
use
and
use
some
clusters.
You
know
like
sometimes
labeling
like
as
much
as
we
hope
it
is
consistent.
It
may
not
be
plus
also
there
are
some
operators
out
there
like
yeah,
believe
it
or
not.
They
actually
create,
like
crd,
like
during
runtime,
like
on
the
fly
like
not
between
the
yaml.
C
So
it's
like
there's
no
way
for
users
to
at
least
like
you
know,
free
label
things
the
way
they
want
it
to
so
it's
like
The
Operators
have
crd
that
create
crd.
So
you
just
get
it
into
like
you
know
like
just
the
turtle,
all
the
way
down
kind
of
thing.
It's
like.
Where
do
you
know
it's
very
complicated
like
making
making
the
data
protection
workflow
very
complicated
just
by
relying
on
labels?
C
Okay,
that's
cool!
Okay,
that's
great!
So
the
other
one
I
want
to
quickly
bring
up
is
also
like
around
like
not
this
particular
one.
Sorry
and
I
get
the
the
last
one
there.
C
So
yeah,
it's
around,
like
yeah,
just
tell
latencies
of
running
a
batch
of
backup
jobs.
So
my
my
understanding
right
now
is
like
yeah
within
the
backup
job.
Everything
is
back
up.
Sequentially,
ideally
like
that
would
be
fast,
but
if
you
can
imagine
like,
if
uses
like,
which
is
not
uncommon,
these
days
right,
like
instead
of
one
namespace
at
a
time
just
submit,
like
you
know,
a
policy
that
back
up
that
batch,
the
entire
backup
process
and
say
hey
I
want
to
do
like
10,
20,
100,
namespace
backups.
C
You
know
all
at
once
and,
as
you
can
imagine
like,
maybe
the
first
time
backup
namespace
is
okay,
but
to
tell
latency
like
by
the
time
you
get
to
the
50,
the
60
namespaces
like,
even
if
it
is
like
a
one
minute
like
put
a
namespace
talking
about
just
the
metadata
right
forget
about
the
PVC
Alone
by
the
time
you
get
to
like
the
50
and
the
60
names.
So
it
says
you're
talking
about
an
hour
later
of
just
waiting
and
queuing
waiting
in
the
queue
and
stuff
like
that.
C
So
and
this
particular
proposal
and
the
one
prior
to
it,
like
you
know,
came
I,
came
I
came
across
this
and
I,
and
just
wondering
like,
is
this
like
more
or
less
like
The,
Way
Forward
again
recognizing
that
this
is
not
going
to
happen?
You
know
within
the
next
month
or
two,
but
I
just
want
to
get
a
general
sense
of
it's.
C
Just
like
you
know
the
the
one,
and
only
like
forward
proposal
for
dealing
with
this
kind
of
like
tell
hightail
latency
scenario,
always
just
not
a
problem
at
all.
D
I
think
currently,
we
only
have
this
ongoing
proposal,
which
is
in
draft
and
tiger
is
working
on
this.
So
if
you
have
more
thoughts
on,
did
you
take
a
chance
to
review
this
I
think
this
is
not
complete
in
a
sense,
but
you
would
add
your
thoughts
and
we
could
try
to
Bunch
those
together
in
this
design
to
solve
the
problem.
C
Yeah,
oh
yeah
I
did
look
through
this
and
the
one
the
the
one
before
this
I
think
I
guess
it
makes
sense
until
I
see
you
know.
Unless
I
have
a
chance,
we
have
a
chance
to
prototype
it.
It's
kind
of
hard
to
tell
I
guess
the
only
thing
that
stood
out
here
is
like
yeah
we're
talking
about
creating
one
part,
is
it
per
job
or
per
PVC?
C
F
G
So
what
is
the
reason
for
the
port
for
backup
not
like,
within
that
Valero
main
server
right,
like
a
separate,
go
routine
to
handle
each.
F
To
be
honest,
I
don't
know
this
is
just
an
original
proposal.
I
extended
I
would
assume
it's
easier
to
look
at
the
logs
for
having
a
circuit
pause,
because
if
you
have
a
go
routine
I,
don't
know
how
you
wanna
manage
logs
per
backup,
especially
like
on
backup
that
did
not
complete
successfully.
There
would
be
no
cloud
storage,
look
at.
C
Oh
I
think
like
I,
guess
like
the
I
guess,
what
Savannah
was
pointing
out
is
like
I
mean
at
least
on
paper.
We
would
think
like
per
pot.
Put
back
up
is
more
scalable,
and
you
know
you
sort
of
like
just
isolate
like
the
resource
requirements
and
limits
without
one
job,
like
you
know
like
just
holding
up
the
entire
server
and
stuff
like
that,
but
it's
really
hard
kind
of
hard
to
quantify.
C
Unless,
like
we
do
some
spike
on
it
to
say,
okay
separating
it
out
into
each
part,
is
you
know
at
the
at
the
expense
of
creating
more
Trends
and
parts
coming
in
going
up
and
down
kind
of
thing?
It's
actually
more
efficient
than
you
know
just
like,
for
example,
a
simple
simple
go
routines
within
the
server
and
controller.
So
I
guess,
like
a
question,
is
like
a
follow-up
question
from
chicana's
point
is
like?
Is
there
so
I
guess
something
like
this?
This
design
is
still
under
review
and
or.
F
D
Yeah,
it's
still
not
under
review.
This
is
still
in
draft,
so
the
whole
design
is
in
progress
but
yeah.
We
would
appreciate
your
feedback
that
could
help
us
speed.
D
And
help
us
with
the
with
this
feature,
to
put
it
in
where
I
was
earlier
releases,
but
not
planned
for
Valero,
One
Eleven
for
sure
yeah.
C
Is
this
like?
Would
you
would
this
be
like
a
fundamental?
It
sounds
like
you're,
a
fundamental
architecture,
change.
C
Yeah,
okay,
I'm,
just
trying
to
see
like
you
know,
I
mean
for
one
it's
okay,
reviewing
the
design
is
one
thing
right,
but
also
like
just
recognizing
the
risk
around
this.
D
If
you
take
a
look
at
the
backup
and
restore
controller
right,
both
are
handling
multiple
cases
and
it's
a
bit
complicated
to
make
changes
to
those.
So,
okay
and.
D
Down
you
know,
the
performance
metrics
also
depends
on
the
storage
that
you
are
going
to
use
with
as
well.
Yeah
yeah
yeah,
the
storage
as
well
as
the
network
bandwidth.
These
are
the
parameters.
Sometimes
you
don't
have
a
handle
on
as
when
I
wrote,
developer,
I
would
say
so.
D
C
Okay,
this
one,
let
me
make
sure,
like
you,
know,
I'm,
not
going
crazy.
C
I'm
curious
like
what
are
the
reasons
of
not
using
jobs
and
reverting
to
Parts?
Is
it
just
because
the
the
chances
that
the
job
workload
might
start
more
than
one
part.
F
Yeah,
there's
there's
like
a
little
side
note
in
kubernetes
documentation
of
jobs,
how
it
works,
and
basically
you
cannot
guarantee
that
only
one
comes
up
for
when
you
create
I
can't
remember
exactly,
but
it's
something
like
you
can't
guarantee
that
a
single
pod
will
come
up,
but
it
might
be
two
depending
on
how
the
reconciler
and
the
API
respond,
which
means
could
cause
some
issues
yeah,
because
you
wouldn't
want
two
parts
running
the
same
backup
at
the
same
time
and
then
uploading
yeah.
C
Yeah,
especially
if
the
backup
job
could
be
expensive
right,
you
want
to.
Let
me
run
it
twice
for
this.
You
know
for
your
one
request:
okay,
that
that
makes
sense
to
me
so
and
meanwhile,
like
I,
mean
obviously
like
we
have
like
users
just
counting
on
us
to
come
up
with
something
for
them.
Meanwhile,
like
I,
guess,
there's
really
no
walk
around
right,
like
as
far
as
I
know
so
like
we
not
like.
We
can
spin
up
two
Valero
controller
pot.
B
Mean
I
don't
know
if
there's
official
support
I
I
there
might
be,
but
you
may
know
this
I'm
not
sure
you
can
install
Valero
and
namespace
is
other
than
Valero
and
it's
possible
to
install
Valero
twice
as
long
as
it's
the
same
version
but
I
don't
know
off
the
top
of
my
head,
whether
we
officially
support
running
two.
At
the
same
time,.
C
B
So
much
same
name
to
this
doesn't
solve
for
CR.
So
if
you,
if
you
click,
create
a
Valero,
you
know
name,
says
Valero
and
then
Valero
two.
If
you
create
a
backup,
CRM
Valera
2,
then
the
Valero
two
pod
will
take
the
backup
if
you
click,
create
it
in
the
the
Valero
namespace
and
then
the
Valero
pod
will
take
it.
So
Valero
only
looks
in
its
own
namespace
for
Bolero
CRS.
B
C
Right
right:
okay,
gotcha,
okay,
cool
yeah,
thanks
for
yeah,
thanks
everybody
for
the
feedback
and
the
input.
I'll
take
a
look
at
the
ongoing
proposals
and
see
if
I
can
probably
some
comments
and
you
know
and
contribute
in
some
ways,
I'm
so
kind
of.
Do
you
have
any
other
questions
you
want
to
add
or
feedback
comments.
G
No,
that's
it
so
I
guess.
The
next
step
is
for
the
cluster
resources,
maybe
bring
it
up
and
then
call
with
the
Beijing
team.
Is
there.
C
Yeah
at
least
again
I
guess
next
step
yeah,
you
know
before
the
meetings
like
at
least
like
yeah,
you
know,
like
you
and
I,
can
take
a
look
at
the
proposal
and
see
we
can
add
any
comments
to
it.
First
and
just
make
sure
it's
you
know,
help
everyone,
and
not
just
our
case,
okay,
cool
thanks.
Everybody
appreciate.
B
It
and
in
terms
of
scheduling
time
for
to
talk
to
the
Beijing
team,
the
meeting
a
week
from
today,
as
we
mentioned
earlier,
is
currently
scheduled,
but
most
likely
the
majority
of
that
team
will
not
be
there.
So
I
would
say
three
weeks
from
today,
but
this
evening
you
know
would
be
most
of
every
time
to
kind
of
catch.
Everybody.
B
C
A
All
right,
thank
you,
but
by
the
way
for
these
kind
of
discussions,
we
have
the
Valero
death
Channel,
but
it's
like
deal
with
who,
with
some
other
folks
that
are
just
fooling
but
not
actively
contributing.
A
Do
you
think
it
makes
things
make
sense
to
have
like
a
dedicated
for
maintainers,
where
all
these
kind
of
proposals,
which
are
Super
specific
to
be
discussed
like
asynchronous
and.
B
B
User
of
alert
not
making
code
changes.
The
blur
users
is
a
place
to
ask
your
questions,
and
if
you're
talking
about
PR
implementation,
you
know
design
proposals.
Dev
is
the
perfect
place.
I,
don't
think
we
really
I
mean
there
may
be
some
need
forever,
maintainers
channel
for
other
reasons,
but
I
think
for
this,
especially
since
this
is
a
discussion
that
involves
people
that
are
not
active
maintainers.
You
know
that
they're
not
currently
I
think
the
below
Dev
is
the
most
appropriate
slack
Channel
right
now.
For
this.
A
A
Nope;
okay,
with
that,
thank
you
we'll
be
waiting
for
Keep
Calm
announcements
in
in
two
weeks.
Right,
sixth
of
February
should
be.
D
A
So
fingers
crossed
for
everyone
who
applied
until
then
have
a
good
day
good
night
and
talk
to
you
next
time.
Bye.
Thank.