►
From YouTube: Velero Community Meeting - Feb 22, 2022
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
Anyone
have
the
hacking
so
welcome.
Folks,
today
is
february
22nd
and
we
are
meeting
in
yeah
we're
meeting.
Can
someone
please
drop
the
hack
mdn,
we're
not
quite
prepared,
so
anyone
has
it
open.
If
not,
I
can
go
to
the
valero.ia.
Oh
thank
you.
Scott
is
prepared,
so
I
am
going
to
share
my
screen
now.
A
So
just
a
reminder:
if
everyone
looks
at
the
link
in
the
chat,
if
you
can
please
add
your
name
and
affiliation
just
to
double
check
everyone's
seen,
the
right
screen,
correct,
yep,
I'm
going
to
do
it
myself,
because
I
have
not
done
this
yet.
B
Okay,
I'm
new
there,
hey
guys
yeah,
I'm
still
editing
the
hack
md.
So
this
week
I
have
been
mainly
working
on
the
plan
for
one
night
and
have
them
put
in
the
road
map
exactly
with
eleanor
and
assign
folks
in
the
team
to
work
on
it,
and
I
I
I
started
the
investigation
on
the
ci
side
plugin.
They
I
may
discuss
with
you
in
the
you
know,
upcoming
weeks,
to
understand
the
gaps
for
ga
per
discussion
with
eleanor.
B
We
may
want
to
first
ga
the
features
that
do
not
require
the
data
movement
and
later
when
we,
you
know
working
on
the
data
movement
layer,
design
in
parallel,
and
we
will
have
a
plan
for
you
know,
ga
this
set
plugin
that
requests
data
movement
and,
in
addition
to
that,
I
spent
some
time
to
work
on
the
issue
of
4080.
Yesterday,
I'm
gonna
have
a
quick
discussion
with
you
guys
regarding
how
we
should
fix
it.
B
That's
yeah,
probably
all
I
have
I'll
add
it
to
put
in
this.
A
Spot
yeah:
are
there
any
questions
or
comments
for
daniel.
D
Yeah
one
so
daniel
you
had
mentioned
you'll
build
a
two
eight,
an
rc
that
we
can
check.
B
Yeah
yeah
yesterday
check,
we
are
still
working
on
it
and
we
see
some
arrow
in
our
pipeline,
so
fixing
it
okay.
Do
you
have
an
update
from
172.
E
Yeah
we
have
upgraded
the
golan
version
and
fix
some
of
the
series,
but
not
all
of
them
are
fixed
because
someone
series
I
introduced
by
the
base
image
and
the
rest
binary.
We
do
not
recompile
the
red
binary,
so.
B
Okay,
so
we
will
keep
you
updated,
so
I
think
we
can
do
it
today
or
tomorrow,
right
yeah,.
E
We
can
push
it
personally.
A
D
Yes,
yes,
yeah,
so
yeah,
that's
fine!
I
think
so
I
guess
the
only
question
would
be
whatever
are
remaining
if
rustic
is
actually
affected
or
is
it
just
not
applicable,
it's
just
a
golan
issue
not
applicable
to
rustic.
If
we
can
get
that
clarification,
that
might
be.
A
A
Okay,
I
am
assuming
because
no
one
else
has
did
anyone
else
want
to
give
a
status
update.
I
assume,
because
I
don't
see
any
other
names
there.
The
answer
is
no.
A
Discussion
topics
by
the
way
have
we
we've
announced.
One
eight
was
out
right.
I
think
that
we've
said
this
in
some
meetings.
If
you
don't
know,
1
8
is
out
very
exciting.
Let
me
hand
it
over
to
daniel
who
I'm
pretty
sure
put
that
fix,
for
he
wants
to
talk
about
40
80..
Am
I
correct
daniel?
Would
you
like
me
to
unshare
my
screen?
Do
you
want
to
share
yours
or,
or
should
I
just
pull
up
the
issue?
I.
B
I
need
a
minute
sorry,
I'll
I'll
show
my
agreement.
Let
me
open
that.
Okay,
sure
yeah,
I'm
trying
to
edit
the
hack
md,
but
it
still
look
weird
daniel.
A
Do
you
want
me
to
talk
about
the
road
map
first
and
then
you
can
do
4080
after
yeah
perfect.
So
with
one
eight
done,
we
are
basically
done
with
the
one
nine
road
map,
although
we
still
do
care
about
feedback,
and
maybe
there
can
be
tweaks
so
I'll.
Try
to
do
this.
My
goal
is
to
cover
this
in
about
three
minutes,
but
obviously
ask
more
questions.
If
you'd,
like
things
are
roughly
distributed,
we've
got
p
zeros
which
are
like
boy.
A
A
We
really
really
want
to
get
a
data
movement
layer
into
valero's
architecture,
taking
the
data
mover
from
the
valero
plug-in
for
vsphere,
move
it
over
to
valero
proper
bridget,
who
did
the
existing
design
dock
and
did
much
of
this
work
is
no
longer
with
us.
So
what
we're
saying
is
that
for
one
nine
period
this
is
going
to
be
a
an
investigation,
a
design
period,
because
the
existing
team
is
not
terribly
familiar
with
the
architecture
and
wants
to
understand
it
before
where
they
do
such
a
big,
a
big
move.
A
We've
also
have
kind
of
a
late
joiner
to
the
list,
but
one
that
we
feel
very
strongly
about
it's.
This
idea
of
we
have
a
csi
plug-in.
It
is
decently
functional.
We
think
we
have
not
brought
it
to
ga,
because
we
worry
about
systems
that
implement
csi,
but
that
do
not
actually
move
the
snapshot
after
the
snapshot
is
triggered.
So
our
plan
is
to
bring
it
to
ga
just
for
aws
and
azure.
A
There's
a
few
benefits
one
is
that
we're
generally
encouraging
people
to
use
csi,
but,
more
importantly,
at
least
on
aws
and
possibly
on
azure.
I'm
still
looking
into
this.
It's
a
lot
safer
from
a
credential
point
of
view.
If
you
use
the
csi
plug-in
for
aws,
rather
than
our
aws
plug-in
and
then
so
so
we're
going
to
bring
to
ga
the
aws
and
azure,
which
we
know
do
have
a
data
mover
underneath
everyone
else
or
every
other
place,
we're
going
to
have
big
letters.
A
Somehow
saying
user,
be
very
careful
use
at
your
own
risk
and
then
once
we
get,
this
data
mover
moved
to
valero
in
a
few
releases.
My
understanding
is
that
we
may
hook
it
up
to
the
csi
plug-in
and
finally,
we
can
handle
environments
that
have
csi
snapshotting,
but
no
data
movement.
So
these
are.
This
is
also
an
investigation.
A
Because
again
the
team
who
is
here
now
has
never
worked
with
the
csi
plug-in.
So,
of
course
they
need
time
to
us
look
into
it.
Think
about
how
to
protect
the
user.
We
will
look
into
all
the
existing
open
issues,
because
maybe
there
are
bugs
that
we
need
to
fix.
We
just
really
don't
feel
like.
We
know
the
status
now
dave.
If
dave
has
any
institutional
knowledge,
we
probably
would
love
to
hear
it.
I'm
sure
we'd
love
to
hear
it,
but
just
so
you
know
this
is
going
to
be
so.
A
This
is
an
investigation
for
1
9,
so
110
we're
hoping
to
do
that.
Work
tentatively,
upload
progress.
We've
talked
a
lot
about.
We
want
to
understand
what
parts
dave
can
work
on
what
parts
we'll
work
on,
but
that's
certainly
boy.
We
want
to
get
that
all
done
for
one.
Nine
carbel
is
a
method
of
installation
that
is
used
in
tanzu,
so
we
have
been
working
on
the
packaging
for
vsphere,
but
it
is
open
source.
So
anyone
else
who
wants
to
use
karbel
to
install.
Please
do
so.
A
We
are
going
to
continue
improving
the
valero
testing,
dan
fung
and
and
when
and
others
and
ming
have
done
an
excellent
job
of
really
improving
our
testing,
and
we
want
to
continue
we'll
do
this.
Every
release
we
want
to
keep
investing
and
making
valera
more
trustworthy
and
users
can
trust
what's
happening,
cubic
builder
tech
debt.
I,
if
people
have
questions
on
that,
I
will
entirely
defer
to
the
engineering
team,
but
I
am
told
that
it
modernizes
our
code
base
and
is
worthwhile
to
do,
and
then
we've
got
a
few.
A
One
thing
is,
for
instance,
my
understanding
is
right
now,
when
the
valeria
server
fails,
it
doesn't
nice
kind
of
fail,
silently
it
doesn't
easily
surface
errors,
and
so
we
want
to
make
it
both
so
that
users
yeah
basically
provide
api
support
to
understand
what
user.
What
errors
the
valeria
support,
bolero
server
is
happening
is
is
throwing
we
have
two
related
to
backup
storage.
Oh
actually,
sorry.
A
Okay,
basically
backup
storage
location,
my
understanding
is
the
status
is
sometimes
temperamental,
even
if
the
backup
storage
location
is
actually
available.
Sometimes
it'll
show
not
available
so
this
one.
I
believe
these
two
are
very
closely
related.
This
one
is
kind
of
clarify
how
it's
working,
and
I
believe
that
this
is
a
fix
to
fix
the
status.
So
look
in
those
issues
and
feel
free
to
ask
more
questions,
but
again
it
should
make
it
clear
whether
a
backup
storage
location
is
actually
down
or
not.
A
We
want
to
fix
some
docs
issues,
we've
divided
them
into
two
categories
because,
as
we
plan
our
roadmap,
of
course,
engineering
time
is
limited,
so
we've
got
five
four
issues
that
require
engineering
input,
they're
very
three
of
the
four
very
general
issues
that
have
to
do
with
hey,
explain
how
a
restore
works
better,
adding
a
few.
So
a
user
asked
for
some
specific
examples:
how
to
do
a
cluster
migration,
because
our
cluster
migration
page
is
kind
of
small.
A
We
wanted
to
do
better
and
then
I
believe
it
was
rustic
and
volume
snapshot.
Examples
kind
of
saying
a
little
more
about
that,
which
is
a
pretty
basic
use
case
and,
lastly,
there's
something
about
oh
azure
service
provider
provision
permissions
anyways,
it's
one
of
the
four
here
if
you're
curious
as
13
upvotes,
so
clearly
a
lot
of
valeria
users
feel
this
pain.
So
we
really
wanted
to
try
to
solve
that,
and
we've
got
two
that
we
hope
to
get
in,
but
we
put
is
p1
because
they're
a
little
lower
priority.
A
A
Well,
you
know
what
I'm
going
to
pause.
If
we
finish
our
discussions
early,
I
will
keep
going
through
the
road
map.
I'll
merely
say
that
we've
got
actually.
You
know.
I
can
basically
finish
it.
Basically,
we've
got
some
smaller
p
ones
that
we
hope
to
get
to.
You
can
look
into
them
more
here,
actually
yeah,
and
then
this
one
in
particular,
is
kind
of.
We
don't
say
anything
about
belair
performance
or
resource
limits,
so
we'd
like
to
at
least
put
something
in
the
documentation.
A
A
A
It
allows
us
to
move
away
from
rustic,
which
is
not
ideal
in
a
number
of
ways.
It's
not
terribly
well
supported
and
it's
slow
and
other
issues
and,
for
instance,
copia,
will
come
with
encryption
at
rest.
Now
it's
not
a
feature
that
we
can
just
automatically
offer
to
valero
users.
We
don't
want
valeria
users
to
accidentally
hurt
themselves
by
losing
their
credentials,
so
we
have
to
think
carefully
about
how
how
to
offer
the
feature
to
valero
users,
but
copia
just
brings
a
whole
bunch.
A
I
should've
said
it's
a
repo,
an
open
source
repo,
so
we're
going
to
investigate
that
and
then
a
bit
more
docs
work
and
then
work
here.
That,
anyway,
might
depend
on
item
snapshot
or
maybe
or
on
upload
progress
or
maybe
upload
progress
depends
on
that.
This
one,
I
think,
may
change
in
the
next
week
or
two
depending
on
what
dave
tells
us,
so
that
was
a
lightning
fast
going
through
one
nine
any
questions
or
comments,
oh,
and
by
the
way
sean
had
commented
at
the
very
top
giving
feedback.
A
We,
I
believe
daniel
replied.
I
asked
daniel
about
this
and
I
don't
think
we
managed
to
get
a
comment
yet,
but
we
will
comment
on
that.
Sean
also
asked
for
parallelization.
We
totally
totally
want
to
do
that.
We
just
feel
like
there's
enough
investigations
in
one
nine
that
we
don't
really
want
one
more
unless
sean
wants
to
do
it,
but
we
are
very
excited
to.
A
We
are
absolutely
in
line
that
we
want
to
do
parallelization
as
well,
and
we're
just
slightly
higher
prioritizing
bringing
the
csi
snapshotter
to
ga
the
data
mover
and
the
copia,
because
they're
just
so
impactful
and
rafael
less
relevant
now,
because
he's
actually
working
on
something
else,
so
we
already
talked
to
him.
Okay,
let
me
pause
any
questions.
Comments.
C
Yeah
a
quick
question,
I
know
at
one
point
the
plug-in
versioning
was
pushed
from
one
eight
to
one
nine.
It
sounds
like
that's
pushed
again
out
of
one
nine
at
this
point.
A
Basically,
bridgette,
because
that
was
kind
of
something
that
bridgette
was
owning
right.
A
Don't
have
a
natural,
and
I
know
that
fong
was
considering
working
on
it,
so
ifong
wants
to
work
on
it,
that's
great.
Basically,
in
short,
if
it's
something
we
need,
you
know,
this
is
how
we've
prioritized.
If
anyone
wants
to
jump
in
and
work
on
it,
we
would
encourage
you
to.
B
B
Okay,
scott,
before
before
brilliant
left,
we-
and
we
are-
we-
went
through
the
design
she
refined
it,
and
I
think
it
looked
better
now,
because
previously
there
was
some
confusion.
Why
didn't
you
check
the
latest
update
in
the
design
and
yeah.
C
B
Yeah
yeah,
the
the
reason
we
didn't
put
it
in
the
1
9
is
that
we
don't
feel
there
is
a
very
urgent
requirement
requiring
this
mechanism.
If
there
is,
we
can,
you
know,
consider
you
know,
address
the
project.
C
Yeah
and
that's
that's
one
thing
I
think
on
our
side,
we'll
need
to
look
at
as
well,
because
I
know
we
have
a
use
case.
Basically
on
our
with
with
our
plug-ins
with
openshift.
We
have
an
issue
with
image
stream
tags
where
we,
we
have
a
race
condition
that
really
needs
a
new
plug-in
methods
to
resolve,
and
so
this
is
something
that
we
were
kind
of
waiting
on
to
get
something
in
place.
For
that
I
I'll
need
to
talk
to
dylan
about
this
offline
to
see.
C
I
I'm
not
sure
if
that
priority
is
lowered
for
us
now
or
it's
the
same
as
it
was
because
I
actually
had
an
initial
kind
of
proof
of
concept
to
how
to
fix
the
problem
which
modified
the
plug-in
interface.
So
we
actually
couldn't
get
that
in
the
code
base.
We
need
to
wait
for
plug-in
versioning,
because
the
fix
involves
adding
a
new
method
to
the
restore
item
action
plug-in.
So
we
obviously
can't
change
that
until
we
have
plug-in
versioning.
C
Yes,
that's
true,
that
was
that
that
was
yeah.
That
was
the
other
use
case,
and
I
know
I
know
that
was
the
case
that
fung
had
I'm
not
sure
yeah.
D
So
the
problem
we
are
facing
is
right,
for
this
is
for
for
an
app
consistency,
use
cases
unless
we
can
guarantee
defined
timeout.
We
can't
like
use
the
pre
and
post
hooks
to
say
lock
a
database
on
google
database
because
there
is
no
guarantee
when
done
post,
hopefully
yeah.
C
Right
so
so
we
do
have
two
use
cases
that
need
this.
It's
just
a
question
of
figuring
out,
you
know
getting
the
design
finalized
and
then
having
someone
to
have
time
to
start
working
on
it.
It
sounds
like.
A
Dare
I
say
this
is
where
I
want
daniel
and
others
engineers
to
speak
up,
but
if,
if
you
know
as
as
you're
saying
for
one
nine,
if
you
have
engineers
to
work
on
it,
I
think
that
the
team
would
we'll
still
we'll
certainly
work
to
get
it
in.
If
you
don't,
then
we
can
definitely
have
a
more
serious
conversation
for
110
about
it.
Yep.
C
B
Because
the
plugin
framework
is
a
very
fundamental
mechanism
in
the
lateral,
so
probably
before
we
ga
we
want
to
do
some
poc
and
verify
the
design.
So
it
may
take
a
really
long
time.
C
So
I
was
just
gonna
say
ideally
really
before
we
release
this.
Not
only
do
we
need
to
actually
implement
this
feature,
but
then
we
need
to
implement
the
use
cases
on
top
of
that,
so
that
we
have,
you
know
the
the
timeouts,
for
example,
and
then
this
to
this
other
case
for
the
the
additional
items
plug-in,
because
if
you
don't
have
the
you
know
you
you
versioned
it,
but
unless
you've
added
something
to
that
version,
you
know
it's
hard
to
sort
of
prove
that
it's
doing
anything
useful
until
you
actually
have
those
changes
there.
C
So
this
is
that's.
You
really
need
to
have
all
three
of
those
together
in
a
release,
whether
it's
one,
nine
or
110.
You
know
it's
just
but
they're
all
going
to
depend
on
each
other,
because
we
can't
even
really
start
working
on
these
other
features
that
depend
on
the
version
until
the
versioning
design
has
worked
out,
and
you
know
ready
to
get
committed
to.
B
Yeah
yeah,
so
I
envisioned
that
the
versioning
and
the
actual
feature
that
rely
on
the
virgin
may
be
g8
in
one
version,
because
before
that
we're
gonna
do
a
lot
of
poc
and
verify
the
design
if
there
is
a
concrete
implementation
that
leverage
that
versioning
mechanism-
and
we
feel
this
solid,
offering
we
just
ga
the
versioning
mechanism-
and
this
feature
together-
that's
right.
I
think
yeah.
C
B
So
it's
not
really
yet,
but
yeah
yeah,
I
actually
they
have
the
same
feeling
regarding
the
upload
progress
monitor.
Are
we
gonna
ga
the
plugin
type?
First,
then,
in
some
filter
version
to
deliver
the
item,
snapshot
or
plugin
implementation
or
vga
some
thing
together.
F
Well,
I
mean
the
item
snapshotter
plug-in
we
put
in
right
that
that
got
loaded
into
one
one,
eight
actually
right,
so
we
can
look
at,
for
example
like
maybe
even
with
the
csi
snapshotter.
C
F
Look
at
moving
that
into
the
item.
Snapshotter,
the
one
of
the
things
that
I
thought
we
should
look
at
in
terms
of
the
csi
plug-in
is
the
csi
plug-in
is
not
a
volume
snapshotter.
F
B
Okay,
I'll
yeah
yeah
I'll
reach
out
to
you
after
I,
you
know
we
do
some
investigation
and
we
can
continue
the
discipline
yeah.
I'm
also
thinking
it
may
make
sense
to
ga
the
css
plugin
after
it's
transformed
to
item
snapshots,
but
we
need
to
look
at
the
timeline
because
there
are
some
dependencies
like
we
still
probably
want
to
leverage
that
and
etc.
B
But
yes,
yes,
but
yeah,
there
are
some
details.
Last
time
I
checked
with
the
you
know
the
guys
in
the
vco
team.
A
So
that
so
scott,
hopefully
we
kind
of
answer
that
question.
Does
anyone
have
any
other
questions
about
the
roadmap
before
we
move
on
to
4080
daniel's,
fun,
new
bug.
A
Okay,
so
daniel
I'll
stop
sharing-
and
you
said
you
want
to
share-
is
that
correct
and
may
I
just
suggest
by
the
way,
looking
at
the
plan
for
today,
we've
covered
the
road
map,
so
daniel's
gonna
talk
about
40
80
and
we've
got
two
other
prs
to
discuss.
So
I'm
gonna,
let's
try
to
time
box
you
daniel
to
ten
minutes
and
we'll
see
where
we
are
and
that
way
everyone
gets
10
minutes,
and
then
we
have
five
minutes
of
wiggle
room.
Does
that
sound?
B
B
So
the
issue
is
caused
by
the
crd
remapping
plugin,
which
is
the
backup
item
action
plugin
that
try
to
fetch
the
crd
via
v1
beta1.
If
the
the
the
item
to
backup
is
a
v1crd,
but
it
has
violation.
B
So
so,
when
user
upgraded
to
the
kubernetes
version
122,
this
plugin
caused
the
issue
because
for
some
input,
v1
crd
it
has
violation.
Then
the
plugin
tried
to
back
up
the
crd
via
v1
beta
1
api,
but
it
does
not
exist
in
kubernetes
122
it
was
removed.
B
Then
the
backup
failed,
and
this
issue
was
open
and
really
did
some
initial
investigation,
and
her
suggestion
is
that
we
should
just
document
and
make
sure
that
user
upgrade
all
the
v1
beta
1
crds
to
the
v1.
In
the
you
know,
the
new
version
of
kubernetes
before
he
started
to
you
know,
use
valero
to
do
the
backup,
but
there
is
some
disagreement
here
like
first
there's
a
lot
of
work.
Second,
there's
some
disagreement
and
people
are
trying
to
fix
it,
and
I
did
some
investigation.
B
I
think.
Actually,
we
have
two
choices.
First,
we
just
do
what
what
bridgette
suggested
and
make
the
plugin
fail
early.
So
if
there
is
a
violation,
user
need
to
fix
their
crd,
and
second
probably
we
can
change
the
code
in
the
crd,
remapping
plugin,
because
I
noticed
there
is
a
restore
item,
action
to
modify
the
preserved
unknown
field,
which
is
one
of
the
violation
caused
by
the
old
crd
format.
B
B
So
the
content
that
is
backup
may
be
invalid
for
v1
crd,
but
we
can
leverage
this
resource
item
action
plug-in
to
mitigate
it,
because
the
most
cases
mentioned
in
this
thread
is
related
to
this
field.
So
I
briefly
discussed
chanting
about
these
two
choices.
Yesterday,
first,
we
failed
early
and
that
user
fixed
the
theory.
Second,
we
yeah
just
the
the
second
option
I
mentioned,
but
there
is
a
risk
that
the
crd
that
is
backed
up
may
be
invalid,
so
it
failed.
B
If
user
will
see
this
issue
when
they
do
the
restoration
well,
many
of
the
cases
will
be
fixed
by
the
resource
item
action,
but
some
may
still
fail.
If
that
happens,
you
will
need
to
fix
the
v1
beta
1
cre
in
the
source,
cluster
and
backup
again
or
they
need
to
write
a
resource
atomizer.
Maybe
we
can
enhance
the
resource
item.
Action
plugin
to
you
know,
handle
this
migration
scenario
better.
B
F
B
B
F
So
I'm
just
thinking
you
probably
don't
want
to
like
silently
delete
fields
or
anything
like
that,
because
then
you
don't
know
that
it's
happening,
but
would
it
make
sense
to
let
the
remap
plug
in
give
it
some
options?
And
you
could
add
you
could
let
the
user
add
in
fields
that
are
going
to
be
ignored
or
deleted
on
restore.
B
Actually,
the
remap
at
the
remap
actually
remap
plug-in
it's
a
backup
at
the
macro.
What
it
does
is
it's
check
the
content
of
the
v1
crd.
If
it
has
violation
or
some
condition
it
meets
some
condition,
it
will
try
to
get
the
crt
via
v1
beta1
and
in
v1
and
beta1.
There
is
no
such
evaluation
because
that's
a
valid
crd
for
v1
beta1.
B
No,
the
the
issue
is
that
plugin
stop
working
in
version
122
coronations,
because
there
is
no
v1.
B
So
currently,
there
is
no
issue
in
resort
because
the
backup
fails,
but
then
there's
some,
you
know
unhappiness
from
users
so,
and
I
also
noticed
that
nola
added
very
early
there
is
a
resource.
I
can
try
to
fix
this
issue.
It's
not
removing
this
field,
silently
it
has
done
some
migration
according
to
the
suggestion
in
kubernetes
documents,
but
the
impact
for
that
is.
B
We
don't
have
resources
action
to
handle
all
the
violations
and
it
it
can
be
tricky
because
we
cannot
test
all
the
scenarios
so
yeah,
I'm
a
little
hesitant
regarding
which
option,
but
since
genting
is,
has
some
strong
opinions.
The
second
is
better.
F
B
Yeah
yeah
that
that
happens
only
when
we
are
dealing
with
crds.
B
Yeah,
so
any
comments
yeah,
I
think
I'll
leave
it
the
issue
and
pr
open
for
another
couple
of
days.
So
it
seems
we
are
going
to
move
on
with
this
option
tool.
A
Sounds
good,
okay,
great
and
you
did
very
well
within
time.
You
had
a
minute
and
50
seconds
left
well,
folks
can
think
for
the
remainder
of
this
meeting.
If
we
have
a
little
extra
time
at
the
end,
we
can
kind
of
return
to
this,
but
thanks
daniel
for
walking
us
through
that.
A
The
next
is,
I
see
we
have
a
pr
4613..
Does
whoever
want
to
talk
about?
Do
you
want
to
share
your
screen
or
do
you
want
me
to.
A
So
yeah
tell
us
tell
us
what
you
want
to
talk
about.
Share
your
screen
and
we'll.
G
So
this
is
this
cool
request
is
regarding
the
design
for
adding
support,
for
so
there
are
two
pr's.
Actually,
let's
just
discuss
this
one
first,
so
the
first
one
is
adding
additional
spec
field
call
existing
resource
policy
on
the
restore
api.
G
So
this
is
this
design
only
pertains
to
kubernetes
resources
and
not
pv
data,
and
as
such,
and
so
in
the
last
discussion
we
were
asked
to
add
some
non
goals
and
update
the
use
cases.
So
I
did
that
and
also
wanted
to
discuss
whether
or
not
we
should
go
ahead
with
the
approach.
One
I'll
give
some
background
about
the
approach
number
one.
So
in
this
approach
we'll
be
just
adding
existing
resource
policy
spec
to
the
restore
api,
this
spec
will
be
able
to
take
in
three
policy
types
like
none,
update
and
update
all.
G
So
basically,
if
you
see
in
the
summary
table,
none
preserves
the
existing
value
of
behavior
and
no
action
is
performed
similarly
for
the
logging
as
well.
But
if
you,
if
the
user
specifies
update
policy
in
the
restore,
then
valero
will
try
to
patch
on
the
change
resource.
Let's
say
some
service
has
mutated
or
secret
has
mutated.
It
will
try
to
perform
a
patch,
and
it
will
also
warn
the
user
if
the
patch
fails
like
if
the
patch
is
regarding
some
immutable
fields.
G
G
B
This
one
was
not
on
my
radar.
I
added
some
comments
regarding
the
other
design,
but
this
one
I
haven't
checked.
I
need
to
look
into
details.
Currently,
I
think
the
non-policy
is
a
very
early
design
decision.
I'm
not
sure
I
believe
they
have
discussed
other
possibility.
B
You
know
to
handle
the
restore
when
the
resource
already
exists
in
the
target
kubernetes
clutter,
but
they
choose
to
just
skip
it's
simpler
to
implement
and
it's
very
predictable.
So
I
I.
F
C
C
Additional
and
we
also
envision
possibly
adding
future
policies
like
one
one
policy
that
someone
had
suggested,
for
example,
is
that
you
know
to
handle
immutable
fields
is
if
you
really
want
to
make
sure
that
the
object
is
there,
we
could
actually
have
a
policy
that
would
delete
and
recreate
items
we're
not
proposing
implement
now,
because
that's
that's
potentially
destructive
hard
to
get
right.
We're
just
not
thinking
about
that
now,
but
that's
a
possible
future.
You
know
a
policy
you
could
add
as
well.
Yeah.
B
Yeah,
but
my
concern
is
the
updating
update,
oh
update,
all
seems
a
little
straightforward,
though
I
don't
know
the
use
case,
but
the
update
you
try
to
patch
it.
You
need
to
calculate
the
delta
correctly
and
pat
it
and
some
may
fail
may
succeed.
So
I
think
this
may
cause
some
unpredictable
results
and
I
I
wanna
understand.
I
hope,
I'm
not
sure
if
anyone
in
this
meeting
have
involved
in
the
very
early
phase
of
valero
when
they
choose,
you
know,
use
the
non-policy
for
all
resources.
C
Yeah
that
that
that
all
that
decisions
were
was
recently
made
before
I
was
involved
here,
I
also
wanted
to
clarify
you.
It
mentioned
the
update
all
the
use
cases.
The
basic
basically
update
all
is
mostly
like
the
regular
update.
The
difference
is
that
anytime
valera
restores
a
resource,
we
have
a
label,
that's
the
labels.
What
backup
was
was
used
and
the
the
update,
all
okay,
and
so
in
the
case
where
the
resource
exists.
Already,
so
you
know,
say
you
have
a
backup
one
and
you
restore
it.
C
You
know
if
you
have
a
failover
cluster,
so
today
I
do
a
backup
restore
to
the
failover
cluster
tomorrow.
I
do
another
backup
and
restore
it
to
the
failover
cluster
for
resources
that
didn't
change
between
today
and
tomorrow.
I
still
have
that
original
resource,
which
means
the
failover
cluster.
If
you
look
at
it,
you
don't
know
that
that
object's
been
consulted
and
updated.
C
So
the
update
all
basically
would
update
those
labels
even
for
the
unchanged
resources
and
the
use
case
for
this
is
you
know,
say
I
delete
a
resource
in
the
live
cluster
after
backup.
One
backup
two
is
not
there
anymore.
So
when
I
restore
that
to
the
cluster,
the
resource
that
was
deleted
will
not
have
an
updated
label,
which
means,
if
I
want
to
then
after
I
restore
to
that
cluster,
have
some
offline
action
that
deletes
anything
from
an
old
backup.
C
I
can
use
those
labels
because
we've
updated
the
labels,
so
that's
the
reason
for
the
update
all
is
basically
to
to
allow
the
labels
to
get
updated
even
for
resources
that
haven't
changed
since
the
last
restore
in
terms
of
what
the
resources
look
like
in
the
cluster.
C
We,
you
know
we're
still,
you
know
if
the
resource
is
already
there,
we're
not
changing
anything,
but
if
it's
changed
and
it's
there,
then
we're
updating
it
so
that
that's
kind
of
the
the
thinking
around
that
and
as
you
as
you
mentioned,
the
restore
the
patch
could
fail
in
some
cases.
I
think
in
the
case
where
a
patch
fails.
It
ends
up
looking
like
the
current
policy,
because,
basically
you
try
to
patch
something
the
patch
fails,
which
means
the
resources
unchanged
and
we
have
a
warning.
C
B
C
Right,
exactly
and
and
and
the
one
one
one
reason
that
would
definitely
cause
the
update
to
fail
is
if
the
res,
if
the
thing
you're
trying
to
restore,
is
different
in
some
immutable.
You
know
field,
because
if
you
try
to
patch
a
resource
and
change
an
immutable
field,
then
the
kubernetes
update
or
patch
is
going
to
fail,
because
it's
immutable
fields,
and
so
then
we'll
have
the
valeria
log
with
the
failure
and
showing
that
warning.
C
Yeah
exactly
yeah
yeah,
so
basically
because
you're
showing
what
because
you're
creating
a
warning
and
not
just
an
info
log.
If
you
do
a
valero
describe
on
that
restore
you
know
all
the
warnings
get
enumerated
there
on
that
output.
So
you
so
you'll
see
it
there
yeah.
B
Yeah
my
own
yeah,
I
I
think
we
need
to.
I
hope
I
can
talk
to
like
nolan
or
some
very
early
maintainer
of
valero
regarding
why
the
decision
was
made
and
regarding
the
update.
Another
concern
concern.
Currently
I
have
is
that
it
may
go.
I
see
in
future,
people
may
add
more
policy
and,
like
I
want
to
patch
this
field
now
that
field
we
need
to
control
the
complexity.
You
know
I
see
this
may
be.
B
C
C
Or
update
the
resource
or
if
we
decide
to
add
that
potentially
destructively
later,
you
know,
delete
and
recreate
again
the
policies
themselves,
even
if
the
implementation
is
complex.
But
then
it's
not
a
configurable
thing.
You
know
you're,
not
saying.
Oh,
I
want
to
update
you
know
this
spec
field,
but
not
that
spec
field,
because
you
know
that,
because
that.
B
B
It
definitely
yeah
yeah.
I
I
think
I'll
I'll
ask
someone
in
the
team
and
I'll
also
look
at
this
design,
and
we
need
to
discuss
again
later
because
I
haven't
read
through
this.
C
Yeah
and
yeah,
and
if
anybody
does
have
any
other
insight
from
kind
of
early
discussions,
I
know
there's
a
linked
issue
where
some
issues
were
discussed
around
that
kind
of
ahead
of
time,
which
is
we
were
kind
of
basing
this
partially
on.
C
F
Yeah,
I
mean
you
know
we
had
some.
We
we
have
discussions
about
this
periodically.
You
know
when
nolan
was
here,
because
people
people
ask
this
feature
fairly.
Often
it's,
I
think
it's
strictly
conservatism
in
terms
of
not
wanting
to
open
the
can
of
worms
of
of
what
happens
when
you
start
updating
on
the
restore,
but
you
know
the
approach
being
taken
here.
Let
you
select
that
behavior
and
I
think
it's
worthwhile
to
try
it
out
and
see.
You
know
what
kind
of
trouble
we
get
into.
C
C
To
me
just
again,
just
looking
at
kind
of
high
level
with
what
we're
proposing
here
is
that
you
know
it
seems
that
the
patch
itself
ought
to
be
a
relatively
safe
thing,
because
you
know
either
you
succeed
in
modifying
the
object
or
you
don't,
and
you
warn,
and
you
put
a
warning
here
and
so
from
the
point
of
view
of
you
know:
data
integrity,
I'm
not
seeing
any
obvious
cases
where
this
is
adding
risk,
but
obviously
you
know
so
that's
aside
from
the
risk
associated
with
any.
C
F
F
There's
something
new
right
that
you
know
got
added
afterwards.
It
depends
on
the
first
thing
that
you're
patching
backwards.
So
I
I
think,
there's
a
lot
of,
I
think.
There's
some
good
use
cases
for
this.
I
think
there's
a
lot
of
ways
to
get
your
fingers
off
with
it.
I
think
you
know
it's
worthwhile
to
give
it
a
you
know
an
investigation.
F
A
Now,
by
the
way
we've
been
10
minutes
into
this
discussion
and
I
do
sh
shubham,
I
think,
do
you
have
the
other
pr
as
well.
G
A
G
C
Yeah,
sorry,
just
just
a
general
comment
about
both
of
these,
because
I
know
we
had
these
we've
had
these
pr's
up
a
couple
of
weeks
now
and
we're.
Obviously
it's
great
now
that
we're
getting
more
discussion
around
it
and
hopefully
get
some
feedback
on
you
know
we
just
we
need
to
go
to
a
point
relatively
soon.
You
know
if
we
want
to
get
these
into
one
nine,
where
you
know
we've
got
enough
feedback.
We've
got
enough,
you
know
approval
to
have
to
say
yeah
like
okay.
This
is
good
to
go.
C
I
mean
I
don't
want
to
rush
anything
of
course,
but
at
the
same
time
I
want
to
make
sure
that
you
know
providing
feedback.
Has
the
kind
of
level
of
priority
for
the
team
so
that
we
can,
you
know
eventually
say:
okay,
we
have
approval,
we
have
sign
off.
This
is
good.
Shabam
can
go
and
you
know
start
putting
a
implementation.
C
Actually,
we
already
have
a
couple
of
poc.
You
know
prs
relating
to
this
anyway,
but
you
know
once
we
have
a
design,
that's
approved,
then
those
then
then
we
can
start
reviewing
those
pr's
as
well
and
looking
at
the
use
case,
to
see
if
there's
any
use,
cases
that
are
mis,
you
know
missed,
but
obviously
we're
not
going
to
be
reviewing
any
of
those
implementation
prs,
because
they're
kind
of
at
a
draft
level
until
with
the
design
itself
is
signed
off.
C
You
know,
because
we
know
at
this
point:
the
design
is
still
subject
to
change
until
it's
approved.
A
And
there
I
get
ask
like
I,
I
totally
hear
what
you're
saying
you're
trying
to
develop
for
your
own
feature,
your
own
product
and
obviously,
if
we're
slower
with
cycles
you,
you
can't
meet
your
deadlines.
I
assume
you
would
have
to
fork
if
you
well,
you
might
have
to
fork
or
something
all
this
to
say.
Is
I
really
yeah?
We
really
do
want
to
encourage
other.
You
know
outside
contributors
from
just
the
vmware
team,
so
I
think
that
we
will
try
to
do
better
at
pr
review.
A
C
We
have
two
versions
of
it
and
the
other
thing
we've
done
in
the
past
and
we've
actually
backed
this
out.
We
don't
want
to
do
this
anymore.
Is
I
don't
want
to
make
any
changes
that
modify
crds
that
aren't
upstream?
First.
A
Well,
don't
get
me
wrong,
I'm
not
blaming
you
for
forking
in
the
path
I'm
merely
pointing
out.
If
you
have
to
fork
it
stinks
for
you
all,
because
forking
is
tough.
We're
missing
we're
missing
contributions
from
you
all
who
could
improve
valero
directly.
So
I
really
for
one
night
we're
hoping
to
kind
of
come
out
with
a
pr
review,
sla,
not
merging,
but
certainly
responses.
So
we
can
keep
the
conversation
going
and
we
will
definitely
prioritize
other
issues
in
one
night.
If
you
need
to.
C
And
again,
because
both
of
these
involve
crd
changes
that
that's
a
specific
area
where
I
really
don't
want
to
mess
with
forking,
because
you
know
the
crds
are
different.
All
of
a
sudden
things
get
a
lot
messier.
You
know
if
it's
a
bug
fix,
you
know
if
we
have
to
get
it
in
for
a
deadline
and
then
push
it
upstream.
That's
fine!
You
know,
as
long
as
in
the
you
know,
eventually
they
all
get
reconciled
and
they're
the
same.
But
when
you
start
talking
about
api
changes,
you
know
I
went
upstream
first.
A
Sounds
good
yeah,
so
I
think
we
definitely
had
well
the
the
majority.
C
H
C
H
I
can
jump
in,
and
I
briefly
mentioned
selena
I'm
still
working
on
kind
of
formally
drafting
up
an
explanation
of
kind
of
how
our
existing
release
cycle
has
worked
and
how
we're
trying
to
change
it.
But
you
know
we
have
customers
that
rely
on
valero.
We
have
our
own
release
cycle
where
we're
trying
to
avoid
the
process
that
we've
gotten
to
in
the
past.
H
It's
a
bad
pattern
of
essentially
carrying
crd
fork,
fixes
and
then
having
to
rebase
it
when
we
pull
the
new
releases,
we're
trying
to
say
more
into
like
the
upstream
tip,
we're
probably
looking
at
you
know
three
to
four
months
out
trying
to
get
another
release
cut
that
can
include
this
fix
and
we'd,
ideally
like
to
replace
it
on
an
actual
release
branch
for
valero.
H
You
know,
obviously,
we're
willing
to
there's
already
an
existing
schedule
for
valero
we're
not
trying
to
change
that,
but
you
know
like
the
the
existing
governance
funnel
for
valero,
since
I've
been
a
part
of
it
as
like.
If
the
design
approve
design
gets
approved
and
gets
merged,
it's
slated
for
the
next
release.
I
think
we're
just
looking
for.
H
Maybe
not
it's
tough
for
us
to
be
able
to
spin
our
wheels
for
three
weeks
waiting
for
feedback
on
the
design
or
we're
trying
to
get
it
implemented,
and
then
that's
how
we
always
end
up
implementing
these,
like
you
know,
halfway
fixes
on
our
end
that
end
up
changing
upstream
and
then
we
have
this
rebase
hell
to
go
through.
H
B
C
C
Depends
on
how
quickly
things
move
I've
seen
it
go
both
ways
for
a
really
big
feature.
That
tends
to
be
that
way,
because
you
know
you
spend
a
few
months.
You
know
for
a
big
feature
that
affects
a
whole
bunch
of
the
code
base.
That's
the
norm
for
smaller
features,
I've
seen
where,
especially
where
you
know,
if
you
get
a
design,
that's
approved
that
everyone's
kind
of
said.
Look
we
like
this
and
it's
relatively
isolated
in
the
code.
It
changes.
G
C
C
But
my
point
is
that
if,
if
just
just
to
just
assume
these
two
get
approved,
say
one
week
from
today,
we'll
probably
have
a
pr
ready
to
be
reviewed
within
a
week
or
two
after
that.
That's
just
you
know,
throwing
numbers
out.
You
know,
but.
H
Yeah
you
know,
historically,
I
think
I've
been
around
vladimir
for
a
while
there's
a
lot
of
people
that
will
submit
designs
and
expect.
Maybe
the
core
valero
team
to
you
know
implement
that
and
that's
not
what
we're
asking
it's
like
yeah.
You
know
we
would
definitely
do
the
work
to
get
it
implemented
to
ensure
that
cuts
that
we
lose
quickly
yeah.
Maybe
that's
a
little
bit
different
to
have
the
existing
hey.
I
need
this
design
feature,
but
I'm
not
going
to
implement
it.
That's
not
kind
of
what
we're
we're
pitching
here.
H
C
Yeah
and-
and
I
think
that's
a
good
point
to
it-
you
know
in
cases
where
you
know
when
one
group
of
people
has
the
design
in
mind,
but
they
don't
have
the
resources
to
write.
It
then
clearly
that's
going
to
get
pushed
off
to
next
release,
but
you
know
it's
almost
you
know
some
of
these
features
are
like
okay.
C
I
need
this
done,
so
I'm
going
to
write
the
design,
I'm
going
to
get
this
van
approve
and
then
I'm
going
to
immediately
write
start
implementing
it,
and
so
in
that
sense
you
know
you
have
a
design
and
followed
by
an
implementation
that
might
be
very
close
to
each
other,
because
the
same
person
who
puts
the
design
together
once
it
gets
approved,
is
actually
already
has
the
cycles
available
and
allocated.
You
know
to
work
on
that
implementation.
C
G
C
B
Would
that
sound
like
for
you.
C
I
I-
and
this
may
be
a
question
as
much
for
dylan
or
eleanor.
I
see
kind
of
these
two
two
different
questions.
You
know
this
is
a
feature.
Do
we
want
this
at
all?
If
we
do
want
it,
does
this
design
make
sense
whether
it's
in
1,
9
or
110
or
111?
That's
a
different
question
that
you
know
you
know.
In
other
words,
we
could
approve
the
the
design
today
and
still
say
we're
not
going
to
work
on
this
for
two
months
because
we're
not
you
know
this
is
a
low
priority.
C
B
Yeah,
my
my
concern
is,
you
know,
as
I
mentioned,
and
I
I
think
they've
reached
some
good
point
regarding
the
rollback
scenario
and
yeah.
That's
my
current
comment
and
I
I'll
need
to
take
a
look
and
I'll
add
some
other
guys.
Take
a
look
they
if
you
have
any
comment.
Please
also
add
to
this
deal.
I
think
that's
all
we're
gonna
do
for
this.
One
yeah.
F
H
Well,
we
have
implemented
actually
we've
demoed
it.
So
this
isn't,
I
think,
we're
we're
more
just
kind
of
stalled
in
like
a
holding
pattern
in
terms
of,
if
there's
any
feedback
towards
the
design
at
all,
because
we
have
implemented
it.
We've
tested
it
with
the
use
case
that
our
customer
needs
and
it
does
work
for
that
use
case.
So,
okay,
I
totally
understand
dave.
C
I
don't
know
if
it
needs
to
be
or
not
that's
a
big
question
for
day
for
someone
else,
but
I
think
we
do
need
to
make
the
you
know
whatever
documentation
is.
Part
of
this
feature
needs
to
be
clear
on.
I
think
what
some
of
those
risks
might
be
for
choosing
things
and
to
make
it
clear
that
you
know
this
choice.
Is
you
know
preserving
legacy?
Behavior.
This
choice
means
this
other
thing:
here's
the
risks.
You
know
that
kind
of
thing.
F
C
Maybe
legacy
is
kind
of
fragile.
You
know
what
I
mean
is
current
behavior.
You
know,
in
other
words,
if
you
choose
none,
what
you
get
out
of
valero
was
identical
to
the
behavior
before
this
feature
was
added,
whether
you
want
to
whether
that's
called
legacy
behavior
or
previous
behavior.
You
know
the
point
is.
E
C
F
C
C
F
H
Oh
okay,
I
don't
want
to
beat
a
dead
horse
here,
but
I
think
we
discussed
this
too
at
the
community
hall
a
week
and
a
half
ago
or
two.
I
I
totally
agree
that,
like
there's,
definitely
potentially
inconsistent
behavior
that
could
result
from
this,
but
at
the
end
of
the
day
like
if
valero
is
a
tool,
we
don't
want
to
necessarily
safeguard
it.
When
users
may
know
exactly
what
they
need
out
of
the
tool
right.
So.
C
E
C
I
back
up
to
say
these
two
things
need
to
need
to
work
together
and
then
I
restore
those
two
things.
One
of
those
two
things
is
an
old
object.
It
doesn't
get
the
configuration
that
points
to
its
secondary
object
or
whatever,
and
so
that
risk
of
inconsistent
behavior
is
already
there.
If
you
have
a
name
status
with
some
of
the
resources
there
already.
A
Can
I
ask
a
really
naive
question
that
plays
into
like
how
do
we
protect
users
from
hurting
themselves,
plus
it
also
plays
into
the
csi
plug-in
brought
to
ga?
A
Do
you
think
it's
reasonable
to
assume
that
most
most
users
are
using
the
cli,
and
so
then,
if
we
they
install
the
cli
plug-in,
we
can
put
a
nice
big
block
of
text
that
says,
watch
out
not
durable
blah
blah
and
for
your
feature.
Similarly,
is
there
a
place
in
the
plug-in
where
we
can
kind
of
after
they
run
a
certain
command
or,
and
maybe
these
are
two
different
cases?
Maybe
your
feature
would
not
allow
that.
I
guess
my
question
is:
can
we
at
least
put
a
nice
big
block
of
text
of
like
watch
out.
C
H
C
Although
now
that
I'm
describing
what
I
was
just
saying
before
about
the
fact
that
the
the
nun
behavior
is,
I
think,
just
as
susceptible
to
this
to
this
kind
of
watch
out,
I
I
think
really
you
have
to
watch
out
either
way
because
you
know
basically
we're
talking
about.
You
know
if
you're
updating
things
that
are
already
there
and
you
don't
really
update
everything.
You
know
you
might
have
inconsistent.
C
You
know
cluster
behavior,
but
at
the
same
time,
if
you're
not
updating
anything
but
you're,
getting
all
the
new
resources,
you
still
have
that
risk
of
inconsistent
clusters.
Anytime,
you
restore
to
a
cluster
that
has
some
of
the
things
already
there
you
have
that
risk
already.
I
don't.
I
don't
know
that
this
feature
increases
the
risk
it
might
you
know
I
don't
know
that
it
decreases
it.
It's
essentially
you're
changing
from
you
know
some
amount
of
risk
to
some
different
amount
of
risk,
which
is
probably
similar
in
in
scope.
F
F
F
Right
and
and
then
but
this
feature
does
so
now-
we're
we
start
to
do
you
know
this
patching
in
place,
I'm
not
against
it
right.
I'm
just
saying
that
we
need
to
be
very
clear
with
people
like
you
know.
You
really
do
need
to
know
what
you're
doing
and
like
if
you,
if
you
expect
that,
for
example,
you're
just
going
to
roll
your
cluster
back
magically
to
where
it
was
at
yesterday,
and
this
is
your
production
cluster.
Maybe
you
maybe
that's
not
what
you
want
to
do.
F
C
F
A
Well,
I
we
are
over
time.
We
did
not
get
a
chance
to
look
at
the
second
pr.
Might
I
suggest
that
we
really
appreciate
you
coming
clearly
you're
eager
to
get
these
reviewed.
We
will
do
our
best.
Ideally,
ideally,
the
team
can
maybe
talk
today.
The
beijing
team
can
talk
today
and
at
least
respond
when
we
plan
to
review
it
to
give
you
a
kind
of
a
predictability
in
the
next
few
weeks.
A
Hopefully
we'll
develop
an
sla
as
we
talked
about
and
and
dare
I
say,
just
an
idea,
just
a
general
thought,
because
I
know
the
pr
review
is
onerous.
I
wonder
a
question
for
all
the
engineers
here
who
do
reviews?
A
Would
it
make
sense
to
like
have
engineers
look
at
an
initial
pr
and
then
actually
even
schedule,
half
an
hour
with
the
submitter
to
talk
through
the
pr
just
a
question
I
don't
know
like
I
I
used
when
I
was
an
engineer
in
the
day
I
really
enjoyed
kind
of
talking
through
code,
as
opposed
to
just
doing
a
code
review
by
reading
alone.
I
enjoyed
kind
of
talking
with
the
person
about
their
code,
but
just
a
question
about
how
to
get
these
done
faster
and
I
don't
know
yeah.
A
C
For
me,
you
know
it
kind
of
depends
on
the
kind
of
if
it's
a
code
pr.
It's
usually
easiest
for
me
just
to
look
at
the
code
common.
If
I
need
to
ping
someone
on
you
know
slack.
If
I
need
to
you
know,
sometimes,
if
there's
a
big
set
of
changes,
it
makes
sense
to
talk
through
it.
Sometimes
it
just
makes
sense
to
comment
on
it.
I
think
the
design
ones
are
a
little
bit.
C
It
doesn't
work,
and
I
think
too,
for
the
code
bug
fix
all
that.
You
know
we
have
the
system
in
place
that
auto
assigns,
which
you
know
seems
to
work
reasonably.
Well,
you
know
it's
still.
We
have
to
people
sometimes,
but
I
think
again
that
auto
assign
thing
doesn't
work
as
well
for
future
reviews
where
we
really
want.
Ideally,
we
had
more
than
just
the
two
reviewers
that
looked
at
it
I
mean
technically
two
reviewers.
C
B
C
B
What
you
so
you're
suggesting
the
sso
sla
is
mainly
around
pr
review
for
design.
Is
that
what
you're
saying?
Because
the
code
reveal,
I
think,
it's
relatively
in
good
shape?
If,
if
he's
panning
for
real,
we
just
add
someone
and
ask
him
to
take
a
look
but
yeah.
I
I
feel
also
this
feature
design
because,
like
the
post
prayer
hook
proposed
by
rafa
and
also
this
one
yeah,
I
was
not
responded
very
fast
because
it
was
on
my.
It
was
not
on
my
radar.
B
To
be
honest,
I
was
not
attending
the
community
meetings
in
the
u.s
time
zone,
so
I
think
we
probably
should
establish
an
sla
focusing
on
the
feature
design
pr
review.
Do
you
guys
think.
A
C
I
I
think
I
I
would
pretty
much
agree
with
everything
you
just
said.
I
think
there
are
exceptions
I
have
there.
There
have
been
pr's,
especially
pr's
that
have
been
forgiven
from
people
that
are
maintainers.
I've
seen
those
that
have
kind
of
sat
there
for
a
long
time,
and
you
know
it's
hard
to
say
too.
In
some
cases
you
know
these
were
old
pr's
that
were
submitted.
The
reviewers
are
not
necessarily
on
the
team
anymore.
I
mean
those
are
kind
of
exceptions.
I
think
I
think
in
general,
lately
bug
fix
code
change.
C
Prs
mostly
have
been
reviewed
relatively
time
in
the
timely
manner
and
when
they
haven't
people
have
been
good
about.
You
know,
focusing
people
say
hey,
you
know.
If
you
look
at
this,
I
know
I
know
you
know
sometimes
I'll
get
a
a
ping
on
slack
to
say,
hey,
look
at
this
pr
and
then
I'll
look
at
it.
You
know,
that's
fine,
I
don't
I
don't
mind
someone
poking
me.
If
I
haven't
looked
at
something
in
a
while,
because
you
know
you
get
busy,
you
know
you,
it
just
falls
off
the
radar.
C
You
know,
that's
fine.
I
think
those
the
design
ones
are
kind
of
a
special
case.
I
think
we've
historically
just
not
done
well
with
getting
to
those
in
a
timely
manner
and
the
challenge
there
is
those
are
the
ones
that
we
want
the
most
people
to
look
at,
because
you
know
we
want
to
make
sure
that
this
is
a
design
that
the
team
as
a
whole,
you
know
agrees
with
before
we
start
putting
code
in
place,
and
you
know
wanting
to
that's
get
reviewed
to
get
put
in.
C
I
would
say
for
this
one
pr
that
when
that
we're
not
getting
to
today,
if
people
could
look
at
that
and
provide
some
feedback
before
and
after
because
because
the
part
of
the
challenge
too,
with
the
the
flip-flop
meeting,
you
know
we
obviously
have
to
switch
to
meeting
times
because
of
the
time
zones,
but
this
other
one,
I
think
we
did.
Branch
may
bring
up
last
week
and
but
again
there
wasn't
actually
man,
I
don't
remember,
did
we
get
both
of
them
last
week
it
was
the
first
one
we
got.
C
We
went
to
both
times,
but
you
know
the
issue
was
that
the
design
came
out
last
week.
It
was
mentioned,
but
again
you
know
not.
Everyone
is
on
every
call
because
of
the
time
zone
issues,
so
we
didn't
get
to
this
week,
so
we
can
bring
it
up
again
next
week
and
talk
through
it.
But
again,
some
people
that
are
here
today
won't
be
here
next
tuesday.
So
that's
another
challenge
with
some
of
these
things,
so
I
I
would
say
for
people
that
aren't
going
to
be.
You
know
available
next
week.
C
B
C
A
I
think
that
there's
no
sla
for
like
how
long
it
takes
total
to
merge
in
a
pr
right
like
we,
I
think,
do
we
all
agree
that
really
the
important
thing
is
okay,
we
know
within
three
days,
we'll
always
hear
back
from
something
and
the
worst
it'll
be
we're
trying
to
do
this
we're
doing
our
best,
but
we'll
give
some
kind
of
response
within
a
few
days.
Hopefully.
C
C
That
brings
up
a
use
case
that
we
hadn't
thought
of,
and
then
that
goes
back
and
there's
a
major
change,
and
you
know
that
back
and
forth
could
take
weeks
and
it's
okay,
because
it's
back
and
forth
and
changes
are
being
made,
and
you
know
the
design
is
improving.
What's
frustrating
I
think
was
mentioned
is
that
you
know
cases
where
you
know
you
have
a
design
and
it's
out
there
and
it's
been.
You
know
two
weeks
and
there's
no,
you
know
you
don't
have
enough
feedback
to
move
on.
You
know
it's
like.
C
F
So
I
think
you
know
pretty
much
it's
a
matter
of
like
trying
to
improve,
so
I
the
issue's,
definitely
there.
I
think
that
everybody's
aware-
and
I
think
you
know,
there's
no
there's
not
like
a
magic
wand.
Anybody
can
wave
at
this
point
and
say
hey
if
you
do
this
it'll
get
better.
The
other
thing
I
was
going
to
suggest
is:
go
ahead
and
schedule
an
ad
hoc
meeting
to
discuss
a
particular
item
and
put
it
out.
F
You
know
on
the
mailing
list
and
you
know
figure
out
if
the
key
people
can
attend
at
whatever
time
it
needs
to
be,
and
just
you
know
dedicate
time
to
simply
going
through
that
community
meeting
is
great,
but
you
know
we
don't
always
have
you
know
that
much
time
to
go
through
one
issue,
so
there's
nothing
wrong
with
scheduling
additional
meetings.
We
keep
them
public,
but
I
I
would
do
that
too.
A
Right
so
I
think
we
have
a
and
dave.
I
really
like
that
you
gave
a
few
actionable.
I
first
of
all,
like
you
really
like
your
point:
let's
strive
to
improve
we're,
constantly
learning
and
changing,
and
definitely
your
point
about
exactly
reaching
out
and
really
pinging
people,
because
we
all
get
busy.
We
are
10
minutes
over
and
I
really
want
to
respect
people's
time.
So,
let's
stop
here,
but
we,
I
have
learned
a
lot
from
this
meeting
and
we
will
definitely
follow
up
on
the
things
we
talked
about.
A
So
thank
you
all
for
coming
and
have
a
good
night
or
good
morning
depending
yeah.
I
guess
not.
A
good
midday
have
a
good
night
or
good
morning,
depending
on
where
you're
located.