►
From YouTube: Velero Community Meeting - Apri 26, 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
Meeting
today
the
April
26th,
so
first,
let's
take
some
overview
of
the
status
for
wave
1.10.
We
will
create
another
package,
so
we
are
planning
to
to
prepare
the
prepare
it
from
May
8th.
So
the
tentative
release
date
may
be
around
the
the
way
chat
weekend
at
that
week
or
the
next
and
for
we
went
on
11.
We
have
G8
8
on
April
20s.
A
So
for
all
the
the
changes
you
can
visit,
this
release
notes
and
the
four-way
1.12.
We
have
almost
a
down
the
plan.
I
think
Daniel
later
will
go
through
with
us
for
the
roadmap
and
we
have
finished
the
first
round
of
the
candidate
YouTube.
A
So
some
for
some
we
have
moved
to
to
the
mail
flow
when
we
went
on
12
miles
to
do
and
some
still
in
in
the
candidate
list,
and
for
so
we
will
continue
investigate
them,
and
then
we
will
decide
whether
to
move
it
into
way
1.12
or
move
it
out,
yeah
that
that
is
for
for
the
for
the
releases
and
another
thing,
the
building
team
will
have
a
holiday
from
this
weekend
and
the
will
be
back
on
May
4th
and
some
member
will
be
back
on
May,
8th,
that's
it
and
for
some
individual
updates,
myself
is
working
on
the
investigation
of
1.12
one
part
of
candidate
issues
and
also
the
breakdown
of
a
little
bit
more
tasks
according
to
the
data
model,
design
and
I
also
started
some
changes
for
for
a
little
more,
that
is
this
PR.
A
We
have
created
the
data
upload
and
data
download
crd
into
under
the
one.
We
want
our
one,
our
version,
the
things
like
it
seems
this
is
the
first
time
that
we
we
create
some
crd
under
a
version
other
than
we
want.
So
we
have
changed
quite
a
lot
of
the
the
you
know.
The
code
organization
also
some
code
generator
12..
A
B
I
have
a
quick
question
to
other
folks
on
the
call
like
we
are
relatively
new
and
unexperienced
in
this
area,
but
in
our
internal
discussion,
there's
concern
that
whether
it
is
right
to
support
different
version
of
CRP
I
mean
different
version
of
different
crds
under
the
same
group.
Is
that
a
conventional
Behavior
or
not?
Do
you
have
any
a
suggestion.
C
Yeah
I,
don't
actually
haven't
done
much
with
that
myself
in
terms
of
making
them
different,
I
mean
I,
know
I
mean
I'm,
not
really
sure
whether
as
I
said
it
makes
sense.
Oh,
this
crd
is
not
stable,
yet
we
should
make
it
available
now
for
one
versus
this
one
is
beta
or
V1,
because
I
know
another
aspect
to
the
changing.
The
crd
version
is
that
should
if
we
went,
for
example,
to
Valero,
you
know
version
2.0
that
moved
everything
to
V2
crds.
C
C
We
update
those
V1
crds,
so
you
can't
have,
for
example,
a
Volare
1.10
and
1.11
installed
in
two
different
namespaces
in
the
same
cluster,
because
the
crds
are
in
Conflict
I,
don't
actually
have
any
specific
experience,
though
you
know
having
one
group
using
two
different
versions
at
the
same
time,
so
I
don't
actually
know
if
I
have
my
head
with
it.
That
would
be
an
issue
or
not
I'm,
not
sure
about.
D
C
You
have
any
experience
there
or
not.
E
So
I
don't
have
any
experience
with
so
just
to
clarify.
We
are
saying
that
weller.io
V1
are
the
existing
crds
and
well
erode.io.
Slash
U1,
Alpha
One,
slash
here,
data
more
are
the
other
cids
right.
That's
it.
C
It
going
to
be
the
same
group
group
or
is
it
going
to
be
different.
B
They
are
under
the
same
group,
but
if
it's
wrong
to
do
this,
we
can
switch
to
other
group.
If
we
don't
have
a,
you
can
add
a
comment
in
the
pr
or
in
the
design
somewhere
and
as
a
follow-up
as
I'm
traveling
here
in
the
headquarter
of
VMware
I,
maybe
have
chance
to
meet
some
POC
member
and
who
is
aspiration.
Kubernetes
and
maybe
I
can
ask
them
for
advice,
I,
I,
I've
done
some
quick
research
on
some
running
environments
turns
out
yeah
the
same
group.
They
always
have
the
same
version.
C
Mover
is
kind
of
a
slightly
different
category
of
things.
You
know
different
than
core
Valero
that
you
may
not
you
know
not
every
user
would
use,
so
it
might
actually
clarify
to
use
a
different
group
for
the
daily
mover,
crds
versus
the
regular
ones.
I'm,
not
sure
I
mean
I,
don't
know,
that'll
break
anything
in
the
current
design,
but
that
might
make
sense
to
the
difference
here
and
then
then,
there's
no
expectation
that
the
versions
would
be
the
same.
If
you
had
a
different
group,
then
they're
separate.
E
B
C
Right
but
there's
also
no
convention
for
daily
member,
because
this
is
a
totally
new
thing
and
it's
a
sort
of
a
different
kind
of
functionality
with
its
own.
So
I'm
not
saying
it
needs
to
be
in
her
group
necessarily
I'm
saying
it
would
it
might
be
appropriate
to
have
it
in
a
different
group,
because
data
mover
is
kind
of
you
know
an
extension
to
Valero.
It's
kind
of
a
different
kind
of
functionality
that
we're
kind
of
building
on
top
of
Valero.
So
it's
yeah.
C
I
mean
you're
right.
We
should
resolve
the
fundamental
question
first
yeah,
but
at
the
same
time
we
also
should
probably
consider
among
the
options
whether
it
makes
sense
to
use
a
different
group,
and
maybe
we
don't
maybe
doesn't
but
I
think
that's.
That
is
an
option
to
consider
as
well.
B
For
for
for
our
product,
it's
probably
easier
to
have
them
under
the
same
group,
because
there
are
some
assumptions
we
I'm
not
sure,
if
that's
also
true
for
openshift,
but
we
have
different
groups
for
different
there.
They
reflect
some
money
from
management
perspective.
They
reflect
some,
how
we
organize
things
and
how
things
are
fit
together.
So
yeah,
I,
I,
think
I
will
talk
to
some
experts
in
in
in
Palo
Alto,
hopefully,
and
give
you
some
update.
B
E
F
A
Okay,
thanks
thanks
all,
and
so
it
means
that
there
are
two
questions
so.
B
C
We
already
have
that
with
like
backups
anyway,
where
we
have
you
know
the
backup
deletion
controller
is
dealing
with.
You
know
backups
and
so
I
mean,
but
it's
as
long
as
as
long
as
they're
watching
you
know
under
different
circumstances,
so
I
mean
I.
Think,
but
it's
a
question
of
you
know
you
do
want
to
avoid
kind
of
conflicts
where
two
different
controllers
try
to
act
upon
the
same
gonna
see
how,
at
the
same
time,
on
the
same
state.
C
B
A
Okay,
so
I
think
the
the
core
question
is
here
so,
whether
that
whether
it
makes
sense
to
have
two
different
versions
on
under
the
single
group
right
and
then
following
up,
we
may
have
other
discussion
like
whether
we
want
to
have
the
data
more
into
a
single
group
right,
yeah
I
think
we
can
continue
the
discussion
in
this
in
this
in
this
this
PR
or
we
can
discuss
in
the
in
the
select
Channel,
okay.
A
Let's
see
what's
new
information
will
work
out
later
thanks
thanks
Daniel,
that's
that's
for
my
part
and
the
next
one.
She
okay.
G
I
worked
on
1.9.7
and
1.11,
releasing
and
I'm
working
on
enable
more
lenders
for
Valero
now
and
further
interest.
I
think
some
later
reported
a
warning.
Breaking
change
and
I
already
created
a
PR,
but
may
need
to
consider
that
whether
it
is
needed,
for
example,
some,
for
example,
the
1.7
3.
G
G
It
renamed
some
options,
some
structure
and
some
method
name.
Please
navigate
down
a
little
bit
to
the
command
command
packet,
CMD
70
package.
G
I
I
think
this
warning
makes
sense
it
basic
basically,
because
this
package
name
is
installed
and
no
need
to
include
the
package
name
into
the
structure
tool.
So
it
suggests
that
to
rename
it
to
just
options,
but
because
it
is
exported
exported
in
the
structure,
the
rename
still
has
some
risk
to
break
the
users.
B
B
That's
that
doesn't
make
sense,
because
otherwise
there
will
be
a
two
much
overhead
for
us
to
be
compatible
like
yeah.
C
Yeah
I
mean
I,
think
there's
two
levels
of
breaking
change
here:
I
I
think
should
I
mentioned
something
one
of
the
comments
that
I
mean
if
you're
talking
about
changing
the
name
of
something
you
know
as
long
as
that's
something
that's
I
mean
that'll,
be
an
obvious
thing
when
you,
you
know,
pull
in
your
depth
and
things
don't
work
anymore,
because
the
name
is
different
and
you
can
you
know
it's
a
if
it's
a
simple
update
to
the
user.
C
C
B
C
Course,
but
what
I
mean
is
that
if,
if
you
have
a
package
with
you
know
code
in
it
than
anyone
who
includes
the
Valero,
you
know
packages
in
their
the
golang
code
and
they're
using
a
function?
That's
that's
here
and
you
make
it
a
private
function.
That's
no
longer
available
to
that
user.
Then
then
they
can't
upgrade
their
code
to
use
it.
If
you
change
the
name
of
it
or
you
change
the
method,
signature
to
add
a
field
or
remove
a
field,
that's
all
things
that
users
can
respond
to.
C
But
if,
if
you
make
it
completely
private,
for
example
like
and
then
the
relevance
here
is
that
the
oadp
installer
uses
the
install
package,
you
know
we
don't
use
the
Valero
CLI
install,
but
we
use
the
install
package
to
add.
You
know
additional
ADP
things
to
that
as
well.
C
So
if
that
package
would
completely
go
away
with
no
replacement
or
were
to
be
say
if
a
bunch
of
these
functions
were
to
were
to
be
no
longer
exported,
then
that
would
be
a
breaking
change
that
wouldn't
necessarily
have
an
obvious
fix
other
than
copying
and
pasting
a
bunch
of
code
elsewhere.
C
But
if
you're
just
talking
about
changing
the
name,
you
know
from
install
options
to
options
or
whatever,
but
it's
still
exported
that's
a
breaking
change
that
can
be
worked
around
and
fixed
pretty
easily
by
just
you
know,
when
we
update
to
the
new
version,
we
just
changed
the
names.
You
know,
that's
an
easy
change.
B
So
so
are
you
saying
we
need
to
be
careful
with
the
slash
PKG
soft
directory
and
for,
for
example,
the
internal
directory?
We
are
okay
to
make
great
changes,
because
in
in
terms
of
removing
or
on
exporting
functions,
I
find
that
that's
normal.
When
we,
you
know
iterate
on
on
versions
so
you're
saying
for
every
for
all
the
code
under
slash
PKG
directly.
We
should
not
make
breaking
change
as
long
as
they
are
exported.
C
Well,
I
mean
and
again
breaking
change
is
kind
of
a
general
category
because
anytime,
you
change
the
name
of
something:
that's
exported,
that's
a
breaking
change,
because
anyone
who's
using
it
their
code
won't
compile
anymore
they're
going
to
have
to
change
that
you
know,
but
if
it's
a
breaking
change
like
that
that
can
or
if
you're,
adding
new,
you
know
adding
new,
you
know
changing
method
signatures
and
all
that
is
a
pretty
common
kind
of
thing.
You
know
a.
D
C
New
release,
so
we
have
some
new
parameters.
We
need.
We've
got
to
make
this
change
here,
but
I
would
be
concerned
about
something
that
was.
You
know,
exported
and
available.
Multiple
versions
and
others
might
be
relying
on
it,
and
then
you
make
it
completely
unexported
you
make
it
impossible
for
a
user
to
call
that
now,
then
they
have
to
figure
out.
What
do
we
do?
Do
we,
you
know,
do
they
have
to
copy
and
paste
this
code
into
their
make
their
own?
C
You
know
own,
and
you
know
so
that
that's
where
I'm
saying,
if
you
take
something,
that's
public
now
that
users
May,
especially
if
it's
if
it's,
if
it's
a
public
function,
that
you
know,
we
know
for
sure
that
you
know
someone's
using
it
and
because
we
we
can
give
an
example.
You
know
this
project
is
using
this
function
right
now.
If
you
change
the
name,
that's
fine.
They
can
respond
to
that.
If
you
add
or
remove
parameters,
because
your
functionality
changes,
that's
fine
but
making
it
completely
unexported
so
that
they
can't
call
it
anymore.
C
I
think
that's!
You
would
need
a
very
strong
justification
to
say
it's
got
to
be
this
way
and
it's
a
problem
and
and
work
with
the
user,
then
to.
B
B
B
C
B
D
C
Know
there
will
be
some
breaking
changes
and
as
long
as
there
are
changes
that
someone
developing
with
this
with
enough
time
built
into
the
schedule
to
you,
know
to
test
with
the
new
release
and
all
that
that
makes
sense-
and
you
know
anyone
who's
going
to
be
building
something
on
off
of
Valero
112,
and
this
includes
oadp.
You
know
we're
going
to
be
using
and
testing
with
some
of
this
stuff
along
the
way.
C
So
if
we
do
end
up
merging
something
that
removes
something
that
you
know
is
needed
for
oedp
to
compile
with
it'll
be
obvious
in
the
development
cycle,
and
then
we
can
raise
it
hey.
You
know
we
just
committed
something
to
Maine
that
removes
this
function
that
we
need.
Can
we
talk
about
putting
it
back?
You
know,
I
think
as
we
go
through
the
development
process.
That
makes
sense
and
that's
where
again
we're
putting
the
comments
in
here
now
saying
for
these
specific
functions.
We
know
we're
using
them,
so
let's
be
careful
with
them
now.
C
E
And
the
thing
is
we
most
likely
use
just
the
install
package
and
as
Scott
mentioned,
if
we
don't,
if
we
just
make
those
things
unexported,
then
it
might
affect
not
just
us.
It
will
affect
other
users
as
well,
who
are
integrating
with.
B
Yeah
but
I
only
care
about
I
mean
because
you
are
also
maintainers,
so
I
think
there
are.
Some
users
are
more
important
than
other.
I
I
I
and
does
that
sound
bad,
but
I
mean
because
one
package
can
be
imported
by
some
random
guy.
If,
if
they
somehow
didn't
say
we
can't
make
breaking
changes,
sometimes
we
have
to
ignore
their
feedback
Maybe.
B
C
Make
here
that's
exported
that
we
think
hey
there's.
We
can't
think
of
any
use
cases
for
this
to
be
exported.
We
change
it
to
make
it
unexported,
because
we're
not
aware
of
any
when
using
it.
That's
fine,
then
we
get
if
someone
realizes
that
it
breaks
them
and
they
put
in
the
issue,
and
then
we
can
make
that
decision.
Oh
okay,
maybe
we
should
put
this
back.
We
can
revert.
B
I
A
Yeah
I
think
the
current
problem
we
are
discussing
only
happened
when
some
user
is
developing
or
import
the
code
of
well
our
directory
and
by
that
they
can
change,
make
the
make
the
change
your
code
in
my
in
their
development
cycle
when
they
imported
the
new
related
new
version
of
uber
right.
So
as
long
as
at
large,
we
are
having
where
we
are
doing
the
right
thing
or
going
to
the
right
direction
like
make
the
where
are
called
more
healthy,
I.
A
C
Yeah
and
again,
I
think
that
makes
sense,
and
in
most
cases,
users
just
need
to
update
what
they're
dealing
with
to
work
with
the
new
version,
the
only
case
where
we
would
have
this
discussion
of
hey,
we
need
to
revert
this
or
we
need
to
make
a
change
here
would
be
if
we
refactor
the
code
in
Valero
in
such
a
way
to
make
some
use
case
impossible,
which
this
is
an
edge
case.
I
mean
we
just
need
to
deal
with
that
as
case
button
to
have
that
I.
Don't.
C
That
happening,
but
if
it
does,
then
we
can,
you
know,
deal
with
appropriately
and
come
up
with
some
answer
that
fixes
what
we
were
trying
to
accomplish,
while
at
the
same
time
allowing
another
user
to
work
with
it,
and
that
doesn't
mean
no
breaking
changes.
It
just
means
that
we
need
to
be
able
to.
J
C
Talking
about
do
details
and
implementation
details
that
are
exposed,
which
means
someone
might
be
using,
but
we're
not
talking
about
published
apis
documented
things.
You
know
this
came
up
with
ODP
because
we
specifically
take
that
install
package
and
use
that
in
the
oedp-
and
you
know
the
code,
no
ADP,
then
it
solves
Valero
and
so
we're
relying
on
publicly
exported
functions
which
aren't
a
published
API,
which
means
we're
not
telling
Bolero.
Hey,
don't
change
this
ever.
But
what
we
are
saying
is
we
rely
on
this
and
so
any
changes.
C
A
Okay,
thanks
everyone,
so
she
do.
You
have
anything
else.
A
Thanks
and
next
his.
F
C
C
C
Yeah
that
sounds
right.
You
know
and
again
right
now
they
don't
yeah.
They
have
a
hosted
service
that
runs
across
multiple
clusters.
I,
we
did
talk
a
little
bit
again.
They
do
hope
to
release
a
kind
of
single
cluster
version
of
this
as
an
open
source
Upstream
project
at
this
point
that
doesn't
exist.
C
So
there
isn't
any
code,
you
can,
you
know,
download
and
and
install,
although
apparently
you
can
sign
up
on
their
hosted
service
for
a
free
fit
a
free
tier
to
sort
of
test
it
out
and
but
yeah
I
think
they're
they've
tested
it
with
up
through
110
now
and
so
once
111
comes
out,
I,
don't
know
what
the
time
I'm
not
sure
what
the
time
frame
is
for
when
that
becomes
supported,
but
and
then
I
know
they
are
testing
with
the
the
mainly
with
the
the
the
primary
you
know,
Upstream
relay
releases
I
know
they're
doing
some
testing
also
with
ODP,
although
I
don't
know
how
much
they
do
with
that
and
I'm
not
and
then,
of
course
right
now
they
have
their
own
Fork
that
they're
working
with
but
again
I
think
they
work.
C
They
want
to
work
towards
not
so
much
relying
on.
You
know,
changes
in
their
own
Fork
in
the
future,
but
again
I,
don't
know
how
extensive
their
changes
are,
or
any
of
that
that
wasn't
clear
to
me.
A
Okay:
okay,
thanks
and
do
not
assuming.
I
I'm
working
on
a
Valero
CI
to
support
this.
Moreover,
test
scenario,
which
is
can
perform
better
and
restore
across
providers
and
also
some
nightly
issue
caused
by
PR
of
fixing
a
linked
warnings.
I'm
working
on
that.
B
Yeah,
that's
a
question
also
I
have
for
sure,
since
you
are
delivering
your
data
mover
post,
Valero
111,
so
as
for
defining
the
test
scenarios,
I
think
definitely
you
can
reach
out
to
subanguards
that
to
get
some
guidance
also
right.
F
A
Okay,
that's
for
the
update
and
for
the
topics
so
I
think
then
you
have
two
topics
so
time
to
you.
Thank
you.
Yeah.
B
So
yeah,
let
me.
H
B
Not
quite
useful,
if
there's
only
one
screen,
so
we
have
some
internal
discussion
within
the
Valero
development
team.
So
there
we
propose
a
tentative
timeline.
I
mean
we
Define.
The
several
Milestones
as
before.
First
is
the
feature
freeze.
B
So
after
the
feature
freeze,
there
will
not
be
any
1.12
candidates
any
if
it
will
be
either
in
the
Milestone
or
out
of
112..
So
that
is
a
main
31st.
So
they'll
give
us
more
buffer
to
add
new
issues
into
112
and
the
feature
complete
date.
We
are
targeting
the
mid
of
July
and
after
that,
based
on
our
previous
experience,
therefore,
to
five
weeks
between
the
FC
to
the
ga
date.
B
So
these
are
the
following
days:
I
put
in
the
put
on
in
the
wiki,
so
first
I
want
to
check
with
you
guys.
Are
you
okay
with
this
date,
other
maintainers
or
Developers,
so
I
mean
there's
a
month
month
that
we
can
add.
We
are
open
to,
and
you
know,
add
new
issues
into
the
milestone.
C
Yeah,
so
this
is
basically
four
months
from
1.11
in
terms
of
you
know,
approximately
in
terms
of
the
full
from
GA
to
GA.
C
Yeah
and
Shivam
or
Wes
I,
don't
have
any
specific
Insight
on
our
next
ADP
release
and
where
this
fits
in.
But
this
looks
just
as
a
pure
Upstream
point
of
view.
I
think
this
is
a
timeline
that
makes
sense
to
me.
I,
don't
know
if
there's
any
changes
we'd
want
to
hear
or
not,
but
other.
B
Than
yeah
yeah
I
wanna
explain
how
one
risk
is
that
in
terms
of
release
Cadence
considering
there
is
a
Christmas
and
a
Chinese
national
holiday
in
Q4.
So
it
may
put
us
a
little
bit
risky
to
deliver
three
minor
releases
a
year,
but
I
think
you
guys
are
okay.
We
deliver
only
two
minus
releases
right.
J
C
In
the
way,
I
mean
I,
think
I
think
we're
kind
of
thinking
in
general
of
hey
about
four
months
here.
But
you
know,
like
you
said
you
know.
December
is
something
that
kind
of
you
know.
Everybody's
gonna
have
more
time
off
there
and
less
focused,
and
so
we
just
have
to
keep
that
in
mind
that
you
know
1.13
might
take
a
little
longer
to
get
out
than.
D
C
B
Okay
and
as
for
the
major
feature
that
I
only
put
on
two
of
them
here,
maybe
I'll
add
more.
But
first
thing
is
the
support
default
data
mover
as
young,
who
has
been
you
know,
discussing
with
you
guys
since
1.11
11
time
frame
and
there's
a
design,
and
we
also
Define
the
iPic
I
won't
open
it
as
a
long
list
of
tasks
we've
defined.
B
So
this
is
we
we
want
to
trade
it
as
an
anchor
feature.
That
means
we
won't
release
1912
until
we
consider
this
one
done,
for
example,
if
we,
if
this
needs
four
more
weeks,
we
delay
1.12
four
more
weeks,
because
this
is
really
important
to
us
and
we
really
want
to
deliver
that
in
the
next
minorities.
B
Yeah
and
the
other
one
is
proposed
by
Angel
from
Microsoft
he's
really
active,
like
adding
enhancements
to
Valero,
and
this
one
he
told
me
that
is
more
important
for
them,
which
is
the
Json
substitution
policy.
C
B
C
We've
on
the
red
hat
side,
we've
definitely
had
requests
from
customers
that
this
would
meet
a
need
for
you
know
when,
then
you
know
I
think
this.
This
will
handle
a
lot
of
use
cases
where
you
know.
In
the
past
we've
always
said:
hey,
you
have
to
write
a
plug-in,
but
there
might
be
some
small
tweaks
you
want
to
make
if
it
doesn't
really
warrant
a
separate
plug-in
for
it
that
this
would
actually
resolve
an
issue.
War
so
I
think.
B
B
Yeah
so
I'm
moving
this
to
1.12
miles
yeah
and
in
addition
to
that
I
also
added
design
or
investigation
section
to
imply
what
we
may
spend
Anthem.
That
does
not
deliver
in
the
next
minor
release,
but
we
want
to
investigate.
Hopefully
we
do
that
in
the
next
release
after
112..
The
first
thing
is
the
versioning
of
lateral,
CRS
I
opened
an
issue,
but
I
I
still
need
more
discussion
to
get
more
concrete
idea,
but
I
I
have
the
feeling
that
you
may
need
to
consider
introducing
some
break
change
into
Valero
CR.
B
Then
there
will
be
some
question
regarding
how
do
we
introduce
the
conversion
web
hook?
Whether
or
not
do
we
need
to
support
different
versions
of
CRS
in
the
same
Valero
instance,
and
is
that
okay
we
have?
We
want
to
be
two
of
crds
at
the
same
time
in
Valero,
but
I
think
hopefully
in
1.12.
We
can
have
more
discussion
around
this
topic
and
take
some
action
in
the
next
release.
C
Yeah
I
I
would
say
the
biggest
issue
that,
in
terms
of
the
question
of
supporting
multiple,
that
we're
going
to
have
to
deal
with,
is
to
make
sure
that
we
don't
break.
You
know
backup
compatibility
so
that
a
backup
made
with
the
version
V1
and
then
you
want
to
restore-
and
maybe
you
saw
that
with
conversion.
But
the
point
is
we
need
to
be
able
to
take
a
backup
in
that
backup,
storage,
location
from
you
know:
Valero
1.11
and
restore
it
in
this
new
version
of
a
lot
that
uses
v2crs.
B
Yeah,
that's
a
good
point:
yeah
yeah
and.
C
C
Point
you
may
be
able
to
resolve
that
with
conversions
or
something
I'm,
not
saying
we
necessarily
have
to
support
2cr
C
version
the
same
time.
What
I'm
saying
is
that
whatever
we
have
in
that
Object
Store,
including
the
backup
metadata
file
that
needs
to
be
supported,
if
that
that
might
mean
grabbing
the
Json
and
transforming
it
into
a
you,
know,
V2
or
it
might
mean
sporting,
the
boat
I,
don't
know
as
long
as
long
as
we.
We
support
fully
that
backup.
B
Yeah
yeah
yeah,
so
thank
you
staff
and
please
make
sure
you
add
a
comment
in
the
issue
and
yeah
we're
gonna,
resolve
them
all
and
try
to
write
a
design,
hopefully
in
one
or
twelve
right,
you're
gonna
do
that
right.
I
had
a
comment
to
this
issue.
B
Thank
you
and
the
other
one
is
we
are
trying
to
figure
out.
Is
it
possible
to
You
Know,
download
artifacts
without
accessing
up
that
store?
That's
something
yeah
we
have
been
discussing
with
you
also
and
from
our
side.
We
really
want
to
support
the
unified
data
path
and
we
want
to
support
user
using
NFS
as
a
backhand,
for
you
know,
storing
backup
so
having
to
access
updates
for
to
you
know
in
backup
describe
and
download
request
is
clearly
on.
C
The
question
of
NFS
I
think
we
also
want
to
consider.
You
know
for
I
mean
I
know
in
the
past.
When
this
has
come
up.
You
know
it
seemed
to
me
that
the
the
the
first
thought
as
to
how
you
would
implement
it
would
actually
be
well.
We
just
need
to
write
a
an
object,
store
plug-in
like
Valero
plug-in,
for
you
know,
AWS
Valera
plugin
for
NFS,
or
you
know,
plugin
for
file
system
and
basically
Implement
those
Object
Store
apis,
which
writes
to
a
back-end
file
system.
C
And
if
you
did
that,
then
you
wouldn't
have
to
make
any
core
Valero
changes.
You
would
just
need
a
new
plugin
I,
don't
know
if
that's
appropriate
here,
but
I
think
when
we
make
that
when
we
had
that
discussion
about
supporting
backup
on
NFS
one
possible
invitation,
there
would
be
just
to
write
an
object
star
plugin
that
writes
to
a
file
system
and.
C
You
don't
need
any
changes
to
corvallero,
you
just
create.
You
know
the
Valero
plug-in
for
NFS.
You
know
parallel
to
the
AWS
and
the
Azure
and
the
gcp
ones.
B
Yeah
I
understood
but
I
think
the
unified
data
path
is
a
bigger
story.
I
I
think
that
will
require.
B
Yeah
that
one
has
you
know,
dependency
on
the
certain
object
stores
to
return
the
download
URL
and
you
you
can
do
that.
Yeah.
That's.
C
D
C
F
A
Yeah,
actually
this
this
talk,
oh,
this
is
the
imaginary
item
is
for
multiple
purpose,
the
first
of
all
so
Scott.
We
have
discussed
a
little
bit
during
the
the
discussion
about
the
biway
too,
that
the
background
that
details
are
required
to
download
something
from
the
after.
A
So
that
is
the
the
first
thing,
and
the
second
thing
that
you
know
in
some
on-premise
environments
that
their
clients
will
not
be
able
to
accept
the
objects
or
whatever
it
is
of
just
so
is,
and
because
of
some
Network
isolation,
they
will
have.
They
have
no
access
to
their
officer
objects
directly.
So,
in
that
kind
of
environment
the
client
will
not
be
able
to
to
take
around
to
fully
take
advantage
of
the
the
feature
like
download
something
from
the
client
side
and
the.
A
Finally,
that
is
a
big
story
about
the
the
the
unified
data
paths
so
to
solve
the
problem
that
to
support
of
our
system.
Target
is
one
one
thing,
and,
and
we
we
also
have
some
more
requirements
like
we
want
to
put
everything
into
a
backup
store
so
that
we
can
support
the
one
feature
like
a
report
replication
and
something
like
that.
A
So
but
yeah,
that's
a
big
story,
but
I
think
we
think
that
the
the
unified
database
will
rely
on
the
current
thing
where
I
talk
about
that
is
not
download
from
the
object
store
from
the
client
that
yeah.
A
B
C
C
Those
proposals
were
submitted,
I
think
it
was
about
a
year
year
and
a
half
ago
now,
but
the
people
involved
in
those
are
no
longer
involved
in
the
Valero
community.
So.
C
B
B
I'll
yeah
yeah,
I,
I'll,
I'll
I'll
do
the
double
chat
and
yeah
I
plan
to
you
know,
find
that
out
and
somehow
reconsider
implementing
it
or
you
know,
refine
the
design
and
make
sure
there's
something
we
can
deliver
because.
C
Yeah,
those
are
that's
another
example
of
of
you
know,
proposals
that
I
know:
we've
actually
had
come
up
with
even
with
red
hats.
I
had
a
few
use
cases
that
those
would
help
us
with
if
they
were
available,
but
they
weren't
there
yet
so
I'd,
definitely
interested
in
seeing
those
you
know
get
some
attention
again.
C
C
In
other
words,
ladp
could
use
that
feature
if
it
were
available
for
some
of
the
things
there.
There
have
been
things
we've
talked
about
that
you
know,
for
example,
you
know
well,
one
of
the
things
that's
very
complicated
to
deal
with
with
Valero
and
openshift
is
deployment
configs
they're
harder
than
the
deployments
to
deal
with.
D
C
Rustic
in
particular,
you
know:
we've
had
to
do
some
plug-in
work,
kind
of
jump,
fixing
Hoops
because
with
deployment
configs,
when
you
restore
that
deployment
config,
it
redeploys
the
Pod
with
a
different
name
which
breaks,
rustic
and
I.
Think
Kobe
with
this
will
be
the
same
same
issue,
although
we
haven't,
you
know,
tested
it
with
that,
and
so
we've
had
a
plug-in
where
we
scale
down
the
deployment
config
and
disconnect
the
pods,
so
that
rustic
could
act
on
the
Pod
post
restore.
D
B
Yeah
yeah,
so
I
I,
I,
yeah
I,
don't
want
to
go
too
much
in
detail,
but
it's
great
that
you
also
have
the
requirements.
So
so
we
should
definitely
collaborate
on
this,
but
generally
the
thought
is
yeah.
We
want
to
make
Valero
the
backup
restore
workflow
in
Valero,
more
customizable
to
suit
different
cases.
I
think
generally,
that's
a
direction.
We
should
be.
C
Moving
on
yeah
and
one
of
the
examples
given
I
know
in
those
proposals
was,
for
example,
in
some
cases
you
wanted
to
have
a
free
backup
hook,
or
you
know
plug-in
that
would
actually
say,
shut
down
in
a
database
or
something
before
you
started
the
backup.
So
you
can
get
consistent
in
the
file
system.
Data
run
the
backup
and
then
your
post
backup
would
start
it
up
again.
So
you.
B
Right,
yeah,
yeah,
absolutely
so
yeah.
So
that's
something
you
want
to
work
on
together.
B
Yeah
yeah
and
they're
they're,
you
know,
I'm
gonna
go
go
faster,
then
there's
a
backup
and
the
restore
controller
refactor
and
we
have
been
working
on.
You
know,
to
move
to
up
to
shift
them
to
another
programming
model,
but
we
are
still
using
the
client
says.
So
there
are
some
details:
students
working
on
and
I
think
we
we
want
to
try
to
remove
more
of
them
and
make
the
programming
model
in
Valero
more
consistent
and
in
terms
of
quality
yeah.
We
also
set
some
goals
to
improve
this
UI
coverage.
B
So
if
other
folks
can
consider
to
do
some
contribution
in
this
aspect,
that
will
be
also
helpful.
We
also
want
to
publish
the
performance
test
more
regularly,
so
we
we
provide
a
more
predictable
output
for
each
release.
That's
something
we're
going
to
work
on
so
yeah,
that's
all
for
the
112
roadmap.
It's
still
a
draft.
B
If
you
have
any
comments,
please
also,
you
know,
feel
free
to
send
a
message
in
the
slack,
Channel
and
I
think
we're
gonna
leave
it
in
the
draft
state
for
a
couple
of
weeks
and
after
that
we
consider
it
finalized.
B
That's
it,
and
another
topic
from
me
is:
let
me
open
the.
B
B
Okay,
so
I
want
to
quickly
discuss
this
with
other
maintainers
and
try
to
make
decisions
on
these
ones.
First
thing
is:
is.
B
Yeah
yeah,
he
ping
me
after
one
community
meeting
say
we
should
consider
Implement
them
in
112,
but
personally
I,
don't
consider
them
very
high
priority.
I
I,
don't
know.
What's
your
opinion
in
Scotland
shoeban,
for
example,
I've
been
new
generally
because
we
are
considering
the
versioning
of
backup
CR,
so
I
try
to
refrain
from
adding
too
many
a
new
fields
in
the
back
of
stack
and
the
additional
resources
we
have
different
ways
to
implement
it
in
instead
of
adding
it
to
backups.
B
Back,
for
example,
I
mean
we
have
introduced
this
resource
policy.
Maybe
we
can
add
that
in
the
policy,
so
we
don't
making
the
backup
CR
too
large,
and
also
this
can
be
worked
around
by
you
know.
Writing
your
own
backup
item
action
and
return
additional
items
or
you
use
it
like
those
selectors.
So
there
are
so
many
options.
So
I
personally
considered
this
one,
not
a
very
high
priority,
I'm,
not
sure.
If
there's
any
disagreement.
C
I
mean
I
think
it's
it's
definitely
a
real
use
case.
I
think
the
challenge
really
is
to
make.
If
we
can
come
up
with
a
design
for
this,
that
makes
sense
that,
doesn't
you
know,
make
the
backup
CMR
confusing
and
I
I
mean
to
me
a
question
of
priority
is
more
I
mean
if
we
say
it's
a
higher
or
lower
priority,
it's
more
a
question
whether
we
have
the
resources
to
work
on
it
and
if
you
know,
if,
if
he's
going
to
implement
this,
you
know,
then
that
that
solves
that
question.
C
The
bigger
question
is:
is
there
anything
in
this
design
that
you
know
would
be
a
problem
for
you
know,
like
I
said
we
don't
want
to
be
adding
things
to
the
CR.
That
makes
it
confusing
or
hard
for
users
to
understand,
and
we
have
so
many
ways
of
selecting
things.
We
need
to
be
very
careful
about
that.
C
I
think
the
problem
is
that
I
think
the
use
case
described
here
is
a
valid
one.
I,
just
don't
know,
you
know
if
it's
going
to
be
difficult
to
come
up
with
a
design
here,
I
think
of
the
API
part
that
that's
you
know
clear
enough
that
doesn't
make
things
too
complicated,
but
I,
don't
because
I
think
the
idea
here
is
because,
right
now,
all
of
our
selection
is
either
we
either
use
label
selectors
or
we,
you
know,
specify
things
by
by
type.
C
This
was
this
was
a
way
of
also
saying
oh
I
also
want
to.
You
know,
include
pods,
but
only
the
Pod
with
this
name,
and
you
know
that
kind
of
thing:
I
don't
know
if
that,
because
right
now
that
that
other,
you
know
the
policy
you
know
where
we
were
able
to
specify
you
know
Skip
specific
PVS
with
certain
characteristics.
I,
don't
know
if
that's
flexible
enough
to
also
be
able
to
say,
hey,
I
also
want
to
add
these
other
things
that
aren't
PVCs.
C
You
know,
I
want
to
add
all
pods
with
this
name
or
I
want
to.
You
know,
do
something
like
that.
That
might
be
a
place
that
makes
sense.
I
haven't
really
looked
at
that,
specifically
the
problem
with
label.
Selectors
is
right
now
at
least
the
way
it
works
in
Bolero
is
once
you
use
a
label
selector
that
gets
applied
to
everything.
So
if
I
want
to
use
a
label
selector,
then
everything
in
the
backup
has
to
have
that
label.
You
know
you
know,
there's
there's
no
way
of
saying.
C
C
I
think
at
one
point
there
was
also
a
suggestion:
I,
don't
remember
which
issue
it
was:
it's
been
a
while
I've
of
of
actually
taking
the
the
fields
we
use.
The
existing
fields
for
include
next
include
exclude
resources
and
provide
a
way
to
somehow
include
names
in
there
too,
but
again
that
could
make
it
more
confusing,
depending
on
how
it's
implemented,
and
we
would
have
to
be
careful,
there
I
think
it's
just
something.
You
know
in
general,
that's
a
it's
a
risk
with
any
of
this
selection.
C
C
I
think
one
thing
to
consider
at
all
of
these
use
cases
is
I.
Think
one
question
to
ask:
when
we
we
start
talking
about
hey.
Let's,
let's
add
the
super
flexible
way
of
of
doing
things
is
in
in
some
cases
the
right
answer
may
be,
instead
of
finding
a
way
to
do
all
of
this
in
one
backup.
The
answer
is
you
make
two
backups,
you
know
one
backup
by
type
and
a
second
backup
that
is
a
label
selector,
for
example,
and
then-
and
sometimes
sometimes
that's
the
easiest
way
to
partition.
B
But
that
makes
consistency
even
more
challenging
because
you're
making
two
backups
remember.
The
logically
should
be
one.
C
D
C
If
I
want,
you
know
all
PVCs
but
deployments
only
with
the
but
this
one
deployment,
you
know
things
like
that.
Some
of
that
kind
of
combining
I
want
all
these
types,
but
I
also
want
these
specific
deployments.
These
specific
Secrets
there's
no
way
of
doing
that
right
now
in
Valero,
and
you
could
label
those
specific
things
you
want
with
label
selector,
but
then
you'd
have
to
do
backups,
because
there's
no
way
of
doing
that
together
in
one
backup
the
way
labels
lectures
work.
B
C
Exactly
so
so
this
pair
we're
looking
at
so
this
this
issue,
we're
looking
right
now
is
one
example
of
you
know
one
user's
request
for
more
flexibility
in
in
One
Direction,
and
then
we
have
other
things
and
so
I
think
we
just
need
to
come
up.
If
we
do
something
like
this,
we
need
to
be
careful
about
doing
it,
and
you
know.
C
Know
if
we
add
five
different
ways
of
of
selecting
Things
based
on
five
different
users,
specific
use
case,
then
you
just
end
up
with
even
more
confusion
and
you're,
still
not
you're,
still
not
solving
all
the
use
cases.
So,
but
at
the
same
time
we
don't
want
to
push
everyone
off
and
say
we
don't
want
to
do
any
of
this
stuff,
because.
D
C
C
B
C
Trying
to
remember
West,
you
remember
what
I
think
pretty
was
talking
about
something
that
the
coupon
about
you
know
the
notion
of
wanting
to
have
multiple
backups,
where
there's
kind
of
some
notion
of
priority.
So
you
know
you'd
have
backup
one
backup,
two
and
backup
three
and
then,
when
you
restore
you
restart
with
the
opposite
order,
so
some
idea
of
chaining
backups
to
where
they're
related
to
each
other
I
I,
don't
I,
didn't
hear
the
whole
part
of
that
discussion.
C
Okay
got
it
so,
but
but
there
was
a
discussion
I
heard
part
of
that
was
talking
about
I.
Believe
it
was,
you
know
the
notion
that
you
might
have
you
know.
Maybe
it's
a
schedule
that
that
runs
two
backups
or
something
and
then
and
there's
some
order
between
them.
Saying,
okay,
you
know
you
want
to
do
backup.
One
follow
that
back
up
two
and
then
you,
then
you
restore
on
the
opposite
door
and
I
think
the
basic
use
case
there
was.
You
might
have
two
different
namespaces
with
two
different
applications.
C
That
one
depends
on
the
other,
so
you
know
you
want
to
have
them
in
separate
backups,
because
maybe
they're
different
users
or
whatever,
but
there's
some
priority
of
you
know
one
depends
on
two,
so
you
need
to
back
it
up
in
a
certain
in
order
to
restore
in
a
certain
order.
If
we
had
that
kind
of
notion,
that
would
also
possibly
work
help
for
some
of
these
cases-
or
maybe
you
just
have
you
know
a
backup
that
takes
certain
types
and
then
a
second
backup
takes
a
label
selector
and
kind
of
combines
those
two.
C
So
you
know
there's
lots
of
ways
to
start
to
approach
this,
but
yeah.
We
just
have
to
keep
the
API
usability
in
mind.
F
B
So
yeah,
because
we
are
running
a
lot
of
time
out
quickly,
you
know
talk
about
these
pull
requests.
I
think
these
two
came
up
as
a
similar
request,
like
we
want
a
more
flexibility
in
terms
of
you
know,
resource
selection,
so
I
I
will
also
comment
in
this
PR
to
suggest
you
know,
apply
the
a
resource,
policy
approach
and
yeah
and
we'll
see
if
we
can
make
the
design
merged.
C
Yeah
I
think
the
field
selectors,
one
in
particular
I
think,
does
align
more
with
the
resource
policy,
because
the
field
selectors
is
basically
saying
Hey.
I
want
to
select
items
based
on
hey
this
value
and
metadata
is
something
and
that's
kind
of
like
the
in
the
research
policy.
Where
we're
saying
you
know,
I
want
to
skip
this
PVC
if
it's
meet
certain
characteristics,
so
it
may
be
that
some,
you
know
we
can
include
or
exclude.
C
You
know
if
the
resource,
if
the
the
policy
selection
policy
or
whatever
that
functionality
has
some
way
of
either,
including
or
excluding
based
on
in
a
metadata.
F
B
Probably
do
you
know
if,
for
example,
if
this
is
implemented,
this
will
be
less
important
for
island
or,
do
you
know
the
status
of
these.
C
I
I
do
think
that
these
two
are
very
similar,
and
so,
if
we
do
decide
that
we
can
fit
something
like
this
into,
you
know
the
API
changes
we
needed
some
kind
of
unified
thing.
That's
you
know
one
change
that
meets
that
set
of
needs.
B
Yeah
yeah
I
think
yeah.
We
can
continue
the
discussion
with
Ivan,
but
generally
the
I
think
the
general
agreement
is
that
we
will
ask
him
to
refine
the
design
and
we
reveal
them
and
we'll
see
whether
it
will
be
part
of
112
based
on
the
status
right.
B
Yeah
yeah.
C
Yeah
I
mean
I,
think
that's
a
combination
of
getting
the
design
approved
in
time
and
then
from
a
from
an
implementation
point
of
view.
You
know,
if
he's
able
to
implement
it,
and
he
said
you
know,
then
the
priority
of
question
becomes
less
relevant
because
it,
you
know
I
mean.
Obviously
it
takes
some
resources
to
maintainers,
because
we've
got
to
review.
You
know
PR's
and
all
that.
But
the
point
is
the
most
important
part
is
getting
the
design.
You
know
fruits.
B
C
Right,
oh
yeah.
That
definitely
needs
to
be
part
of
the
implementation.
B
My
personal
preference
at
the
moment
is
that
we
can
more
the
design
oneself
and
implementing
one
certain
if
it's
okay,
for
you
guys,
because
yeah
yeah
that
doesn't
seem
to
be
very
high
priority.
For
me,
to
be
honest,
then,
maybe
can
delay
further,
but
but
in
general,
as
a
general
direction.
I
think
we
want
to
make
sure
we
don't
make
too
much
change
to
the
spec
of
the
CRS
until
we
well
I
mean
before
we
have
a
agreement
in
terms
of
versioning
could.
C
Yeah
and
I
guess
the
good
thing
would
be
if,
if
we
do,
if
the,
if
the
resource
policy
approach
is
something
that
works
here,
that
would
minimize
the
crd
change.
You
know
the
API
change
there,
because
then
it
would
just
mean,
but
but
again,
like
I,
said
the
first
thing
we
just
need
to
get
in
a
design
going
because
sometimes
especially
if
there's
a
lot
of
back
and
forth
and
a
lot
of
changes
needed
that
process
itself
can
take
some
time.
C
So,
even
if
we
just
said
we
said
hey,
we
want
this
in
113.
Ideally
we
get
the
design
approved
in
112
in
that
time
frame
just
because
that
that
process
can
sometimes
take
a
while.
B
We
also
have
other
jobs,
so
sometimes
the
design
you
know
have
the
design
revealed
on
time.
It's
really
a
challenge
for
us
so,
but
that
that's
how
it
is
at
the
moment
we'll
try,
but
I
I
cannot
make
any
commitment,
for
you
know
third-party
programs
for
for
the
designs
from
VMware
or
red
hat,
because
we're
maintainers
and
also
the
Microsoft
guy.
They
are
really
active
and
doing
the
contribution.
I
think
we
kind
of
prioritize
certain
designs
more
than
others.
That's
the
how
it
is
at
the
moment
and
yeah.
B
B
A
Oh
yeah
I
think
we
have
finished
all
the
items.
Thank
you
everyone
we
can
finish
off
here
today,
thanks
for
Donnie.