►
From YouTube: Velero Community Meeting/Open Discussion - July 14, 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everyone
and
welcome
to
the
valero
community
meeting
open
discussion
today
is
a
very
very
special
day,
because
this
is
the
first
time
we're
doing
it
in
the
beijing
time
zone.
So
super
super
excited
to
start
this.
This
series
of
community
meetings
we're
doing
the
community
meetings
for
valero,
where
we're
scheduling
them
on
a
bi-weekly
rotation,
so
the
first
and
third
tuesday.
We
have
it
in
the
americas,
time
zones
so
and
then
the
second
and
fourth
tuesday
or
wednesday.
A
If
you're
in
beijing
wednesday
morning,
we
have
it
in
the
beijing
time
zone
so
super
exciting,
and
I
want
to
thank
everyone
for
for
joining
today.
Super
excited
to
have
you
all
here
we're
going
to
run
this
as
a
the
regular
belaru
community
meeting
so
same
thing
on
every
week,
so
we're
going
to
go
through
some
status
updates,
we'll
do
some
discussion
topics
and
then
we'll
do
shout
outs.
A
So
if
you
have
anything
that
you
would
like
to
talk
about
any
status
updates
that
you
want
to
bring
up
to
the
team
things
that
you
feel
are
important
to
share
with
the
the
larger
team
and
the
larger
community
and
things
that
you
want
to
discuss
as
well
with
the
larger
team
and
the
larger
community,
please
add
them
to
the
hacking
d.
Also,
please
add
your
your
name
and
affiliation
to
the
hackmd
there,
it's
very,
very
useful
for
us
all.
There
we
go
all
right,
so
we're
going
to
start
off
with
some
status
updates.
B
Yeah
I
I've
been
working
on
a
new
feature
called
valero
debug,
which
helps
the
communication
between
developer
and
user,
and
so
user
can
use
this
command
and
collect
the
log
bundle
to
easily
fund
all
the
log
files
in
one
turbo
and
send
it
to
a
developer
I'll.
Do
a
quick,
walkthrough
and
demo
later,
and
one
thing
I
didn't
mention.
I
also
enabled
the
stale
bot
in
the
bolero
ripple
such
that.
A
Daniel
we
had
some
discussions
around
the
stale
bot.
I
think
it's
great
to
have
that
implemented
and
yeah
essentially
get
rid
of
old
issues
that
no
one
is
responding
to.
So
I
think
it's
a
great
feature.
Thank
you
for
that
all
right.
Next
up
we
have
bridget.
C
Hi
everyone
so,
as
I
mentioned
in
last
week's
meeting,
that
I've
spent
the
majority
of
the
last
week
catching
up
on
community
support
and
responding
to
various
issues,
slang
discussions
and
so
on
them
that
we
haven't
been
keeping
up
with
recently.
So
I
think
we're
all
mostly
caught
up
tonight.
So
thanks
everyone
for
for
your
patience
there.
While
we
get
through
that,
aside
from
that,
I'm
now
preparing
for
the
valero
162
release,
so
that's
a
link
to
the
milestone
there.
C
It's
not
going
to
be
a
very
big
release.
It's
mostly
just
some
build
script.
Changes
to
your
lie
to
allow
us
to
customize
the
registry:
that's
used,
so
we
can
customize
the
the
registry
that
valera
will
attempt
to
pull
from
by
default,
and
we
can
configure
that
at
build
time,
and
but
it's
also
going
to
include
some
security
fixes
as
well,
which
various
members
of
the
community
have.
Let
us
know
about
so
hope
to
get
that
out
this
week.
A
D
I
have
enabled
the
ut
test.
I'm
gonna
have
action
for
the
pull
request.
We
test
several
versions
of
kubernetes
provided
by
client,
but
but
I
I
I
saw
some
red
random
case
failure.
D
Currently
I
will
look
into
this
issue,
so
if
you
got
it
get
it
get
this
culture
get
this
issue,
you
can
just
rerun
the
job
and
pass
the
checking
and
the
next.
We
will
set
up
several
jenkins
public
to
do
some
regular
e2
testing
to
cover
more
providers
and
scenarios
and
we'll
add
more
test
cases.
A
Me
awesome,
so
is
this
building
upon
the
the
work
that
you
did
here.
D
B
Okay,
one
question:
so
currently
we
are
not
setting
those
github
actions
as
mandatory
right.
What's
the
right
one,
I
mean
you
don't
need
to
pass
all
the
interim
tests
to
murder
pr
right
yeah,
but
but
we
wanna,
you
know,
make
those
on
the
criteria
for
merging
the
pr.
A
Right
awesome
next.
E
Up
dave,
yeah
still
working
on
upload
progress:
oh
hey,
my
camera's
stuff,
yeah,
still
working
on
upload
progress,
fighting
with
go
and
we're
working
on
release
planning.
For
you
know
the
one
seven
release
as
well
as
162.
A
A
Okay,
yeah
sounds
good
all
right.
Does
anyone
have
any
other
status
updates
that
they
want
to
share.
F
Sorry
just
a
comment:
I
would
like
to
thanks
bridget
to
spend
the
many
efforts
to
support
the
community.
I
think
there
is
a
lot
of
questions
and
in
dislike
and
github
issue,
that's
all
and
as
well
as
dania
and
wink.
I
also
spent
many
efforts
in
the
past
week
to
review
the
issues
in
github,
so
I
think
many
of
the
issues
are
already
being
updated
by
them
yeah.
I
would
like
to
thank
them
for
that
effort.
B
So
you
can
see
my
screen
right.
The
google
doc.
B
Okay,
so
this
is
the
draft
of
the
design
that
I
plan
to
transform
into
a
markdown
and
a
red
have
a
pr.
So
the
goal
of
this.
B
Valero
debug
command
is
to
help
user
easily
collect
a
log
of
different
components
of
valero
and
the
resources
that
are
helpful
for
debugging
to
help.
You
know
simplify
the
communication
between
the
letter,
user
and
developer
because
oftentimes
the
user
open
an
issue
and
they
collect
some
logs
and
developers
tell
them
now.
We
need
more
and
back
and
forth
back
and
forth.
So
this
is
a
shortcut.
The
user
can
run.
This
command
collect
everything
that
should
be
helpful
for
developer
to
debug
the
issue.
B
As
for
the
content
or
information
to
be
collected,
we
will
try
to
collect
the
deployment
locks,
rustic
demon
set
locks
and,
if
user
specify
the
backup
or
restore,
will
also
collect
the
definition
of
the
specified,
backup
or
restore
resource
logs
and
additional
resources
such
as
bsl
pulse
volume,
backup
al
volume
resource.
B
B
That's
essentially
is
a
color
for
a
starlark
script,
which
is
a
dialect
of
python,
so
you
can
write
a
starlock
script
and
there
are
some
internal
function
to
help
you
communicate
with
this
kubernetes
api
and
collect
logs
and
run
commands
or
collect
the
definition
of
different
objects.
B
B
So
that's
overall
how
it
works
in
details.
We
we
can
implement
an
option
to
you,
know:
trans
translate
the
parameter
of
a
valero
command
line
to
the
arcs
that
we
pass
through
crafty
and
then
use
those
values
to
control
items
we
want
to
collect
and
how
we
collect
them.
B
One
tricky
thing
is
a
quick
config
because
of
the
layers
cr
in
the
layer
cry
we
allow
user
to
set
the
path
to
config,
as
well
as
the
context
at
the
same
time,
because
we
use
client
goal
and
it
respects
it.
Honors,
the
environment
variable
and
all
the
default
values,
but
that's
not
how
crash
d
works.
B
As
far
as
I
know,
I'll
crash
the
procrasti,
you
need
to
pass
the
a
path
of
the
coup
config
to
the
function,
to
make
sure
it's
used
for
the
subsequent
cause
to
the
kubernetes
api
server.
So
the
way
we
wanna
make
the
parameter
in
the
lateral
works
for
crash
d,
we
plan
to
generate
a
temporary,
quick
config
file
based
on
the
user,
setting
and
feed
it
to
the
crafty
and
after
the
command
ends.
B
We
remove
the
file,
but
there
is
some
I
mean
they've
mentioned
that
we
may
want
to
update
crafty,
that's
an
option.
I
will
talk
to
them,
but
I
don't
want.
This
feature
depends
on
the
merging
the
pr,
because
I
expect
there's
a
lot
of
back
and
forth,
because
there
are
other
tools
depending
on
crash
d,
and
if
we
change
the
way
is
triggered,
there
may
be
some
pushback.
B
Yeah
yeah,
but
but
that's
not
how
crazy
works.
I
need
to
look
into
the
code,
but
yeah
that's
an
option.
I
would
say
I
already
have
an
issue
and
we're.
E
Gonna
do
security
problems
right
with
writing
the
user's
credential
out
to
a
file,
even
if
it's
only
temporary.
B
But
but
we
do
not,
I
mean
we
do
not
expose
new
stuff
because
those
information
already
on
user's
file
system.
E
If
it's
like
in
their
environment
or
we're
running
like
inside
of
a
container
where
we're
picking
it
up
from
like
the
cluster
environment,
I
I
wouldn't,
I
don't
think
no.
B
No,
no,
I
I
know,
but
but
that's
maybe
the
only
way
to
make
things
work,
and
I
would
like
to
point
out
it's
not
happening
in
the
container.
It's
in
it's
acting
as
a
it's
a
it
happens
on
the
client
side,
it
works
as
a
client
of
the
coordinates
api
part
of
the
valero
say
all
right.
B
I
understand
I
understand
the
concern
yeah
yeah-
I
thought
about
this,
but
currently
this
may
be
the
only
way
I
would
talk
to
the
crash
team
maintainer
and
see
how
things
goes,
but
the
progress
may
be
very
slow.
I
think
keep
things
in
the
valero
command
line
is
the
way
that
is
more
manageable
because
we
own
that
ripple
yeah.
I.
B
E
B
E
B
Because
user
may
may
modify
the
contacts,
but
incorrectly
you
cannot
set
the
contacts
in
the
coup
countries.
You'll
only
read
the
default
one
yeah
so.
E
B
It
I
understand,
but
we
will
see,
I
mean
we
have
some
options
to.
You
know
talk
to
the
crafty
maintainers
and
see
how
they
think,
but
yeah
probably
we
add
an
optional.
I
mean
an
optional
parameter
to
specify
the
context.
Probably
that's
acceptable
to
them.
Let's
see,
okay,
so
the
plan
for
the
implementation.
I
will
first
pump
up,
go
and
embed
the
startup
script
and
implement
the
command
and
add
android
and
test
so
I'll.
Do
a
quick
demo.
B
Okay
yeah,
so
it
supports
currently
three
additional
parameters.
The
output
is
the
path
of
the
bundle,
turbo
and
the
the
backup
and
restore
where
you
set
the
name
of
the
backup
or
restore
object
and
the
logs
of
this,
and
I
can
use
this
command
valero
debug.
I
set
a
a
backup
so
that
it
will
collect
this
log
of
this
backup
and
all
this
default.
B
All
these
resources
and
running
now
this
is
output
of
crash
d.
B
B
Unfortunately,
the
path
is
a
little
bit
long,
because
this
is
how
crazy
works.
I
create
this
temporary
directory
on
the
operating
system
and
it
collects
everything
in
this
folder
and
the
turret,
but
I
think
that's
good
enough,
for
you
know,
debugging
and
yeah
here
are
all
the
logs,
and
you
know
the
information
that
collects
by
the
crafty.
B
So
we
can
easily
update
the
crashly
script
and
to
make
it
collect
more
resources
as
needed.
One
tricky
part
is
also
read
by
dave,
so,
which
is
also
a
good
point,
is
how
we
collect
the
log
of
vsphere
plugin,
based
on
my
understanding,
most
of
other
plugins.
All
the
parts
are
running
inside
of
the
level
namespace,
but
with
fear
plugin
is
not.
It
has
a
really
tricky
scenario.
B
Crazy
yeah,
yeah
yeah,
so
ideally
user
issues
some
combined
and
to
this
guy
it
may
also
collect
you
know
lots
of
these
guys.
We
can
push
it
to
the
v-sphere
plug-in
developer,
but
I
think
that
will
make
them.
E
I'm
not
as
concerned
about
yesterday's
supervisor,
but
even
just
in
a
regular
cluster.
We
wind
up
with,
like
the
the
scale-out
data
movers
and
the
backup
driver
running
in
its
own
pod.
So
what
would
be
you
know?
I
was
thinking
that
we
could
just
make
a
mechanism
where
the
plugins
could
return
another
starlock
script
that
we
just
run.
I'm
not
sure
how
to
do
that.
Well,
though,
since
we're
on
the
command
line
and
the
plugins
running
over,
maybe
it
just
maybe
it
just
writes
it
out.
E
You
know
it
doesn't
have
to
be
dynamic
right,
so
maybe
it's
just
something
that
it
writes
into
the
the
container
directory
or
something
when
they
come.
E
Have
the
same
thing
I
think,
like
open
ebs,
for
example,
has
its
own
kind
of
a
fan
out
thing,
so
it'd
be
nice
if
we
could
make
it
a
generic.
B
Okay,
yeah
yeah
I'll
double
check,
I'm
not
sure
if
we
can
trigger
another
startup
script
within
one.
Maybe
you
can
use
the
sql
file
or
function
in
python,
but
I
need
to
take
another
look
yeah.
I
will
start
the
conversation
with
the
with
your
plugin
team
and
try
it
yup.
That's
my
part.
Any
comments.
I
I
have
a
quick
question
here,
my
baby,
so
basically
the
level
will
run
some
script
to
them
to
clear
down
the
custom
and
everything
right
so
does
that
currently
in
the
whatever
already
or
you
have
to
enhance
that
or
to
run
the
script,
and
what
is
the
concern
about?
B
I
don't,
I
don't
think
the
hacker,
I
don't
think
the
hacker
can
have
higher
privilege,
because
first,
if
you
want
to
interact
with
kubernetes
api
server
to
do
any
destructive
action,
you
need
a
certain
role
in
kubernetes
and
you
need
a
config
file.
That's
the
key,
you
know
to
do
it
and
even
we
provide
this
script
in
plain
text
and
make
user
run
and
it
doesn't,
you
know,
increase
this.
Would
I
say,
attack.
E
Whoa
the
possibility,
because
the
idea
being
that,
if,
if
you're,
able
to
override
the
script
somehow
and
then
when
the
user
runs
the
valero
command,
they
run
a
bad
script
with
their
credentials
right
phone.
B
Correct
we're
using
this
going
bad
mechanism,
so
it's
in
the
binary.
So
it's
not
easy
for
user
to
modify.
I
I
I
B
E
A
So
that
is
good.
Do
you
want
to
share
your
screen,
or
should
I
pull
it
up
here.
I
Yeah,
could
you
pull
up
the
issue
that
I
I
I
raised
this
issue
last
week
in
an
informal
way,
and
then
I
fired
the
bus
and
after
looking
to
it
a
little
bit,
I
I
saying
that
the
the
priority
class
is
is
a
coconut
class.
It's
not
like
a
cid
like
a
customer
crd
or
something
so
when
a
part
is
using
it
and
if
the
destination
cluster,
where
it
being
restored,
doesn't
have
it,
it
will
cause
a
problem.
I
So
my
my
my
point
here
is:
I
I
think
we
should
fix
it
in
available
both
instead
of
like
a
plug-in
to
handle
the
case,
because
not
only
for
this
rarity
class,
but
I
think
we
can
make
it
general
enough
so
that,
if
an
entity
like
a
part
or
deployment
referring
to
some
cluster
resource,
just
a
scope
resort,
we
should
backing
it
up
as
well.
I
If
that,
if
that
is,
if
the
the
flat,
including
cluster
resource,
is
set
to
new,
because
that's
the
you
know
the
way
we
design
the
the
function
of
that
class
is
that
if
it's,
if
an
entity,
including
some
known
resort
cluster
resort
type,
you
should
include
it
in
the
back
up
right
and
in
this
case
clearly
that
price
gp
class
is
not
a
cd.
This
is
a
it's
a
kubernetes
class,
so
we
should
include
it.
J
J
Here's
an
example
where
you
know
you
can
look
in
the
spec
and
the
spec
calls
for
this
kind
of
association
that
we
can
follow,
but
I
still
think
they're
all
one-off
cases
that
we
have
to
identify
here's
a
case
where
kubernetes
resource
references,
another
kubernetes
resource,
that's
cluster
scope.
We
need
to
handle
this.
I
think
you
can
make
the
argument
that,
because
these
are
kubernetes
core
kubernetes
resources,
bolero
core
should
handle
it
rather
than
a
you
know
third-party
plug-in,
then
each
person
that's
using
this
would
have
to
write
and
then
it's
an
implementation
detail.
J
I'd
say
whether
if
we
decide
that
valero
core
should
handle
this,
we
might
implement
that
as
a
you
know,
backup
item
action,
plugin
that
is
in
the
main
villara
code
base,
or
we
might
put
it
in
backup.go,
but
that's
an
implementation
detail
at
that
point,
but
I
don't
think
there's
a
generic
way
to
say
anything
that
we're
backing
up.
That
has
a
reference
to
anything,
that's
the
clusterscript
resource.
I
think
we
have
to
actually
identify
a
pod
spec
in
this
field
might
reference
something
that
this
is
the
type
let's
handle
it.
J
Those
are
all
kind
of
one-off,
I
think,
but
if
they're
all
core
kubernetes
types
that
anyone
using
valero
would
run
into,
I
think
you
could
make
the
case
that
valero
core
should
handle
it,
but
I
still
think
we'd
have
to
individually
implement
those
on
a
case-by-case
basis.
Starting
with
this
as
one
example.
I
The
I
I
the
main
thing
was
that
that
the
the
the
authority
class
is
is
a
part
of
a
kubernetes
core
right.
So,
whether
it
is
you
know,
one
off
that
we
should
handle,
or
we
should
make
the
little
code
it
can
eric
enough,
so
that
it's,
including
all
of
the
cluster
resources
that
being
used
by
any
entity
and
add
that
into
the
into
the
you
know,
part
of
the
main
main
data
path
is
the
backup.
I
I
still
lean
toward
that.
I
You
know
if
it
is
a
core
class,
we
should
include
it
in.
However,
I
I
haven't
looked
into.
I
Because
I
know
for
sure
that
if
we
hit
like
if
we
hit
like
pvc
right
and
we
will
dig
out
a
pb
right-
this,
which
is
a
cluster
scope
right
and
then
so
on
and
so
forth.
So
the
same
thing
with
the
you
know:
cluster
role,
binding
and
all
that.
I
J
Yeah
yeah,
I
I
I
think
I
think
you're
right
in
terms
of
what
should
be
handled.
I
actually
agree
with
you
that
this
is
something
that
we
probably
should
put
into
valero.
I'm
not
aware
of
a
generic
way
of
doing
this.
The
examples
you
gave
which
valero
handles
are
handled
specifically
by
looking
at
pvs
and
pvcs
and
looking
at
you
know
those
specific
resources
and
places
we
know
to
expect
them,
but
I
mean
the
the
intent
of
include
cluster
scoped
resources.
The
default.
You
know
nil
option
is
to
do
exactly
this.
J
You
know
because
if
you
say
true,
you
include
everything
in
the
cluster.
If
you
say
false,
you
include
no
cluster
scope,
resources
and,
if
you
leave
it
blank,
the
default
is
to
pull
in
things
as
relevant,
and
I
think
this
is
an
example
of
something
that
biller
probably
should
be
pulling
in
as
relevant.
If
you
can
come
up
with
a
way
of
doing
this
in
a
generic
way,
that's
great!
I
just
I
don't
know
of
a
way
right
now.
J
Valero
internally
has
several
backup
item
action
and
restored
item
action,
plugins
that
are
implemented
as
plugins
but
included
in
the
product,
because
you
know
we
need
to
do
this
for
all
backups
and
restores,
but
the
easiest
way
to
implement
it
may
well
be
to
write
a
plug-in
that
is
then
supported
in
the
valero
release.
So
that
is
a
that
is
a
kind
of
middle
ground
between
a
generic
solution
that
works
for
everything
which
I
don't
know.
You
know
if
exists,
and
a
third-party
plug-in.
That's
not
supported.
I
It
really
is
that,
in
the
way
that
we,
you
know
if
it
is
set
up
with
the
through
clarity,
I
mean
include
customer
role
as
software
resources.
J
J
J
It's
there
to
look
for
it,
there's
no
generic
way
to
valero,
hey,
find
everything.
That's
cluster
scope
that
might
be
referenced
by
something
in
your
backup,
because
these
are
all
specific
kubernetes
models
and
specific
resource
types
you
know
just
like,
for
example,
we
have
custom
code
for
crds
anytime
you're
backing
up
a
cr.
I
I
That
block
it
may
be
the
best
way
to
add
on
this
functionality
right,
because
otherwise,
that
will
have
to
know
every
single
kubernetes
core
ties.
You
know,
rp
class
is
one
of
them
right.
Otherwise
we
have
to,
and
each
of
the
this
time
the.
I
E
E
J
Exactly
that's
what
I
was
trying
to
say.
In
other
words,
I
think
you
want
to
distinguish
between
you
know.
Is
it
a
plug-in,
that's
an
implementation
detail
and
then
there's
the
requirements.
Question.
Does
this
belong
to
core
valero?
Should
valero
do
this
thing
and
I
think
the
answer
is
yes.
Do
we
do
we
implement
it
by
writing
a
plug-in?
That's
part
of
core
valero?
Maybe,
but
that's
an
implementation
detail.
E
J
Because
that
kind
of
gets
into
this
thing,
yeah
exactly
a
backup
item
action,
you're
right
but
but
but
rather
than
you
know,
putting
it
as
a
you
know,
third-party
plug-in
not
supported
separate
container.
It's
something
that
I
think
I
think
belongs
in
core
valero,
but
probably
implement
it
as
a
backup
action
stack.
You
know
like
a
vitamix.
E
E
Right
so
I
guess
the
only
the
only
thinking
would
be
you
know:
do
users
expect
that
if
they
back
up
and
restore
these,
you
know,
is
this
priority
class
going
to
get
restored?
What
happens
if
one
already
exists?
E
Those
kind
of
things
would
be
something
to
think
through
right.
I
mean.
J
If
one
already
existed
that,
I
think
the
generic
valero
answer
applies.
If
it
already
just
you
know,
we
we
don't
do
anything
with
it.
We
leave.
What's
there,
I
think
part
of
what's
going
on
here
is
that
the
documentation
around
include
cluster
and
cluster
scope.
Resources
is,
if
you
leave
it
blank,
then
conceptually.
That
means
backup
cluster
scope,
resources
that
are
related
to
namespace
resources,
which
is
what
this
is
wow.
It's
analogous
to
a
pv
to
a
crd,
yeah.
J
I
J
Registers
it
and
then
that
can
be
reviewed
as
a
you
know,
vr
that
does.
B
A
K
Yeah
so
excuse
me
genting
and
scott,
and
I
and
bridget
were
having
a
bit
of
a
discussion
about
v1
and
v1
beta
1
support,
and
it
occurred
to
me
we're
all
here,
so
it
might
be
best
just
to
talk
in
person
since
it
looked
like,
we
were
diving
into
deeper
details,
the
very
short
that
I
understand
and
then
I'll,
let
genting
or
scott
or
bridget
say
more
actually
does
do
any
of
you
want
to
just
start
by
the
explanation,
because
I
think
you
all
have
more
context
than
I
do.
J
Okay,
so
basically,
the
issue
is
that,
right
now
for
all
of
our
crds
we're
using
the
v1
beta
1,
crd
definition,
v1
has
been
available
since
kubernetes
116
and
when
122
comes
out,
the
v1
beta
1
disappears,
which
means
the
crds
as
we've
defined
them
in
valero.
1
6
will
not
be
installable
and
we
can
write
it.
J
It's
122.,
the
simplest
thing
to
do
would
just
be
to,
and
you
know,
in
addition
to
changing
the
v1
beta
1
to
v1,
there
are
certain
crd
changes
in
terms
of
fields
have
been
moved
around
and
multiple
version
support.
Most
of
that
you
know
the
framework
is
generating
that
for
us
anyway.
But
the
point
is
the
actual
crd
file
on
disk
is
going
to
be
different.
The
simplest
solution
is
just
to
make
everything
v1
only
and
abandoned
support
for
b1
beta
1..
J
The
downside
to
that
is
valero
163.
If
that's
where
we
introduced,
this
will
no
longer
be
installable
on
kubernetes,
115
or
older,
and
I
know
when
this
first
came
up.
Some
of
the
comments
from
I
know
what
I
mentioned:
that
we'd
actually
rather
have
a
larger
in
a
window
of
supported
versions
specifically
to
handle
the
case
of
migrations
where
people
are
getting
off
of
older
versions
and
moving
to
newer
ones.
The
downside
to
that
approach
of
adding
both
is
now
you
have
additional
testing
requirements.
I
know
the
helm
chart
in
particular.
J
Probably
we
would
have
to
be
viewing
only,
but
for
the
installer
we
could
introduce
in
fact
the
pr
that's
out
there
from
genting.
Now
it
actually
does
maintain
both
v1
beta,
1
and
v1.
Support
works
for
both
I've
run
into
n
tests
with
both,
and
you
know
it
works
that
way
again.
The
only
downside
really
to
that
is
additional
testing
overhead,
but
the
upside
is
you
now
can
maintain
that
support
all
the
way
back
to
112,
which
is
our
current
minimum
supported
version.
J
K
K
And
I
had
talked
about
this
when
bridge
helped
me
understand
the
ritual
originally,
and
it
felt
like
okay
with
this
additional
testing
burden
and
who
uses
such
old
versions
now
hearing
about
the
additional
users
who
might
need
to
do
those
older
migrations.
I
wanted
to
hear
what
folks
thought
and,
of
course,
those
of
you
who
are
working
on
the
testing
I'd
love
to
hear
what
additional.
E
E
J
We
actually
are
using
valero
out
of
support,
we're
actually
because
we
have
a
youth
customers
that
want
to
go
off
of
openshift
3
and
that's
kubernetes,
111
and
older,
and
we've
actually
just
modified
the
crds
for
those
three
clusters
to
remove
that
validation,
because
the
only
thing
that
you
know
actually
breaks
in
valero
right
now,
when
kubernetes
111,
for
example,
is
that
cod
validation,
we
pull
data
out.
It
doesn't
break.
J
J
J
Yeah,
I
would
agree
you,
you
don't
want
your
backups
to
no
longer
work
because
you
happen
to
be
moving
to
a
new
version
of
valero.
I
think
that's
something
we
do
want
to
be
testing.
I
don't
know
how
much
that's
being
tested
now,
but.
I
J
E
Yes,
but
I
think
that
that's
so
I
think
one
of
the
things
we
need
to
understand
is
are
people
you
know.
What's
the
expectation
on
the
lifetime
of
like
these
valero
backups,
you
know
our
default
time
to
live
is
30
days
so.
E
That's
something
that
plays
into
this,
but
I
I
would
prefer
to
handle.
I
think
we
need
to
handle
backwards.
Compatibility
of
the
backups,
that's
a
basic
expectation
and
we
can
make
a
decision
now.
You
know
we
can
always
drop
support
for
the
v1
beta1
crds
later.
But
the
question
is,
you
know:
are
we
going
to?
E
J
Yeah,
I
would
say
also
if
we're
treating
this
as
a
you
know,
this
is
a
163
it.
It
would
kind
of
worry
me
that
162
works
on
you
know
115,
but
163
doesn't
because
that
feels
like
the
kind
of
thing
you
want
to
break
at
a
major
release
correct,
but
you
know
that,
but
I
understand
this
is
a
one-off.
You
know
this
is
a
one-time
thing.
This
is
kind
of
a
big
deal
with
the
crd
change.
You
know
this
is
not
a
normal.
E
J
E
J
That
that
that
could
make
some
sense
I
mean
I,
I
know
that
was
one
thing
eleanor
asked
if
this
is
going
to
be
a
problem
for
the
red
hat
use
case,
and
I
was
going
to
say
we're
hitting
this
issue
for
our
migration
side
with
our
own
crds
too.
So
you
know
we're
wrestling
with
the
same
question
and
one
of
the
things
we're
considering
is
exactly
that
to
say.
J
Look
the
version
of
our
product
that
upgrades
to
the
v1
you
know
crds
is
not
going
to
be
supported,
for
you
know
open
shift
3,
but
for
the
migration
use
case,
the
source
cluster
needs
to
run
the
older
version
of
the
product
and
they
need
to
work
together,
which
is
kind
of
the
same
thing
in
your
case
of
the
backup
works.
But
we
don't.
I
J
Worry
about
restoring
so
that
that
would
make
sense
to
say,
and
also
by
the
time
one
seven
comes
out.
I
don't
know
that's
going
to
be
after
you
know,
kubernetes
123
is
out.
I
mean
if
you're
looking
at
the
number
of,
because
that
was
one
thing
that
concerned
nolan
had
at
one
point
was
one
of
the
comments
on
the
early
comments
on
this
issue.
Was
you
know,
there's
a
certain.
I
think
it
was
like.
He
didn't
like
the
idea.
Yeah.
K
J
So
you
still
have
that
issue.
That
again
was
this
is
this
is
just
concerning
nolan
rays,
it's
not
necessarily
a
valero
concern
as
a
whole.
He
was
saying
look.
We
only
have
six
kubernetes
versions
that
we
support
across
that
felt.
Like
a
small
number,
I
don't
know
again
how
valid
that
is.
I
mean
the
other
point
was
hey.
J
This
has
been
out
for
two
years,
so
anyone
on
you
know
115
is
on
a
two-year-old
version
of
kubernetes,
and
you
know
at
that
point
that's
more
of
a
migration
concern
than
a
backup
and
restore
concern,
and
as
long
as
we're
supporting
backups
there,
that
may
not
be
a
huge
problem.
E
J
That
also
gives
us
a
longer
time
window
to
sort
of
test
the
question
of
again
those
backups
working
in
the
newer
version,
yeah
and
again
and
again,
to
be
clear.
It
sounds
like
we
can't
do
that
for
helm
chart
so
for
helmsharp.
We
would
be
v1
only
just
because
it
sounds
like
in
that
case,
you
need
one
version
of
the
crds
that
you
install.
E
E
B
J
Oh
and
one
other
point,
I
would
add
this
of
some
relevance.
I
do
have
a
pr
out
there
that
updates
the
end-to-end
tests
to
support
running
with
either
v1
or
v2.
Basically,
it
adds
a
parameter
to
sort
of
pass
that
screw
so
that
you
could
run
the
end-to-end
tests
at
least
and
choose
okay
run
end
to
end
with
v1,
then
run
and
end
with
view
and
beta1,
and
it
runs
with
either
one.
E
J
And
I
would
say
one
other
point
about
the
testing
and
support
is
that
since
161
is
already
out
and
162
is
coming
up
soon,
that's
all
fully
tested
with
b1
beta1,
because
that's
what
that's,
what
we've
been
using
for
years
as
long
as,
and
so
the
concern
for
testing
right
now
is
just
does
do
these
does
the
same
code
that
works
with
b1
beta1
also
work
with
v1
crds,
because
that's
really
the
only
change
for
163
is
basically
using
supporting
v1,
crds
or
v1
beta1
crds.
J
J
I
don't
really
see
as
much
testing
overhead
there,
because
the
only
thing
that's
new
is
the
v1
option
and
that's
what
we
need
to
make
sure
works.
V1,
beta1,
crds
already
work
and
that's
not
being
changed.
J
J
Maybe
we
want
to
go
ahead
and
support
this
sort
of
dual
crds
that
and
genting's
pr
for
163,
but
by
by
the
time
one
seven
comes,
maybe
we're
ready
to
drop
b1
beta,
1
support,
and
that
gives
people
some
time
to
sort
of
adjust
to
that.
E
L
Need
to
add
instant
installation
if
the
cubase
server
is
available,
it
will
detect
the
cube
api
server,
preferred
it
scr
the
api
versions
yeah,
for
example
like
if
you
are
legal
and
one
day,
no.
L
I
believe
yes,
because
it's
related
to
the
frankly
the
feature
before
that
the
alvaro
will
choose
the
preferred
api
version
for
backup.
If
I
remember
correctly
frankie,
what
do
you
think.
E
So
here's
my
here's,
my
thinking
so
we're
going
to
install
either
v1
vr,
v1,
crds
or
possibly
v1
beta1
crds.
So
there's
going
to
be
kubernetes
clusters
that
don't
support
v1
right,
so
we're
going
to
install
v1,
beta1
okay
when
you're
at
the
command
line-
and
you
say
valero
backup
that
writes
a
cr,
but
it
has
to
write
the
correct
one
right.
Yes,.
J
C
Yeah,
so
when
you
create
a
cr,
it's
it
invokes
the
valero
api.
So
that's
the
it's
like
valero.io
v1,
that's
in
the
version
field.
J
J
Yes,
but
again
I
from
what
I've
seen
the
cr
itself
should
look
the
same
in
both
cases,
and
I
got
as
far
as
running
end-to-end
tests,
using
both
v1
beta1
and
b1,
using
kind.
So
you
know
skipping
the
ones
that
kind
skips,
but
other
than
that
things
were
successful
running
there.
J
I
think
it's
just
the.
I
think
the
only
thing
I
think
well,
I
know
there's
some
things
that
are
skipped.
I
think
the
only
thing
skipped
on
kind
are
the
the
snapshot.
You
know
issues
which
don't
really
interact
intersect,
a
whole
lot
with
the
valero
crs.
J
So
but
you
know
the
point
is
the
basic
kind.
You
know
backup
and
restore
with
rustic
and
then
the
the
kind
of
gbk
tests,
and
all
of
that
I
was
able
to
run
those
using
an
end
test
with
both
v1
and
v1
beta1
and
that
that
was
with
my
pr
that
I
added
which
allows
you
to
set
that
on
the
indian
tests.
J
K
So
I
assume
it
sounds
to
me,
I
I
mean.
Maybe
dave
is
saying
that
it
sounds
like
daniel.
Do
you
want
to
think
a
little
bit
more
about
the
testing
side
of
it
and
we
can
kind
of
maybe
continue
this
conversation
in
the
slack
thread?
Would
that
make
sense?
And
of
course
we
can
continue
in
two
weeks
when
we're
all
back
together
in
this
meeting.
B
At
least
we
should
test
only
b1
right.
If
that's
the
case,
I
think
that's
probably
doable.
If
ask
that,
there's
a
flag
to
control
it.
J
J
V1
is
what's
run
by
default,
so
if
you
instead,
if,
if
genting's
pr
is
merged
and
nothing
else,
changes
when
you
run
end-to-end
tests,
you'll
get
v1
with
my
follow-on
pr
again,
if
you
run
end
and
test
without
specifying
version,
you'll
get
b1,
but
you
could
also
run
into
n
tests
specifying
v1
beta1
as
the
crd
version.
J
So
you
can
show
that
you
know
the
end.
End
tests
run
successfully
both
using
v1,
beta1
or
v1,
and
I
would
say
again:
v1
is
our
priority,
because
that's
what
you
know
for
122,
you
have
to
have
and
v1
beta
what
only
really
matters
to
users
that
are
on
115
and
older.
J
Yeah
yeah
gentings
is
most
important,
but
yeah
I
mean
mine,
lets
you
run
into
nz,
so
I
would
want
those
both
together.
They
don't
they
don't
touch
the
same
files,
but
my
pr
has
to
have
his
merge
first.
Otherwise,
because
it
references
changes
that
he
made.
E
I
B
F
E
No,
I
think
we
need
to
test
both.
I
mean
if
it
doesn't
work,
we're
going
to
have
to
come
up
with
another.
So
so
the
the
reason
for
supporting
both
is
so
that
we
can
say
we
have
backwards,
compatibility
from
1634
or
163
with
both,
and
you
know,
if
you
can't
install
163
into
112,
then
it's
or
it
doesn't
work.
When
you
install
it
it's
kind
of
silly.
F
Okay,
with
that,
we
we
also
need
to
test
the
both
in
1.63
yeah.
J
I
think
so,
and
and-
and
I
think
part
of
that
too
is
we're
trying
to
get
160
released
soon,
and
you
know
it
would
be
nice
to
give
people
that
are
on
older
clusters,
some
warning
to
say:
okay,
163
works
for
you,
but
one
seven
may
not.
You
know
we're
deprecating
this
or
whatever,
and
I'm
not
sure
what
the
wording
is
here,
but
this
gives
them
some
time
to
sort
of.
J
You
know
decide
what
to
do
about
that,
because
one
seven
we're
saying
we
probably
won't
support
both
at
that
point,
although
I
don't
think
we've
made
a
final
decision
there,
but
I
think
for
163,
given
that
I
think
we're
trying
to
get
that
released
relatively
quickly.
It
would
make
me
nervous
to
say
we're
not
going
to
support
b1
beta
1
anymore,
especially
since
we
have
a
pr
that
seems
to
do
that
and
work
well
for
that,
but
again,
obviously
there's
the
testing
needs
to
make
sure
that
we
can
claim
that
it
actually
does
work.
F
Yeah,
I
should
assume
this
is
the
first
time
we
face
this
situation.
Maybe
in
future
we
will
still
have
many,
I'm
not
sure
many.
This
will
happen
again
due
to
the
kuvlini's
version
support.
So
this
is
a
practice
action
which,
firstly,
we
we
can
know
something
about
this-
that.
J
F
E
A
All
right
sure
we
wrap
up
this
discussion,
continuing
slack
with
the
with
the
notes
and
everything
here
awesome.
So
I
only
got
one
small
thing
and
then
some
shout
outs-
and
I
know
we're
over
time,
so
I
apologize
for
that.
Some
really
good
discussion
here,
though,
so
I
hope
you
all
enjoy
that
the
the
discussion
topic
that
I
have
is
around
maintainership
and
governance.
So
I
would
like
to
see
if
we
could
add
daniel
and
wankei
as
maintainers.
A
A
Regarding
the
governance,
we've
had
some
discussions
around
the
wording
in
the
governance
dock
and
starting
next
week,
essentially
I'll
see.
If
I
can
review
it
a
bit
see
if
we
can
reword
a
few
things,
make
it
a
little
clearer
make
it
a
little,
also
a
little
more
open
on
what
a
maintainer
agrees
to
do.
A
So,
instead
of
doing
all
of
these
things
that
we
currently
have
in
our
maintainer
description,
I
want
to
make
sure
that
we
can
say
you
should
do
some
of
these.
Maybe
you
have
other
other
responsibilities
within
the
project
as
well.
That
way,
we
can
open
it
up
for
more
maintainers
who
do
different
things
within
the
project
and
also
open
it
up
a
little
more
for
sub
project
maintainers.
If
that's
a,
if
that's
a
concept
that
we
want
to
go
towards
as
well,
but
I'll
open
up
a
pr.
A
So
we
can
have
discussions
around
this
again.
Changes
to
the
governance,
even
small
ones,
need
a
super
majority
agreement.
J
Just
just
a
quick
comment
on
that.
I
think
now
that
we're
talking
about
and
opening
up
to
kind
of
different
focuses.
A
K
Only
I
don't
know
I
mean
just.
I
know
that
damn
fung
is
maybe
new.
Sorry,
if
we
already
did
this
introduction-
and
I
was
not
paying
attention
but
dan
fung
is
going
to
be
working
more.
Maybe
do
you
want
to
introduce
yourself
because
it's
actually
perfect
with
scott
sleden,
not
that
she's
a
maintainer
yet,
but
she
has
a
similar
background
and
fun.
Am
I
putting
on
the
spot
or.
N
Yes,
yes,
I
will
responsible
for
maybe
on
some
ci
cd
and
e2e
test.
Yes,
and
also,
I
add
a
jinx
pipeline
for
security
check
and
it
works.
It
works
yesterday
and
I
I
will
show
the
re
report
to
to
to
team
members
yeah.
That's
awesome.
K
And
so
it's
really
cool,
so
dan
fung
is
was
on
the
harbor
team
for
the
past
few
years,
focusing
on
end-to-end
tests
from
what
I
understand
and
now
she's
moved
over
to
valero.
So
I
think
we're
gonna
see
a
real
increase
in
in
the
quality
of
our
testing,
which
is
amazing,
so
welcome
dan
from
and
you'll
probably
see
her
a
lot
more
around.
A
Thank
you
dan
pong,
and,
and
thank
you
eleanor
all
right.
So
last
thing
shout
outs,
so
the
we
got
four
shout
outs
here.
The
first
one
is
here
for
from
daniel
enabling
the
stale
bot
here.
So
thank
you
for
for
doing
that
really
appreciate
that,
as
we
talked
about
the
next
one
is
from
gentang
here,
upgrading
the
cluster
binding
to
use
the
v1
api
good
stuff
here
next
one
is
from
taric
who
created
within
the
helm,
chart
repo,
so
he
added
the
functionality
of
allowing
disabling
schedule
and
value
overrides.
A
So
when
you
have
a
multi-layer
environment,
you
can
disable
a
schedule
that
is
defined
in
a
comments,
values
file.
So
thank
you
for
that
taric
and
the
next
one
is
again
from
genting
here,
a
quote
string
in
the
palm
charts
fix
this
a
certain
thing.
I
think
this
was
we
talked
about
this
a
couple
of
weeks
ago
with,
in
a
in
an
earlier
shout
out.
A
This
one
from
fong,
thank
you
so
much
for
for
doing
this
one!
No!
We!
This
is
an
issue,
never
mind,
not
a
shout
out.
We
already
have
a
discussion
about
that.
I'm
getting
tired,
it's
late!
So
with
that,
thank
you.
Everyone
for
joining
have
a
fantastic
rest
of
the
week.
This
has
been
lovely
to
see
you
all
today,
the
first
valero
community
meeting
in
the
beijing
time
zone.
Thank
you.
Everyone
for
joining
have
a
fantastic
day.
Bye,
bye.