►
From YouTube: Velero Community Meeting - July 13, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
today
is
july
13,
and
this
is
velaro
community
meeting
and
we
have
still
have
10.
A
The
women
begin
team
is
have
primarily
focused
on
the
copia
integration
design
and
we
have
nearly
finalized
it
and
the
task
has
also
been
broke
down
and
issues
has
been
done
and-
and
we
can
view
all
the
issues
from
this
link
and
there's
the
issues
have
been
attacked
with
copia
integration
labels
and
I
think
the
the
pr
is
it's
close
to
merge
and
but-
and
I
believe
that
all
most
of
the
time
of
the
week
1.10
this
pr
or
this
designs
is
open
for
for
discussion.
A
B
Hey
yeah,
so
so
I've
been
reviewing
the
design
with
the
team
and
work
with
breakdown
task
for
cochlear
integration.
So,
like
you
mentioned
they're
all
done
so
we
have
started
or
working
on
the
specific
tasks.
For
me,
I'm
I'll,
be
you
know,
updating
the
crds.
It's
like
a
top-down
approach
from
my
side,
I'll,
be
working
on
the
crd
changes
controller
changes
into
some
refactor
to
make
sure
there
is
there.
B
There
is
a
possible
to
add
a
path
for
a
copia
in
addition
to
jurassic
and
after
that,
young
huey
amin
will
do
some
fundamental
work
and
make
sure
there
are.
You
know
the
end-to-end
flow
works,
and
in
addition
to
that,
I
have
fixed
a
small
issue
with
4
8
15..
B
B
Which
line
of
the
code
in
the
plugin
will
throw
this
new
pointer
issue,
so
I
just
simply
dump
all
these
runtime
frames
in
the
log,
so
it
doesn't
look
good,
but
it
do
help.
It
does
helps
for
debugging
the
issue
to
find
out
the
problem
in
the
plugin
code
and
in
addition
to
that,
I'm
reviewing
the
data
more
related
prs
by
shubham
and
scott,
and
I
will
follow
up
with
you
guys
later.
A
Okay,
okay,
thank
you
daniel
for
me,
I
I'm
also
working
on
the
the
copying
integration
design
and
the
task
breakdown,
and
these
days
I
have
also
started
some
of
the
tasks
yeah.
So
that's
it
and.
D
I'm
working
on
the
pr
to
reduce
the
crd
size,
as
this
mainly
achieved
by
replace
the
pulse
back
in
restore.
Certainly,
we
slip
generic
object
and
also
working
on
reviewing
vsl,
credential
and
atom
action,
progress,
monitoring,
pr
and
that's
all.
A
Yes,
I
think
this
is
another
this
one
right.
This
is
another
a
large
design
and
we
may
have
you
know
some
more
time
to
review
it
and.
A
E
Some
background
for
kind
of
where
that
came
from
too,
when
you
get
to
me.
A
Yeah
yeah,
we
may
need
some
statically
time
for
the
discussion.
Yeah.
E
Yeah,
that's
fine
and
we
can
talk
about
today
and
if
people
want
to
look
at
it
basically,
a
couple
of
weeks
ago,
shabam
introduced
a
need
that
we
had
for
data
mover
around
what
we
were
calling
asynchronous
plugin
actions.
And
then
we
had
some
follow-on
discussion
on
slack
to
point
out
that
there
was
a
lot
of
overlap
between
that
and
dave's
design
from
you
know
quite
a
while
back
on
the
upload
progress
monitoring,
and
I
actually
we
looked
at
that
and
realized
that
the
goals
really
were
very
similar.
E
So
we
decided
it
made
a
lot
of
sense
to
try
to
integrate
those
two
into
a
single
kind
of
more
flexible
and
basically
take
dave's
design
for
upload
progress,
monitoring
for
snapshots
and
ex
kind
of
make
it
more
general
to
apply
to
backup,
item
action
and
restore
imax
as
well
and
try
to
kind
of
collect
the
combined
needs
in
a
single
proposal
with
kind
of
a
general
more
general
model,
and
that
was
the
intent
here
with.
I
basically
took
all
of
the
content
of
dave's
design.
E
I
took
shoe
bombs
design
that
we
had
internally
at
red
hat
and
tried
to
merge
the
set
of
requirements
between
both
of
them,
and
I
want
to
basically
get
a
single
design
that
works
for
kind
of
all
the
use
cases
here,
and
this
was
kind
of
a
first
attempt
to
that.
I
noticed
there
was
some
feedback.
I
responded
to
some
of
that
already,
but
I'm
sure
there's
more.
Some
more
ongoing
discussion
needed
a
couple
of
places
where
I
I
pointed
out
that
I
needed
to
revise
the
design
and
response
to
some
comments.
E
B
Okay,
so
essentially
you're
proposing
that
we
do
not
write
a
plugin,
as
dave
suggested
in
his
design.
We
we
we
do
not
use
the
item,
snapshot
plugin.
Instead,
we
use
the
existing
yeah.
E
E
Snapshotter
and
my
thinking
talking
to
shibam
and
dylan
on
our
side
was
that,
first
of
all,
now
that
we
have
the
plug-in
versioning
api
kind
of
in
work
for
110.,
it
seemed
to
make
more
sense
to
instead
of
creating
two
new
plugin
types,
one
for
backups
and
one
for
restore.
Let's
just
do
because
he
already
proposed
modifying
volume,
snapshotter
to
add
a
progress
method.
E
Let's
do
the
same
thing
for
backup,
item
action
and
restore
item
action.
Most
plugins
won't
need
that.
That's
fine!
That
can
be
a
no
op.
You
know
it
can
do
nothing
can
return
true
whatever,
but
this
gives
us
the
option
to
edit
the
other
advantage
of
using
the
existing
plugin
type.
Is
we
don't
have
to
add,
because
right
now,
for
example,
in
backups
there's
a
section
in
the
backup
processing
where
we
loop
over
all
the
backup
item
actions?
You
know
call
it
modify,
call
down
the
chain.
E
Take
the
additional
items.
Do
all
that.
So
if
you
introduce
a
new
plugin
type,
we
have
to
add
another
loop
that
duplicates
all
that
logic.
If
we
can
just
modify
the
mod,
the
interface
to
add
the
new
method,
but
now
that
we
have
the
plug-in
versioning
for
once-
and
we
can
do
that-
we
don't
have
to
add
a
new
place
to
hold
this
logic,
and
then
we
can
handle
everything
else.
Basically,
the
same
as
so.
E
The
basic
change
from
dave's
design
is,
instead
of
creating
a
new
plugin
type
for
what
he
was
calling
item:
shop,
shutter
or
snapshot
item
action.
We're
just
going
to
modify
backup
item
action
to
add
this,
the
an
optional
again
a
snapshot
id
or
what
we're
calling
a
operation
id,
because
it's
again
more
generalized
than
snapshots
for
a
snapshot.
It
will
be
a
snapshot
id,
but
it
could
be
something
else.
E
It's
just
a
string
the
plugin
knows
about,
but
we
also
want
the
same
thing
on
the
restore
side
because
from
talking
to
shoe
bomb
and
the
data
mover
design,
he
had
in
mind.
We
really
need
the
same
thing
on
the
restore
side,
and
that's
one
thing
that
was
absent
from
dave's
design
is.
He
was
only
talking
about
the
backup
and
whatever
changes
we
make
to
backup
item
action.
E
We
want
to
make
the
same
changes
to
restore
item
action
because
for
data
mover
and
certain
other
plug-in
types
we
may
want
that
on
the
restore
side
as
well.
So
so
the
main
advantages
over
dave's
proposal
is
we're
not
adding
any
new
plug-in
types
we're
taking
making
use
of
the
plug-in
versioning
api
api
versioning,
so
that
we
can
modify
the
existing
backup
item
action
and
restore
item
action
in
kind
of
the
same
way
that
he
was
already
modifying.
E
In
his
proposal.
The
volume
snapshotter.
E
And
I
I
also
want
to
call
out
there
are
a
couple
of
things
that
were
commented
on
in
the
review
to
question,
and
this
is
one
of
dave's
original
points
where
he
he
was
saying,
because
we
go
through
at
the
end
of
the
backup,
for
example,
and
then
we
go
and
we're
in
the
kind
of
wait
for
snapshots
phase
dave
dave's
proposal
had
not
writing
the
backup
to
object
store
until
the
back
was
complete
and
the
question
on
the
on
the
vr
was:
why
don't
we
write
it
when
we're
done?
E
You
know
and
before
we're
waiting-
and
I
actually
kind
of
agree
with
that-
I
was
hoping
dave
could
respond.
I
don't
know
how
active
he
is
now.
I
don't
know
if
he's
going
to
see
this,
but
I
I
think
I
I'm
kind
of
thinking
the
same
thing.
We
get
to
a
point
at
the
end
of
the
current
backup
processing,
where.
E
For
the
the
backup
item
actions,
you
know
all
of
these
things
we're
waiting
for.
If
it's
done
we're
done,
we
finish
it.
We're
done
we
go
on,
but
if
we're
still
waiting
for
these
external
snapshot,
uploads
or
item
action
operations,
why
don't
we
go
ahead
and
write
the
backup
at
this
point?
You
know
everything
that
we
know
and
we
still
we're
still
in
that
waiting
phase.
E
That
way,
if
something
were
to
happen
to
the
valero
process
and
it
were
to
bounce
everything's
an
object
store,
we
can
recover
wait
for
results
and
we
don't
lose
anything.
So
I
actually
think
that's
a
good
suggestion,
I'm
just
hoping
to
hear
some
feedback
from
davis
to
maybe
he
has
some
other
reasons
for
not
doing
this
in
his
proposal.
That
the
other
thing
I
haven't
done
yet-
and
I
kind
of
need
to
do
is
dave-
had
a
draft
pr
where
he
implemented
some
of
this.
E
I
need
to
look
at
that
to
see
whether
there
were
changes
from
his
design
to
his
draft
pr
to
see,
if
there's
anything
else,
that
we
need
to
incorporate
into
this,
because
obviously
that'll
have
to
be
reworked
as
well.
B
Yeah
yeah
yeah.
I
think
the
main
reason
delaying
uploading
the
table
is
that
he
doesn't
want
the
backup
appeal
to
be
ready
to
use.
B
E
My
concern
is,
if
we're
at
a
point
where
we're
already
done
with
the
backup,
except
for
waiting.
Maybe
we
should
write
it
because
that
way,
if
something
were
to
happen
to
the
layer
process
that
were
to
bounce
or
whatever
you
know,
we
don't
lose
the
whole
thing,
because
at
that
point
everything
is
in
object,
store
we're
just
waiting
for
you
know
results,
but
we
should
be
able
to
recover
at
that
point.
So
that
might
be
something
worth
doing,
because
the
backup
states.
D
B
Yeah
so
you're
suggesting
that
although
the
data
movement
may
be
failure,
we
cannot
restore
some
particular
pvs,
but
there
are
a
lot
of.
B
B
E
E
If
we
write
everything
to
object
store,
then
if
the
valero
pod
were
to
restart
for
some
reason,
valero
can
still
recover
from
that
finish,
waiting
for
these
actions
and
everything's
good,
because
and
that
that's
why
it
might
make
sense.
And
again
I
was
responding.
I
forget
who
reviewed
the
commented
that
there
was
a
suggestion,
so
why?
Why
are
we
not
writing
this
to
back
up?
E
A
In
that
way,
scott
does
it
mean
the
backup
has
been
uploaded,
but
before
the
the
data,
the
soundcloud
has
been
moved
to
all.
E
E
Yeah
exactly
it's
not,
in
other
words
the
backup's
not
completed.
If
you
actually
do
a
valero
backup
get
you'll
see,
the
backup
is
still
in
that
waiting
for
upload
state,
but
valero
already
has
the
data
everything
that
it's
going
to
write
to
object
store.
It
should
just
write
it
there,
because
that
way,
it's
already
in
the
object
store
it
does.
It
doesn't
mean
that
valero
is
going
to
use
it
for
a
restore.
It
just
means
that
once
valero
is
done
with
the
backup
before
it
goes
to
the
next.
E
Let's
free
up
that
memory
in
the
valero
pod.
It
doesn't
need
to
hold
that
in
memory.
It
can
just
write
it
to
the
backup
store
before
it
starts
the
next
backup,
but
no
the
valero
backup
status
in
the
status.phase
is
still
not
completed.
So
valero
knows
that
it's
not
done
with
uploading.
It's
got
that
point
where
it's
still
going
to
have
to
check
those.
E
Reason
to
hold
this,
you
know
huge
set
of
backups
and
memory
and
not
write
it
to
the
object
store.
Let's
just
write
it
out.
While
we
have
it,
let's
free
up
the
memory
for
the
valero,
because
that
way
when
valero
starts
the
next
backup,
because
that's
another
key
part
of
dave's
design
that
I
kept
was
once
the
backup
is
done
and
all
we're
doing
is
waiting
for
snapshot
uploads,
for
example.
We
can
start
the
next
backup
now,
but
let's
not
hold
this
back
up
in
memory.
E
You
know
waiting
to
write
at
objector.
Let's
write
it
out
once
we're
done
with
that,
we
can
check
again
to
say:
hey
is
the
upload's
completed
if
they're
completed,
we
mark
the
backup
is
done
and
we
move
on,
but
if
they're
not
completed,
we
keep
it
in
that
waiting
for
upload
state
or
that
kind
of
the
more
general
new
static
name
ahead
in
the
pr
and
then
that's
something
that
valero
keeps
checking.
You
know
periodically.
E
B
E
No
and
that
that
was
part
of
that
confusion
because
see
because
the
because
dave's
proposal
was
you
know,
you
know
we
even
called
it
snapchat.
You
know
snapchat
upload
progress
monitoring.
I
didn't
even
think
that
it
was
to
look
at
it
as
relevant
and
when
we
had
that
conversation
on
slack
last
week,
I
looked
at
it
and
I
realized
his
proposal
was
probably
80
the
same
as
shoe
bombs
in
terms
of
what
they
were
wanting
to
add.
So.
F
E
Once
I
looked
at
that,
I
realized
it
really
does
make
sense
to
make
this
one
integrated
thing
and
apply
it
both
to
okay
snapshot
uploads,
as
well
as
these
asynchronous
actions
that
we're
going
to
need
for
data
mover
and
once
we
have
it
third-party
plug-ins.
For
example,
one
of
the
plug-ins
that
we
have
for
openshift
for
red
hat
is
for
copying.
Internal
images
from
our
an
openship
has
an
internal
docker
registry
as
part
of
the
cluster.
E
B
Yeah
yeah
I'll
take
a
closer
look
and
yeah.
My
concern
is,
we
may
need
to
because
dave
has
been
quite
inactive
in
the
recent
community
meetings.
Oh.
E
That's
fine
too,
you
know
I.
I
did
ping
him
on
the
the
thing
if
he's
willing
to.
If
he
has
time
to
respond,
that's
great
but,
like
you
said,
he's
not
been
active
lately
and
we
may
have
just
make
a
decision
and
if
we
need
to
change
something
right,
that's
why
I'm
saying
his
design
actually
called
for
not
uploading
the
backup
until
it
was
complete
and
one
of
the
reviewers
will
question
that
say
what
you
know.
E
Why
do
we
need
to
wait,
and
I
actually
kind
of
agree
with
that-
it's
just
that
I
was
kind
of
taking
dave's
a
dime,
but
I
I
actually
wanted
to
revisit
that,
and
I
think
it
would
be
better
to
upload
that
the
backup
to
the
object
store
as
soon
as
we're
done
with
valero's
done
with
it.
You
know
if
dave
can
respond
and
he
has
a
reason
why
we
shouldn't
do
that.
That's
fine!
If
he
doesn't
respond
and
we
you
know
it
works
for
us
to
change
that.
I
mean
that's
fine.
F
E
E
Yeah
I
I've
seen
that
pr-
and
I
know
it's
there.
I
I
kind
of
intentionally
want
the
one
of
the
originals.
E
B
So
freaking
out,
but
I
just
want
to
point
out
there-
there
has
been
one
or
two
pr's
already
merged
to
the
main
branch
when
they
was
implementing
this
upload
progress.
Okay,.
B
E
I
know
there's
one
open
pr
that
he
had
that's
not
merged,
yet,
if
you've
seen
a
couple
of
prs
that
are
merged,
if
you
could,
if
you
could
link
them
on
my
design.
Pr,
as
I
said,
I
need
to
look
at
anything,
that's
been
merged
and
anything
that's
been
proposed
to
make
sure
that
if
I'm
proposing
something
that
we
decide,
we
need
to
change.
We
we're
fully
aware
of
what
the
implications
might
be,
including
you
know,
if
there's
already
code
there
that
contradicts
this.
That's
okay!
E
As
long
as
we
agree,
we
all
want
the
change.
We
just
need
to
make
make
sure
that
we're
aware
you
know
this
is
a
change
we
need
to
make
because
it
meets
a
larger
use
case,
and
we
know
that
this
is
what
has
to
change
in
the
code
base
and,
as
I
said,
I
know
there's
that
draft
pr
that's
not
merged.
Yet.
E
I
also
want
to
look
at
that
to
see
if
there
were
any
changes
there
from
the
design,
but
if
there's
anything
already
merged
for
this,
I
definitely
want
to
see
that
I
mean
obviously
to
either
account
for
it
or
make
a
change
or
whatever,
because
we
now
that
we
can
do
make
changes
to
the
plug-in
apis.
You
know
that's
good.
We
have
more
flexibility,
but
let's
make
sure
we're
making
the
right
set
of
changes
the
first
time,
because
we
want
to
make
a
v2.
A
B
A
B
A
A
Yeah,
I
want
to
add
another
thing:
it's
like
you
know,
just
as
shubham
mentioned
just
now.
This
progress
monitor
should
be
very
generic
and
work
for
every
scenarios.
Like
you
know,
we
have
durables
and
products,
we
have
non-durable
snapshot
and
we
have
data
mover
and
right
and
some
sometimes
may
be
dependent
on
users.
For
example,
I
have
other
user.
I
have
a
aws
eurovision
product.
I
want
to
move
it.
I
don't
want
to
move
it.
A
So
what
I
just
want
to
mention
that
we
need
to
make
this
this
this
design,
very
generic.
E
I
need
this
action
to
happen
in
this
external
controller.
Every
time
we
do
a
backup
or
this
action
to
happen,
and
this
external
controller.
Every
time
we
do
a
restore
and
my
plugin
is
going
to
initiate
that
action
by
creating
some
cr
that
some
plug
in
this
some
sorry,
some
controller-
that's
not
bolero,
is
going
to
you
know,
grab
onto
and
process,
and
then
I
and
then,
because
we
have
this
progress
method.
E
The
plugin
is
responsible
for
when
you
know
valero
at
the
end
of
the
backup
or
restore
calls
this
progress
to
say:
hey
are
you
done
yet
gives
it
that
string
id
that
plug-in
can
look
up
its
own
custom
cr
that
it
created?
If
larry
knows
another
thing
about
and
say:
oh
that's
done
now
respond.
So
yeah,
that's
exactly
my
goal
is
that
it
needs
to
be
generic.
E
The
early
initial
use
case
for
this
is
in
fact,
snapshot
upload
and
data
mover,
but
we
want
to
make
sure
this
works
for
really
any
plug
any
backup
item,
action,
restore
item,
action
or
volume,
snapshot
or
plug-in.
That
has
some
operation
that
it
wants
to
trigger
during
its
execute
phase.
That's
then
going
to
continue
in
its
own
thread
or
its
own
process
for
its
own
pod.
Then
valeria
needs
to
check
back
on
at
the
end
of
the
backup,
restore
to
say:
hey,
are
you
done
yet
that's
the
goal
here.
A
Oh
yeah,
okay.
I
think
there
should
be
more
time
for
us
to
discuss
this
and
yeah.
E
Yeah
feel
free
to
comment
on
the
pr
ping
me
in
slack
whatever,
and
we
can
talk
about
it
again
next
meeting
as
well.
E
Scott
and
I
will
again
look
at
dave's
pr
and
any
prs
that
daniel
or
anyone
else
can
point
to
me
that
were
already
merged
to
see.
If
that
those
prs.
Also
might
you
know
suggest
that
I
need
to
make
some
changes
to
the
design
to
accommodate
things
there
or,
if
not,
then
we
need
to
make
note
of
when
we
implement
this.
We
need
to
make
some
changes
some
existing
code
as
a
result
of
the
change.
G
Okay,
let's
move
on
and
time
for
your
update.
Please.
H
Okay,
I'm
working
on
a
migration
in
text
and
I
have
passed
the
script
on
a
aws
and
asia
provider
and
still
working
on
the
sphere
environment
about
this
test
case.
Currently,
I
use
two
backup
command
to
backup
the
workload
the
namespace
and
the
cluster
scope
resource.
I'm
trying
to
find
a
way
to
to
combine
these
two
command
in
one
backup
command.
H
Currently,
I'm
I
I
think
I
I
have.
I
haven't,
found
a
good
way
to
back
up
these
two
kind
of
resource
in
in
one
bank
of
command.
A
Okay,
thank
you
and
scott.
I
think
what
we
have
just
mentioned
is
it's.
What
we
wanna
mention
here
right.
E
And
I'm
just
mentioning
one
other
thing,
not
new
work
for
me,
but
I
just
there
were
some
additional
comments
on
it
that
I
responded
to
the
volume
snapshot,
location
credentials,
question
that
that
pr
still
out
there
I
do
need
to
rebase
it
with
the
crd
changes.
But
if
there's
any
questions
there,
I
did
want
to
clarify.
I
know
this
is
something
that
bridget
started
working
on
and
then,
as
I
understand
it,
you
know
it
was
a
prioritization
thing.
The
reason
she
pulled
that
out
and
didn't
finish.
E
It
wasn't
that
she
thought
it
was
a
bad
thing.
It
was
that
the
business
need
for
it
was
smaller
back
for
bsl's.
The
notion
of
needing
set
of
additional
credentials
for
each
location
is
obvious,
because
you
might
have
three
different
bsls,
all
with
different
credentials
for
volume
snapshots.
E
So
the
only
way
to
do
that
right
now
without
messing
up
your
default
bsl
would
be
to
set
credentials
in
the
volume,
snapchat
location
and
the
other
reason
why
we
want
this
is
so
that
once
users
have
gotten
accustomed
to
not
having
to
create
those
default
credentials
that
creation
time
they
only
create
those
and
add
those
for
each
bsl.
They
create
for
backup
storage
locations,
as
this
would
allow
them
to
use
the
same
method
for
managing
their
volume.
Snapchat
locations
again
only
adding
the
credentials
when
they
create
the
vsl.
E
So,
for
example,
for
a
user
that
say
normally
uses
menio
for
their
object,
storage.
They
already
have
that
and
their
credentials
and
then
now
they
want
to
start
using
snapshots
during
aws
cluster.
They
create
a
vsl
with
their
amazon
region
for
that
they
want,
to
just
add
the
credentials
right
there
without
having
to
mess
with
default
credentials
or
mount
secrets,
or
any
of
that.
E
B
F
E
Every
s3
bucket
you
create,
might
have
its
own
credentials,
so
even
right
now,
in
other
words,
you
might
not
have
three
different
volume
snapshot
locations
with
different
types
of
credentials,
like
you
might,
with
backup
storage
locations.
At
the
same
time,
your
you
might
be
using
your
default
credentials
for
because
right
now,
valero's
notion
of
the
default
credentials.
Location
is
the
same
for
volume,
snapshot,
locations
and
backup
storage
locations.
E
But
if
your
backup
storage
locations
are
you
know
in
some
third-party
s3
store
and
not
aws
like
say
minio
or
nooba,
and
if
that's
what
your
default
credential
secret
is
pointing
to,
and
then
you
want
to
start
using
snapshots
if
you
can
just
add
those
credentials
to
your
valium
snapshot,
location,
your
aws
credentials,
because
those
nubik
credentials
are
obviously
not
going
to
be
valid
for
aws
snapshots,
so
it,
in
other
words
I
took
bridget's
comment-
is
not
doing
this
as
a
bad
thing,
but
the
if
you
want
to
pick
one
area,
that's
more
important.
A
E
Snapshots
but
you
might
still
use
a
different
set
than
the
default,
so
you
still
need
this.
If
the
only
volume
snapshot
credentials,
you
need
are
different
from
your
backup,
storage
location
default
because
say
you
know
if
you've
already,
you
know
centered
your
valero
install
around
using
mineo,
for
example,
because
you
know
this
is
your
local
object
store,
but
you
happen
to
have
an
aws
cluster
and
you
have
an
azure
cluster,
and
so
those
different
clusters
have
to
use
different
credentials
for
their
volume
snapshots.
E
So
maybe
your
default
credentials
are
set
up
around
your.
You
know,
internal,
your
local,
you
know
back
object
store,
but
those
volume
snapshot
locations
have
to
be
geared
towards
the
specific
location
of
your
cluster.
So
that's
a
use
case
in.
In
other
words,
this
isn't
something
that
you
absolutely
have
to
have
to
back
things
up,
but
having
this
makes
it
convenient
to
manage
your
credentials
in
the
same
way
for
volume
snapchats.
As
for
backup
storage,
it
doesn't
require
you
to
change
your
default
credentials.
E
Based
on
where
your
look
cluster
is,
for
example,
it
lets
you
decide
at
the
point
you
create
those
snapshot.
Locations
add
the
credentials
then
just
like
we're
doing
with
volume
snapchat
start
with
backup
storage
locations.
So
I
kind
of
understood,
bridget's
comments
as
saying
look.
We
have
limited
resources
for
this
release.
E
We
don't
have
time
to
get
volume
snapshots
in
we're.
Just
gonna
do
the
backup,
storage
location
because
that's
the
low
hanging
fruit,
that's
the
bigger
pain
point
but
and,
as
I
understand
talking
to
dylan,
we've
got
customers
with
odp
and
red
hat
where
they
want
to
be
able
to
manage
the
volume
snapshots
in
the
same
way.
E
So
I
just
kind
of
revised,
you
know
kind
of
put
back
some
of
what
was
originally
there
with
the
crd
changes
for
the
vsls
and
then
adding
the
the
kind
of
controller
and
logic
changes
needed
to
support
that
and
again
we
already
have
that
support
in
the
aws
plug-in
we
just
need
to.
In
addition
to
that,
current
open
pr
that
I
do
need
to
rebase
because
of
crd
changes.
E
For
that
you
know
crd
file.
We
will
also,
once
that's
merged,
need
to
add
support
for
gcp
and
azure
plugins,
because
right
now
a
ws
plugin
already
supports
this.
It
actually
with
the
changes
to
valero
in
my
pr,
this
actually
works.
You
know
in
an
aws
cluster
environment
without
any
changes
to
that
plugin,
because
that
plugin
already
supports
looking
for
credentials
there.
We
need
to
make
the
same
changes
to
azure
and
gcp.
A
Okay,
okay,
thanks
god,
I
think.
Okay,
I
think
daniel
may
have
some
problem
with
with
his
network,
so
I
will
want
one
sumo
quadrant
from
it
like.
So
is
this
with
vsr
change?
In
the
same
same
pr,
here.
E
Oh,
no,
no,
it's
totally
different.
The
pr
is
already
out
there.
If
you
look
at
open,
pr's
and
filter
by
my
name,
you
should
see
another
one.
I
should
link
it
in
here,
but
if
you
yeah,
if
you
look
at
what's
open
on
valera
right
now,
I
can
find
the
link.
E
I
Okay,
I'm
working
on
the
item
to
adjust
the
package
structure
for
rest,
and
this
is
part
of
the
copier
equation
and
first
I
need
to
pronounce.
Is
we
found
the
issue
in
one
line?
A
Okay,
thank
you
and
then,
let's
move
on
to
the
discussion
section.
First
of
all,
very
very
it's
a
very
simple
question.
So
for
the
for
the
core
pr
integra
integration
design,
do
we
have
any
pending
questions
before
it
is
merged?
I
think,
especially
for
scott
and
shubham.
Do
you
have
any
pending
questions.
E
I
don't
at
the
moment
I'll
I'll
have
I'll
look
at
it
again,
but
right
now
I
know
I
have
looked
at
before
and
I
think
I
don't
have
any
current
additional
questions
on
that.
A
Okay
and
for
the
site,
yeah.
G
I'll
take
a
look
at
it
once
I
don't
have
any
pending
questions,
though,
but
yeah
I'll
take
a
final
look.
A
Okay,
thank
you
and
the
status
of
the
pr
it's
so
I
think
daniel
has
been,
has
proved
that
and
so
stop
and
survive.
If
you
you,
please
further
review
it,
and
if
there
is
no
more
questions,
scott,
please
help
to
approve
that.
Okay,.
E
Yeah
I'll
I'll
have
a
look
at
it
tomorrow
and
then
I
should
I'll
get
some
feedback
either
feedback
or
approval.
If
I
don't
have
any
additional
questions,
yeah.
Thank
you.
J
Oh,
let
me
check,
I
think
daniel
is
daniel.
Has.
F
Some
problem
his
net
with
his
network.
He
cannot
connect
to
the
global
proxy,
so
yeah.
He
just.
Let
me
help
to
ask:
ask
the
he
asked
the
question
he
put
in
the
discussion
topic
yeah.
So
I
think
that
then
I
want
to
confirm.
F
If,
if,
if
we
have
any
other
questions
or
concerns
for
the
one
dollar,
a
1.10
plan,
so
I'm
not
sure
scott
or
support,
have
you
already
take
a
look
to
that
line
of
1.10.
E
I
know
I
know
we
actually
had
some
conversation
with
dylan
actually
today
because
we're
actually
we
actually,
we
actually
have
an
odp
group
kind
of
in-person
meetup
this
week,
so
kind
of
we're
all
in
raleigh
this
week
and
we'll
have
some
I'll
talk
to
dylan
again
tomorrow
to
see
if
there's
any
additional
comments
he
had,
because
I
know
we
had
some
discussions
around
that,
but
I
don't
know
if
we
got
a
point
of
you
know
any
kind
of
final
resolution
there
today.
F
Okay
good,
so
please
take
a
look
to
that.
If
anything
needed
to
no
earth
fallout,
please
discuss
with
us.
F
Also
then
they
put
another
comment
in
that
section.
You
know
we
we
have
some.
I
mean
organization
organization
restructuring
in
the
company,
so
some
of
the
team
will
take
some
more
responsibility
for
the
companies,
but
then
but
another,
but
we
are
still
working
with
our
project.
That
is
that
that
is
not
a
change.
Yeah.
E
And
I
had
a
quick
question
release
the
question
from
japan
question.
I
noticed
that
we
had
the
issue
with
the
bsl
validation
kind
of
you
know,
with
one
nine
there's
a
kind
of
continuous
validation
instead
of
the
one
minute
delays
that
was
cherry
picked
to
the
one.
Nine
branch
is
the
intent
to
release
a
191
with
that
fix
and
if
so,
what's
the
timing
around
that.
F
Yeah
we
we
previously
have
some
discussion
on
that
patch
release.
We
want
to
see
if
there
any
more
issue
found
in
the
community.
So
if
we
may
plan
to
work
on
this
patch
release
start
from
by
end
of
this
month,
so
maybe
in
next
month
we
can
release
that
patch.
E
F
A
D
E
D
You
you,
you
mean
the
the
parts
back.
What
is
useful
in
you.
E
Know
right
right
and
I
was
yeah.
I
don't
know
that
I've
ever
interacted
with
restore
in
a
way
that
that
you
know
had
to
mess
with
that.
So
so
I'm
not
familiar
with
the
need
there.
So
I
don't
really
know
what
that's
used
for,
and
so
it's
hard
for
me
to
say
you
know
who
might
need
it
because
I
I
haven't
seen
the
need
for
it,
but
I
don't
really
know
where
it
would
fit
in
where
it
would
be
useful.
Oh
you
know,
in
other
words,
what
functionality
are
we
losing
by
getting
rid
of
it.
D
Basically,
I
think
no
function
negative
losing
because
we
I
I
use
the
preserve
unknown
field
to
let
the
controller
all
of
the
kubay
api
server
to
keep
all
the
field
unknown
in
the
part
in
the
in
the
neat
container
area
field,
and
I
think
other
things
should
work.
I
say
just
there
is
no
such
detail.
D
Definition
in
the
crd
of
restore,
so
I
say
except
the
crd
definition,
young
file
and
logic
the,
but
the
valero
working
logic
and
code
hasn't
changed
much
from
that
and
talking
about
the
parts
back
it
is
used
for
the
hook
in
the
restore,
because
in
restore
process,
there
is
possibility
that,
when
trying
to
run
some
hooks
before
the
restore
all
the
other
parts
started,
we
need
to
use
something
like
you
need
container.
D
D
E
Yeah
that
makes
sense
yeah,
I'm
not
sure.
As
I
said,
I
don't
think
I
we
have
any
use
on
the
right
outside
where
we've
done
much
with
that
directly
shiba
might
have
some
different
recollection,
but
it
doesn't
sound
to
me
like
there's
anything
on
our
side
where
you
know
this
would
impact
us.
But
it's
just
not
obvious
to
me
if
there
was
a
problem
like
how
users
would
see
it
when
they
would
see
it
and
all
that.
D
A
Okay,
okay,
something-
and
maybe
we
have
the
details
in
the
slack
and
anyone
else
could
sing
that
for
a
while
and
just
see
if
there
is
any
unseen.
D
A
Yeah
thanks
and
the
next
one
is
from
johnny.
I
telling
please.
F
Yeah,
that's
that's
a
animal
regard
regarding
the
community
meeting
time.
I
think
only
have
already
created
a
discussion
topic
for
these
weeks
ago.
So
please
take
a
look
at
that
and
I
think
we
try.
What
we
are
trying
to
resolve
is
previously.
We
have
two
different
series
community
meeting
for
about
the
fourth
at
least
three
four
time,
zoom
right,
so
it
put
some
challenge.
Sometimes
people
could
not
join.
F
I
think
there
is
not
a
perfect
way
for
us
to
have
a
single
meeting
to
meet
together,
so
we
have
some.
We
only
actually
put
two
proposals
here.
One
is
to
combine
our
organization
into
a
single
community
meeting
series,
but
that
it
makes
difficult
for
like
beijing
folks
to
join.
I
think
it
is
too
late
once
daylight,
seven
switch
again.
It
will
to
yeah.
It
went
to
23
right
you're
too
late
for
us,
so
the
another
option
is
steer,
keep
two
session,
but
each
station
will
be
the
bi-weekly.
F
Why
change
to
bi-weekly
is
because
previously
we
have
our
first
or
third
vehicle
months
for
one
series,
another
two,
the
second
and
the
fourth
week
for
another
time
zone
series,
but
that
will
face
a
problem
if
the
first
week
is
start
from
wednesday.
So
we
will
have
two
community
meetings
one
week
in
the
second
week,
so
we
we,
we
may
think
change
to
bi-weekly
we'll
keep
things
simple.
E
Yeah,
I
I
think
I
think
it's
become
pretty
clear
that
there's
not
one
time
that
works
every
week
for
everybody.
I
think
the
other
problem
is
that
like
right
now,
for
example,
we
have
the
two
meetings,
the
the
meeting.
That's
you
know,
noon
us
eastern
time
is
very
convenient
for
for
me,
but
pretty
much
impossible
for
beijing,
but
then
the
beijing
centric
time
is
convenient
for
you
and
still
possible.
E
For
me
you
know
it's
not
perfect,
but
it
works
and
I'm
thinking
maybe
it
makes
sense
to
take
the
u.s
centric
time
and
make
it
like
say
two
hours
earlier.
That
way.
You
know
it's.
The
beijing
team
may
not
come
every
time,
but
if
it's
at
you
know
10
pm
or
9
p.m,
instead
of
midnight.
E
F
E
Beijing
people
to
come
for
those
alternate.
You
know
u.s
centric
weeks,
but
it's
not
so
early
that
it's
impossible,
because
we
also
have
it's
it's
a
little
bit
different
now,
because
dave
is
not
actively
joining
all
the
time
like
he
was
before
because
he's
in
california,
which
is
three
hours
earlier
than.
H
E
So
the
if
we
were
to
make
the
u.s
centric
meeting
two
hours
earlier
than
it
currently
is,
it
would
be
at
nine
o'clock
or
say
ten
o'clock
for
me.
F
E
For
for
dave
and
for
fong
who's,
also
on
the
us
west
coast,
the
this
current
time
slots
actually
better,
because
this
is
in
a
late
afternoon
for
them.
F
E
So,
basically
take
you
know,
keeping
the
beijing
centric
time
sun
meeting
as
it
is
because
I
think
that's
probably
the
best
combination
that
allows
both
groups
to
meet
at
the
same
time,
but
for
the
u.s
centric
meetings.
If
we
move
it
say
two
hours
earlier,
that
would
allow
people
in
beijing
to
join
if
they
needed
to
it
wouldn't
be
convenient,
but
it
would
be
possible.
You
know
if
there
was
an
exception
where
you
know
you
want.
F
E
E
Make
sense
to
do
the
bye
week.
You
know,
I
still
think
one
meeting
a
week
is
still
probably
better,
because
I
think
if
we
do
two
a
week
where
we're
meeting
with
different
times
that
that's
going
to
be
harder
for
people
to
schedule
around
just
because
there's
I
don't
know
that
we
need
that
many
meetings
I
mean
I
mean,
but
yeah.
F
E
I
guess
just
thinking
in
my
in
terms
of
my
own
participation,
for
example.
If
I
know
that
I've
got
a
nighttime
meeting
twice
a
month
and
a
daytime
meeting
twice
a
month,
I
can
most
months
manage
to
make
all
of
them.
But
if
it's
a
nighttime
meeting
every
tuesday
more
I'm
gonna
miss
more
of
them,
but
there's
more
often
we
have
meetings
so
that
may
be
okay,
in
other
words,
right
now,
when
we
alternate
twice
a
month.
E
H
E
You
know
just
because
it's
easy
enough
to
schedule.
You
know
block
out
that
evening
twice
a
month
for
me,
but
it's
not
during
normal
working
hours.
So
it's
probably
not
something
I'd
be
able
to
do
every
single
week.
E
Yeah,
I'm
thinking
keep
the
same
first.
Third,
second,
fourth,
and
we
do
you're
right.
We
do
need
to
figure
out
a
way
to
schedule
it
so
that
when
the
first
of
the
month
is
a
wednesday,
we
don't
have
this,
because
you
know-
and
there
may
be
a
way
of
doing
that
with
google
and
time
zones
to
sort
of
fix
that
or
even
do
the
one-off
change
like
we
did
last
month,
where
we
just
move
the
meetings.
E
You're
right,
it
makes
no
sense
to
have
you
know
back-to-back
meetings
one
week
and
then
no
meeting
the
next
week,
but
that's
kind
of
a
calendar
problem
rather
than
a
scheduling
problem.
I
mean
we
need
to
figure
it
out,
but
but
I
think
one
meeting
a
week
is
probably
still
the
appropriate
frequency.
I
think,
having
two
meetings
a
week
and
you're
going
to
have
people
choosing
which
meetings
they
go
to
and
it's
going
to
be
harder
to
get
everybody
together
at
one
time,
but.
H
E
Do
think
that
it
might
make
sense
to
move
that
u.s
centric
meeting
time
a
couple
hours
earlier.
I
I'd
like
to
hear
some
feedback
from
people
on
the
west
coast.
The
only
people
I
think
that
regularly
attend
from
that
time
zone
now
would
be
fong
and
sometimes
dave
I'd
like
to
hear
their
feedback
on
this.
If,
if
they
haven't.
E
E
F
E
My
thinking
is
that
we
can't
make
one
time
that's
convenient
for
everybody
every
week,
but
if
we
can
make
it
work
twice
a
month,
it's
convenient
for
you
and
twice
a
month.
It's
only
slightly
inconvenient
for
you.
You
know.
That's.
F
E
Twice
a
month
that
you
can
know
you'll,
be
there
every
time
and
twice
a
month
if
you
need
to
be
there,
if
there's
something
you
want
to
discuss,
if
you
want
to,
you
know,
make
an
effort,
you
can
do
it
yeah,
but
there's
no
expectation.
You
have
to
be
there,
but
you
have
the
option,
whereas
right
now
twice
a
month,
the
beijing
team
pretty
much
can't
be
there,
because
it's
a
midnight,
you
know
that's
not,
except
that's,
not
reasonable.
F
E
And
orlan
will
be
there
as
well,
because
and
again
right
now,
that's
the
issue
right
now.
Is
this
time
slot.
You
know,
orland
can't
come
because
it's
three
in
the
morning
where
he
is
in
bulgaria,
so
we
still
have
to
have
one
meeting
twice
a
month.
That's
a
time
slot
that
he
can
participate
in
and
that
the
the
moving
of
the
us
centric
one
two
hours
earlier
would
be
perfectly
fine
for
him,
because
that
puts
it
closer
to
the
middle
of
his
day.
Anyway.
H
F
Is
all
that
is
a
better
choice?
I
think
your
proposal,
maybe,
is
still
the
better
choice
yeah.
So
let's
get
the
other
maintenance
or
other
folks
to
feedback
on
this.
So
yeah.
E
E
E
F
G
Yeah
thanks
julie,
and
I
think
we
have
done
the
to
this
meeting
and
thank
you
for
your
time.
Everyone
and
have
a
good
day,
and
I.