►
From YouTube: Velero Community Meeting - Oct 15, 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
One
welcome
everyone
and
to
the
Valero
community
and
open
discussion
meeting
happy
to
have
you
all
here.
We're
we
have
a
agenda
today
and
we'll
get
a
few
things
that
we
want
to
go
over.
It
looks
like
I'm
gonna
be
able
to
light
one.
So
if
you
have
any
questions,
please
let
us
know
in
the
chat
and
or
just
unmute
yourself
and
speak.
So
let
me
share
my
screen.
So
I'll
show
you
all
the
gender.
A
Alright,
so
the
agenda
for
today,
I'm
gonna,
give
you
some
status
updates.
Then
we
have
some
discussion
topics.
If
you
have
any
questions
that
you
want
to
add
in.
You
can
either
do
that
in
the
chat
or
here
in
the
hack
MP,
which
is
linked
from
the
community
page
up
on
valera
bio.
So,
first
off,
let's
go
through
some
status
updates,
carlesha.
C
Carly
see
your
he
need
to
mute
there.
We
go
okay,
so
yeah,
just
figuring
out
a
few
of
the
the
details
related
to
the
rustic
volume
snapshot
or
and
I
started
documenting
it
I'd
like
to
get
a
document
out.
That
folks
can
do
some
more
review
on
still
need
to
do
some
refinements
on
that
before
it's
ready
to
publish,
but
hopefully
soon
and
then
I'm
also
spend
some
time
just
taking
a
look
at
our
general
documentation
again
and
I.
C
Put
up
a
design
proposal
for
kind
of
a
revised
table
of
contents
for
our
documentation
and
I've
also
been
looking
at
making
some
refinements
to
the
install
documentation
to
hopefully
make
the
flow
a
little
bit
easier
to
follow
for
users.
So
that's
that's!
Basically
it
and
I'm.
Just
you
know,
continuing
to
review,
open,
PRS
and
and
push
towards
the
first
beta
release
for
1.2.
D
D
E
Good
morning,
I
wanted
to
quickly
go
over
some
stuff
that
we're
gonna
do
at
Keep,
Calm
San
Diego,
to
make
sure
that
the
whole
team
knew
here.
So
we
have
solidified
the
VMware
booth.
At
this
point
and
inside
the
booth
we
are
going
to
have
a
education
type
mini
lab
area
where
we
are
working
on
having
mini
type
labs
for
the
open
source
projects
that
we're
highlighting
and
within
booth.
E
One
of
those
projects
is
Valero,
and
so
it
looks
like
we're
going
to
be
doing
this
on
stereo,
which
is
what
a
platform
that
some
folks
use
internally
right
now
for
some
training
items,
boskie
and
Cody
are
going
to
be
helping.
E
Do
this
and
we'll
have
more
updates
next
week
for
everybody,
but
I
wanted
to
make
sure
that
everybody
knew
that
this
was
going
on
and
we're
definitely
committed
to
getting
more
hands
on
keyboards
right
now,
so
I
want
to
make
sure
that
the
community
knew
that
we
were
able
to
go
ahead
and
we'll
have
Valero
highlighted
for
us
all.
That's
it!
E
A
C
So
this
is
mostly
related
to
the
the
plug-in
repos
that
we're
extracting
and
the
example
on
plug-in
repo.
So
right
now,
with
our
make
file
and
our
our
docker
file
we're
we're
essentially
to
where
we
have
kind
of
our
own
builder
docker
image
that
we're
using
or
builder
stage
within
the
build
process,
I
would
say
so
we're
building
the
plug-in
binary
within
one
image,
and
then
we
have
a
our
actual
docker
file
is
taking
that
binary.
C
That
was
built
in
the
in
the
Builder
image
and
copying
it
into
in
an
actual
container
image
that
we're
then
gonna
be
publishing
to
docker
hub.
So
anyway,
the
kind
of
the
advantage
of
the
set
up
we
have
right
now
is
that
we
can
use
the
go
build
cache.
So
we
actually
create
directories
on
the
local
machines,
like
the
developers
laptop
at
the
store.
C
They
go,
build,
cache
information
and
then
let's
get
by
and
mounted
into
the
Builder
container,
so
that
they
can
be
used
there
and
updated
and
I
was
looking
at
at
changing
the
process
for
the
docker
image.
Build
for
these
plugins
to
take
advantage
of
multi
stage
builds,
which
I
think
simplifies
the
make
file
and
the
docker
file
a
lot,
but
one
downside
to
that
is
that
it
gets
more
difficult
to
actually
use
the
go,
build
cache
in
a
way
that
that
is
useful
within
the
Builder
image.
C
So
I
was
kind
of
looking
for
input
from
carlion
on
anyone
else
on.
You
know,
if
you
had
any
thoughts
on
like.
Would
it
be
better
to
move
to
a
multi-stage
build
which
I
think
would
simplify
the
docker
file
and
the
make
file
a
lot?
Or
is
there
a
lot
of
benefit
to
using
the
go,
build?
I
guess
my
opinion
is
that
you
know
for
the
plug-in
images.
I
don't
like
the
builds
are
relatively
small
you
you
will
definitely
get
some
beat
up
if
you're
using
the
cash
but
I.
C
Don't
think
it's
all
that
significant
I.
Can
you
know?
I
can
certainly
do
some
benchmarking
and
see
like
what
the
build
time
to
look
like,
but
you
know
I,
don't
think
there
anything.
That's
gonna,
be
a
significant
drag
to
productivity
for
anyone
working
on
these
things.
So
just
curious.
If
anyone
had
any
thoughts,
there
do.
D
D
C
D
C
C
D
C
And
I
guess
that's!
The
other
thing
is:
is
you
know
if
you're
a
developer
working
on
these
plugins?
You
know
if
you're,
just
building
and
testing
at
the
binary,
you
know,
builds
and
passes.
Tests
like
you
can
just
run,
go
build
or
go
test
locally.
You
don't
really
need
to
build.
It
get
build
a
full
image
and
if
you're
doing
that,
then
you
know
you'll
you'll
get
native,
build
cache
support
anyway.
So
yeah.
B
Yeah
I'm
taking
if
we
are
considering
using,
compelled
cash
or
not,
and
we
don't
really
have
a
speed
problem
that
we
need
to
solve,
then
focusing
on
and
doing
the
multistage
fields
and
having
those
that
those
darker
files
and
make
files
give
a
better
indication
of
what
to
use
when
in
more
better
organized.
So.
B
C
Okay,
yeah
I,
think
I
think
we
can
do
a
fair
amount
of
simplification
there
like
there
are
some
things
in
the
make
file
that
are
really
just
not
necessary,
given
our
repositories
or
structure
now
and
the
doctor
file
stuff
can
simplify
a
lot
as
well.
So
I'll
probably
work
work
in
the
next
couple
of
days,
I'm
just
throwing
up
a
draft
PR
for
that.
So
you
know
folks
can
take
a
look
concretely
at
what
it
might
look
like.
Yeah.
B
C
I
think
that
you
know
the
one
that's
in
the
plugin
example.
Repo
was
definitely
put
together
fairly
quickly
kind
of
copy
and
pasted
from
other
places
and
has
never
really
been
like
looked
at
and
and
optimized
and
simplified.
So
I
think
it's
a
definitely
a
good
time
now
to
so
look
at
doing
that,
okay!
Well,
that's
all
I
wanted
to
cover
there.
A
So
I
got
two
small
items
here
we
talked
about
rearranging
the
the
documentation
rewriting
a
bunch
of
stuff
now,
especially
with
the
plugins,
and
how
to
pull
things
out.
I
just
wanted
to
show
you
one
thing
that
the
contour
team
has
done,
and
that
might
be
interesting
to
do
here
as
well,
so
they
have
essentially
pulled
out
a
bunch
of
documentation
that
they
had
for
specific
use
cases
and
put
them
under
a
guides
and
URL.
So
we've
got
a
few
different
things
here.
A
A
few
different
guides
and
I
was
just
wondering
if
this
is
something
that
you
would
like
to
look
into
when
we're
doing
the
real
work
of
the
docs
anyway,
we
can
also
have
something
like
this,
so
we
could
have
the
documentation
and
maybe
a
guides
link
up
here.
If
you
wanted
to
entirely
up
to
you
and
then
entirely
up
to
discussion
as
well
or
up
for
discussion
rather
I.
A
They
wanted
it
to
be
very
clear
that
they
have
guides
on
how
how
to
do
different
things,
essentially
so,
making
it
very
clear
for
the
users
that
they
can
look
at
guides
immediately,
as
he
use
cases
on
how
to
do
different
things,
instead
of
having
to
go
to
the
documentation
than
looking
for
the
guys
there.
So
it's
actually
just
skipping
one
step.
C
Got
it
yeah
I
mean
I
might
think
about
like
keeping
it
in
the
documentation,
but
you
could
still
have
the
the
guides
link
at
the
top
of
the
website
that
just
redirects
into
the
relevant
documentation
section
but
but
I.
Definitely
like
the
idea
of
having
having
a
section
like
this,
which
is
kind
of
its
own
dedicated
set
of
information.
Yeah.
A
And
I
think
it
could
be
fed
through
some
of
the
blog
post
over
here
that
we
have
as
well,
especially
the
one
from
Cormac
where
he
goes
through
different
use
cases.
Those
could
then
be
turned
into
guides
and
the
guides
could
be
updated
while
the
blog
post
still
lives
on
as
they
are,
but
we
can
always
update
the
guides
easily.
C
Yeah
and
we
I
mean
in
our
existing
documentation,
we
have
a
couple
of
like
really
small
examples
of
you
know
what
I
would
consider
guides.
We
have
things
around
like
ER
and
cluster
migration,
but
I
would
say
they're
they're,
pretty
weak.
They
could
use
some
significant
updating
and
there
there
are
like
many
more
scenarios
that
we
would
actually
want
to
cover
in
that
section.
So
we
just
need
to
do
some
more
more
writing.
D
B
So
I
also
really
like
this
and
to
me
it's
sort
of
like
day
one
day.
Two,
you
type
of
thing,
for
example,
you've
been
running
Valera
and
you
think,
oh,
what
else
can
I
do
a
filler
and
then
you
go
through
the
guides
list
and
everything
is
listed
there
conveniently
and
I
think
this
is
what
you'll
have
to
say.
B
We
can't
even
post
links
to
blog
posts
right
there
and
just
keep
adding
to
it
and
just
having
one
page
where
everything
can
be
listed,
we
don't
feel
restrained
now,
I
agree
with
Stephen
Hartman
that
it
would
be
ideal
to
have
the
guides
also
listen
documentation.
The
one
issue
that
I
see
is
that
we
are
limited
with
the
format
of
our
dogs,
for
example.
Some
dogs
are,
they
have
like
a
top
level
and
you
click
to
expand.
B
But
then
you
keep
click
to
contract
too,
because
if
you,
if
we
have
20
documents
for
guides,
will
I
mean
if
we
list
to
anything
is
very.
This
left
navigation
starts
looking
weird
right.
So
what
tends
to
happen
is
that
we
we
will
want.
It
will
get
to
a
point,
but
we
will
want
to
refrain
from
adding
things
and
that's
what
I
would
like
to
elect
for
us
not
to
be
in
that
position.
We
would
like
first
to
have
proper
places
for
things
that
we
feel.
B
Oh,
let's
add
one
more
is
not
a
big
deal,
we're
not
going
to
worry.
Oh,
but
if
we
add
one
more
or
five
more
than
the
navigation
is
going
to
start
sucking.
So
yes,
it'll
be
good,
but
I
don't
know
how
to
reconcile
the
fact
that
if
we
are
a
bunch
of
things
there,
these
navigation
is
going
to
look
horrible.
A
D
A
Can
do
many
many
things?
Oh
yeah,
absolutely
I
can
mock
up
a
few
different
different
versions,
and
then
we
can
iterate
on
that.
That's
great,
okay,
the
and
I
think
the
the
guides
here-
and
this
goes
out
to
everyone
on
the
call
here,
both
the
lower
team
and
all
the
community
members.
It
would
be
awesome
to
have
some
contributions
for
guides
as
well.
A
A
All
right,
the
thing
that
I
wanted
to
talk
about
is-
and
I
mentioned
this
last
week
as
well-
implementing
a
slash
blog
and
the
website
for
a
cleaner
look
for
the
links
the
right.
Now,
it's
a
little
weird
because
we
do
have
slash
blog,
which
goes
to
here,
but
then,
when
you
click
on
these,
they
actually
don't
have.
Slash
blog
in
the
URL
just
goes
to
valor
dot,
IO
/
title.
So
this
is
a
simple
fix
to
just
a
simple
redirect.
A
Essentially
the
the
small
issue
we
have
right
now
is
that
we
already
have
published
articles,
but
all
I
need
to
do
is
insert
a
static
URL
redirect
for
the
existing
verticals
and
that's
per
article.
That
would
be
a
quick
fix,
and
that
would
mean
that
every
time
you
go
to
slash
blog,
you
will
see
all
the
blogs
and
then
all
the
articles
will
be
under
slash
blog
as
well.
It
would
just
be
a
cleaner
look,
essentially.
C
Edie
I'll
cover
this
just
had
one
that
I
found
looking
through
the
log,
but
so
Andy
Zhang
who
works
at
Microsoft,
contributed
a
PR
for
adding
support
for
the
China
and
German
clouds.
For
our
a
sure,
plugins
I
may
have
mentioned
this
last
week.
It
was
I
think
it
was
in
progress
at
that
point,
but
we
got
that
that
PR
merge.
So
this
is
I
know.
We've
had
a
long-standing
requests
to
add
support
for
the
German
cloud,
and
this
also
announced
supports
the
the
China
cloud
as
well.
C
So
hopefully,
this
is
useful
for
some
Azure
users
out
there,
and
this
will
be
included
in
the
1.2
release
that
we're
targeting
for
around
the
end
of
this
month.
So
thanks
a
lot
to
Andy
for
for
contributing-
and
it's
always
great
to
have
folks
who
you
know
have
folks
from
the
cloud
providers
helping
out
with
the
velaro
plugins.