►
From YouTube: Velero Community Meeting - Oct 27, 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
folks
today
is
october
26th
and
it's
the
valera
community
meeting.
Let
me
share
my
screen,
so
we
can
all
look
at
the
same.
Let's
see
sure,
can
everyone
see
the
the
agenda
great.
As
a
reminder,
please
add
yourself
as
an
attendee.
If
you
have
not
done
so
and
I'll
put
the
link
in
the
chat,
handy
access
so
for
status,
updates
dave
would.
C
Yeah,
so
let's
see
so
what
are
we
doing
so
item
snapshotter?
I'm
gonna,
try
and
get
that
reviewed
with
everybody
this
week
and
there
haven't
been
any
any
real
comments
on
that.
So
get
that
in
hopefully,
and
still
working
on
the
upload
progress.
I
think
I
got
deletion
included
with
the
new
item
snapshot
or
apis,
and
this
week
I
am
on
support.
So,
okay.
A
Thank
you
any
any
questions
for
one
kai.
A
Looks
like
daniel
is
writing
his
update,
actually
just
while
daniel's
doing
that
it
occurs
to
me
that
we
have.
Is
it
worthwhile
to
perhaps
introduce
we
have
some
new
folks
forgiving?
If
I
missed
this
introduction,
but
we
have
some
new
folks
at
vmware
working
on
valero,
so
it
might
make
sense
to
do
introductions.
A
Oh
good
bruce,
why
don't
you
go
first.
A
You
on
the
spot,
just
a
very
quick
introduction
if
you'd
like
or
maybe
you
don't
need
to
it's
up
to
you,
but
we've
got
scott
here
and
also
fung
who
are
outside
of
vmware
and
they're
frequent
attendees
of
the
meeting.
So
it
might
be
nice
for
or
you
know,
actually
sorry
you
don't
have
to
produce
yourself
if
you
like,
I
realize
this
is
recorded,
so
we
don't
know
who's
going
to
be
watching.
E
A
A
E
E
My
chinese
name
is
junction,
so
come
you
by
which
name
you
you
prefer
I'll,
be
fine
with
those
okay.
Then
I
before
I
join
vmware.
I
work
for
several
public
cloud
providers
in
china,
for
example
the
jd
cloud
and
the
kingsoft
cloud,
and
my
experience
is
mainly
focusing
on
the
kubernetes
service
pro
spanish
extension
and
some
customized
on
the
public
or
the
private
cloud
service.
A
F
F
And
let's,
lastly,
I
have
introduced
myself
so,
and
maybe
there
is
some
somebody
not
here
so
I
will
introduce
myself
again
and
my
name
is
chomin,
which,
which
you
can
you
can
remember
my
name
and
it
is
pronounced.
Like
a
true
man,
I
love
I
like
the
movie
to
miss
world.
You
can
call
me
truman.
Okay
and
my.
F
I
worked
at
the
alibaba
cloud
and
before
and
in
the
machine
learning
platform,
and-
and
I
also
I'm
doing
some
work
about
the
kubernetes
and
docker
development
and
in
the
in
the
alibaba
cloud
I
have
you.
I
have
seen
a
lot
of
components
in
our
platform
such
as
contour
and
harbor
and
and
others
and
velero,
et
cetera,
and
all
of
these
that
come
from
vmware.
That
is
a
very
amazing
things,
so
I'm
very
proud
of
and
come
to
this,
this
amazing
amazing
company
and
the
amazing
team-
and
that's
all
that's
all
I
I
can.
A
Thank
you
bill.
Thank
you
so
much
both
for
being
here
and
you'll
you'll
see
them
around
a
fair
amount.
More
so.
C
A
Yeah
and
sorry
for
putting
me
on
the
spot,
it's
8
p.m.
In
my
time,
I
don't
think
it's
clearly
so
back
to
our
usual
status
updates
daniel.
Do
you
want
to
let
us
know
what
you've
been
working
on.
H
Yeah,
I
I
have
been
supporting
the
community
issues
last
week
and
yeah,
I
found
the
situation
that
people
are
using
very
old.
Valero
versions
are
still
writing
writing
up
issues.
H
So
I
see
eleanor
added
up
the
discussion
topic
as
for
the
super
matrix,
so
we
can
discuss
that
later
and
this
week
I'm
working
on
the
aws
plugin
to
support
csi
volume
snapshots,
and
I
will
also
try
to
bump
up
goal
1.17
to
fix
cv
and,
hopefully,
level
reach
this
module
graph
pruning
to
reduce
some
unnecessary
dependencies.
A
Bless
you,
okay,
so
first
first
topic
then
I
brought
up,
although
I
think
that
it
was
a
conversation
kind
of
with
daniel.
So
I
believe
that
for
azure,
the
azure
plug-in
incrementals
are
not
enabled
by
default,
and
so
we
we
have
someone
here
asked
for
sup
or
sorry,
maybe
they're,
not
increment
added
at
all,
it's
impossible
to
sorry.
I
should
prepare
more.
I
think
it's
that
right,
that
we
can't
do
increments
at
all
with
the
azure
plug-in
and
the
question
is:
do
we
want
to
enable
that?
But
can
someone?
C
That's
pretty
much
it
I
mean,
I
think
it's
pretty
much
a
flag
because
incrementals
are
introduced
after
valero
was
originally
written
the
quest,
so
this
is
just
internal
to
azure.
It's
not
anything
where
we're
going
to
see
it.
I
think
the
question
like
daniel
says
here
is:
what's
the
trade-off,
why
is
it
that
azure
just
didn't
enable
these
everywhere.
I
I
No,
it
was
actually
some
steven
where
add,
support
for
incremental
snapshots
of
azure
disks.
The
commit
from
june
of
2020.
C
Yeah,
I
don't
remember
that
I
mean
that
was
before
I
started
actually
to
be
here
all
the
time.
I
think.
I
J
J
I
A
I
H
H
To
reference
that
pr
you're
talking
about-
and
we
can
continue
discussion
in
this
issue
because
I
I
I
added
that
comment
based
on
my
discussion
with
beyond
the
bridget-
I
I
recall
and
yeah,
because
we
are
curious-
why
this
is
not
enabled
by
default,
because
it's
not
generic
enough
to
apply
to
all
cloud
providers.
I
I
I
think,
that's
what
we
talked
about
bridges.
I
I'm
I
mean
the
other
providers
already
had
incremental
support
in
the
plug-ins.
Okay.
C
Yeah
I
mean
because
this
is
all
internal
right,
so
the
vsphere
plug-in
is
different,
because
the
way
that
we're
handling
the
data
movement-
but
this
is
just
internal
to
azure
block,
and
the
other
thing
is
that
we
need
to
use
this
in
order
to
change
block
tracking.
So
if
we
as
we
move
forward
with
being
able
to
extract
data,
we're
going
to
have
to
use
these
anyway,
otherwise
we're
going
to
have
to
do
full
backups
every
time
of
the
of
the
disks.
So.
C
C
C
A
Actually,
just
a
quick
I'll
make
kind
of
an
announcement,
or
it's
not
really
a
discussion
topic.
Our
valero
writer
has
been
on
leave,
but
now
she
will
be
coming
back
november
1st.
So
if
we
have
documentation
things,
we
are
likely
to
be
able
to
kind
of
maybe
do
a
bit
of
a
push
to
improve
overlay
or
documentation.
So
bye.
A
So,
just
specifically
for
this
one,
it
sounds
like
we
could
potentially
yeah.
If
we
have
a
an
issue,
we
can
definitely
create
a
doc
issue
so
that
she
could
help
with
that.
H
C
C
C
A
Great
well
daniel,
thank
you
for
bringing
this
highlighting
this
because
yeah
that
we've
all
learned
that
this
and
thank
you,
scott
for
remembering
this
yeah
amazing
thanks.
H
A
Okay,
so
the
next
item
also
thank
you
again
to
daniel
for
this
item.
We've
talked
about
it
a
little
bit,
but
it
would
be
good
to
bring
up
now
with
now
that
he
and
others
on
the
team
have
more
context.
A
The
question
is,
of
course,
what
versions
of
valero
do
we
want
to
kind
of
support
from
a?
I
don't
know
what
to
call
community
support
perspective,
not
from
the
literal
code,
what
works
with
the
code,
but
what
do
we
want
to
support
and
or
sorry
rather
and
then
that's
relevant
really
to
kubernetes
versions?
H
Yeah
the
background
is,
you
know.
After
joining
this
team,
I
found
we
don't
have
a
clear
definition
regarding
the
support
metrics.
There
are
two
dimensions
I
can
think
about.
First,
what
versions
of
valero
should
we
support?
H
Second,
what
versions
of
kubernetes
do
we
support,
because
we're
constantly
saying
getting
issues
from
community
users
saying
I'm
using,
for
example,
below
1.1,
on
kubernetes
1.15?
And
let's
see
this
issue,
it's
not
realistic
for
us
to
support
all
these
combinations.
So
I
wish
to
propose
we
narrowed
down
the
support
scope
in
per
internally
discussion.
We
want
to
support,
like
n
minus
one
version
of
bilateral
and
n
minus
two
versions
of
kubernetes,
that
is
to
say,
for
example,
right
now
we
released
the
level
1.7.
H
H
We
will
not
go
further
to
digging
into
this
issue.
We
just
ask
him
to
upgrade
and
see
if
he
can
reproduce
this
issue
and
similarly
for
kubernetes.
So
we
support
three
recent
release:
minor
versions
of
kubernetes,
for
example,
1.2121
1.2,
that's
for
now.
I
I
would
I
would
be
careful
on
the
communities.
I
think
the
n
minus
one
makes
sense
on
valero.
The
thing
with
kubernetes
is
that,
especially
when
people
people
are
trying
to
get
off
old
versions,
kubernetes
one
of
the
last
things
they
need.
You
know
the
last
thing
you
do
before
you
decommission
a
kubernetes
cluster
is
possibly
back
everything
up,
which
means
you
know,
you're
going
to
want
to
run
valero
on
that.
I
So
I
know
in
the
past
the
approach
we've
taken
and
aside
from
not
documenting
well
enough,
which
we
need
to
do
is
basically
you
know
we
would
support
a
certain
version
until
something
changed
in
the
code.
That
says
we're
not
going
to
do
this,
and
then
we
made
an
explicit
decision.
Like
you
know,
we
we,
I
guess
the
most
recent
thing
was
the
crds
are
now
you
know
some
of
the
validations
in
crds
doesn't
work
with
kubernetes.
I
think
it's
1
11
and
older,
so
it's
112
and
later
that
we
had
been
supporting.
I
There
was
some
concern
when
we
went
to
the
v1
crds
that
we
would
drop
all
support
for
older
versions,
but
we
ended
up
instead,
creating
the
split
so
that
the
v1
beta1
and
the
v1
crds
were
created,
and
that
was
to
support
kubernetes
between
1,
12
and
115..
I
So
I
I
don't
know
the
best
way
of
kind
of
no,
you
know
knowing
when
to
bring
that
forward.
I
mean,
as
I
said
in
the
past,
I
know
we
basically
said
we'll
support
it.
Until
something
comes
up
that
we,
you
know,
doesn't
work
and
then
we
change
the
support
for
the
next
release.
You
know
if,
if,
for
example,
bolero
1.8
adds
some
features
that
would
be
difficult
to
support
on
kubernetes
114,
then
that
might
be
the
point
that
we'd
say:
okay
at
least
115
and
later.
H
I
I
I'm
not
sure
the
answer.
I
think
you
just.
We
need
to
be
careful
about
not
making
it
too
narrow.
I
don't
know
if
there's
also
some
some
some
value
in
defining
kind
of
level.
You
know
saying
you
know
this
is
a
version
that
we
definitely
support.
You
know
we
guarantee
it
works
and
then
maybe
there's
a
range
of
versions
that
it's
you
know
we'll
try
to
support
kind
of
best
effort,
but
we
can't
guarantee
it
and
then
there's
a
certain
version
that
we
know
don't
work.
I
When
we
say
look,
we
know
111
doesn't
work
at
all.
You
can't
even
install
it,
don't
even
try.
You
know,
112
or
whatever.
Maybe
there's
certain
versions
that
we
can't
guarantee
support
on,
because
we
don't
test
fully
on,
but
it's
known
not
to
break
or
it's
not
known
to
break.
Rather
I
I
just
again
the
concern
is
if
we
have
a
situation
where
people
can't
use
valero
to
back
up
their
workloads
to
move
to
newer
clusters
that
that
kind
of
becomes
a
barrier
to
using
valero
for
them.
H
I
And
that's
even
an
aggressive,
even
with
one
seven
is
an
issue
because
I
think,
with
one
seven,
even
with
the
automated
in
the
end
in
tests,
we
only
do
what
116
and
newer
116
to
122.
I
think
so,
even
there,
I
guess
the
question
is
for
115.
C
I
I
J
I
C
I
C
I
think
we
will,
because
you
know
we
we
definitely
are
on
the
hook
for
that,
but
you
know
we're
not
so
somebody
who's
on
the
paid
support
is
going
to
come
by
and
say
hey.
This
thing
needs
to
work,
we're
going
to
be
like
yes,
we're
going
to
do
that
I
mean,
and
I
think
we
also
have
to
be
thinking
about
not
breaking
things
like
the
breaking
changes
that
are
obviously
breaking
changes.
We
need
to
be
careful
about
right.
I
think
daniel's
concern
is
just
that.
You
know
you
know.
C
I
Right
exactly-
and
you
know,
on
the
red
hat
side,
we're
kind
of
in
some
of
that
situation
too,
because
we're
using
bolero
for
these
you
know
open
shift
three
to
four
migrations
with
openshift
3
is
kubernetes
111.,
it's
out
of
support
for
valero.
I
So
I
know
that
you
know
if
we
get
a
customer
for,
for
you
know,
mtc
migrations
and
and
valero's
braking
on
the
the
on
the
threes
cluster
side,
that's
kind
of
on
us
to
fix,
not
us,
meaning
the
red
hat
team,
not
the
valero
team,
because
it's
something
we're
knowingly
using
out
of
support
at
this
point
because
we
started
on
it.
But
that's
the
decision
we
can
make
because
it's
a
product
that
we're
giving
to
customers
based
on
valero.
I
But
you
know
when
you're
talking
about
what
valero
as
a
project
as
a
release
supports.
That's
a
more
you
know,
that's
something:
you're
testing
and
you're
gonna
say
hey.
If
you're
using
this
version,
it's
supported.
You
know
it
needs
to
work,
and
I
don't
know
if
there's
room
to
make
these
other
distinctions
again.
Where
you
know
there
may
be
certain
combinations
that
we
think
will
probably
work
but
you're
on
your
own
versus
other
combinations
that
we
we
just
know
right
off
the
bat
it
won't
work,
don't
even
try.
C
K
A
What
could
we
just
be
explicit,
basically
say
something
like
we
test
valero
on
the
there's
two
things
that
come
to
mind.
One
is
if
someone
asks
for
help
like.
Is
there
a
certain
version
of
kubernetes,
where
we
say
you
have
to
upgrade
to
this
minimum
version
of
kubernetes
before
we'll
investigate
your
problem
and
two,
do
we
want
to
be
explicit
about
what
versions
we
test
on
like,
instead
of
saying
it's
supported
or
not,
could
we
say
either
both
of
those
things.
C
Yeah,
I
think
we
could
say,
certainly
do
the
latter
and
we
should
be
opening
up
like
the
test
results
because
we're
starting
to
actually
do
testing
and
we
actually
have
results.
We
can
output
at
this
point,
so
we
know
which
platforms
and
which
versions
we've
tested
and
if
we
can
have
other
people.
You
know
running
like
indian
tests,
for
example
against
those
during
the
release
process,
and
you
know
other
platforms
that
we're
not
covering
internally.
I
think
that
would
be
really
useful.
We
maybe
have
like
a
a
place
where
that
goes.
H
Yeah,
but
that
still
came
to
the
situation.
For
example,
when
we
release
1.7
the
user
use
1.7
to
back
up
his
workload
on
kubernetes,
say
1.14
can
see
some
issue.
Do
we
want
to
fix
that
or
not?
We
should
fix.
C
I
mean
it's
it's
going
to
be
like
because
I
I
think
you
know
there's
the
very
good
point
that
we
we
need
to
support
quite
a
ways
back.
I
mean
migration
and
some
people
just
haven't
upgraded,
but
then
it's
like
yeah
there's
this
new
feature
that
we
added
that
doesn't
work
on
114..
Sorry,
you
know,
that's
you
know.
Is
it
important
for
us
to
fix
that
that
feature
for
114?
I
don't
know
and
yeah.
I
I
I
thought
it
was
just
116
and
a
newer,
maybe
not.
I
Right-
and
that
goes
back,
you
know,
is
there
room
for
a
situation
where
we
say
this
is
this?
Is
you
know
this
is
what
we
test.
There's
some
range
outside
of
what
we
test.
It
should
work,
but
you
know
we
don't
have
the
resources
to
test
all
the
time
and
therefore
that's
a
little.
You
know
kind
of
the
gray
area
there.
H
A
I
I
So
you
kind
of
need
this,
the
kind
of
two-dimensional
matrix
to
show
for
each
release,
which
versions
it
was
tested
with,
because
when
you
come
out
with
a
new
bug
fix
release,
even
that
might
change
the
number.
You
know
the
testing
matrix
and
certainly
one
seven
versus
one
six
versus
one
eight.
You
know,
there's
gonna
be
different
versions.
It's
been
tested
with.
H
I'm
thinking
does
kubernetes.
The
community
has
any
have
any
support
policy
like
a
certain
version
of
grenades,
is
out
of
support
you're
only
wrong.
H
I
mean
I
mean:
does
kubernetes
has
any
support
policy,
for
example,
1.12
is
out
of
support?
Do
they
have
any
support
policy
like
this.
K
Yeah,
I
I
ever
heard
that
they
maybe
have
this
such
policy
to
support
a
four
recently
released
like
that.
Maybe
we
can
confirm
this.
A
Anyway,
yeah
probably
best
not
to
research
on
the
fly
yeah.
Well,
let's
put
this
way,
so
it
sounds
like
we're
all
feeling
pretty
good
about
this
idea
of
n
minus
one
for
valero
releases,
and
if
someone
is
below
n
minus
one,
we'll
ask
them
to
upgrade,
but
we
can
still
publicize
that
pr
to
get
feedback
before
we
do
this.
I
absolutely
agree
with
scott
and
dave
that
a
chart
of
of
releases
versus
what
they're
tested
on
is
excellent.
I
think
this
last
bit
about
is
someone
says:
hey.
A
I
have
this
problem
with
1.14
help
me.
I
guess
for
now
what
dave's
saying
kind
of
makes
sense?
If
it's
like
a
huge
breaking
change,
maybe
we
would
deal
with
it
if
it's
a
oh,
this
specific
feature
doesn't
work.
We
may
not
it's,
but
I
also
hear
daniel.
I
hear
what
you're
saying
it's
much
nicer
to
be
able
to
just
say:
hey
you've
got
to
upgrade
your
well
yeah
that
no.
A
H
A
How
about
this,
could
we
say
something
like
if,
if
you're
trying
to
regularly
run
valero
on
this
version
of
kubernetes
and
below
we're
not
going
to
support
it,
if
you're,
if
you're,
only
trying
to
migrate
or
or
upgrade,
then
maybe
we're
basically
like
functionality,
that's
for
a
specific
migration
or
upgrade.
We
may
be
more
willing
to
support
to
scott's
point
to
let
them
get
off
of
that
version
of
kubernetes,
but
if
they're
regularly
trying
to
run
valero,
that's
what
we're
not
going
to
support.
A
I
I
I
And-
and
you
know,
but
you
know
if
we're
saying
that
163
is
supported
for
112
and
older
and
newer
and
once
in
one
seven
is
you
know
for
1,
15
and
newer.
Just
you
know
116
a
newer
that
would
give
you
a
path
there,
but
then,
once
one
eight
comes
out
now
we
no
longer
have
a
supported
valero,
for
you
know:
kubernetes
114.
A
Here's
another
question,
though,
can't
we
make
our
support
policy
more
narrow.
This
is
community
best
effort
support.
Even
it
makes
it
a
lot
easier
for
for
the
maintainers
and
for
the
community,
the
support
community
to
kind
of
more
carefully
or
more
quickly
go
through
issues
and
focus
on
the
ones
that
are
kind
of
easiest
to
I
don't
know,
but
but
then
like.
If
someone
I
don't
know,
I
guess
that
then
I
think
that
they
can
always
push
back
and
say
please
I'm
in
a
real
pic.
You
know,
like
I'm,
really
stuck
on
this.
A
I
I
don't
know,
and
that's
what
I
think,
the
distinction
between
you
know
this
probably
works.
We
didn't
test
it
because
it's
not
part
of
our
you
know
we
don't
have
the
bandwidth
for
that
versus
the.
We
know.
This
won't
work
because
we
added
code,
that's
incompatible
with
this
version.
You
know
that,
and
that
goes
back
to
you
know,
probably
what
you
would
tell
a
vmware
customer
that
you're
supporting
valero
with
a
you
know
with
a
support
contract
is
going
to
be
a
little
bit
different,
because
then
you
dedicate
resources
to
that
customer.
C
That's
and
we
might
cut
them
a
new
release,
we
might
cut
them
like
1.3,
you
know
1.1.2,
because
that's
what
they
have
installed,
that's
what
works
for
them
and
we
have
to
do
a
minor
patch
to
that
it's
possibility.
So
I
think
one
of
the
important
things
is
like
the
guidance
for
ourselves
as
we're
developing.
C
As
you
know,
like
we
had
this
discussion
last
time
about
hey,
do
we
introduce
a
breaking
change
with
the
new
crds
and
it's
really
good
and
it's
we're
probably
going
to
have
other
breaking
changes
and
some
of
them
we're
not
going
to
know
we
broke
stuff,
so
we
probably
need
to
have
a
policy
of
like
picking
like
a
baseline
version
that
we
expect
things
to
at
least
work.
You
know
pass
the
ed
tests
on
and
continue
to
run
against
that
and
any
breaking
changes
would
have
to
be
approved.
I
Yeah.
Well
then,
that's
where,
if
you,
if
we
add
something
you
know
and
you're
doing
that
you
know
the
indian
test
that
they're
they're
suddenly
failing
on,
say
kubernetes
116,
then
we
can
make
the
decision.
Well,
you
know
hey
velar,
when
it's
coming
out.
Is
it
okay
now
to
drop
support
for
116,
or
do
we
still
do?
We
need
to
find
a
way
to
do
this
new
thing
without
breaking
it?
But
if
you
have
tests
that
that
break
on
you,
then
you
can
have
that
conversation
before
the
release.
C
I
That
also
goes
back
to,
I
guess
my
previous
point
of
you
know,
rather
than
having
an
inflexible,
you
know
n
minus
two
or
whatever
is
that?
Let's
you
know
we
have
this
notion
what
we
support.
We
shouldn't
take
something
off
the
support
with
a
new
version
without
good
reason-
and
you
know,
a
new
feature
is
a
good
reason.
If
we-
and
it
may
be-
you
know,
look
it's
taking
too
long
to
run
tests
now
that
kubernetes,
you
know,
128
is
out.
We
don't
really
need
to
be
testing
on
12
versions.
I
Let's
take
some
off
the
end
here.
That
would
make
sense
as
well,
but
again
those
kinds
of
decisions
for
future
versions,
and
now
that
we
define
what
we're
supporting
for
say,
one
seven,
then,
when
one
eight
comes
out,
we
can
have
that
conversation.
You
know,
okay,
we
now
have
two
new
kubernetes
releases
that
one
seven
didn't
support.
I
Do
we
have
a
larger
set
of
releases,
we're
testing
against,
or
do
we
need
to
narrow
that
down?
Because
it's
too
many
to
support
or
or
if
there's
some
feature
that
says,
we
really
have
to
narrow
the
support
because
we're
adding
something
to
support.
You
know
a
new
18419
feature
that
doesn't
work
on
kubernetes
1
16..
A
We're
kind
of
putting
into
words,
I
think
what
you're
saying.
Forgive
me
if
I
missed
the
last
details
so
that
we've
already
talked
about.
I
B
I
You
don't
have
the
v1
crds
and
there
will
be
similar
things
in
the
future.
Where
something
happened
you
know,
kubernetes
introduces
a
breaking
change
that
we
need
a
new
valero
version
to
accommodate,
which
means
the
older
valera
version
will
no
longer
work
on
on
that
newest
kubernetes.
H
H
I
J
I
Know
that
112
is
absolute
minimum
to
even
install
valero,
because
our
crds
one
won't
work
with
111.,
but
112
to
115
is
kind
of
this
gray
area
of
it
will
probably
work,
but
it's
not
tested
with
our
automated
testing.
A
Okay,
so
what
I
would
suggest
is,
I
think,
I'm
really
glad
we
have
this
conversation,
so
I
think
right
where
I
document
and
now
I
will
say
making
the
these
tables
is
actually
going
to
take
a
lot
of
time,
especially
this
well
we'll
see.
Maybe
I
would
suggest
like
write
document
and
fill
in
easy
to
know,
values
and
then,
basically,
in
terms
of
we'll
get
the
sense
of
what
we
are
considering
showing
we'll
have
the
pr
done
and
if
and
if
we
all
agree
that,
yes,
this
is
what
we
want
to
communicate.
A
A
I
J
I
That's
something
we
we
should
be
able
to
say.
You
know
we're
already
running
tests
on
these
versions.
You
know
up
through
kubernetes
122,
for
example.
We
know
to
work.
You
know.
A
I
I
had
one
other
question
in
terms
of
support:
we're
saying
n
minus
one
so,
for
example,
one
seven
zero
and
one
six
three,
but
are
we
still
supporting
162
or
161,
or
do
we
only
support
the
most
recent
I
mean.
How
does
how
does
that
work
within
a
series?
You
know
if
I'm
on
one
six
one
one
six
two
comes
that
one
six
three
comes
out
at
one
point:
one:
six
one
cease
to
be
supported.
H
I
Begin
through
does
that
mean
we
only
support
the
latest
patch
version
for
each
or
do
we
support
I'm
just
thinking.
You
know.
Valero171
comes
out
next
week,
three
days
later,
a
bug
comes
in
for
170
someone's
on.
Do
we
say
you
know
dragon
171?
We
don't
support
one
seven
zero.
After
one,
seven
one
comes
out.
H
H
A
Yeah,
okay,
so
then,
and
then
okay,
so
in
that
case
we
will
support
any
patch
release
within
the
supported
window
within
the
supported
range.
A
Okay,
good,
thank
you,
scott
for
raising
that.
I'm
glad
that
we
can
kind
of
get
this
discussion
going.
Okay.
So,
as
I
mentioned
one
we'll
work
on
this,
probably
once
in
november,
once
our
doc
doc
writer
returns
okay.
Well,
that
was
a
long
discussion,
but
again
I
really
found
that
really
valuable
thanks
folks,
frankie
hello.
G
A
G
What
do
you
want
to
talk
about?
Well,
I
had
so.
I
had
so
much
success
getting
people's
ideas.
Last
time
I
thought
I
might
repeat
it.
This
is
for
a
different
issue.
This
is
for
when
a
backup,
storage
location
is
deleted,
remove
associated
backups
and
rustic
repos
from
the
cluster.
So
I
have
a
summary
of
what
I
thought
they
wanted
towards
the
bottom.
G
Yes
here,
so
my
understanding
of
this
is
that
when
they
do
the
command,
valero
backup
location
delete
with
the
bsl
name,
which,
by
the
way
was
implemented
with
lara
1.6.
Then
they
would
like
these
two
things
to
be
deleted:
associated
backups
and
associated
rustic
repositories.
Now
carlesia
commented
that
a
bsl
is
only
a
representation
of
storage
and
deleting
it
will
never
delete
the
backups
uploaded
to
that
storage.
G
This
is
intentional
okay,
but
she
also
suggested
that
maybe
a
forced
delete
of
backups
associated
with
bsl
when
the
bsl
is
deleted
is
okay
so
to-
and
I
also
mentioned
that
nolan
suggested
that
maybe
we
could
work
on
issue
2697,
which
is
related
to
restores,
but
I
kind
of
don't
think
they're
they're
not
close
enough
to
work
on
together,
especially
with
the
design
I'm
proposing.
So
if
we
go
to
the
next
section
my
proposed
design,
I
was
thinking
instead
of
a
force
hold
on.
C
C
C
C
I
I
And
and
I
think
part
of
the
computer,
I
think
we
need
to
be
careful
because
there's
a
lot
of
things
going
on
here,
the
things
that
the
back
delete,
backup
request
deals
with
it
sounds
like
those
are
things
that
are
not
in
the
cluster,
but
in
the
actual
back
you
know
the
s3
bucket
or
whatever,
and
then
the
backup
storage
location.
So
when
you
delete
a
backup
using
delete
backup
request,
we
actually
remove
those
ones.
G
C
I
I
That
means,
when
I
create
a
backup
and
cluster
one,
the
sync
controller
in
cluster
two
creates
you
know
the
valero
backup
resource
in
cluster
two,
I
do
my
backups
from
cluster
one.
I
restore
them
to
cluster
two,
I'm
done
with
cluster
with
this
backup
storage
location
in
cluster
one
now,
so
I
delete
the
backup
storage
location,
but
I
still
have
these
valero
backups
and
other
resources.
I
G
I
G
G
Resource,
not
the
json
files
that
were
created
during
backup
that
have
been
uploaded
to
s3.
Okay,
I
need
to
rewrite
my
idea,
so
thank
you.
That
was
very
helpful.
I
definitely
got
confused
between
the
backup
json
files
that
are
in
s3
versus
the
backup
resources
that
are
only
in
the
kubernetes
cluster,
all
right
I'll.
C
C
I
And
not
only
that,
but
and
and
all
those
backups
that
are
still
there,
you
end
up
getting
your
valero
log
files
filled
with
this
backup.
Storage
location
is
not
found
every
time
you
know
it's
iterating
over
those
backups.
G
I
It
would
be
the
rest
of
the
again
the
kubernetes
resources,
so
that
would
be
the
odd
volume
backups
I'm
guessing
and
pod
volume
restores
would
be
what
we're
talking
about.
G
I
Again,
we're
just
deleting
kubernetes
resources
here,
not
you
know
we're
not
touching
the
s3
bucket
or
azure
or
whatever.
You
know
that,
whatever
the
you
know,
the
external
storage
is.
G
G
C
C
I
Because,
again,
basically,
another
way
of
looking
at
this
is
that
anything
you
delete.
When
you
remove
the
backup
storage
location,
I
imagine,
would
just
come
back
automatically
if
you
re-add
the
backup
storage
location,
because
when
you
add
the
new
backup,
storage
location,
if
you
know,
if
you
add
it
back
the
sync
controller,
the
backup
scene
controller
sees
all
this
stuff
and
puts
it
back.
I
Sees
those
and
says:
oh,
you
have
backups
there
that
aren't
in
my
cluster
I'm
going
to
create
these
things,
and
so
the
kubernetes
resources
get
created
so
anything
that
you're
deleting
cleaning
up
when
you
delete
the
backup
storage
location
should
come
back
automatically.
If
you
were
to
re-add
that
that
would
be
a
good
test
case
to
make
sure
you
did
the
right
things,
anything
you
remove.
I
You
know
when
you
delete.
It
should
come
back
when
you
re-add
that
backup
search
location
again.
G
Makes
sense,
I
think
I've
seen
that
happen
personally.
I
G
Right
for
for
me,
the
way
I've
seen
it
is:
I've
created
a
brand
new
cluster
installed,
valero
hooked.
J
G
I
was
gonna
just
if
it
was
simple.
I
was
just
gonna
make
a
comment
saying
my
design,
but
if
you
wanted
to,
if
you
wanted
me
to,
I
can
just
make
a
pr
with
the
simple
design.
J
G
Okay,
yeah
yeah
sure
I'll
go
ahead
and
put
a
my
design,
an
md
file.
A
Awesome
great
well
frankie.
Thank
you
so
much
for
bringing
this
up,
and
I
think
this
is
exactly
what
we
want
the
community
meeting
to
be
for
is
kind
of
talking
through.
So
thank
you
that
was
really
great.
I
already
covered
this
so
fun
plug-in
versioning.
J
Yeah
I
want
to
continue
working
on
that
to
hopefully
drop
it
up,
maybe
sometime
in
the
next
few
weeks.
So
I
want
to
keep
up
with
bridget.
L
Yeah
I'm
available
to
spend
some
time
on
I'll
ping
you
we
can
set
up
some
time,
I'll,
put
you
on
slack
tomorrow
and
then
maybe
we
can
set
up
a
session
to
to
go
through
this
and
come
up
with
a
plan.
Okay,.
L
A
A
Okay
yeah,
so
we
got
nine
minutes
left
any
other
issues.
People
want
to
bring
up.
A
Cool,
I
think
we're
not
doing.
I
don't
even
quite
know
how
we
do
community
shout
outs.
Am
I
right,
though,
that
maybe
we'll
wait
for
jonas
to
do
it
next
week,
since
it
looks
like
nothing
is
prepared
here,
okay!
Well,
everyone
have
a
great
evening
or
morning,
depending
on
where
you
are
and
we'll
see
you
all
another
time,
all
right.