►
From YouTube: Velero Community Meeting - Oct 22, 2019
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
Hi
everyone
and
welcome
to
the
Bolero
community
meeting,
slash
open
discussion.
My
name
is
journalist
Rosslyn
and
today
we're
gonna
go
over
a
bunch
of
stuff
regarding
the
Bolero
project
per
usual.
So
let
me
share
my
screen
with
the
meeting
notes
and
if
you
have
any
questions
or
concerns
or
comments,
just
unmute
yourself
or
watch
them
in
the
chat.
B
Yeah
not
too
much
I
mean
the
last
week
has
basically
been
kind
of
walking
down
getting
ready
to
cut
the
first
beta
for
1.2,
so
I
think
we're
getting
pretty
close
there
and
I
I
think
we
should
be
able
to
ship
one
of
those.
This
week
we've
got.
Let's
see,
we've
got
the
you
know
the
plug-in
code
extracted
into
their
own
repositories.
B
We've
got
images,
building
and
pushing
up
to
docker
hub,
so
just
locking
down
a
couple
more
things
and
then
I
think
we'll
be
ready
to
to
release
that
beta,
so
yeah,
mostly
just
out
and
keeping
up
with
reviews
and
PRS
that
are
coming
in
from
the
community.
I
think
that's
that's
about
it.
So
pass
it
over
to
Carly,
see
you
next.
C
D
That's
policy
yeah
I
can
go
yes,
I
was
working
on
CI
for
pushing
images
to
docker
hub
and
then
yesterday
there
was
an
issue
with
the
CID
generation,
where
we
were
just
kind
of
sporadically
you're,
seeing
updates
to
see
IDs,
even
though
we
weren't
expecting
them,
and
the
reason
was
because
there
was
a
change
in
the
controller
gen
tool
that
we're
using
to
generate
those.
So
we've
now
fixed
the
version
of
control
agent,
so
that
so
that
we
don't
run
into
random
changes
like
that
in
the
future.
D
What
else
yeah
it's
a
few
more
things
that
are
pending
on
just
finishing
up
the
repo
change,
so
just
changing
references
to
the
old
GC,
our
image
repository
to
docker
hub
and
removing
some
of
the
GCR
push
scripts.
So
I'll
probably
get
around
to
do
now
today,
other
than
that
I've
been
taking
a
look
at
some
of
the
execution
hook,
stuff
the
execution
home
controller,
I'm
gonna
start
contributing.
B
D
C
B
A
Well,
any
questions
there
all
right
sounds
like
we
have
a
beta,
soon
sweet.
Let's
move
into
discussion
topics,
Steve
yeah.
B
Related
to
all
the
things
we've
been
talking
about,
I
just
wanted
to
touch
base
with
folks
live
on
this
again,
because
I
know
we
had
a
little
bit
back
and
forth
on
it
earlier
on.
So
now
that
the
the
plugins
are
in
their
own
repositories
and
we'll
be
pushing
out
separate
images
for
for
those
we
we
do
need
to
decide
kind
of
how
we
want
to
version
them
at
least
initially.
B
So
you
know
we,
we
add
a
little
bit
of
discussion
about
whether
the
kind
of
the
version
numbers
for
the
plugins
should
stay
in
sync
with
the
velaro
version
or
whether
they
should
be
version
independently
and
I.
Think
you
know,
I
think
where
we
landed
is
that
we
want
them
to
be
able
to
be
version
independently,
because
they
don't
necessarily
need
to
there's
no
reason
they
need
to
stay
in
sync
and
part
of
the
benefit
of
having
them
in
their
own
repositories
that
they
can
evolve
independently.
B
So
I
guess
the
question
is,
you
know,
for
the
initial
release.
Do
y'all
think
it
makes
sense
to
to
call
them
1.2
and
to
be
initially
in
sync,
with
the
velaro
version,
or
should
we
just
call
them
1.0
to
make
it
clear
that
they're,
you
know
they're
not
in
sync,
as
far
as
version
numbers
with
the
with
the
main
velaro
binary,
so
we
kind
of
just
wanted
to
see
if
anyone
had
any
any
thoughts
there.
A
Can
you
talk
a
little
about
the
the
pros
and
cons
regarding
the
versioning
here,
because
for
from
from
a
direct
perspective,
it
looks
a
little
confusing
you
might
have
to
have
a
proper
support
matrix
with
everything
listed
out
if
you
have
different
versions.
So
what
was
the
pro
and
con
with
regards
to
different
versioning
structures?
Yeah.
B
B
The
downside
of
that
is
that
it
it
limits
our
releases
to
the
plugins.
So
you
know,
for
example,
we
couldn't.
We
essentially
couldn't
release
a
new
minor
version
of
the
plug-in
until
we
released
the
bolero
version,
so
we'd
kind
of
be
limited
to
only
releasing
new
versions
of
the
plugins.
When
we
released
the
lair
o,
which
you
know,
isn't
necessarily
a
major
downside,
but
it
is
a
limitation.
B
Yeah,
on
the
other
hand,
if
we
you
know
if
they
vary
independently,
it
means
we
can
release
either
one
whenever
we
need
to,
but
then
from
from
a
kind
of
usability
perspective,
like
you
said,
we
need
to
have
that
some
sort,
some
form
of
compatibility
matrix.
That
indicates
if
you're
using
you
know
velaro
version
X.
B
D
B
B
D
A
C
E
C
A
B
A
Yeah
I
think
that
makes
sense,
so
plugging
versioning
gonna
be
separate
from
from
bolero
to
have
them
be
independent
of
each
other.
I
think
that
makes
a
lot
of
sense
and
then
comfortability
matrix
documentation
will
be
in
the
plugin
repost
itself
and
we'll
just
link
to
those
matrixes
from
the
regular
bolero
Doc's.
B
C
A
B
We
are
we'll
have
to
think
a
little
bit
about
how
we
want
to
just
have
what
we
want
to
do
with
the
plug-in
documentation.
As
far
as
like,
when
we
tag
a
new
release
of
the
plug-in,
you
know,
do
we
go
in
and
like
update
the
version
numbers
in
the
do
we
want
to
create
like
branches
for
releases
and
update
version
numbers
there,
or
are
we
just
gonna,
keep
the
master
documentation
as
like
the
overall
compatibility
matrix
that
lists
like
every
past
version
of
the
plug-in
and
every
version
of
bolero
that
it's
compatible
with?
D
I
guess
my
I
feel
like
we
should
go
with
one,
oh
just
to
to
you
a
point
Steve,
to
make
it
clear
that
this
is
not
gonna
follow
the
plug
conversions,
because
even
if
we
did
go
for
one
two
today
and
said
it
was
in
sync,
it
would
be
confusing
if
we
decided
to
dance
wish
and
and
have
it
changed
in
the
future
and
I
know.
We
definitely
want
it
to
change
in
the
future.
So
I
think
just
sticking
one
over
now
is
probably
the
best
bet.
C
A
Awesome
I
do
have
one
one
thing
that
I
worked
on
last
week
was
the
the
blog
redirect
and
I
got
that
working
khaleesi.
You
weren't
a
fan
of
the
the
dates
in
there.
Do
you
want
me
to
remove
those?
No,
the
reason
why
I
added
those
is
because
it's
it's
easy
for
anyone
who
clicks
the
link
to
see
when
it
was
really
when
when
that
blood
was
polished,
that's
why
we
have
today
to
that
yeah.
C
No
sorry
in
after
I
added
that
comment
was
late
on
Friday
and
I.
Realized
I,
didn't
say,
speak
to
the
reason
why
I
don't
like
it
so
say
it
now:
I
think
it
dates,
unnecessarily
dates,
blog
posts,
so,
for
example,
I
at
least
that's
how
he
goes
with
me.
If
I
am
looking
for
something
new
and
newish
and
I
see
it's
from
six
months
ago,
I
move
on
them
like
up
now.
C
I
want
something
newer,
but
it
doesn't
it's
just
a
psychological
thing
for
me:
I
think
it
just
dates,
things
unnecessarily
and
that's
one
thing,
and
another
thing
is
that
if
you
look
at
my
autumn
blogs,
they
don't
want
dates,
articles
anymore,
they
don't
date
posts,
oh
I,
think
for
those
reasons,
I
don't
think
we
should
they.
Our
writer
yeah.
A
B
A
Important
than
1,
so
we
can
absolutely
remove
it
from
the
link.
I
think
you
bring
up
a
valid
question
and
I'm
the
same.
If
I
look
for
something
and
it's
6
months
or
older,
well,
I'm
gonna,
look
for
something
else,
so
I'm
exactly
the
same.
So
if
no
one
has
any
concerns
or
anything
about
that,
I'll
just
make
that
change,
and
then
we
can
move
forward.
B
Yeah
I
can
cover
this
I
got
a
handful
of
contributions
over
the
last
week
or
so
so
just
go
top
to
bottom.
I
think
these
are
most
recent.
To
least
recent,
so
Rossford
que
submitted
a
fixed
one
of
our
documentation
diagrams.
We
thought
some
old
references.
The
arc
is
the
CLI
name,
so
this
person
updated
it
to
correctly
call
it
Valera.
So
thanks
for
that,
that
was
I,
don't
know
that
we
even
had
the
original
source
of
that
image
anymore.
So
appreciate
someone
doing
that.
B
Then
Alexander
demikhov
noticed
that
if
you're,
if
you
do
a
Valero,
restore
and
you
remap
namespaces
that
the
if
you
have
any
role
bindings
or
cluster
role
bindings,
they
are
not
correctly
updated
to
refer
to
the
correct
namespace,
and
so
he
created
a
couple
of
plugins
restore
item
action
plugins
that
actually
correctly
remap
these
namespaces.
So
that
closes
a
long-standing
issue.
We've
had
around
that's
not
working
correctly
in
certain
circumstances,
so
I
really
appreciate
that
that
bug
fix
then
frank,
51
added
support
for
a
new
flag
to
the
velaro
install
command.
B
So
this
is
first
scenario
where
you
want
to
install
Valero,
but
you
don't
have
an
initial
storage
location,
backup,
storage
location
that
you
want
to
configure.
So
we
have
this
new
flag,
no
default
storage
location
which
allows
you
to
omit
providing
things
like
the
provider
and
the
bucket
that
you
want
to
use
so
probably
not
a
typical
use
case
for
most
folks,
but
can
be
useful
in
some
scenarios.
B
So,
thanks
for
adding
that
Frank,
51
and
then
SC
go
Scott,
we
got
his
PR
merged
for
when
you're,
taking
a
backup
if
you're
backing
up
any
custom
resources.
We
didn't
have
logic.
That
would
say
if
you're
backing
up
a
custom
resource,
make
sure
that
the
custom
resource
definition
for
that
resource
is
also
backed
up,
and
this
is
I
would
say.
This
was
kind
of
expected.
Behavior,
if
you,
if
you
had
the
include
cluster
resources
flag
set
to
nil,
which
is
the
default
which,
in
other
context
being
means
backup
any
related
cluster
scoped
resources.
B
So
Scott
added
support
for
for
adding
this
linkage.
So
if
you're
backing
up
a
CR
D
and
this
flag
is
nil,
then
make
sure
that
you're?
Sorry,
if
you're
backing
up
a
custom
resource
and
the
flag
is
nil,
make
sure
you're
also
backing
up
the
custom
resource
definition.
So
you
know
given
given
the
kind
of
rising
popularity
of
CR
DS
and
their
use
in
lots
of
different
applications.
This
is
a
I'd
say
a
pretty
important
addition
to
our
functionality.
So
thanks
a
lot
Scott
for
that
change.
A
E
I'm
Steve,
this
is
intention
and
actually
I
am
therefore
x51
and
it
does
measured
and
I.
Thank
you
again
for
allowing
me
to
merge
it
through
the
Valero
and
I.
Think
and
I
want
to
thank
your
further
comment.
You
mentioned
in
the
for
request,
and
it's
very
give
me
a
lot
of
help.
It's
really
helpful
yeah.