►
From YouTube: Velero Community Meeting - March 7, 2023
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
Right,
hello,
everyone
today
is
March
7th.
My
name
is
Julian
vasilov
and
I'm,
the
community
manager
for
Valero,
that's
official
community
meeting.
So
please
follow
the
code
of
conduct
and
just
be
nice
to
each
other
I've
added
the
link
to
our
community
meetings
into
the
chat.
So
please
add
yourself,
add
your
topics
and
updates,
or
whatever
you
want
to
have
for
a
discussion.
A
I
can
see.
That's
done
from
many
folks
already.
Thank
you
very
much
so
with
that
I
can
see
that
our
show
added
views
caught
and
then
shubham,
so
I'll
go
the
same
way.
So
I'm
sure
do
you
want
to
share
or
should
I
share
and
we
can
go
through
the
PRS
or
maybe.
B
You
can
share
I,
have
some
issues
sharing
through
sure.
B
So
this
is
basically
briefly
talk
about
both
of
these
PRS
and
basically
try
to
see
what
discussion
we
need
in
this
forum.
So
this
PR
we
I
raise
for
for
providing
a
support
for
multiple
snaps
or
class
selection
through
the
CSI,
plugin
and
Scott,
and
super
have
already
gone
through
the
pr
and
I
think
we
are
at
an
overall
consensus
and
I
see
that
Daniel
also
joined
today.
So
I
was
hoping
that,
like
we
could
use
this
forum
to
kind
of
come
to
a
consensus
as
to
what
makes
sense
does
not
make
sense.
B
So
maybe
I'll
quickly
take
a
minute
to
explain
what
all
approaches
we
thought
through
and
what
we
kind
of
landed
on,
so
that
we
can
take
the
conversation
from
there.
So,
basically,
there
are
three
approaches
right
as
of
today,
the
the
volume
standard
class
is
selected
by
a
label
on
a
volume
software
class
for
a
particular
driver.
It
is
more
of
a
global
Behavior,
where
you
can't
really
say
that,
for
this
backup
use
this
volume
snapshot
class
or
for
this
schedule,
you
will
use
this
specific
one.
B
So
the
second
approach
for
backup,
CR,
I,
believe
shubham
and
Scott
were
also
kind
of
against
introducing
CSI
specific
parents
in
the
backups
here,
and
the
annotations
route
is
a
very
user
and
friendly
route
in
my
opinion,
so
that
is
kind
of
what
I
I
also
don't
want
to
have.
So
on
the
third
approach
that
I
have
proposed
the
plugin
in
fruits
approach.
I,
think
that
Daniel
had
some
comments,
so
I
mean.
Maybe
we
can
try
to
get
some
consensus
amongst
folks
here.
So
go
ahead!
Daniel!
Yes,.
C
I
I
understand
that
requirement.
That's
a
valid
one,
so
I
think
the
major
disagreement
from
my
understanding
is
whether
it
should
be
the
plugin
input
or
it
should
be
in
the
backup
three
hours
pack
I.
Personally,
the
don't
like
very
much
the
plugin
impulse.
I,
don't
think
we
want
to
expose
the
detail
of
plugin
to
the
user,
who
write
the
backup
CRS
back.
That's
my
personal
opinion.
I
haven't
had
a
chance
to
discuss
with
other
developers
in
China,
but
yeah
I.
D
Was
gonna
say
another
another
thing
that
we
need
to
keep
in
mind
here
too,
is
that
I
think
the
other
thing
we
want
to
try
to
avoid
is
to
build
into
Valero
core
code,
any
knowledge
of
something
that's
in
a
plug-in,
because
the
idea
is
that
I
ought
to
be
able
to
change
a
plug-in
without
needing
to
change
Valero
core.
So,
for
example,
if
I
you
know,
if
you
change
the
way
you
register
a
plug-in
or
if
you
change,
you
know
the
API
for
a
plug-in.
D
That's
not
the
API,
but
like
the
inputs
of
a
plug-in
that
shouldn't
require
Valero
to
changes.
So
the
the
generic
approach
kind
of
says.
You
know
it
does
at
least
a
voice
that
it
decouples
it
from
Valero's
internal
design.
So
you
don't
have
to
coordinate
those
changes.
It
also
allows
third-party
plugins
vendor
plugins
to
use
the
same
mechanism
because
we're
obviously
not
going
to
be
building
in
Spec
field
changes.
You
know
specific
to
a
Dell
plug
under
a
red
hat,
plug
under
an
IBM
plugin
in
the
in
the
specs.
D
So
building
out
this
I
know
for
a
long
time.
We've
had
this
issue
and
the
only
answer
so
far
has
been
red,
annotations
and
I
actually
think
annotations
are
better
than
modifying
the
spec,
because
at
least
the
annotations
don't
hard
code
plug
in
specific
things
that
aren't
in
Valero
core
and
the
Valero
core
code.
So
I
think,
if
we're
not
going
to
do
the
the
mod
the
the
approach
where
we
you
know,
we
have
the
plugin
inputs.
I,
actually
think
the
existing
annotation
approach
is
probably
cleaner
than
you
know.
C
I
I
yeah
just
share
some
of
my
thoughts
around
that
thanks
for
for
the
information
God.
That
makes
sense,
but
I
would
like
to
point
out
that
the
CSI
plugin
is
a
little
bit
special
because
that's
a
very
generic
plugin,
we
don't
wanna.
We
don't
want
to
change
the
lateral
Spark
for
plugin,
because
the
plugin
is
often
vendor
specific.
We
don't
wanna
put
vendor
specific
information
in
the
spec,
but
CSI
is
not
something
like.
D
Yeah
yeah
I
mean
that's
true.
Yes,
another
question
I
would
have
relating
to
the
answer.
Maybe
we
don't
want
to
worry
about
that.
Here
is
if
you're
talking
about
a
plug-in,
that's
not
CSI
plug-in.
Do
we
want
to
just
continue
to
say
the
best
way?
D
For
you
know,
red
hat
or
for
our
Dell
to
hand
the
plug-in
inputs
is
to
use
annotations
or
do
we
want
to
build
some
kind
of
mechanism
into
the
spec
to
allow
that
to
be
explicit,
and
if
we
don't
have
to
do
that
as
part
of
this,
if
we
decide
that
the
CSI
is
a
special
case
and
it
doesn't
need
to
be
here,
but
it
and
I
think
it
could
be
if
we
decided
that
we
liked,
for
example,
the
the
plug-in
inputs
and
we
wanted
to
treat
CSI.
D
That
would
allow
us
to
create
CSI
in
the
same
way,
but
but
it
may
be
that
we
want
to
go
ahead
and
treat
CSI
as
a
special
case,
because
almost
everybody
going
forward
is
going
to
be
using
CSI
plugin,
even
though
it's
implemented
as
a
plugin
we're
essentially
developing
an
s-core
functionality,
so
I
so
I
I
do
see
that
you
know
we
could
make
an
exception
there.
D
C
Yeah
I
think
I
think
the
my
my
personal
leave
favorite
is
the
plugin
inputs.
I
think
we
may
have
a
separate
discussion
regarding
plugin
input,
whether
it's
needed
I
personally,
don't
want
to
expose
that
to
the
end
user
so
as
for
CSI
I
think
either
using
annotation
or
a
backup.
Spec
sounds
okay
to
me
at
the
moment:
I'm,
not
sure
why
Andrew
we
mentioned
the
annotations
approach
has
been
decided
as
a
bad
one
or
no
no
I.
D
Don't
think
it's
bad
necessarily
I
think
I
think
it's
the
best
that
we
can
do
right
now.
I
just
think
that
I've
seen
you
know
some
people
have
said
that,
oh
you
know
annotations.
Just
kind
of
you
know
a
second
best
thing.
You
know
that
having
an
explicit
support
for
that
might
make
more
sense,
I,
don't
think
admissions
is
bad.
I
I
think
it's
kind
of
you
know
the
best
we
can
do
here.
D
I,
don't
know
that
it's
ideal
as
far
as
exposing
the
plug-in
and
inputs
to
the
user,
you're
exposing
them
either
way,
because,
even
if
you
don't
you
do
this
approach,
the
plugin
has
to
publish
hey
I'm
looking
for
the
sanitation
now
the
advantage
of
The
annotation
approach.
Is
you
don't
have
to
worry
about
how
the
plugin
was
registered?
What
name
was
used
because
there
is
a
risk?
D
If
that
name
changes
you
know
between
the
V2
and
the
V3,
they
might
use
a
different
name
to
register
the
plugin
and
the
user
would
use
this
old,
CRS
wouldn't
work
anymore.
So
that
is
a
risk
of
this
approach.
Probably
right
right
I
mean
my
own
opinion
is
I.
Think
annotations
is
kind
of
my
second
favorite
as
well.
It's
just
that
you
know
I,
think
my
first
and
third
of
the
reverse,
Series
so
doing
annotations
is
kind
of
a
compromise
that
I
think
everyone
here
that
I've
heard
talk
about
it.
D
It
says:
okay,
not
my
favorite,
but
it
works.
That
would
also
be
the
easiest
to
implement
because
it
wouldn't
require
any
changes
to
the
lyric
core
code.
D
B
Know
the
API
right
so
even
in
BSL
today,
right
if
you
really
see
the
profits,
just
a
property
back,
the
user
has
to
go
and
figure
out.
If
it
is
what
kind
of
storage
provider
it
is,
provide
the
same,
correct,
plugin
name,
if
it's
Azure
or
AWS,
you
need
to
provide
the
correct
name
and
then
it's
a
generic
property
back
right.
I!
Don't
really
understand
how
this
is
different
from
that
design.
It's
the
exact
same
method
right,
you
specify
the
plugin
in
you,
give
it
a
generic
property
back.
That's
the
exact
thing
I'm
doing
here.
D
Yeah
I
think
I
think
that's
right,
I
mean
I.
Think
I
think
this
is
the
kind
of
same
approach
that
we
are
taking
with
the
object,
store,
plugins
but
I,
I,
guess:
I,
guess
the
only
difference,
because
that
whatever's
looked
at
this
PR
I
was
thinking
that
was
kind
of
similar
too.
The
only
difference
really
is
that
that
actually
goes
on
the
backup,
storage
location,
and
this
is
and
then
this
would
be
going
on
the
backup,
CR
or
the
restore
CR.
D
Know
that
that's
a
significant
difference,
but
that
that
is
the
one
example
where
we
give
plug-in.
You
know
plug-in
specific
inputs
to
plugins,
not
using
annotations
and.
E
D
So
I
mean
I,
actually
think
it's
a
good
idea,
whether
it's
essential
here,
you
know
whether
this
is
the
use
case
that
would
drive
us
to
do
that
or
not
because
we're
already
using
annotation
outside
of
Object
Store.
D
The
only
way
backups,
backup
and
restore
plugins
are
getting
inputs
is
annotations
and
we're
already
using
that
you
know
anyway,
so
it
might
make
sense
to
I
mean
from
an
ease
of
implementation,
to
just
do
the
same
thing
here
and
treat
this
as
a
separate
proposal
not
connected
to
a
specific
plugin
saying:
okay,
we
want
to
propose
a
generic
way
of
getting
plug-in
inputs.
D
Let's
propose
it,
let's
implement
it
and
then
plugins
can
later
you
know,
modify
their
apis
to
use
that
instead
of
annotation.
So
that
would
be
another
way
of
doing
this.
I
I,
don't
personally
object
to
this
proposal,
but
I
also
don't
object
to
the
annotations
one,
that's
kind
of
where
I'm
saying
that
I
I,
like
the
the
property
approach
better
but
I,
do
prefer
annotations
to
modifying
the
spec
in
the
CSI
specific
way.
B
C
I,
don't
consider
it
a
very
sorry
sorry
to
interrupt,
but
I
don't
consider
is
a
very
generic
requirement
that
we
need
to
allow
user
to
add
some
plugin
inputs
in
their
backup,
I,
I,
I,
I
I.
Think
that's
something
we
need
to
discuss
and
decide.
I,
don't
think!
That's
a
very
required
generate
generic
requirement
for
that.
I.
D
If
you
already
have
plugins
with
that
requirement,
it's
just
that
right
now,
in
the
absence
of
any
support
from
Valero
itself,
annotations
always
work
because
you
know
that's,
that's
kubernetes
feature
that
Valeria
doesn't
get
involved
in.
So
we
already
I
know
on
the
red
hat
side.
D
We
have
several
plugins
that
have
taken
annotations
on
the
backup
CR
to
you
know
as
plug-in
inputs,
because
that
was
the
only
way
we
could
do
it
because
there
wasn't,
you
know
any
kind
of
map
or
properties
field
or
whatever,
and
if
we
had
that
available,
we
probably
would
have
used
it.
But
in
the
absence
of
that
we
use
annotations.
You
know
at
some
level
it's
an
implication
detail
but
obviously
goes
into
the
API.
Either
way.
D
You've
got
some
map
on
the
you
know,
backup
that
you
pull
things
out
of,
because
the
annotations
themselves
are
math.
You
know
key
value
pairs
are
there.
The
only
difference
would
be.
If
you
made
this
plug-in
specific,
then
the
plugins
would
be
limited
to
getting
their
own
data,
whereas
annotations
you're,
essentially
exposing
to
every
plugin,
which
isn't
I
mean
as
long
as
you're,
not
doing
since
anything.
I'm
sensitive
here,
it's
not
it's
not
a
problem.
It's
just.
D
E
D
Know
the
other,
the
other
disadvantage
of
annotations
is
it's
possible
for
two
plugins
to
Define.
You
know
the
the
plugins
have
to
design
Define
their
own
name
spacing
so
that
The
annotation
names
don't
Clash,
that's
kind
of
putting
responsibility
on
plug
and
owners
to
not
clash
with
other
plugins.
Whereas
if
you
had
the
map
approach,
you
couldn't
Clash,
because
each
plugin
has
its
own
set
of
inputs
so,
but
but
but
I
would
say
to
me.
D
This
feels,
like
a
longer
term
design
question
for
plug-in
inputs
that
doesn't
need
to
be
tied
to
a
specific
plug-in
requirement.
I
think
it's
a
discussion
worth
having
and
I
would
actually
favor
implementing
it.
But
at
the
same
time,
if
the
CSI-
you
know
feature
here,
is
needed,
I
think
we
delay
implementation
of
that
feature
discussing
this.
If
maybe
it
makes
sense
to
just
do
the
annotations
first
and
Mer
and
migrates
to
a
longer
term,
more
sustainable
approach.
D
Once
we
can
agree
on
something
that
that
you
know
it's
generic
enough,
but
is
also
you
know,
it
feels
like
it's
sustainable,
for
you
know,
maintenance
and
all
that.
C
That
sounds
good
to
me,
because
I'm
still
not
quite
convinced,
I
get
the
idea
that
you
may
wanna
customize
the
behavior
of
plugins
through
some
input.
And
how
do
you
do
that?
You
want
to
introduce
plugin
input,
but
my
my
concern
is
that
we
are
exposing
too
much
implementation
detail
to
users
who
are
calling
Valero
CPI.
So
that's
something
we
need.
D
To
debate
yeah
response
to
that
is
that
we're
already
doing
that
we're
doing
that
via
annotations.
Now,
because
you
know
a
map
of
info
plug-in
so
plug-in
writers
and
myself
included
when
I've
written
plugins
in
the
past
have
used
the
annotations
feature
of
kubernetes
as
a
makeshift
substitute
for
a
plug-in
inputs,
and
so
we're
still
exposing
just
as
much
to
the
user
with
annotations.
It's
just
that
the
plugin
has
to
manage
it.
You
know
on
its
own
and
we
have
to
make
sure
that
we
create
names
for
these
annotations
that
don't
clash
with
anything.
D
D
So
I,
so
if
that's
okay
just
say,
let's
just
do
annotations
right
now.
That's
the
easiest
thing
to
do:
implementation,
wise!
So
there's
no
wasted
effort.
If
we
then
later
add
annotation
or
add
the
you
know
the
config
approach,
then
you
can
just
modify
the
plugin
later
to
pull
from
the
config
instead
of
annotation.
So
so
it's
not
like
we're
writing
a
whole
new
feature
that
has
to
be
you
know,
Rewritten
from
scratch,
so
I
think
doing
the
easy
thing
now
and
then
migrating
to
the
longer
term
solution.
D
If
we
can
agree
on
one,
it's
probably
the
fastest
way
to
get
this
feature
merged
without
wasting
any
effort.
D
F
D
Tiger
also
mentioned
the
the
other
approach
that
we've
done
in
plugins
before
is
use
config
Maps,
but
I
think
in
that
case
the
plug-in
has
to
basically
publish
hey,
create
a
feedback
config
map
with
this
name,
and
so
so
that's
another
workaround.
Basically
and
again
it's
it's
not
that
config
maps
are
ideal.
It's
that
I
need
something
more
structured
than
annotations.
D
So
I
tell
the
user
in
my
documentation,
create
this
config
map
and
we'll
look
here
for
configuration
and
that's
another
thing
that
can
be
done
as
well
and
again
that
would
be
without
any
explicit
connections
to
the
Valero.
You
know
the
spec.
D
To
expose
to
the
user
what
the
plugin
needs,
if
the
plugin
needs,
that
I
mean
yeah,
the
only
way
to
completely
hide
plug
it
in
you
know
everything
the
plugin
does
the
user
is,
if
you
don't
need
any
input
from
the
user,
you
know,
and
a
lot
of
plugins
are
simple
enough.
You
know
we're.
You
can
get
everything
you
need
from
the
basic
resources
being
saved
and
backed
up
and
from
the
plug
on
the
backup.
D
So
if
you
don't
need
to
expose
anything
to
the
user,
because
you
don't
need
to
ask
them
for
additional
configuration,
you're
good,
but
if
there
are
cases
where
we,
you
know,
there's
plug-in
functionality
that
requires
user
configuration
right
now.
You
can
either
use
annotations
with
a
kind
of
well-known
name
that
you
publish,
create
this
annotation
with
this
name.
Plugin
looks
for
it
or
config.
D
Maps
create
again
create
a
config
map
with
this
name
and
the
plugin
will
look
for
it
and
and
I
think
if
you
can
add
explicit
support,
eventually
and
Valero.
If
we,
if
we
can
come
up
with
a
design,
you
know
in
112
or
whatever
that
draw
some
future
release
that
that
we
can
agree
that
you
know
makes
sense,
then
plugins
can
choose
to
migrate
to
this
newer
system.
D
You
know
for
that,
but
I
think
you
know
you're
not
really
losing
any
effort
by
writing
the
plug-in
changes.
Now
that
use
one
of
these
two
mechanisms.
You
know
whether
it's,
whether
it's
a
creative,
config
math
or
look
at
annotations
and
again,
depending
on
how
structured
the
data
is
and
how
many
fields
you
need,
but
the
config
maps
and
the
annotations
both
have
that
same
risk
of
you
know:
you're,
essentially
managing
this
completely
outside
of
any
API,
and
so
the
closest.
B
So
maybe
Daniel,
if
it's
okay,
do
you
want
to
like,
maybe
think
more
on
this?
If
it's
making
any
sense
discuss
with
more
people,
if
it's
not
convincing
enough
for
now,
I
mean
I
understand,
we
can
decouple
both
designs
for
now
we
can
go
with
annotations
and
then
do
this
later,
but
I
I
kind
of
still
want
to
see
this
plugin
inputs
get
lit
up
because
the
second
proposal,
as
well
right,
I'm
planning
to
leverage
the
same
field
I
mean
anyways.
We
can
skip
it
if
we
go
The.
B
D
Another
advantage
to
you
know
creating
a
separate
design
reversal
for
the
NH
plug-in
inputs.
Is
that
then
you
know,
then
people
can
look
at
their
own
plugins.
You
know,
I
can
look
at
the
red
hat
plugins
and
we
can
kind
of
add
comments
to
that
proposal.
Giving
examples
of
use
cases
of
you
know
currently
existing
plugins
that
need
inputs.
D
B
C
My
concern
regarding
exposing
the
implementation
details
and
you,
you
think,
that's
okay,
right.
C
Mean
I
mean
I
I
express
some
concern
regarding
the
plugin
inputs,
because
we
are
exposing
this
internal
mechanism
of
Valero
and
some
internal
things.
So
from
an
API
design
point
of
view,
I
I
think
we
may
it
host.
We
maybe
are
exposing
some
irrelevant
details
to
the
user,
because
if
user
want
to
set
a
a
volume
snapshot
class,
you
just
said
it
one
way
or
another,
but
he
doesn't
need
to
know.
Oh
that's
handled
by
a
CSI
plugin.
B
C
I,
don't
think
so
because,
like
I
express,
we
may
later,
for
example,
I'll
change,
the
name
of
the
Plugin
or
you
know,
move
the
plugin
into
some
other
mechanism.
For
example,
we
implement
the
CSI,
not
using
plugin
and
I
understand
we
need
user
input.
We
need
to
provide
it
one
way
or
another,
but
I
I'm,
just
at
the
moment
right
now,
I'm
not
quite
convinced
that
we
need
a
expose
detail
of
plugins
to
the
user.
I
hope
that
makes
sense.
C
Because
I'm
thinking
From
apis
perspective,
we
may
want
to
make
it
more.
You
know
scenario
specific.
Instead
of
implementation,
specific.
B
C
Yeah,
but
that's
just
my
thought
at
the
moment,
I
got
the
idea
because
you,
you
guys,
have
a
lot
of
different
plugins
which
are
not
on
the
upstream
and
you.
You
want
some
way
to
customize,
it
I'll
think
about
it,
but
from
the
API
perspective,
I
I'm,
not
sure.
If
it's
the
right
thing
to
do,
we
we
will
add
you
that
I
put
plugins
name
and
the
input.
This
way.
B
Anyways,
whenever
they
install
Valero,
they
anyways
give
the
plugin
names
to
install
right,
so
I
mean
it's.
The
user
is
already
exposed
to
all
that
information.
I'm
I
I
have
stories
I'm
still
not
fully
convinced.
Why?
What
additional
are
we
exposing
to
them?
If
they're
installing
a
plugin?
They
are
providing
annotations
for
that
same
functionality,
then,
if
they
want
an
opt-in
feature,
it
should
be
okay
for
them.
To
put
it
in
the
CR
right.
Cr
is
still
better
than
an
annotation.
B
B
Thank
you,
okay,
so
yeah
this
was
the
first
one,
I
mean
so
for
now,
what
I'll
do
is
I
split
it
into
two
I'll
create
one
for
plugin
inputs.
Where
folks
can
give
their
examples,
and
for
this
volume
snapshot,
one
I'll
go
with
the
annotations
route.
Just
for
implementation
is
that
okay,
Daniel.
B
B
Okay,
cool
cool
thanks!
Thank
you.
Okay,
now,
coming
to
the
second
proposal,
this
is
around
Json
substitutions.
We
discussed
this
in
I.
Think
previous
meeting
as
well.
I
you
had
some
concerns
around
using
the
Ria
for
Json
substitution.
Your
concern
was
that,
since
this
is
an
Ria,
it
will
be
triggered
for
each
object
but
I
kind
of
had
one
point
there.
Maybe
we
can
make
certain
code
changes,
which
kind
of
say
that
like
if
the
customer
has
not
opted
to
use
this
plugin,
we
will
kind
of
leave
it
dormant.
B
D
Will
say
if
you,
if
you're
using
if
it's
an
Ria,
you
can
also
use
the
you
know,
there's
the
applies
to
function
and
the
plugin,
so
you
might
be
able
to
depending
on
how
the
inputs
are
set
up.
So,
for
example,
if
the
inputs
for
this
or
config
map.
F
D
The
applies
to
because,
because
we
do
call
the
the
simplest
way
to
handle
applies
to
is,
if
there's
a
way
to
configure
you
know
hey,
you
know,
I
only
want
to
apply
this
to
you
know
secrets,
for
example.
If
there's
some
way
of
providing
that
input,
then
the
applies
to
plug-in
sorry.
The
applies
to
Method
will
return.
D
You
know,
based
on
the
context
again,
we
have
to
figure
out
the
inputs
angle,
because
most
of
the
simpler
plugins
applies
to
is
pretty
simple.
You
know
this
is
a
plug-in
for
pods.
This
is
a
plug-in,
for
you
know
PVCs,
or
this
is
a
generic
plugin.
That
applies
to
everything.
For
example,
we
had
a.
We
had
a
plug-in
on
the
openshift
side
that
initially
we
ran
on
everything,
because
it
was
just
some
background.
D
You
know
it
set
an
annotation
and
did
a
couple
of
small
things,
but
it
turned
out
that
was
a
performance
problem
to
run
on
every
single
resource
when
we
realized
that
we
only
actually
needed
it
for
certain
resource
types.
So,
instead
of
applies
to
being
returned
everything
we
just
provided
a
list
of
the
you
know
six
or
seven
different
resource
types
that
it
applied
to,
and
so
you
know,
if
you
had
a
thousand
Secrets
or
whatever,
then
it
wouldn't
call
on
those.
D
C
Substitute
so
so
how?
What
do
you
think?
What
do
you
guys
think
if
we
put
that
into
the
restore
workflow
like.
D
That
would
be
another.
That
would
be
another
approach
that
would
work.
I
mean
the
plug-in
approach
is
nice
because
you
know
someone
can
write
it
without
needing
to
change
the
restore
workflow
I
think
if
this
is
generic
enough,
that's
you
know
enough.
People
want
to
use
this.
This
would
make
sense
as
some
as
a
generic
restore
workflow,
because
if
this
is
something
and
again
I'm
imagining,
for
example,
you
know
again
say
you
have
a
config
map
and
it's
a
map
of
in
a
resource
type
to
some
transformation.
D
You
know
struct,
then
the
restore
workflow
could
say
Okay
based
on
resource
in
a
bit
based
on
the
the
GB.
You
know
the
group,
the
group
resource
we're
looking
at
okay.
There
is
a
matching
substitution
or
there's
not,
and
if
it's
not
least
yet,
but
if
there
is,
then
we
apply
the
substitution,
so
so
I
think
adding
into
the
restore
workflow
would
make
sense,
especially
if.
F
D
Something,
that's
you
know,
yeah.
C
Because
oh
yeah
yeah
I
mean
yeah
after
reading
the
PR
I
kind
of
convinced
that
this
is
a
relatively
generic
requirement
and
many
users
may
find
it
useful,
so
I
think
it.
It
probably
makes
sense
to
merge
into
the
restorable
flow
and
we
don't
have
the
performance
issue
because
you
only
load
the
conflict
map
once
in.
D
D
D
Also
you're
not
going
through
that
you
know
RPC,
you
know
to
get
to.
D
So
this
is
definitely
you
know
something
generic
enough
that
I
wouldn't
be
opposed
to,
including
this
in
the
restore
workflow.
You
know
it
would
also
give
us
some
flexibility
to
figure
out
the
right
place,
to
put
it
in
the
restore
workflow.
You
know,
for
example,
is
this
something
we
would
I
would
imagine
we'd
want
to
put
this
near
the
end
after
applying
the
other
restore
item
actions
kind
of
before
we
actually
do.
D
You
know
kind
of
kind
of
right
before
we
do
that
create
call,
but
that
would
be
part
of
the
if
we're
going
to
redesign
this
as
a
workflow
that
would
be
part
of
the
design
proposal
is
to
know
where
exactly
we
want
to
apply
this.
Do
you
want
to
fly
before
plugins
or
after
plugins
I?
Think
it's,
the
is
the
the
distinction
point
that
makes
a
difference.
B
Let's
party,
thanks
for
this
bro,
sorry
folks,
I
I,
mean
I
think
it
makes
sense
if
that's
okay
I'll
modify
the
proposal
in
that
way,
so
that
it's
part
of
the
restore
flow
and
I
hope
we
have
consensus
any
other
folks
opposed
to
it.
Please
let
me
know.
D
Yeah
I
would
also
say
that
you
know
the
majority
of
the
logic
here
is
going
to
be
the
same.
In
terms
of
you
know,
the
bulk
of
this
is
at
some
point.
You
you
get
a
you
get
a
you
know
an
unstructured
item
as
an
input.
You
you
take
this
Json
transformation
and
you
they
have
an
output
that
part's
the
same,
whether
it's
in
a
plug-in
or
whether
it's
in
the
chloride,
the
difference
is
going
to
be.
You
know
how
you
call
it,
how
you
structure
it
and
how
you.
B
In
okay,
so
if
it's
part
of
the
core,
workflow
I
think
even
the
in,
in
that
case,
you
folks
would
be
open
to
taking
a
config
map
reference
as
an
input
in
the
CR.
Is
that
a
valid
assumption,
or
because
the
plugin
inputs
for
was
for
this
exact
thing
right
like
right?
For
for
this
Json
substitution?
How
do
you
pass
in
the
config
map
right
should
not
have
to
rely
on
annotation
so
right.
D
Right
right,
yeah,
exactly
if
it's
in
the
core
workflow,
it
would
not
be
an
annotation
and
it
wouldn't
be
using
plugin
numbers.
It
would
probably
I
I
think
you
would
have
a
couple
of
options.
You
could
take
a
big
map
or
you
could
just
add
a
map.
You
know
to
the
because
you
know
just
just
as
a
spec
field
restore
spec
field
that
it
that
it
is
a
you
know,
string
to
whatever
struck
map.
I
mean
there's
kind
of
depending
on
how
you
structure
this.
B
C
There
has
been
that
design
that
is
merged
regarding
the
resource
filter
policy.
We
introduced
in
V
version
1.11,
which,
in
the
backups
the
RV
reference
the
config
map,
and
it
has
a
lot
of.
B
C
B
It
makes
sense
makes
sense.
Okay,
that's
it
from
my
side,
folks
for
the
first
one
I
kind
of
like
asked
Daniel
once
if
he
gets
time
like
take
some
time
to
have
a
look
at
plug-in
inputs
once
more
thing
through,
but
otherwise
I
think
I
explained
I'll
go
with
annotations
for
now
and
split
the
proposal
and
second,
we
I
will
explore
the
core
workflow
and
update
the
proposal
accordingly,
thanks
a
lot
folks.
Thank
you
for
your
time.
A
Yeah
double
muted,
sorry,
it's
got
your
next.
You
wanna.
D
Yeah,
yes,
sure,
so
so
the
the
backup
out
of
action,
V2
controller
work
was
merged.
It's
not
completely
done
we
kind
of
agree.
There
were
some
things
we
wanted
to
fix
and
change,
but
we
wanted
to
merge
it
because
most
of
those
changes
wouldn't
affect
the
restorative
action
following
work.
So
that
way,
those
two
that
way
I
can
work
on
those
two
PRS.
In
parallel,
the
following
PR,
then
I'm,
just
gonna
give
a
quick
summary
of
what
what
I'm
intending
to
do
in
this
and
I
know.
D
There's
a
discussion
item
relating
to
this
as
well.
So
most
some
of
them
were
pretty
straightforward.
D
D
D
So
there
were
some
exceptions:
I
was
making
around
books
and
volumes
and
that,
upon
reading
the
feedback
and
looking
back
at
the
code,
I
think
I
can
get
rid
of
those
I
think
we
can
just
make
those
the
same
and
they're
most
likely
not
going
to
be
flying
anyway,
because
those
types
are
unlikely
to
be
things
that
we're
creating
as
part
of
a
an
async
plug-in
anyway.
So
it's
really,
it
was
really
an
edge
case.
You
know,
even
if
we
did
need
it,
the
bigger
things.
D
One
was
additional
items
we
were
ignoring.
There
was
actually
good
reason
for
that
in
the
original
PR
I
realized
now
that
I.
That
was
that.
That
reason
is
gone.
The
first
version
of
this
you
might
remember
where
we
actually
went
through
added
all
the
items
backed
everything
up
and
then
in
finalized.
D
If
those
add
additional
items,
we
haven't
had
an
opportunity
to
add
those,
so
we
actually
need
to
process
the
different
items
the
same
way
and
finalize
as
we
do
in
the
first
version,
so
I
think
I
do
need
to
make
that
change
and
the
one
other
one-
and
this
is
this-
was
the
one
where
there
was
some
more
discussion
around
which
and
then
Daniel
has
a
topic
here.
D
We
might
as
well
just
talk
about
it
now,
because
it's
relevant
to
this
comment
and
the
issue
is
and
finalize
we're
now
backing
up
things
that
were
created
as
part
of
an
async
plugin.
We're
not
expecting
these
async
plug-in
created
items
to
have
their
own
async
plugins
on
them,
because
that
that
results
in
the
possibility,
especially
for
badly
written
plug-in
of
an
infinite
Loop
of
finalized
and.
F
D
The
the
current
approach
was
was
to
discard
it,
but
that's
kind
of
a
problem,
as
you
pointed
out,
because-
and
if
you,
if
you
have
a
plug-in,
that's
doing
this,
it
shouldn't
be
doing
this
user
needs
to
know
this
so
I.
My
thinking
of
the
moment
is
that
we
do
two
things.
First
of
all,
we
be
proactive
in
document,
don't
do
this
and
they
and
the
plug-in
example
will
actually
check
I'm
going
to
modify
my
my
plug-in
example
to
actually
check
the
backup
phase
and
not
create
an
operation
ID.
C
D
D
So
that's
actually
pretty
easy.
The
the
second
thing
we
want
to
do-
and
this
this
is
going
to
be
key
for
kind
of
the
point-
is
that
part
is
for
plug-in
developers
for
users
instead
of
discarding
and
ignoring
operation
ID.
If
we
get
an
operation
ID
during
finalize,
we
need
to
log
an
error,
so
at
least
there'll
be
an
error
that
shows
up
and
which
will
which
will
sort
of
you
know,
suggest,
there's
a
bug
somewhere.
That
needs
to
be.
D
You
know
filed
so
so
that
that
was
my
thinking
now
is
to
sort
of
you
know,
kind
of
kind
of
handling
on
both
ends
on
one
side.
You
know
document
and
give
examples
to
sort
of
show,
plug-in
developers
how
to
avoid
this
from
happening
and
then
actually
log
the
error,
if
you,
if
you
you
know
if
it
happens
anyway,.
C
Yeah
so
so
another
question
is:
do
you
or
football
run
some
integration
test
automation
test
for
this?
You
know
updated
workflow
of
backup,
yeah.
D
So
at
this
point
there
aren't
any
end-to-end
tests.
We
have
I,
you
know.
Obviously
the
pr
itself
has
unit
tests,
of
course,
I'm
actually
sure
what
on
our
side
do
you
know
what
our
and
then
testing
plan
is
around
this
with
data
mover
and
the.
F
No
nothing
as
of
now
but
I
can
assure
you
that
I've
been
using
the
V2
changes
right
to
create
new
plugin.
So
yeah.
D
The
VMware
Valero
repo,
correct
yeah.
D
The
one
thing
we
need
for
before
for
an
end-to-end
test
to
get
written
is
really
to
have
not
just
the
full
functionality
in
place,
but
also
that
plug-in
example
that
uses
it.
C
D
C
D
So
we
do
need
to
to
find
a
way
to
get
end-to-end
testing
included
for
this
I
would
agree.
It's
just
that.
We
haven't
gotten
to
a
point
where
it's
practical
to
implement
yet
because
we
don't
have
a
an
emerged
plug-in
example
PR
and-
and
we
really
couldn't
merge-
that
plug-in
example
VR
until
all
the
required.
You
know
bits
in
the
Valeria
people
were
emerged
because
right
now,
that
PR
is
in
draft
State,
because
it's
pointing
to
the
pr
Branch
rather
than
Main.
C
Okay,
I
have
a
additional
comment
around
that,
because
I
know
you
guys
are
implementing
some.
You
know
pii
V2
plugin,
to
leverage
this
async
operation
framework.
So
do
you
guys
plan
to
run
automation
using
this
concrete
implementation
of
the
plugin?
In
addition
to
the
plugin
example,.
D
Oh
yeah,
so
so
in
terms
of
our
own,
you
know
oadp
and
and
testing,
or
are
we
going
to
have
anything
that
that
includes
the
data
mover
with
the
with
the
the
async
plugins
implemented?
Yes,.
F
Yes,
yeah
I
I
think
we
we
already.
F
Data
mover
test
case
right,
West,
correct.
D
C
Yeah
yeah
because
I
want
to
point
out.
Maybe
later
we
may
make
some
change
to
that
based
on
our
understanding,
but
because
we
we
don't,
we
don't
have
any.
You
know:
implementation
of
the
piv2
plugin
with
async
operation.
So
if
you
guys
have
some
automation
test,
even
it's
internally,
I
I
think
that's
helpful
for
us
to
discover
the
break
change
earlier.
C
D
F
F
Yeah,
because.
C
C
Side
yeah
just
in
case
there's
some
possibility
that
the
test
passed
in
it's
plugging
example,
but
break
in.
D
Oh
yeah,
no,
absolutely
so
so
on
the
on
the
Valero
side,
I
feel
on
the
red
hat
side.
We
certainly
will
be
you
know,
including
that
testing,
because
that's
what
we're
delivering
to
customers.
So
we
have
to
be
testing
that,
obviously
those
that's
going
to
require
things
that
are
not
you
know
explicitly
in
the
the
Valero
repos,
so
that
test
probably
is
again
running
in
our
environment.
You
know
in
the
openshift
repos
but
at
the
same
time
the
example,
the
plug-in
example
will
will
test
the
apis.
D
Obviously
it
doesn't
test
everything
because,
for
example,
the
plug-in
example
what
I'm
doing
to
simulate
this
is,
and
you
set
an
annotation
on
a
resource
to
back
it
up,
like
with
the
duration,
say
five
minutes
and
we
simulate
an
operation
by
creating
just
a
secret
with
you
know,
and
then
the
progress
method
in
that
API
just
compares
the
time
and
when
five
minutes
is
up,
it
says
it's
done,
and
so
this
allows
us
to
sort
of
test.
The
controller
workflow.
D
We're
and
we
test,
you
know,
making
sure
that
the
saved
item
in
the
tarball
is
latest
updated,
because
every
time
we
call
it
progress,
we
also
add
an
annotation
that
increments,
so
we're
testing
the
work,
the
you
know
the
the
the
backup
workflow
making
sure
that
the
finalized
works.
D
But
it's
not
quite
the
same
as
a
real
world
test
where
you're
creating
a
CR
and
there's
some
external.
You
know
controller
working,
and
so
obviously
you
need
a
real
world
plugin
to
get
that
level.
D
But
my
plan
then,
for
these
for
for
the
follow
unplug
it
is
to
get
that
sorry
following
PRS
to
get
that
out
the
next
couple
of
days.
Most
of
those
changes
are
relatively
small,
but
you
know
renaming
things
is
you
know.
F
D
D
You
know
the
finalized
logic
and
making
sure
we're
doing
the
additional
items,
and
all
that,
and
in
parallel
to
that,
probably
once
that
VR
is
out
there
and
being
reviewed
I'll
be
are
starting
to
work
on
the
restore
item.
Action
PR,
which.
D
D
Was
the
implementing.
C
D
Controller,
the
that
additional
items
ready
field.
So
that's.
D
The
the
bigger
restore
PR
is
going
to
be
implementing
async
action
on
the
restore
side
which
that
VR
does
not
include,
which
sorry
we're
just
kind
of
running
out
of
time
just
are
do.
D
That's
actually
in
the
discussion
topics
already,
so
we
can.
We.
C
Top
yeah
I
think
we
can
discuss
it
now
and
I
will
I
will
sign
off
with
live
for
me,
so
I
I
think
we
need
at
least
one
more
week
but
yeah.
D
I
think
that
depends
on
how
quickly
you
know
we
can
get
the
reviews
done
and
whether
you
know
new
changes
are
needed,
I
kind
of
like
the
idea
of
slipping
only
a
week
now
with
the
idea
being
next
Tuesday.
We
can
revisit
it
rather
than
saying,
let's
slip
two
weeks
now
for
sure,
because
okay
I
mean
my
my
plan
is
to
get
all
of
my
PRS
submitted
by
the
end
of
this
week.
C
Obviously
yeah,
but
but
we
are
not
done,
I
want
to
point
out
because
after
merged
this
biav2pr,
we
melted
some
break
in
our
pipeline,
so
that
we
will
need
some
time
to
handle
that.
And
there
are
some
ongoing
development
work
from
our
side
and
they.
D
Made
a
new
in
two
weeks:
I
I,
just
don't
know
if
it
makes
sense
to
you,
know,
call
it
week
by
week
or
or
just
say
it's
going
to
be
two
I
mean
again.
C
Yeah
I
think
it's
okay,
we
we
decided
to
sleep
one
week,
but
we
need
to
set
expectation
that
it's
possible.
We
delay
two
weeks.
D
D
So
I
would
I
would
say
one
week,
one
week
delay
with
the
possibility
of
needing
a
second
week,
we're
just
not
sure
yet.
C
Okay,
okay,
yep!
Thank
you,
yeah
I
think!
That's
all
my
topics
has
been
covered.
I'm
gonna
find
out
guys.
Okay,.
A
Right
next
on
the
list,
you
want
to
have
some
peer
reviewed,
but.
F
Yeah
I
know
I,
just
has
been
doing,
I
have
been
doing
some
PR
reviews,
no
implementation
updates
from
my
side.
Thank.
E
Yeah
I
just
need
at
least
one
more
review
on
this
PR.
It
is
to
address
any
hard-coded
default
timeouts
that
word
in
both
backup
and
restore.
So
we
decided
to
just
use
a
server
setting
to
cover
all
of
them
and
there
have
been
some
reviews
on
it,
but
I
have
updated
it
since
and
just
need
like
I
said
another
one
or
two
yeah.
D
It's
already
gone
through
the
initial
review
process
and
requested
changes
have
been
made
as
far
as
I
know,
yeah
and
I
will
and
I'll
also,
and
it
looks
like
it
was
been
updated
since
I
last
reviewed
it
so
I'll
I'll
review
that
again
today,
as
well.
I
I'll
also
point
out
that
one
of
my
open
PRS
depends
on
this.
D
Getting
merged
before
I
can
make
it
ready
out
of
draft,
because
that
the
one
I
just
mentioned
on
the
restore
side
involving
the
you
know
additional
items
being
ready
that
has
a
default
timeout.
That's
going
to
be
this
new
resource
timeout,
so
my
PR
will
need
to
be
modified
to
include
that
once
this
PR
emerges,
so
so
in
that
sense,
this
one's
also
on
the
critical
path
of
not
the
async
work,
but
there's
one
other
PR.
That
needs
to
be
modified
and
reviewed
again
after
this
merges.
A
A
A
Okay
next
one
is
Satya
from
cloud
Casa
go
ahead.
I
think
we
have
you
for
first
time
in
our
call
correct
me
if
I'm
wrong.
A
So
listen
to
a.
A
Okay,
so
please
take
your
time
to
introduce
yourself
and
then
we
can
go
through
your
topics.
G
Yeah
cool,
hey
everyone:
this
is
Satya,
I,
run
operations
for
catalogic
and
within
catalogic
we
we
have
a
service
that
we
run
cloudcaster.
As
of
now
it's
a
it's
a
business
unit
within
catalogic,
but
we're
actually
looking
to
spin
itself
out
into
a
separate
company
where
Cloud
cursor
will
become
it's
its
own
entity.
G
We
have
been
the
benefactors
of
Valero
for
the
last
couple
of
years.
We've
used
belero
for
driving
CSI
snapshot
feature
in
our
product.
We,
we
used
our
own
implementation
of
data,
mover
that
uses
the
snapshot
and
pushes
data
to
S3
S3
storage
that
we
manage
for
customers
as
well
as
customer
managed
S3
instances.
So
we
we
delivered
we've
been
delivering
a
backup
as
a
service
Solution
on
top
of
a
Valero,
but
it
wasn't
exactly
compatible
with
title.
G
I
I
just
wanted
to
quickly
kind
of
introduce
to
the
maintainers
that
you
know
we
are
introducing
a
service
that
would
work
on
top
of
existing
Valero
installations
as
well
and
will
be
completely
compatible
with
Valero.
So
far
we
were
essentially
being
a
replacement
to
Valero.
Where
anytime,
you
install
a
cloudcaster
agent,
it
would
replace
the
functionalities
that
Bolero
is
performing,
and
in
this
case
we
would
simply
allow
a
user
to
come
in
and
manage.
You
know
an
existing
Valero
install
without
any
disruption
right.
G
They
would
continue
to
be
able
to
run
Valero
but
they'd,
get
management,
monitoring,
alerting
and
and
cross
Cloud
recovery,
a
guided
recovery
capabilities
on
top
of
Valero
again.
My
my
motive
today
is
simply
to
introduce
that
we're
we're
working
on
that
service,
so
we
hope
to
be
more
closely
aligned
and
and
want
to
participate
on.
These
calls
going
forward.
G
I
think
you're,
seeing
some
of
our
team
members
already
take
on
a
little
bit
of
the
burden
around
responding
to
slack
messages
and
and
and
q
a
questions
in
in
Valero
and
I.
Think
we'll
continue
to
do
that.
I
think
it's!
It's
good
practice
for
us.
As
well
as
we
add
users
that
run
Valero
on
our
service,
so
we
hope
to
contribute
in
in
that
fashion,
as
well
Alex
I
know.
You
were
also
looking
for
some
collaboration
around
blogs
and
stuff
in
in.
A
A
That's
the
reason
why
I
reach
out
to
you
offline,
because
I
know
you
folks
are
your
service
is
based
around
Valero,
so
I
find
it
like
Supernatural
to
invite
you
and
to
work
on
the
project
together
and
you
can
benefit
from
that
and
the
project
can
benefit
from
your
efforts.
So
I
I
see
it's
kind
of
happening
right
now,
so.
G
Just
comes
down
to
you
know,
lack
of
skill
sets
around
kubernetes
in
general,
so
our
our
goal
is
just
kind
of
democratize
and
and
and
and
and
kind
of
make
this
more
accessible
to
folks
that
have
done
backups
before
they're
used
to
you
know,
defining
a
backup
job,
setting
up
a
policy
and
everything
through
the
UI.
So
we
would
simply
trying
to
build
that
layer.
On
top
the
the
we
will
have
that
functionality
free
for
early
adopters.
G
G
There
is
a
lot
of
use
around
Venero,
but
we're
also
seeing
that
there
are
usability
challenges
that,
hopefully
we
can
help
address
and
and
reduce.
The
number
of
you
know
messages
and
calls
I
I
think
people
are
placing
in
in
this
context,.
A
Yeah,
nice
and
and
there's
a
good
remark
in
the
chat
from
tiger
about
the
UI,
because
you
practically
portion
of
your
your
services,
UI,
which
is
user
friendly
and
for
some
folks,
Bolero
console,
is
not
that
super
friendly.
So
do
you
plan
to
somehow
work
on
this
one
with
us
like
to
Upstream
some,
some
of
the
UI
stuff
that
you've
done.
G
Yeah,
so
a
lot
of
what
we
are
currently
doing
is
is
built
as
a
service.
First
but
or
or
plan
to
contribute
back
is
to
actually
create
a
a
single
server
single
cluster
UI
right.
So
it's
essentially
build
a
UI
that
works
on
a
cluster
level
that
a
user
can
can
see
their
crds
and
and
so
on.
G
So
that
would
be
our
contribution
back
to
the
open
source
Community,
but
the
multi-cluster
management
and
the
multi-cloud
credentials
management
I
think
those
we
will
deliver
as
as
a
service
for
for
our.
You
know
the
the
larger
customers
that
would
have
plenty.
D
G
Yes,
God:
that's
that's
the
current
plan,
we're
we're
literally
just
getting
the
service
off
the
grounds
at
this
point,
so
it
will
only
start
with
what
we
already
have
and
and
to
be
fair,
because
we
were
utilizing
Valero
for
CSI
snapshots.
We
were
already
creating
crds
and
stuff
in
the
back
end,
so
we
were
deeply
familiar
with
how
to
create
the
various
components
in
in
Valero
that
that
put
into
play
to
run
a
backup
and
restore.
G
So
we
are
now
just
essentially
extending
that
to
customer
that
has
already
installed
the
Valero
and
have
set
up.
You
know
these
crds
in
in
the
back
end,
and
and
as
we
get
more
familiar
with
it
and
keep
going
with
it,
I
think
part
of
a
road
map
is
to
essentially
help
build.
This
single
cluster
UI
feature
on
top
of
Valero
and
and
kind
of
community
in
in
May.
A
Nice,
whenever
you're
ready
ping
me
out,
we
can.
We
can
set
up
this
one
and
create
like
a
working
group
for
this
one,
because
it's
like
a
separate
effort
from
from
the
core
Valero
stuff.
In
my
opinion
and
yeah.
G
Understood
we'll
certainly
do
again
we're
we're
looking
to
go
live
with
the
the
services
it's
currently
planned
at
the
upcoming
kubecon.
So
if
anybody
is
there
would
certainly
love
to,
you
know,
demonstrate
and
and
showcase
the
feature
as
well
and
and
I
mean
we
can
also
do
that
on
a
future
Community
called
closer
to
the
end
of
this
month.
If,
if
there
is
any
interest
in
folks
to
see.
D
And
I
will
be
a
coupon,
so
that'll
be
great
to
see
that
while
I'm
there.
A
Yeah,
it's
I'm
every
time,
I'm
like
asking
everyone
a
drop
in
a
line
if
you're
at
kubecon,
we
can
organize
something.
Actually
we
spoke
about
with
Wes
few
times
already
that
we
can
do
something
unofficial,
Valero
meeting
over
lunch
or
dinner,
or
something
like
that,
including
your
demonstrations.
G
About
nine
of
our
team
members
flying
in
certainly
happy
to
kind
of
join
you
guys
in
in
and
plan
with
you
together
as
well,
and
and
will
help
in
creating
the
quorum.
G
I
just
told
one
feedback:
you
you
I
I,
said
your
message
in
slack
as
well:
I
think
there
are
multiple
places
where
this
community
meeting
Zoom
link
and
schedules
are
there
I
I
just
wanted
to
at
least
communicate
as
a
user
that
I've
tried
joining
this
call
multiple
times
and
every
time
I
would
be
wrong
with
either
the
zoom
link
or
or
the
time
slots,
and
it
was
never
clear
whether
the
meeting
is
happening
in
Beijing
time
zone
or
or
the
U.S
time
zone.
D
That's
right:
yeah.
We
changed
that
a
few
months
ago
in
the
meeting
times
it's
a
sort
of
kind
of
it
was
kind
of
set
up
in
a
confusing
way
with
the
first
second.
Third,
fourth,
you
know
Tuesdays.
D
Just
not
working
out
for
us,
and
so
we
changed
and
the
other
problem
was
that
the
North
American
Media
was
was
so
late
that
no
one
in
Vision
could
ever
join
it
and
we
moved
it
earlier
so
that
you
know
Daniel
was
on
today
for
a
little
bit.
It's
not
convenient
for
him,
but
he
can
join
if
he
needs
to,
and
so
that
was
the
reason
for
the
change.
But
we
didn't
quite
like
you
said.
D
The
the
schedule
in
the
hack
MD
is
wrong
and
I
believe
the
I
think
the
slack
reminders
are
correct,
but
the
times.
G
D
Oh
yes,
yeah!
That's
the
other
issue
right!
It's
it's
8,
P.M!
When
we're
on
daylight.
So
sorry
it's
the
the
China
Centric
meeting
is
you
know
at
8
p.m:
U.S
Eastern
during
daylight
savings
time,
but
at
7
pm
us
Eastern.
So,
for
example,
the
next
meeting
will
be
at
8
pm
us
Eastern,
not
7,
PM,
us
Eastern,
I'm,
not
sure
what
time
zone
you're
in
but.
D
So
next
week
it
will
be
at
seven
because
sorry
at
eight,
not
at
seven,
because
we'll
be
back
with
daylight
savings
time.
There's
this
confusion
twice
a
year
because
Beijing
doesn't
change
their
time
for
daylight
savings.
So
the
the
offset
is
different
for
half
the
year.
Because
of
that.
G
Is
kind
of
community
manager
is
you
know
if
it
would
be
great
if
you
can
create
those
ICS
invites
it'll,
be
two
invites
obviously,
given
that
you're
we're
alternating,
so
this
way
can
get
on
people's
calendar
and
and
and
so
what
I?
What
I
realized
is.
If
you
join
once
it
becomes
easy
to
follow
along,
but
I
think
there
is
a
significant
barrier
to
joining
the
first
time
around.
A
G
G
I
am
but
okay,
I
will
I,
will
double
check
and
and
maybe.
A
I'm
not
seeing
or
maybe
they
they
stopped
like
propagating
food
new
users.
Okay,
I'll
check
this
one
and
maybe
I
can,
as
you
said,
that's
a
good
idea
to
export
those
and
add
them
somewhere.
So
people
can
import
them.
Yeah.
D
And
the
current
the
current
setup
is
a
lot
easier
to
do
that
with
the
current
schedule.
Just
because
it's
you
know
it's
every
two
weeks
for
the
starting
point,
and
so
as
long
as
the
Beijing
one
is
set
to
Beijing
time.
It'll
adjust
automatically
for
daylight
savings
for
the
rest
of
us
and
you
know
obviously
the
U.S
Centric
one.
G
A
We
make
it
hard
for
the
trustworthy,
no
I'm
kidding,
but
yeah.
Thank
you
for
that.
I'll
fix
that
the
thing
is
we
have
that
in
so
many
places
that
it's
super
easy
to
forget
to
update
some
of
the
places
that
you
yeah.
G
G
That
Zoom
link
is
also
incorrect
by
the
way
in
the
hack
MD,
because
that's.
A
Where
it
is
like
the
end
point
of
joining
the
meeting,
so
yeah
I'll,
take
notes
and
I'll
fix
that
for
sure.
D
A
Yeah
we
we
switched
to
the
links
when
we
created
the
new,
invites
for
the
bi-weekly
or
every
sick
or
every
other
week
kind
of,
should
you
and
we,
we
removed
this.
This
kind
of
awkward
thing.
G
Yeah
and
and
last
feedback
on
this
I
think
even
if
the
meeting
notes
at
the
bottom
said
what
time
zone
it
actually
happened
in,
we
would
know
that
the
next
meeting
would
be
alternating
schedule.
So,
even
if
you
stayed
here
that
the
meeting
happened
in
this
particular
time
slot,
you
know
we
would
be
able
to
guess
when
the
next
one
is
going
to
be.
A
No
perfect,
thank
you
very
much
and
Wes
I
I
think.
Did
we
touch
on
this
one.
D
Yeah
yeah,
we
discussed
that
already
before
Daniel.
A
D
Consensus
seemed
to
be
we're,
definitely
going
to
be
calling
for
a
one
week
slip,
but
recognizing
that
it
might
turn
into
a
two-week
slip.
A
Well,
let
me
add
that
is
it
where.
D
Is
it
yeah
and
physical,
saying
I
had
a
meeting
tomorrow
to
discuss
that
further
internally
VMware?
But
that's
that's
what
we
you
know
just
because
I
I
know
for
a
fact.
We
need
at
least
a
week
because
I've
got
two
PRS
to
write
this
week
because
then
got
have
to
be
remember
getting
merged
and
if
those
get
merged
relatively
quickly,
then
we
made
it
good
with
one
week,
but
you
know
maybe
not
and
then
there's
other
people
that
have
ongoing
work
as
well.