►
Description
March 31, 2020
Status Updates
[nrb]
Testing https://github.com/vmware-tanzu/velero/pull/2323 with review feedback
Adds the --features flag into the plugin framework for plugins now, still bugs to chase down (informer cache issues)
Led to https://github.com/vmware-tanzu/velero-plugin-for-gcp/pull/23
I created https://github.com/nrb/velero-csi-env based on Ashish’s script for setting up his host path driver
Reviewed https://github.com/vmware-tanzu/velero/pull/2373
[steve]
lot of reviews (CSI, cacert, Azure storage keys)
started looking at two-stage snapshot + backup process again (more discussion below)
[carlisia]
Community support this week + PR reviews + triaging new issues
Tested new Helm 3 chart with helm2 and helm3, PR merged.
Might write a blog post about how to connect Velero with a service
Community: please review the CLI install/config redesign PR: https://github.com/vmware-tanzu/velero/pull/2202
[ashish]
CSI
Update on VolumeSnapshotRef.UID issue
Discussion w/ CSI folks on the usage of secrets in volumesnapshotclass and volumesnapshotcontents
WIP
Opened Issue 2371: Which VolumeSnapshotContents to include in the backup
Building a catalog of buleprints/workflows for backing up and restoring stateful applications/databases. Survey to go out shortly.
[brito-rafa]
Will quickly screenshare and show an example of how a backup tar ball does look like with all API Groups and versions (as PR #2373 )
Discussion Topics
Seems there is a high interest in backing up volumes by default. Should/could we prioritize this? ]
Here’s a request to add an operator to our docs: https://github.com/vmware-tanzu/velero/issues/2375
Here’s a related issue: https://github.com/vmware-tanzu/velero/issues/605
Here’s another: https://github.com/vmware-tanzu/velero/issues/1871
[steve] two-stage snapshot + backup process design (https://github.com/vmware-tanzu/velero/issues/1519)
Problem Statement
Velero does not wait/check for snapshots to be made durable/restorable
A backup marked as completed may still be at risk if the snapshot data is not made durable
A restore may fail if its backup’s snapshots are not yet ready to be restored from
Things to Consider
Do we want to solve this for Velero snapshots? CSI snapshots? Both?
There’s potentially a difference between “durable” and “ready to restore” that needs to be modeled
With EBS/GCP, the snapshot can’t be restored until it’s been made durable by replicating the data to object storage, so they’re effectively the same thing
With the vSphere plugin and maybe the OpenEBS plugin, a local snapshot can be restored from, even if it hasn’t yet been made durable
Should Velero actively drive the upload process, or should it passively check for upload status as reported by an external component?
We don’t want to block the Velero backup queue while waiting for snapshot data to be made durable
We need to keep the timespan between pre- and post-hooks as short as possible, i.e. data replication should take place outside of hook execution
Since it may take a significant amount of time to make a snapshot durable, we need to be able to handle pod restarts, network interruptions, etc. gracefully.
[nolan] v1.3.2 release this week
https://github.com/vmware-tanzu/velero/pull/2350 for plugin dir in object storage
Anything else?
[Mayank] can we upgrade from 1.0.0 to 1.3.1? https://kubernetes.slack.com/archives/C6VCGP4MT/p1585647294073200
[Dylan] Concurrent Backup/Restores
https://github.com/vmware-tanzu/velero/issues/487
Contributor Shoutouts
@mansam for adding support for custom cert bundles (https://github.com/vmware-tanzu/velero/pull/2353, https://github.com/vmware-tanzu/velero-plugin-for-aws/pull/34 and more)
@jaygridley - Azure: support using static storage keys (https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure/pull/32)
Shoutout to Jonas for adding search to our docs!
Helm chart
@yurinnick for making the chart Helm 3 compatible (https://github.com/vmware-tanzu/helm-charts/pull/81)
@yurinnick for fixing timeout chart-testing parameter (https://github.com/vmware-tanzu/helm-charts/pull/85)
A
Hi
everyone
and
welcome
to
this
week's
episode
of
the
Valero
community
meeting
and
open
discussion
today
is
March
31st
2020
the
end
of
a
very
very
long
march
for
most
of
us,
and
we
get
a
bunch
of
the
things
that
we
want
to
go
through
today.
We
have
some
really
heavy
hitters
for
discussion
topics
as
well,
but
we'll
start
off
with
some
status
updates.
A
B
B
Our
native
snapshot
objects,
so
I'm
I,
finally
set
up
a
CSI
environment
and
have
been
testing
that,
and
it
looks
like
there's
some
issues
with
the
CSI
informers,
maybe
not
CSI,
informers
but
informers,
so
I'm
debugging
that
this
will
be
the
basis
for
doing
things
like
the
client
integration.
So
if
you
do
backup
describe
def
def
details
that
will
tell
you
what
snapshots
are
included
because,
right
now
we
don't
have
that
information,
so
this
will
be
prerequisite
for
that.
B
So
as
part
of
this
change,
I
might
I
may
break
this
out
into
its
own
change
just
so
we
can
bundle
it
up
and
maybe,
as
part
of
the
discussion
topics,
I
have
a
discussion
topic
for
v13
too
I
may
pull
this
particular
small
change
out
and
put
it
in
some
PR,
but
I
threw
anything
to
you.
Let
our
plugins
all
just
have
the
features
flag,
since
they
did
not
right
now.
B
I
also
discovered
an
issue
that
we
need
to
update
our
GCP
plugin
to
support
the
CA
search,
object,
storage,
option
Steve
helped
clarify
for
me
that
we
actually
do
have
that
option,
but
similarly,
to
this
features,
flag
change,
I
made
it's
in
the
plug-in
framework,
so
we
need
to
update
the
feature
flat
or
I'm.
Sorry
update
the
dependencies
on
the
plugins
so
that,
and
also
just
to
share
some
of
the
environment.
Stuff.
We've
been
spinning
up.
C
C
B
That
works
correctly,
okay,
yeah
I,
can
do
that
and
I
was
gonna
hold
the
discussion,
but
I
was
thinking
if,
if
I
do
a
separate
PR
for
the
features
to
add
the
features
command
line,
flag,
I
was
wondering
I,
think
that
would
be
small
enough.
I
have
to
test
it,
but
I
think
that
would
be
small
enough
to
put
in
for
one
three
two
to
give
that
to
like
the
CSI
plugin
and
these
plugins.
But
we
can
talk
about
that
in
the
discussion
topics.
If
we
get
there.
Okay.
C
C
B
D
E
E
This
is
the
preferred
version
that
the
way
that
we've
been
taking
backup
with
this
new
version
is
the
same
backup
from
the
same
cluster.
What
you're
gonna
see
under
the
directory
of
the
resource
list
you
continue
to
have
the
preferred
version
here
is
a
namespace
but
you're
gonna
have
the
different
versions
that
the
cluster
support.
When
you
take
a
restore,
it's
always
gonna
look
over
here,
which
is
the
preferred
version.
That's
why
is
backward
compatible
compatibility?
I
can
tell
you
say
that,
but
that's
it
major.
E
E
F
E
E
G
E
E
Okay
is
the
same,
but
one
is
the
V.
One
has
only
one
piece
of
field
here
is
the
same
object
with
a
bunch
other
fields
here.
Right
in
this
case
is
packet
per
second,
you
can
out
scale
based
on
packets
per
second,
if
you
use
the
V
2
beta,
2
type
of
object.
If
you
have
V
1,
the
only
thing
that
you
can
out
scale
is
based
on
CPU.
E
Memory
in
this
case
is
the
CPU,
so
it's
the
same
object
being
shown
in
different
versions,
again
apology
by
the
name
of
the
object
name,
but
now,
with
this
patch
we're
enhancing
or
whatever
want
to
call
it.
You
you're
gonna,
have
multiple
versions
of
the
same
object
and
the
preferred
version
always
going
to
be
on
the
same
classic
directory.
So
for
the
restore
it
doesn't
matter
right.
B
It's
the
only
I'll
make.
One
brief
comment
is
if
you,
if
you
can
get
the
value
of
the
preferred
version
and
toss
it
in
that
namespace
in
that
top-level
namespaces
directory
and
just
say
light
I,
don't
want
to
go
too
deep
into
it
on
this
meeting.
I
want
to
let
other
people
get
in
their
updates,
but
just
toss
a
file
in
that
namespaces
directory
that
the
value
of
the
preferred
version.
F
I
would
change
it
a
little
bit
Raphael
when
we
talked
last
time
when
you
showed
us,
this
I
would
actually
put
that
preferred
another
mentioned
on
the
v1.
That's
what
we
had
said
before.
So,
for
example,
if
v1
is
your
preferred
in
the
new
directory
structure,
you're
creating
that
doesn't
impact
previous,
like
in
the
previous
versions
of
velaro,
you
have
horizontal
potahto,
scalars,
auto
scaling
and
underneath
it
namespace
nothing
else
right
now,
you're
adding
new
folders
in
one
of
the
new
folders
that
you're
adding
that
has
the
default
version.
Add
the
preferred
there!
F
That's
what
we
had
said
that
way.
It's
easy
for
someone
to
view
this
and
know
exactly
what
changed.
Now
we
don't
modify
what
for
backwards
compatibility,
what
used
to
be
there
notify
what's
coming
next!
I
am
I,
miss
that.
So
what?
What
is
that?
What
is
the
request?
So
after
v1
put
parentheses,
LSS
default
or
even.
F
F
F
B
B
A
C
Sure,
just
a
pretty
quick
status
update
for
me
in
this
section,
I
was
out
for
a
couple
days
last
week.
So
a
short
week
for
me
a
lot
of
time
on
reviews.
There
are
lots
of
things
going
on,
so
the
trying
to
stay
on
top
of
the
CSI
snapshot
PRS
and
then
looking
at
the
CS
artwork.
That
Sam
has
been
doing
and
back
and
forth
on
that
Asscher
PR
to
add
support
for
static
storage
keys,
so
we
got
the
CA
cert
or
we've.
We
got
the
first
of
the
CSR
plug
PRS,
merge
and
I.
C
Again,
this
is
something
we'd
started
looking
at
last
year,
so
I
just
started
picking
that
up
again
and
tried
to
kind
of
outline
some
of
the
goals
and
the
design
constraints
or
the
requirements
really
so
I'll
talk
a
little
bit
more
about
that
in
the
open
discussion.
So
that's
that's
pretty
much
it
for
me.
A
G
I'm
on
community
support
this
week
and
yesterday,
I
was
spend
mostly
catching
up
track.
Try
adding
new
issues,
reviewing
PRS
in
a
little
bit
of
support
on
slack
the
I
tested,
so
there
was
a
PR
with
and
updates
to
help
charts
to
make
it
comparable
with
him
three.
You
know
so
it's
when
you
have
a
helm
three
chart
it's
supposed
to
be
comparable
with
helm,
so
I
tested
both
versions,
and
you
is
you
were
you
worked
great
and
that's
merged?
So
now
we
have
compatibility
with
both
helped
origins.
G
I'm
I
am
I,
have
a
document
open
to
write
a
blog
post
about
other
different
gadgets
when,
when
you
are
using
a
service
to
connect
velaro
to
a
an
s3?
Well,
it's
a
menial
in
specific,
so
I'm
I
think
I'm
gonna.
Do
that
right
up
just
reminder
that
there
is
a
CLI
install
configure
a
design
PR
for
people
to
jump
in
and
get
feedback
if
they
want,
and
that's
it
for
me,
I
think.
C
Just
a
quick
comment
on
the
yeah
idea
for
the
blog
post
I
think
it's
a
great
idea
to
have
a
blog,
post
and
I
will
also
mention
that
we
have
a
section
in
the
documentation
that
covers
this
form
menu.
So
I
would
definitely
you
know
start
by
looking
at
that,
and
you
know
any
improvements
to
that.
We
should
wish
me
like
a
blog
post
is
a
good
format,
but
we
should
also
make
sure
that
those
Doc's
have
any
updates
that
we
think
are
necessary,
but
I
would
I
would
certainly
start
by
looking
at
them.
Yeah.
F
C
F
I
mean
if
I
see
it
there,
the
blog
posts
either
one
of
the
general
things
that
you
can
do
there
on
the
coalition.
That's
a
great
idea
is
talk
about
the
fact
that
you
know
not.
Everybody
has
object,
storage
right
and
and
basically
put
it
down.
You
know:
hey,
you
have
a
kubernetes
cluster.
You
know
your
hard
work
doesn't
have
object,
storage
or
you
know
running
out
the
public
cloud
provider.
F
What
do
you
do
and
then
offer
it
up
as
many
hours
as
an
acceptable
option
and
add
that
I
want
to
mention
the
cloudian
offer
the
blog
post
like
that,
similarly,
a
few
weeks
ago
that
talks
about
how
they
accomplished
the
exact
same
goal?
To
that?
So
maybe
reference
that
in
your
blog
talking
about
havior,
if
you're,
if
you
are
a
cloudian
customer
with
hyper
store,
this
is
another
option
for
you.
That
way.
You
know
we
bring
our
community
together
and
we
don't
complain
only
single
solution.
Yeah.
A
G
G
I
G
A
H
H
So,
based
on
that,
we
and
the
workaround
suggested
was
if
you
scroll
down
the
workaround
suggested,
was
to
kind
of
use,
static
volume,
snapshot
contents
like
creating
one
on
demand
to
end
statically,
bind
to
a
volume
snapshot
instead
of
repurposing
or
reusing
or
dynamically
created
one
so,
based
on
that,
we
had
to
kind
of
re-evaluate
our
design
and
kind
of
to
do
some
work
to
fit
into
this
assumption
model.
Here.
C
H
The
idea
here
is
we
that
will
be
like
two
kinds
of
volume
snapshot
contents
in
our
cluster
right
when
you're
trying
to
back
up
one
is
dynamically
created,
meaning
somebody
created
a
volume,
snapshot
content
that
somebody
can
be
bolero
or
some
cluster
operator.
So
the
as
a
result
of
creating
a
volume
snapshot,
a
volume
snapshot,
content
gets
created
behind
the
scenes,
and
that
is
what
is
referred
to
as
the
dynamically
created
volume,
some
short
content
and
the
other
kind
of
volume.
Some
short
content
is
the
statically
created
one.
H
H
Then
there
is
the
third
kind.
Where
is
where
the
snapshot?
The
volume
snapshot,
content
deletion
policy
is
retain,
which
means
if
the
volume
snapshot
associated
with
the
volume
snapshot
content
goes
away.
The
volume
snapshot
content
is
still
retain
in
the
cluster,
so
people
might
want
to
do
this
if
they
want
to
still
keep
the
snapshot
in
their
storage
provider
around,
even
though
their
volumes
not
short
object
in
kubernetes
goes
away
and
like
just
to
make
keep
the
volume
snapshot
discoverable
in
the
kubernetes
cluster
and
use
it
to
create
volumes
further
down.
B
B
So
with
this,
you
can't
do
that,
because
there's
no
volume
snapshot
there,
you
would
have
to
create
a
new
volume
snapshot,
content
right
fog
to
in
order
to
use
that
snapshot
handle.
So
this
event,
in
this
scenario,
this
volumes
snapshot
content
was
either
statically
or
dynamically
created.
It's
not
a
third
type,
it's
one
of
those
two
that
was
orphaned.
B
B
F
B
J
K
H
Okay,
so
so
what
you
said
is
right,
but
if
we
don't
talk
the
orphaned
volume
snapshot
content,
we
lose
the
ability
to
discover
this
reuse,
the
snapshot
handle
that
was
in
this
orphan
volume,
static
content.
So
for
that
reason,
if
you
are
moving
from
one
cluster
to
another,
you
had
a
set
of
orphaned
volumes,
snapshot
contents
in
one
cluster,
and
if
you
don't
back
that
out
and
you
move
to
another
cluster,
those
set
of
volumes
snapshot
handles
are
no
longer
available
for
you
to
use
in
the
new
cluster.
H
So
for
that
reason
we
need
to
backup
the
orphaned
volume
snapshot.
Contents
now
coming
to
the
non
orphaned
volume
snapshot
contents
for
those
they
will
be
backed
up
as
a
result
of
packing
up
a
volume
snapshot
object,
because
that
is
bound.
So
the
way
we
chosen
to
back
up
volume
snapshot
objects
is
we
walk
the
link
from
the
volume
snapshot
to
the
volume
snapshot,
content
and
pick
out
all
the
necessary
information
from
the
volume
snapshot,
content
and
store
it
as
metadata
on
the
volume
snapshot
object
and
when
you're
restoring
a
volume
suffered
object.
H
B
B
H
Okay,
I
can
also
see
a
way
we
can
where
we
back
everything
up,
and
then
we
create
some
because
the
the
flows
for
the
volumes,
not
short
content
and
the
volume
snapshot
itself.
They're
like
the
restore
plug-ins,
are
different
or
will
be
different.
It's
hard
to
exchange
information
and
to
make
that
static,
binding
possible.
H
C
H
B
And
you're
saying
that,
because
the
bound
ones
are
handled
by
the
volume
snapshot,
plugin
yep
I
think
this
is
kind
of
breaking
some
of
the
patterns
that
we
have,
because
it
sounds
like
the
the
volume
snapshot.
Contents
objects
right
now:
a
balance
volume
snapshot,
content,
object,
isn't
being
added
to
the
backup
at
all.
Is
that
accurate?
B
H
B
C
C
H
C
I
kind
of
feel
the
same
way
like
we
should
just
back
it
up
as
it
is,
and
then,
if
we
need
to
do
something
unique
on
restore,
we
should
do
that
on
restore,
but
during
a
backup
we
should
just
capture
whatever
was
in
the
cluster.
It's
it's
always
easier
to
capture
more
information
during
backup,
okay,.
H
B
B
It
might
be
orphaned
if
we're
restoring
into
the
same
cluster
where
we
didn't
clean
up.
But
if
it's
a
new
cluster
it
won't
be.
It
won't
be
a
new
orphaned
one
and
I
kind
of
share
your
concern
about
creating
a
bunch
of
orphaned
ones,
but
no
one
in
the
CSI
snapshot,
meaning
that
I've
talked
to
you
has
been
concerned
about
that
yeah.
B
The
unbound
thing
is
hairy
because
I
don't
want
to
lose
data,
but
I
want
to
like
fully
understand
where
the
intricacies,
because,
like
I,
don't
want
to
I,
don't
want
to
get
super
smart
because
it
feels
like
if
we
don't
have
a
volume
snapshot
in
the
namespace,
and
we
don't
have
a
valid
way
to
use
that
snapshot
handle
anyway,
but
I
think
we
could
have
a
more
detailed
discussion
around
this,
because
we've
got
other
topics
so
I
think
we
should
probably
put
something
open
to
the
community
to
talk
about
this
cuz.
It's
yeah.
C
B
In
in
some
things
like
my
PR
23:23
for
core
Valero
needs,
but
it
makes
assumptions
that
some
it's
only
going
to
send
things
up
to
object,
storage
that
were
created
by
Valero,
but
we
don't
want
to
send
everything
in
the
cluster
of
the
optic
storage,
because
that
would
be
a
lot
so
yeah.
Let's
I
think
we
should
put
a
public
public
meeting
on
and
have
like
a
draw
by
Oh
or
something's
get
session
or
okay,
a
Google
Doc
with
a
spreadsheet
that
tries
to
map
out
some
of
these
things
and
visualize
them
cuz.
H
L
G
Me
sorry,
I
didn't
put
my
name
yeah,
so
I
mostly
we
don't
need.
We
only
have
15
minutes
anyway.
We
don't
need
to
work
this
out
right
now,
but
mostly
wanted
to
bring
awareness
to
everyone,
and
if
anyone
who
has
requested
this
is
on
a
call,
please
say
some.
You
can
you're
welcome
to
jump
in
and
give
your
inputs,
but
mainly
the
awareness
I
want
everybody
to
have.
M
B
C
C
G
B
B
G
We
need
to
have
a
policy
maybe
like
how
we
can
how
old
are
we
document
is
just
say
this
is
what's
out
there,
but
we
don't
support
it.
I,
don't
know
how
useful
that
is,
but
maybe
it
is
I,
don't
know
in
any
case,
I
don't
want
to
hold
up
the
rest
of
our
time.
We
can
iterate
on
this
and
we're
talking
discuss
on
the
PR
as.
I
A
side
note,
the
Contra
project
has
an
examples
directory
within
the
repo
and
example
deployment.
Camels
are
included
in
there,
so
we
could
use
the
pods
or
the
deployments
back.
Excuse
me,
which
was
just
mentioned
in
the
examples
and
point
to
that,
and
then
you
know,
say
these
are
a
starting
point:
they're
not
supported
mm-hmm.
G
J
Just
worth
mentioning
in
terms
of
the
pods
back
is
pretty
much
anything
that
has
a
pod
spec
template.
You
can
do
that
so
same
with
you
know,
jobs
or
diamond
set
or
anything
else.
If
you
want
to.
If
you
want
to
maintain
kind
of
permanently
this,
this
annotation,
you
can
put
it
on
the
template
there.
If
your
use
cases
annotate
right
before
you
do
a
backup
you
might
want
to
get
on
the
pods,
but
it's
it's
two
different
values
cases
there.
A
C
C
So
right
now,
falero
essentially
assumes
that
creating
a
snapshot
is
just
a
single
single
API
call
us,
essentially
a
single
plug-in
call,
and
once
that
call
has
returned,
we
assume
the
snapshot
is
completed
and
there's
nothing
more
for
falero
to
do.
But
what
we've
found
is
that
that
that
assumption
breaks
down
in
a
couple
of
different
scenarios,
and
so
if
you
kind
of
look
at
the
problem
statement
here,
you
know
the
issue
is
that
we're
not
waiting
or
checking
for
the
snapshots
to
be
made
either
durable
or
restorable,
and
these
are
actually
two
different
cases.
C
So
so
you
know,
if
you're,
if
you're
running,
maybe
in
an
on-prem
storage
provider,
when
you
actually
create
a
snapshot,
you
get
a
local
snapshot
on
the
storage
system,
but
in
order
for
that
to
be
a
durable
backup,
the
data
from
that
snapshot
needs
to
be
replicated
off
to
some
some
external,
durable
storage,
and
so
the
snapshot
itself
is
not
the
durable
backup,
there's
actually
a
second
process.
It
has
to
happen
where
the
data
needs
to
move
before
the
backup
is
is
durable.
So
that's
one
case.
C
The
other
case
is
kind
of
around
public
cloud
providers
in
particular
where,
if
you
take
something
like
like
AWS
and
EBS,
for
example,
when
you
make
a
create
snapshot,
API
call
to
EBS,
you
get
back
a
snapshot
ID,
and
so
from
that
perspective
it
looks
like
the
snapshot
is,
has
been
created,
but
what's
actually
happening
is
in
the
background.
Aws
is
replicating
the
data
from
that
snapshot
off
to
s3
and
until
the
data
has
fully
been
replicated
to
s3,
that
snapshot
is
actually
not
restorable.
C
So
I've
kind
of
just
been
picking
up
all
of
the
materials
that
we
already
have
the
issue
and
the
initial
design
dock
that
the
EPS
folks
submitted
and
some
of
the
commentary
on
each
of
those
and
just
trying
to
identify
you
know
our
requirements
and
kind
of
design
constraints.
So
I've
listed
about
half
a
dozen
things
here
that
I'm
currently
thinking
about
I
can
just
run
through
them
pretty
quickly.
C
So
do
we
want
falero
to
be
actively
triggering
those
uploads,
or
should
it
be
more
sort
of
passively
observing
status
and
relying
on
some
external
component
to
to
do
the
upload
and
report
the
status
somewhere
and
then
a
couple
of
the
things
so
right
now
we
only
run
one
Valero
back
up
at
a
time
and
so
I
think
we
definitely
do
not
want
to
block
the
backup
queue
while
we're
waiting
for
this
data
to
replicate
off.
So
we'll
need
to
think
about
how
to
how
to
design.
For
that.
C
We
also
need
to
keep
in
mind
the
pre
and
post
hooks,
and
basically,
we
need
to
keep
this
band
between
running
pre
and
post
hooks
as
short
as
possible,
so
I
think
effectively.
We
want
to
run
a
pre
hook,
take
snapshots,
run
a
post
hook
and
then,
after
the
post
hook
is
run,
do
any
data
replication,
that's
necessary.
C
We
can't
add
the
data
replication
in
between
the
pre
and
post
hooks
and
then
the
last
item
is
just
thinking
about
you
know
since,
since
it
may
take
a
significant
amount
of
time
to
replicate
this
data
off
somewhere
else.
We
need
to
consider
what
happens
when
the
Valero
pod
restarts,
or
you
know
if
we
have
some
other
pods
that
are
actually
managing
the
data
uploaded,
what
happens
if
they
restart?
We
have
Network
interruptions,
etc.
I
I
C
C
J
Well,
just
quick,
a
quick
point:
Steve
and
I
know
this
goes
back
to
an
issue.
I
think
that
I
put
in
a
few
months
ago.
We
ended
up
on
our
end,
implementing
something
in
our
plugins
I'm
gonna
fork
the
plugins
which
it
doesn't
solve
the
full
problem.
You
know
we're
still
waiting
and
blocking,
and
but
I'll
link
to
you
on
slack
kind
of
the
PRS
we
put
in
place,
which
might
be
useful
in
terms
of
thinking
through
requirements
issues.
J
It's
kind
of
you
know
one
way
that
solves
part
of
the
problem,
and
you
know,
but
again
it's
got
the
weaknesses
that
we
mentioned,
that
we're
blocking
we're
not
handling
things
other
than
the
plugins.
But,
and
one
thing
that
you
need
to
figure
out
in
terms
of
the
design
is
how
to
handle
time
out
questions.
Is
that
something
that
we
should
configure?
You
know
/
put
back
up
or
why
just
cuz
in
general,
because
some
you
know
a
large
volume
might
take
hours
to
be
ready,
but
you
bonus
still
gonna
wait
forever.
J
J
Yes,
as
I
dug
into
that
I
realize
it
was
exactly
the
same
issue
for
all
three
and
I
had
yar
that
we've
merged
on
our
Fork
bit
resolves
it
for
all
three.
You
know
to
the
development
of
our
requirements.
So
as
long
as
you
know,
an
upstream
solution
that
solves
those
use,
cases
and
more
would
mean
we
can
get
rid
of.
You
know
the
local
change,
eventually
cool.
C
L
C
Don't
have
them
in
front
of
me,
but
I
mean
I
would
basic.
We
can't
we
can't
document
upgrading
from
every.
You
know
every
source
version
to
every
target
version,
just
as
it's
too
much
for
us
to
maintain,
but
I
would
just
kind
of
go
through
each
of
the
you
know,
upgrading
from
1
to
1.1,
101
and
1.2
and
I
think
there
should
only
be
a
couple
of
things
like
adding
the
plug-in
and
bumping
the
image
version.
Sorry
I'm
just
pulling
it
up
on
slack
here.
B
B
B
A
A
M
M
I
know
that
it's
marked
as
p1
important
I
think
it's
going
to
become
a
little
more
important
for
our
team
in
like
the
next
two
months,
three
months
or
so,
I
was
I
was
just
wonder
if
you
guys
had
like
any
thoughts
on
when
that
would
be
added
to
like
the
top
of
the
roadmap
or,
if
you
think,
businesses
can
be
pushed
out
for
a
little
bit
I.
Just
wonder
what
the
Valera
team
is
thinking
about.
This.
C
M
Well,
I
guess
I
just
wanted
to.
You
know,
bring
up
that
since
I
think
this
will
be
relevant.
Probably
like
two
months
out
for
us
I
know.
We
can't
really
about
resources
here
right
now,
but
it
is
something
that
we're
looking
at.
You
might
bill
to
throw
an
engineer
to
you
on
it
a
little
a
little
bit
of
time
but
I'm
sure
it's
gonna,
take
a
big
design,
phase
and
I
know
that
you
guys
have
already
had
thoughts
on
this,
so
I
just
want
to
keep
it
in
the
back
of
our
heads.
B
C
B
B
B
They
do
really
yes
very
quick.
We
have
this
PR
2350.
We
would
like
to
get
out
in
1
3
2
this
week.
I
don't
know
if
anyone
else
has
anything.
I
know
on
this
release.
I
had
said:
I
would
like
to
collect
more.
They
are
on
this
I
think
we
should
keep.
Should
you
accumulate
a
few
more
changes
to
put
in,
but
I
don't
know
that
there
are
more
changes,
so
just
wanted
to
ask
anyone
if
there's
anything
else
that
they
might
think
would
fit
in
132.
B
We
don't
have
to
say
them
now
contribute
your
shoutouts
done,
but
letting
people
know
we're
going
to
try
to
get
1.
3
2
out
by
Friday
I.
Think
was
what
we
said
and
the
the
main
thing
is
to
get
this
in,
to
allow
plugins
to
have
a
little
spot
for
scratch
and
using
so
yeah,
if
any,
if,
if
anyone
has
PR
as
they
think,
may
fit,
given
that
it's
a
point
release
and
it's
not
going
to
be
huge,
breaking
changes
or
fixes
or
anything
toss
them
in
the
death
stream,
slack.
C
Sure,
first
one
for
Matt
and
Sam
Sam
from
Red
Hat
who's
been
doing
the
awesome
work
on
adding
support
for
custom
serve
bundles
into
both
the
AWS
repo
and
Valero
course.
So
these
are
looking
really
good
and
looks
like
well.
We
should
have
full
support
for
this
for
our
next
release.
Thanks
a
lot
for
these
PRS
and
the
great
work
you're
doing
and
of
course,
thanks
to
Dylan
as
well
for
for
doing
the
design
work
there.
C
And
then
we
have
Jay
Gridley,
who
has
been
patiently
working
through
a
a
PR
in
the
Azure
plug-in
repo
to
add,
support
for
using
static
storage
account
keys,
basically
an
alternate
means
of
authenticating,
particularly
if
you're
not
using
volume
snapshots.
So
we
got
this
merged
and
there
will
be
one
or
two
more
PRS
to
follow
this.
But
thanks
for
the
patience
with
working
through
this
and
glad
we
got
it
merged
and
I'm,
not
sure
who
added
this,
but
definitely
I
echo
this
a
big
shout
out
to
Jonas
for
adding
search
to
our
Docs.
C
B
A
G
A
Awesome,
yeah,
Thank,
You
old
contributors
here,
fantastic
work.
Thank
you,
the
community
members
for
sticking
around
for
so
long
for
for
this
meeting
you
all
rock
and
yeah.
Thank
you.
The
Valera
team
here
that
wraps
up
today's
meeting
and
with
that
have
a
fantastic
week.
Everyone
and
see
you
all
next
week,
bye
everybody.