►
From YouTube: Velero Community Meeting - July 28, 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,
slash
open
discussion
today
is
july,
27th,
2021
and
per
usual.
We're
gonna
go
through
some
status
updates
and
then
have
discussion
topics
and
last
but
not
least,
do
some
shout
outs
as
well.
So
with
that
we
we're
going
to
start
off
with
dave.
B
Sure
what
did
I,
what
lies?
Did
I
write
there
so
bridget
and
I
merged
the
the
crd
changes
today.
Bridget
did
most
of
the
work,
so
that's
reviewed,
that's
in
I'll.
Let
her
go
into
that,
but
one
of
the
things
she
identified
was
that
uninstall
needs
to
be
updated
as
well
to
work
with
the
new
crds.
B
So
I'm
working
on
that
and
banging
my
head
against
the
wall.
I've
been
working
on
getting
the
item,
snapshot
or
plugin
together.
This
is
a
new
plugin
and
we
can
go
over
that
in
the
discussion
topics.
I
have
some
questions
there
for
for
people
and
I'm
on
community
support
this
week.
Yay.
A
All
right
next
up,
we
have
daniel.
C
Yeah,
I
just
want
to
thank
scott
for
the
review
on
my
pr
and
yeah
it's
merged
and
I'm
currently
working
on
the
implementation.
I
was
the.
C
Community
supporter
last
week
and
nothing
really
fun
just
a
bunch
of
regular
issues,
and
we
have
handled
that.
That's
my
problem.
A
Cool
question
for
you
during
the
community
support,
so
this
goes
out
to
yeah.
Everyone
is
doing
community
support
right
now.
If
there
are
any
specific
issues
that
you
find
during
the
week,
do
you
want
to
bring
them
to
the
community
meeting
to
discuss
as
well?
Would
that
be
worthwhile.
C
B
A
Make
this
work
okay,
basic
support.
Most
of
the
time
I
guess
yep,
okay,
yeah
sounds
good,
so
if
something
interesting
arises,
then
we'll
bring
it
to
the
community
all
right.
Thank
you.
Daniel
any
questions.
Comments
for
daniel
around
the
valero
debug
design.
A
You
said
you're
working
on
the
implementation.
Do
you
have
a
a
rough
timeline
of
the
implementation
there,
daniel.
C
I
think
it
can
be
ready
before
the
mid
august,
because
you
know
in
when
we
are
in
our
bu,
we'll
take
the
first
week
off
so
hopefully
by
the
mid
october,
things
will
be
ready
august.
Sorry,
maybe
august
things
will
be
ready.
This
has
some
dependency
on
crash
d.
I
have
talked
to
the
maintainer
of
crash
d
and
they
they
accepted
my
proposal
to
make
enhancement
so
that
it
will
be
more
easily
for
the
integration,
but
they
don't
have
a
hard
time
line.
So
you
need
to
double
check
in
all
this.
A
Thank
you,
daniel
next
step.
Forget
bridgette.
D
Hi
everyone.
So
this
week
we
got
out
v1.2.1
releases
of
the
aws
azure
and
gcp
plugins.
These
include
the
same
security
fixes
and
that
were
fixed
in
valero
162..
I
just
realized.
I
still
have
a
little
bit
of
work
to
do
there
and
update
our
documentation
to
reference
those
new
images,
but
they
are
there
and
they're
available
to
use.
I
spent
some
time
last
week
working
with
the
plug-in
versioning
huge
thanks
to
him
for
for
pushing
that
work
forward.
D
So
I
he
did
mention
he's
going
to
be
taking
some
leaves,
and
so
I
think,
I'll
try
and
pick
up
some
of
that
work
while
he's
out.
So
I
can't
thank
you
for
that.
D
Yeah
also,
as
dave
mentioned,
we've
been
working
towards
the
v163
release
this
week,
with
the
crd
fixes
also
huge
thanks
to
genting
for
for
making
sure
that
we
will
get
that
work
done
so
that
yeah
save
mention
got
merged
earlier
today,
and
then
I
think
this
week
we'll
be
doing
some
testing
and
getting
that
ready.
I
think
that's
it
for
me.
C
B
Test
cases,
I
think
we're
going
to
need
that,
because
I
think
because
bridget
already
tried
it
in
the
indian
test
of
failing
right,
because
the
uninstall
is
not
working.
D
Yeah,
so
the
the
the
issue
is
that
if
you
try
to
run
valero
uninstall
on
a
122
cluster,
it's
still
attempting
to
use
the
v1
beta
1
api,
which
doesn't
exist
up
in
the
122
cluster,
and
so
I
think
everything
else
is
fine
and
all
the
testing
should
work
for
everything
121
and
earlier.
I
think
it's
just
on
122.,
but
I
think
if
we
can
still
work
to
get
all
the
automation
and
everything
in
place,
then
once
dave's
fixes
in
then
those
tests
are
ready.
I
think
that'll
be
great.
So,
okay.
C
So
I'm
a
little
curious
so
so
I
I
think
we
will
need
to
wait
for
the
change
of
from
dave
being
merged
before
we
can
have
a
successful
end-to-end
right.
E
B
F
B
H
B
I
B
Yeah,
so
bridgette
did
a
kind
image
for
122
that
we're
using
for
testing
and
there's
some
details
in
the
slack.
But
that's
that's
where
right
now,
because
you're
using
the
rc
build.
D
A
Is
that
something
that
we
want
to
update
the
contributing
guides
with
make
sure
that
we
have
proper
kind
versioning?
And
things
like
that
as
well,
when
we
run
tests
like
that,.
D
So
the
reason
why
I
think
it
won't
work
at
the
minute
is
because
I
built
that
image
using
a
very
specific
version
of
kind,
but
I
think
whenever
you're
running
kind
and
its
release
notes
tells
you
for
the
version
that
you're,
using
which
image
to
pull,
and
it
will
kind
of
do
it
all.
It'll
pull
the
latest
one
for
you
like
automatically.
B
D
I'll
take
a
look
at
the
other
contribution
docs
to
see,
because
maybe
we're
like
pointing
people
to
a
specific
version
of
kind.
That's
not
going
to
work!
So,
yes,
we're
taking
a
look.
A
All
right,
okay,.
H
A
Awesome
that
sounds
great.
Any
questions
comments
for
wankei.
A
All
right,
scott
and
jin
ting,
just
a
quick
question,
if
you
have
any
status
updates
that
you
would
like
to
share.
A
B
We
have
just
been,
you
know
as
we
get
pr's
and
stuff.
Some
are
little.
B
Look
at
them
and
you
go
yeah,
I
know,
but
we've
been
getting.
You
know
some
pr's
where
it's
like.
Oh,
let's
change
this
functionality.
Let's
add
this
thing
and
we
haven't
really
gone
through
like
a
design
review
and
then
we
wind
up
with,
like
you
know,
back
and
forth
during
the
pr
you
know
where
you
have
to
like
figure
out
what
the
code's
doing
and
then
figure
out.
B
If
it's
a
good
idea,
that's
doing
what
it's
doing
so
daniel
said
that
you
know
on
harbor
they
they
simply
ask
people,
you
know
to
put
in
a
proposal,
and
I
think
that's
something
that
I'd
like
to
add
to
our
flow
and
just
say
you
know
if
it's
above
this
certain
complexity,
we're
going
to
ask
you
to
put
in
a
proposal
or
a
design
dock.
You
know,
depending
on
how
big
it
is.
B
But
you
know
just
just
have
these
things
come
in
early
on,
so
we
can
discuss
whether
it's
this
is
the
direction
we
want
to
go
in
before
we're.
Actually
at
the
point
of
looking
at
the
code
and
trying
to
figure
out
what
the
code
does,
how's
that
sound
for
everybody.
C
Yeah,
I
personally
think
we,
it
sounds
great
and
I
personally
think
maybe
we
should
do
it
a
little
differently
from
harvard,
because
in
harbor
there
is
a
another
ripple
that
people
need
to
push.
The
proposal
which
has
gonna
make
things
a
little
complicated
because
we
need
to
check
different
ripples.
I
think
for
valero.
Probably
we
just
follow
the
design
workflow.
We
just
asked
people
to
you
know,
write
a
pr
into
the
design.
I
B
B
Talked
to
anybody
here
about
anything,
but
we
made
a
bunch
of
changes
to
the
code
and
here
why
aren't
you
adding
these
right
away?
So
I
want
to
encourage
people
to
be.
You
know
if
they're,
if
they're
thinking
about
making
big
changes
that
they
should
be,
you
know,
involved,
run
them
past
the
the
community,
and
you
know
that
there's
no
surprises
for
everybody.
D
Yeah,
I
think,
maybe
for
some
of
the
changes,
even
some
of
them,
maybe
don't
even
necessarily
have
like
an
issue
associated
with
them.
I
think
even
that
would
be
like
a
start.
It's
like
here's,
an
issue
where
I've
talked
about
what
I'd
like
to
do
doesn't
necessarily
have
to
go
through
like
a
review
processor,
I'm
not
sure
like.
D
Maybe
maybe
we
want
to
have
like
a
slightly
lighter
weight
process
for
smaller
requests,
rather
because
sometimes
the
design
dog
could
feel
like
quite
quite
substantial,
and
quite
a
lot
of
effort
needs
to
go
into
it
and
maybe
that's
not
necessary
for
all
changes,
but
even
maybe
just
like
having
an
issue
using
like
the.
D
We
have
like
a
feature
request
like
format,
and
even
that
might
be
like
a
a
good
start.
I
don't
know.
B
Yeah,
I
think
we
can
do
I
mean
we
don't
want
to
have
like
a
heavyweight
process,
but
you
know
we
just.
I
think
we
just
document
that
you
should
do
this
and
then
that
gives
the
reviewer
a
chance
to
like
push
back
and
say
hey.
I
don't
understand
why
you're
doing
this,
let's
do
a
proposal,
at
least
for
this.
You
know
if
they
didn't
and
if
they
did,
then
you
know
we
can
move
it
on
through
that
way.
B
I
think
jonas,
can
I
share
the
screen
share
screen
because
I've
got
the
the
harbor
wording
up
here.
A
Yeah
for
sure
I
was
just
wondering:
do
we
need
to
change
any
the
small
parts
of
the
documentation,
I'm
guessing
probably.
B
Probably
the
documentation
so
harvard
just
says
here,
you
know
pr's
always
welcome.
You
know
it
says,
break
them
down
into
small
changes,
which
you
know.
We
don't
really
say
I
mean
you
know
it's
assumed,
but
it
doesn't
hurt.
And
actually,
where
is
the
proposal?
Part.
B
Oh
yeah,
if
there
will
be
a
significant
effort,
please
document
it
as
an
issue
and
get
a
discussion
going
before
starting
to
work
on
it.
So
something
along
that
line,
so
we're
not
going
to
get
terribly
formal.
Just
we
just
have
something
there
that
we
can
push
back
with
a
little
bit.
B
A
In
our
start,
contributing
documentation,
we
do
say,
create
a
having
a
high
level
design
document
as
like
the
number
one.
A
Yeah,
I
think
just
fleshing
that
out
a
bit
like
why
and
when
a
design
dock
is
needed,
smaller
pr,
not
needed
substantial
effort
needed.
B
Yeah
or
you
know
like
changes
in
functionality
flag,
you
know
yeah
yeah,
so
so
yeah,
so
basically
just
a
little
push
back.
You
know
so
that
we
are
able
to
con.
You
know
I
I
feel
like
we
get
hit
with
some
stuff
and
it's
just
like.
Why
aren't
you
merging
this?
It's
like?
B
Well,
I
don't
think
it's
a
good
idea
and
it's
like
we
don't
have
a
you
know
we're
not
really
in
in
the
process
of
discussing
the
idea,
or
maybe
I
don't
even
understand
the
code
I'm
like
trying
to
review
the
code
I'm
like.
Why
are
we
doing
this
so
anyway?
So
that's
what
I'd
like
to
do
so
I'll
make
some
changes
here
and
we'll
review
it
and
we'll
toss
it
in.
B
So
moving
right
along
so
my
other
topic
was
the
item
snapshotter.
So
this
is
the
api
I'm
working
on.
So
this
is
from
the
upload
progress
monitoring,
and
this
is
essentially
it's
like
volume,
snapshotter
and
moving
towards
backup
item
action.
So
right
now,
volume
snapshotter
handles
snapshot,
create
from
snapshot
and
delete,
backup
item
action,
does
backup
item
action,
there's
also
restore
item
action
and
delete
item
action
and
so
looking
forward.
We
want
to
be
able
to
work
at
the
kubernetes
level,
so
that's
what
this
will
do
and
it
makes
sense.
B
I
think,
to
pull
these
three
different
types
of
things
together
here.
So
backup,
item
action,
restore
item,
action,
delete
item
action
are
not
going
away,
so
those
will
remain
as
the
things
for
when
you're
like
modifying
kubernetes
resources,
but
if
you're
doing
something
that
takes
like
an
external
snapshot
outside
of
valero
item
snapshot
is
going
to
be
the
way
to
go
so
volume
snapshot
will
merge
into
this
and
the
existing,
so
the
csi
plug-in
and
the
vsphere
plug-in
are
both
using
backup,
item
action
and
actually
doing
snapshots.
B
One
of
the
requests
I
got
recently
was
on
restore.
We
pretty
much.
Do
each
volume
hpv
serially
and
you
know
it's
going
to
be
each
item,
so
I
wanted
to
kick
around
the
idea
of
adding
progress
on
restore
and
possibly
even
progress
on.
So
progress
would
really
be
on
create,
create
item
from
snapshot
and
also
possibly
progress
on
delete.
So
we
could
farm
the
deletes
out
faster,
any
thoughts.
You
know
why
that's
a
horrible
idea
why
it's
a
great
idea.
B
So
I'm
thinking,
if
we
do
this,
what
we're
going
to
need
to
do
is
we'll
have
to
have
like
nolan's
manifest
so
on
the
restore
it's
going
to
have
to
go
like
like,
for
example,
like
a
pod,
with
five
tvs
attached
to
it.
We'll
probably
have
to
wait
until
all
the
pvs
are
present
before
starting
the
pod,
so
we'll
have
to
be
able
to
keep
track
of
what
depends
on
what
before
actually
doing
a
thing.
B
E
Story,
good
question.
Sorry,
and
maybe
you
said
this
and
I
missed
it,
so
is
this
something
this
is
of
course,
for
the
future
right,
it's
not
something
that
you're
adding
on
for
1.7,
it's
like
you're
saying
we
even
would
have
to
the
manifest
work,
and
then
you
would
do
this
after
it's
like
looking
ahead.
A
E
B
Yeah
and
just
you
know
getting
a
general
sense
of
you
know
ideas,
so
if
anybody
thinks
of
anything
hit
us
up,
you
know
email
slack
whatever,
and
we
will
have
this
in
for
review.
B
That
part,
the
the
restore
and
delete
snapshot
was
not
part
of
the
original
design.
So
I'm
going
to
upgrade
the
design
dock
with
where
this
is
today
and
then
we
can
go
ahead
and
merge.
You
know
review
and
merge
that
first.
A
F
Yeah,
so
I
just
want
to
give
a
quick
update
on
the
resonance
plugin
versioning
that
I
provide
a
link
there,
that
widget
helps
create
the
design
and
we
have
some
feedback.
I
have
I
base
based
on
feedback
from,
I
think
from
scott.
I
also
incorporate
that
and
then
into
an
implementation,
to
try
to
figure
out
if,
if
this
design
actually
works
or
makes
sense,
so
I
created
an
implementation,
and
I
also
put
a
link
on
in
on
the
document
so
that
we
can.
F
Whoever
can
want
to
help
this
implementation
can
start
playing
with
the
with
the
code.
I
I
try
to
follow
the
design
as
close
as
possible.
F
To
see
if
the
design
actually
makes
sense-
and
we
I
did
some-
I
think
I
work
with
bridget
on
flat
to
point
out
some
of
the
details
that
can
be
shared
to
make
it
more
efficient
and
cleaner
code.
F
I
think
I
also
incorporate
the
feedback
from
scott
to
make
sure
that
in
the
future,
if
we
adding
more
versioning
the
cultural
you
know
spell,
environment
bill
will
be
obviously
racially
so
now
in
the
next
this
week
and
next
week
I
I
will
be
on
vacation
next
week,
so
I
will
not
work
on
this,
so
I'm
asking
the
you
know
community,
if
you
ever
want
to
jump
in
and
help
with
this
effort,
please
contact
witches
and
scott
and
me
to
start
jumping
in.
F
My
next
point
I
want
to
talk
about
is
how
to
test
this
this
this
versioning
right.
So
I
I
right
now.
I
have
very,
I
still
have
very
vast
idea
about
what
the
test
and
exactly
how
we
can
test,
because
the
code
chain
that
I
make
is
is
in
a
lot
of
places
is
a
little
bit
here
and
there
a
little
bit
here.
I'm
not
saying
it
does
not
change
a
lot,
but
it's
a
little
bit
here
and
there
and
then
like,
for
example,.
F
Using
version
one
two
version:
two
variable:
I
mean
interface
in
a
bunch
of
interface
and
and
that
change.
So
how
do
we
test
it
to
make
sure
it
doesn't
make
the
version
one
so
on
and
so
forth,
and
I
also
have
an
idea
of
maybe
I
have
to
implement
like
a
test
version
of
version
2,
so
that
we
can
test
out
the
plug-in
version
2
to
make
sure
the
version
will
also
work
on
whatever
we
want
to
achieve.
F
D
Yes,
I
think,
there's
there's
a
few
different
ways.
I
think
that
we
can
try
and
get
the
sausage
so
dave.
I
know
you
mentioned
like
this
week
with
doing
the
the
I
am
snapshotter
changes
that
you've
been
like,
taking
advantage
of
like
the
tilt
to
get
the
other
plug-ins
to
build
with
the
changes
incorporated.
I
think
so.
That's
like,
I
think
something
that
I
find
useful
when
doing
local
development,
but
not
necessarily
testing.
D
I
think
another
gap
in
like
our
end-to-end
testing,
for
example,
is
that
we're
currently
hard
coding
the
images
to
use
so
maybe
that's
something
that
we
should
be
making
configurable
so
that
you
could
make
a
plug-in
like
a
like,
make
a
variation
on
like
the
aws
plug-in,
for
example,
with
the
new
api
changes,
and
then
you
could
run
the
end-to-end
tests
with
the
version
before
the
version
after
to
like
try
both
combinations.
D
So
I
think,
if
we've
done
the
like
the
the
adaptation
layer
right,
then
you
should
be
able
to
run
like
a
v1
plug-in
with
a
valero,
that's
using
like
the
v2
api.
So
that's
some
ideas.
Yeah,
it's
gonna,
be
it's!
It's
gonna
be
tricky.
It's
probably
some
of
the
most
like
awkward
code
that
I've
had
to
work
with
in
valero,
so
it'll
take
some
thought.
B
F
As
I,
because
the
version
2
also
affects
all
types
of
plug-in
time,
so
objects
to
you
know
backups
items
action,
so
all
of
them
have
to
be
tested
to
make
sure
that
I
do
not
set
them
and
to
be
to
be
honest,
I'm
not
familiar
with
many
of
them.
F
So
far
I
only
use
vsphere.
D
Let's
just
say,
like
obviously
like
will
help
out,
like
with
the
testing,
like
it's
not
going
to
be
entirely
like
your
responsibility,
of
course
not.
But
I
was
just
thinking
like
with
your
branch.
If
you're
going
to
be
on
vacation,
I
was
wondering
like.
Would
it
make
sense
for
us
to
have
this
as
like
a
feature
branch
on
the
valero
repo?
And
that
way,
then
we
can
have
like
it's
easier
for
us
to
like
have
contributions
from
other
people
like
during
that
time.
L
F
Try
it
out,
I
don't
think
that's
the
way.
We
should
deliver
the
item
right
so
so,
maybe
maybe
bridgette
could
you
like
create
a
brand,
and
I
would
I
can
start
merging
my
my
chain
there
and
then
we
can
continue
working
from
there.
That
would
be
maybe
become
like
a
formal
way
for
other
people
to
start
contributing.
D
Easier
great
I'll
I'll,
create
a
branch
and
then
like
you,
can
make
a
pr
against
it
and
we'll
get
those
changes
in
there.
Thank
you
again
for
for
working
on
this
and
it's
very
helpful.
Thank
you.
F
Yes,
on
top
of
that,
I
don't
think
this
one.
We
will
make
it
for
1.7,
because
there's
a
lot
of
shame
and
another
thing
we
want
to
test
and
make
sure
it's
not
breaking.
I
don't
know
you're
going
to
make
it
to
1.7.
Let's
just
leave
it
on
the
feature
brand.
For
now
and
when
we
go
to
a
point
where
we
have
a
very
stable,
then
we
can
say
whether
we
should
merge
it
into
1.7
or
maybe
the
next
release.
D
Yeah,
I
think
as
well,
maybe
with
them,
if
we
have
a
feature
branch
as
well,
and
we
can
probably
set
up
some
of
the
the
test,
automation
and
things
like
that
against
it,
given
that
we
have
like
the
more
the
infrastructure
like
hooked
up
to
the
the
main
velar
repo.
So
we
can
take
advantage
of
that.
C
So
just
one
double
check
with
eleanor,
so
is
it
look?
I
assume
it's
okay,
if
the
plug-in
versioning
sleep
out
of
1.7.
E
I
think
so
I
mean
it
obviously
we'd
love
to
have
it,
but
at
the
same
time
we
do
have
other
priorities
too
and
yeah.
I
know
that
especially
bridget
has
a
lot
of
asks
on
her,
so
I
I
think
that
yeah
I
mean
my
my
understanding
is
that
it
really
depends
on
where
the
plug-in
versioning
apps
are
coming
from.
My
understanding
is,
it's
generally
been
the
community,
and
I
think
folks
here
so
yeah.
D
Dave
is
the
work
that
you're
doing
for
the
new
apis
for
the
I'm
snapchat.
Does
it
depend
on
the
plugin
version?
I
feel
like
you
said
that
no.
B
E
E
I
have
a
question,
a
very
negative
question,
of
course
we're
working
very
hard
right
now.
We
are
only
going
to
three
releases
a
year
for
bolero,
because
it
is,
it
was
just
such
a
long
release
process.
We
had
a
lot
of
manual
testing,
as
our
team
is
now
working
hard
to
make
much
more
automated,
and
we
want
our
release
process
much
more
automated.
E
Could
we
consider
doing
once
a
month
releases
say
I
mean
if
it's
painless?
No,
no.
I
saw
that
look
dave.
Only
if
it's
pain
mike
is
my
question
is
if
we
remove
the
pain
and
the
time
of
the
release,
because
I
just
hate
this
idea
that
if
we
don't
get
plug-in
version
again,
like
I
just
think,
it'll
take
another
like
four
months
to
get
into
the
next
release.
Wouldn't
it
be
great
if
we
were
released
once
a
month
if
it
was
painless,
so
tell
me
why
I'm
wrong
I'm
happy
to
be
told
why
I'm
wrong.
B
B
B
A
C
E
That's
a
good
point,
I'm
trying
to
remember
the
very.
I
think
that
what
do
we
decide?
The
28th
is
what
we're
going
to
try
or
there.
E
I
guess
the
point
is:
is
that
okay,
so
tentatively,
fellow
fellow
valero
community
members,
so
we've
been
trying
to
figure
out
when
exactly
we'll
release
we've
been
saying
september,
but
we've
kept
it
vague
for
now,
and
so
when
we,
so,
let's
see
tentatively,
I
don't
know,
can
someone,
I
don't
know
if
you
want
to
just
even
type
in
the
dates,
but
so
tentatively,
I
believe
we're
thinking
september
28th
and
then
I
believe
that
we
were
what
that
means
then
is
working
backwards.
E
We
were
going
to
give
ourselves,
I
think
about
10
days,
for
a
release,
candidate,
2
and
working
back
from
that.
I
think
about
a
week
for
release
candidate
one,
because
my
understanding
is
in
past
releases.
We've
had
two
release
candidates,
there's
good
things
and
bad
things
about
that
date.
On
one
hand,
that's
good.
It
means
that
I
believe
one
was
code
freeze.
Does
anyone
remember
I
don't
have
the
data.
B
No,
we
we
wound
up
with
like
a
funny
thing
in
there.
I
can
share
the
calendar
yeah.
E
Can
you
just
share
the
calendar?
All
that's
to
say,
though,
is
that
on
one
hand,
of
course,
the
longer
we
wait
until
code
freeze,
the
more
we
have
a
chance
of
getting
features
in
so
september,
6
was
kind
of
a
compromise,
it's
a
little
early
who
knows,
on
the
other
hand,
starting
october
1st,
we
learned
that
october
1st.
E
We
want
them
around,
obviously,
to
be
able
to
do
that,
so
we
didn't
want
to
go
out
much
later
september.
28Th
even
is
pushing
it,
assuming
that
we
might
have
a
couple
issues
after,
and
so
I
think
one
of
our
big
issues
for
the
community
is
whether
you
all
can
help
a
little
bit
with
the
manual
testing.
We
generally
do
for
each
release,
because,
if
that's
the
case,
then
our
release
windows
are
released
candidates.
E
We
can
just
budget
one
week
say
as
opposed
to
two
weeks
for
each
release
candidate,
so
I've
just
basically
so
I'll
stop
actually
talking
and
maybe
dave.
You
can
talk
through
the
schedule
and
then
I'd
love
to
hear
if,
if
any
of
you
especially
can
budget
a
little
bit
of
time,
if
we
give
you
a
time
warning
in
advance
for
testing.
B
Yeah
so
just
schedule
wise
we're
here
in
late
july
and
we're
doing
two
week
sprints
internally
and
so
at
the.
What
is
this
august
9th?
B
We
would
go
into
a
feature
freeze
and
all
that
means
is
we're
not
going
to
add
new
things
to
the
roadmap
at
this
point
and
we're
we're
not
going
to
add
new
things
to
the
roadmap
but
like
if
somebody
shows
up
with
a
pr
with
like
hey.
I
want
to
add
this
big
thing:
it's
like
no
we'll
continue
developing
through
september
6th
and
then
go
into
code
freeze.
At
that
point,
it's
going
to
be
bug
fixes.
B
E
And
so
again
like
in
the
past-
and
this
is
where,
of
course,
dave
and
bridget
can
speak
much
better
to
this
than
me,
but
I
know
that
for
one
six,
for
instance,
there
was
a
lot
of
manual
testing.
E
I
B
I
think
at
this
point
well
in
mankind,
daniel
speaks.
This
is
like,
I
think,
they're
mainly
focusing,
though
on
getting
automation
of
the
existing
indian
tests
and
getting
that
run
against
a
larger
matrix
of
platforms.
B
Automatically
that'll
actually
give
us
a
lot
of
confidence
going
into
the
beginning
of
the
rc
build
because
we
spent
a
lot
of
time
in
the
last
test
cycle,
just
getting
all
the
environments,
I
mean
I
spent
like
three
days
fighting
with
easter
because
I
hadn't
messed
with
it
for
a
while,
so
I
think
that's
going
to
be
a
big
plus,
but
we're
still
going
to
have
the
existing
set
of
manual
steps
that
bridget
had
pulled
together
for
the
last
release.
D
Yeah,
I
think,
like
things
that
aren't
currently
covered
by,
like
our
antenna
tests
you're
just
like
seeing
desert
upgrade
process
work.
So
can
you
like
take
a
backup
with
like
at
the
one
seven
point
it'll
be
like?
Could
you
take
it
back
up
with
one
six
and
then
restore
from
it
using
one
seven?
So
just
there
are
various
cases
like
that
which
maybe
don't
necessarily
have
to
be
platform
specific,
so
it
could
just
be.
You
know,
run
it
on
kind
or
whatever.
It's
not.
D
We
don't
need
everyone
to
like
have
like
a
an
aws
or
like
an
azure
vsphere
like
environment
set
up,
so
it
is
stuff
that
can
be
done
locally
and
more
easily,
but
just
some
some
of
these
cases
where
yeah
it.
It
adds
up
and
they're
just
small
bits
and
pieces
here
and
there
that
we
could
break
up
and
divide
up.
E
So
I
think
our
ask
fellow
community
members
is
starting
september
6,
let's
say
for
the
6th
to
the
13th
raffle
that
week.
Basically,
you
don't
have
to
answer
now,
although
if
you
have
any
thoughts,
we'd
love
to
hear
them,
but
can
you
budget
some
time
basically
for
this?
Can
you
budget
one
day
out
of
that
week
roughly
to
help
us
out
and
if
so,
then
we
can
know
that
we
can
assign
you
a
certain
amount
of
manual
testing
and
it'll
give
us
confidence
in
the
schedule.
E
If
you
feel
like
you
can't
we,
we
understand
and
we'd
love
for
you
to
consider
it,
but
we
may
have
to
adjust
our
schedule
if
we
can't
rely
on
any
additional
testing
help
so
thoughts
now
or
feel
free
to
think
about
it
and
ping.
Us
later.
A
Right,
thank
you.
I
see
genting
had
another
meeting,
so
you
had
to
leave
all
right.
The
last
portion
of
this
is,
of
course,
we're.
Gonna.
Do
shout
outs
to
the
wonderful
people
who
help
build
malero,
so
the
first
one
is
from.
I
think,
you're
you're
on
the
call
here.
Is
it
jai
or
jay,
or
how
do
you
pronounce
your
name.
K
Thank
you
so
much.
That's
jay,
jay
yeah.
A
Awesome
awesome:
you
want
to
talk
about
your
your
fix
here.
K
Yeah
sure
so
I
was
going
through
the
multiple
namespace
test
and
I
just
noticed
there
was
a
missing
expect
statement
and
even
though
I
put
values
where
I
want
to
fail
the
test,
but
I
mean
the
testing
fails,
so
I
just
checked
it
out
further,
and
I
noticed
that
there's
this
expect
tag
missing,
something
just
to
feel
right.
So.
A
Awesome,
thank
you
so
much
for
this
yep.
Thank
you
all
right.
Next
up
we
have
a
a
really
cool
one
from
t,
nicole
williams.
There
we
go.
She
added
replicated
a
company
to
the
adopters
page,
so
replicated
uses
valero
and
they
put
a
a
full
statement
here.
Replicator
uses
the
valero
open
source
project
to
enable
snapshot
in
cots
to
backup
kubernetes,
manifest
and
persistent
volumes.
A
A
That's
huge,
yes
tons
of
those.
I
saw
a
lot
of
those
come
in
as
well
really
awesome
to
see
all
right.
So
with
that.
Thank
you.
Everyone
for
joining
us
tonight
or
today
or
this
morning,
have
a
wonderful
rest
of
the
week.
Everyone
and
next
week
we're
gonna
take
some
time
off,
because
most
of
the
team
are
gonna,
recuperate
a
bit
and
hopefully
relax
a
bit.
So
we're
gonna
take
next
week's
community
meeting
off
and
then
we'll
resume
in
two
weeks
with
that
have
a
fantastic
week.