►
From YouTube: Geo Scheduling Call - 2019-11-08
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
A
B
B
A
Yeah
I
think
one
area
did
an
investigation
on
it
and
I
think
there's
nothing
that
we
can
do
on
this
issue
right
now,
but
he
pointed
to
follow-up
issues
that
could
be
worked
on
and
the
first
one
I
think
it's
not
in
our
domain.
The
second
one
is
so
I
took
the
liberty
of
actually
sort
of
short
cutting
it,
so
we
can
improve
improve
the
login
of
our
sync
services.
A
Yeah,
okay,
but
I
would
point
out
that
looking
at
something
that
was
filed
as
a
bug
and
then
closing
it
because
there
is
nothing
to
do-
is
also
extremely
valuable
because
it
shortens
our
backlog
and
makes
it
clear
that
this
is
not
something
relevant
anymore.
So
it
is
actually
really
really
nice
to
see
so.
B
For
anyone
who
is
watching
us
after
the
fact
and
for
both
of
you
that
on
the
call
I'm
actually
going
through
a
process
at
the
moment
to
try
and
identify
pieces
of
work
where
no
MRR
is
created,
and
why,
because
throughput
is
one
way
of
measuring
stuff
that
it
gets
out
into
the
product,
but
I
feel
that
it's
not
correctly
reflecting
sometimes
when
we
have
research
items
POCs
bugs
that
don't
surface.
So
when
you
see
later
on
that
this
has
a
strange
label
associated
to
it.
B
B
A
B
A
B
Yeah
turn
connect
turn
can
login,
so
I
just
need
to
actually
read
the
instructions
properly
and
I'll,
probably
able
to
look
into
cool.
Ok
done
next.
One
checkpoint
meeting
with
infrastructure,
so
I
think
that,
with
all
of
the
meetings
we've
had
with
the
infrastructure,
we
can
mark
this
as
closed
because
there's
nothing
further.
We
need
to
do
here.
We've
got
the
resources
we
need.
We
have
the
people
we
need.
B
B
A
Think
this
is
closed
by
yeah
like
a
couple
of
a
couple
hours
ago,
I,
don't
say:
there's
technically
any
new
code,
I
think
it's
just
adding
something
back.
I'm
really
happy
to
see
this.
To
this
see
this
done,
because
this
was
blocking
a
couple
of
our
users
from
migrating
and
we
had.
They
had
asked
a
little
while
ago
that
you
know
for
us
to
look
into
it
and
we
did,
and
so
that
should
that
should
work.
Okay,.
A
B
A
B
Okay,
right
I'm
in
review,
is
this
3-2
367
I'm
just
shaking
here.
It's
a
different
one
from
whatsoever
that
we
mentioned
on
check.
Okay,
this
one's
in
review,
but
this
was
looking
at
the
Falco,
failed
migration
to
reminisce
and
find
a
parent,
that's
the
new
issue
that
he's
referenced.
So
he
can
talk
about
that
separately
and
there
is
an
odd
request
here.
B
A
A
A
A
A
A
B
B
B
B
A
A
A
Yes,
but
if,
if
that
list
is
listening
or
Eric
I
mean
Tony
is
listening,
I
think
this
is
we
have
a
retro
item
on
it
as
well,
but
I
think
here
the
solution
was
not
was
not
easy,
so
I'm
quite
happy
that
we
we
applied
the
patches
for
the
customer
and
I
hope
that
this
is
resolved
yeah.
So
thanks,
everyone.
B
A
B
Enable
post
pres
for
staging
meshes
just
pick
this
up
I
know
that
it
would
have
only
been
today.
So
we
need
to
go
further
into
that
and
then
also
to
upgrade
the
run
box
for
staging
okay,
then
Zacks
working
on
exposing
the
sync
information
for
the
design,
we're
close
I'm
if
I'm
correct
me
if
I'm
wrong
Fabian,
but
this
is
the
one
that's
going
to
land
up
in
the
verification
column,
because
that's
when
you
want
to
put
the
release
note
on.
A
A
A
It's
a
big
shout
out,
I
thought
actually
like
made
my
morning
yesterday
morning.
You
know
when
I
saw
that,
because
I
know
that
that
ticket
had,
but
if
you
didn't
have
a
lot
of
definition
and
its
discovery,
heavy
I
was
would
be
great
to
see
that
it
was
picked
up
and
you
know
sort
of
moved
forward
because
honestly
I
didn't
know
what
could
be
done
from
my
end
there
and
so
on
and.
B
I'm
also
I
hadn't,
put
much
detail
because
I
wasn't
sure
what
we
would
actually
land
up
with
on
staging
once
the
one
session
dev
and
we
finished
with
what
they
were
up
to
so
yeah.
It's
been
a
very
ambiguous
one,
I'm
glad
that
okay
for
the
three
testing
ones,
which
of
these
three
I've
picked
Jenny
just
to
find
out
where
we,
where
we're
at
and
what's
required.
Next
she's
put
an
update
on
this
one
just
so
that
we
can
see.
If
there's
anything,
we
can
do
to
help
move
forward.
Yeah.
B
A
Think
that's
great,
because
I
spoke
with
Josh
yesterday
and
I
think
we
are
going
to
do
I
think
a
lot
more
active
testing
and
spinning
up
geo
in
various
testing
scenarios
right
and
work
on
the
provisioner
I.
Think
it's
not
unimportant
for
this,
as
in
making
that
easier
and
I
don't
fully
know
at
this
moment
in
time.
What
does
that
is?
There
is
I
also.
A
B
C
B
Went
through
I
went
through
this
with
both
Philly
and
Mike,
or
maybe
it
was
just
mark
talking
about
what
this
issue
is
actually
looking
for
and
what
we're
going
to
get
out
of
this,
and
there
seems
to
be
a
lot
of
debate
as
to
what
the
right
thing
to
do
here
is.
But
when
thinking
about
the
problem
itself
and
the
impact
that
exists,
it's
not
ideal
that
a
sysadmin
has
to
go
in
and
do
something
manually.
A
So
I
thought
I,
actually
I,
think
I
messed
up
the
labels.
My
understanding
of
this
is
that,
with
the
other
changes
that
mike
has
made
and
now
refreshing,
the
foreign
data
reputable
is
possible
via
a
simple
reconfigure
and
while
that
is
another
manual
step,
I
think
that
is
much
more
appropriate
for
a
sysadmin
compared
to
having
to
do
this
other
manual
rake
task,
even
though
reconfigure
did
some
of
those
in
the
background,
but
it
wasn't
really
working.
A
So
my
suggestion
was
to
say:
okay,
this
is
this
is
not
great,
but
it
is
some
it's
sort
of
another
iteration,
and
it's
not
actually
that
important
at
this
moment
in
time,
so
I
moved
it
to
the
backlog
and
I'm
happy
to
leave
it,
as
is
because
I
don't
think
it's
the
most
important
thing
to
do,
and
I
also
moved
it
out
of
the
epic
that
I
want
to
close,
because
I
think
that
this
can
just
be
a
follow-up
item
at
some
point
in
the
future,
and
so
we
shouldn't
we
shouldn't.
Hang
up.
C
I
add
some
compost
here,
yeah
sure
I.
Think
I
would
consider
this
to
be
done
because
of
the
changes.
So
it's
not
really
troublesome
or
cumbersome
thing
to
do
anymore,
like
doesn't
require
you
to
hack
with
cash
in
this
kind
of
stuff.
It's
just
a
reconfigure
which
is
part
of
the
the
flow
of
grading
and
reconfiguring
it
lab
itself.
I
would
say
that
it's
exact
acceptable
fix
here,
trying
to
think
it
in
a
different
way
what
we
were
actually
trying
to
do
with
the
original
proposal.
C
Component
that
can
oversee
the
whole
cluster
that
can
know
the
state
of
each
component.
That
is
part
of
the
cluster,
and
that
can
do
this
kind
of
health
check.
Our
health
state
probing
on
each
one
of
the
components
and
then
do
something
about
it
if
it's
not
green
fix
or
repair
etc.
So
we
don't
have
the
feature
to
actually
fix
this.
So
I
would
say
that
if
current
fix
is
good
enough,
well.
B
I
would
say
that
some,
the
the
specific
proposal
was
about
automating
the
piece
that
Mike
has
not
done
in
terms
of
making
it
easier
to
do
as
at
all,
but
there
is
also
a
proof-of-concept
idea:
that's
being
floated
about
an
option
where
we
might
be
able
to
get
rid
of
the
foreign
tables
entirely,
so
I
would
be
inclined
to
either
just
put
this
on
the
backlog
and
take
the
in
dev
label
out
or
to
close
it,
but
Fabian.
Nothing
closing!
It
is
your
cause.
B
If
this
is
a
feature
that
you
that
would
still
be
if
we
keep
the
foreign
tables,
if
you
still
want
to
be
able
to
do
this
automatically,
but
what
I'm
going
to
suggest
is
that
we
don't
totally
debate
that
now,
the
the
at
the
very
least
it
needs
to
come
out
of
the
active
column
and
indeed,
and
back
into
some
somewhere
on
your
boards
for
that
decision.
So
what
would
you
recommend
I.
A
B
A
B
A
A
This
is
right,
so
I
I
will
do
something,
a
tiny
bit
difference,
because
I've
added
things
here
to
the
to
the
column
that
I
would
like
to
scheduling
I
could
provide
a
little
bit
more
more
context.
So
we
are
in
an
interesting
situation
where
essentially
we
we
are
almost
finished
with
quite
a
few
things
and
we
are
starting
up
work
on
quite
a
few
other
things
and
that's
great
and
exciting.
A
But
it
also
means
that
there
is
like
some
of
the
items
we
can
work
on
are
not
necessarily
100%
perfectly
defined
yet
and
I
actually
think
we
should
spend
some
more
time,
for
example
like
doing
a
little
bit
of
discovery
in
some
instances
in
order
to
understand
if
we
are
doing
the
right
thing
or
not.
First,
before
diving
into
the
solutions,
so
I
have
actually
created
a
few
issues.
A
A
The
first
thing
I
would
like
to
talk
about
is
related
to
disaster
recovery,
and
the
second
thing
that
we
can
talk
about
is
then
the
POC
and
I
know
that
Rachel
has
some
some
questions
for
the
sort
of
self-service
framework,
and
so
we
are
starting
to
look
at
improvements
to
disaster
recovery
and,
as
part
of
those
improvements
to
our
disaster
recovery
efforts,
I
am
proposing
that
we
are
going
to
focus
on
improving
support
for
failed
plan
over
a
safety
plan
office.
It's
certainly
Friday
great
mix-up
planned,
fail,
overs
and
so
the
reason.
A
A
One
is
to
spin
up
a
guh,
a
cluster
and
then
perform
a
failed
and
failover
and
see
specifically,
you
know
if
anything
has
changed
in
the
past
right
the
problems
we
encounter,
look
at
the
documentation
record
these
outcomes
and
that
will
give
us
a
lot
better.
Understanding
of
you
know,
okay
at
this
moment
in
time
with
the
latest
version
of
get
lab.
Where
can
we
make
specific
improvements?
I
think?
That's!
That's!
Going
to
be
very
valuable,
the
other
thing
is-
and
this
is
not
strictly
related
to
where
it
actually
is.
A
It's
like
we
use
go4
for
this
for
replicating
most
of
the
very
important
data,
but
there's
other
data
that
is
actually
under
the
curve
as
well
and
at
the
moment
we
have
essentially
a
very
high-level
description
in
the
in
the
documentation
that
says,
use
our
sync
and
do
some
things,
but
it's
not
really
clear.
What
does
that
actually
mean
I
think
we
should
also
document
quite
clearly
as
like.
All
of
these
are
the
data
types,
how
they're
being
backed
up?
What
needs
to
happen.
A
So
that's
another
discovery
item
and
then
there
are
two
two
more
things
that
are
I
started
to
kick
off
and
the
one
is
highly
relevant
to
get
calm.
So
this
comes
back
from
something
that
Mike
and
ash
brought
up
at
the
moment.
We
don't
have
an
easy
way
to
pause/resume
or
kill,
let's
say
replication
from
a
primary
to
a
secondary,
and
there
is
a
little
bit
of
discussion
and
debate
on.
What
we
should
do
point
is
supporting
what
we
shouldn't
support,
but
I
think
this
is
important.
A
The
main
scenario
from
Capcom
is,
if
the
secondary,
for
whatever
reason,
puts
a
lot
of
stress
on
the
primary,
how
can
we
focus
Emma?
Stop
that
right?
The
other
thing
is
that
the
pause
logic
that
we
have
in
geo
right
now
I
think
actually
only
pauses
replication
of
repositories
and
files,
not
the
database
replication,
nothing.
That
needs
to
be
a
little
bit
of
thought
on
how
we
can
pass
the
database
replication
as
well.
A
A
A
The
other
bit
and
I
think
this
is.
This
is
going
to
be
quite
exciting
as
part
of
the
planned
failover
and
I
posted
that
in
the
Geo
channel
earlier
many
customers
have
actually
requested
a
type
of
maintenance
mode,
the
lead
only
mode
for
forked
lab,
and
there
are
different
scenarios
that
we
that
we
need
to
think
about.
A
So
I'm.
Looking
at
those
items
right
now,
but
we
need
to
really
knock
knock
out.
You
know
like
what
is
the
minimal
thing
we
can
do
first
because
they
are
I,
think
they're
quite
involved
features,
but
I
have
some
discovery
items
on
the
board
already
to
start
with
this,
but
for
the
team.
I
think
this
is
something
to
also
look
at,
and
you
know
like
if
there's
interest,
I
think
working
with
me
quite
closely
in
trying
to
like
break
this
into
more
actionable
smaller
small
chunks.
A
I
decided
on
the
Billboard
to
also
pull
in
a
few
items
that
are
essentially
dealing
with
technical
debt
and
so
for,
like
bugs
or
performance
improvements
that
were
in
the
backlog
that
people
can
pick
up
in
in
the
mean
time,
and
that
gives
us
a
really
good
opportunity
to
also
you
know
like
reduce
our
our
load
in
that
regard,
and
then,
lastly,
before
we
go
to
the
POC
and
items
in
here
are
related
to
activities
on
staging
for
calm.
So
the
first
one
here
is
actually
true.
A
B
What
I've
done,
if
I've
remembered
to
push
enter
on
the
comment,
is
I?
Think
I
edited
that
issue
to
say
it
shouldn't
be.
Initially
we
created
that
to
say
this
is
the
plan
for
what
we're
going
to
do,
but
the
diagram
itself
actually
needs
to
be
what
it
looks
like
that's
once
it
is
deployed.
This
is
what
it
looks
like,
and
you
know
why
I
didn't
push
enter
is
because
I
think
I'll
ended
up
creating
another
issue
entirely,
which
is
to
document
what
we
did.
If
you're
asking
it
then
go
into
the
epoch.
B
So
I
got
halfway
it
so
that
it's
his
document,
the
geo
installation
on
stage
intercom
and
I-
think
that
one
like
the
architecture
diagram
is
part
of
that.
So
I
think
in
actual
fact,
that
architecture
diagram
one
we
might
be
able
to
close
in
favor
of
just
documenting
the
installation
becomes
related.
B
B
B
B
B
B
A
B
However,
before
we
get
to
that
one,
it's
actually
I
think
be
better
to
just
move
this
one
forward
like
this,
have
the
discussion
a
bit
later
that
worries
and
they
will
have
the
discussion
a
bit
later.
Let's
go
through
everything
else
and
come
back
to
that,
because
the
thing
is:
there's
a
lot
of
proof-of-concept
going
on
right
now
and
I
just
want
to
try
and
focus
done
to
like
which
are
the
most
important
ones
that
you
need
us
to
get
done
so
yeah.
A
A
B
A
B
A
B
A
That
there's
something
we
should
I
think
Gabriel
made
a
comment
here
and
said:
like
hey,
we
should
do
a
sort
of
a
two-step
procedure
right-
and
you
know
mark
this-
for
like
a
big
change
in
13,
but
help
with
a
post
deployment
migration
to
actually
migrate.
This
and
I
think
that's
worth
doing
and
doing
it
are
you
okay.
A
B
A
C
It's
actually
actually,
it
would
like
to
as
soon
as
I
finish
this
one
get
this
other
one,
that
the
fix
is
actually
probably
a
one
or
two
lines,
but
the
what
it
will
take
extra
work
is
adding
tests
for
that
and
doing
the
metal
test.
So
it's
one
of
those
case
that
fixing
it
is
easy,
but
testing
it's
a
little
bit
harder
takes
a
little
bit
of
extra.
You.
B
C
B
B
Okay,
so
there
are,
it
sounds
like
these.
It's
actually
these
three
proof
of
concepts
at
the
moment
that
are
vying
for
attention.
The
first
one
is
the
concept
that
I
will
be
discussing
on
Wednesday,
that
I've
asked
Mike,
Valerie
and
Tony
to
take
a
first
pass
set
so
that
we
have
something
to
talk
about
in
their
meeting,
which
is
about
the
self-service
geo
idea.
C
B
If
we
do
this,
however,
I
said
to
Mike
to
hold
off
doing
the
proof
of
concept,
because
it
hadn't
been
scheduled
yet
and
I
want
to
be
sensitive
to
the
fact
that
stuff
needs
to
get
scheduled.
We
just
don't
want
to
just
do
all
the
things
without
talking
about
it.
First
and
then
I
see
there
with
the
single
source
of
truth
issue.
There
there's
a
further
proof
of
concept
of
Bath's
the
selective
sink
aspect
of
be
using
making
those
registry
tables
as
single
source
of
truth.
B
B
A
A
Yeah
I
feel
like
from
I,
like
my
my
sense
of
priorities.
Is
that
I
would
like
that
to
happen
quickly,
because
I
would
like
to
so
at
the
moment,
because
the
idea
of
this
is
that
we
couple
adding
new
data
types
to
us
feel
a
confident
that
we
can
move
to
a
more
safe
surface
application
right
and
so
until
we
validate
like
some
of
our
assumptions,
I'm,
not
scheduling
additional
data
types.
A
B
B
A
Thought
like
I
remember,
like
Valerie's
thought,
was
that
the
event
system
is
kind
of
like
was
included
in
the
sort
of
geo
framework
idea,
so
I'm,
but
I'm
not
sure
how
possible
this
is
right.
My
concern
with
this
is
I.
Don't
know
how
much
complexity
is
involved
in
doing
all
three
of
those
things
enter
and
in
a
POC
but
and.
B
That's
why
I
recommended
splitting
them
out
to
be
separate
things,
because
I
believe
that
there
are
separate
things,
I
think
that
if
we
decided,
if,
for
whatever
reason,
the
proof
of
concept
that
we
talking
about
on
Wednesday
doesn't
go
anywhere,
we
could
still
do
the.
We
could
still
be
looking
at
changing
how
the
event
system
works
on
its
own
I
think
that
they
are
related.
That
they're
not
coupled
no.
C
Can
add
context
I
see
the
the
event
system
as
a
follow
issue
after
we,
we
start
like
the
the
framework.
The
way
everything
is
right
now
it
will
probably
make
everything
more
complicated
to
do
this
change
order,
then
we
create
all
those
interfaces
in
the
code
and
then
we
just
look
this
extra
event
system
instead
of
using
something
else.
I
think
this
is
a
step
to
okay.
A
B
A
Yeah
and
I
think
the
faster
we
move
on
this,
the
better
because
it
it
will
I
think
that
will
like
give
us
the
opportunity
to
resume
our
activities
as
well.
It
like
adding
you
like,
adding
the
things
that
are
missing
but
and
moving
like
in
that
direction,
but
I
I
like
a
like
I'm
advocating
for
this,
because
it's
sort
of
a
three-step
to
a
minimum
of
viable
change
right
I
want
to
avoid
us
building
something
that
actually
doesn't
make
any
sense
right
and
I.
A
Think
my
understanding
from
the
chats
I
had
with
with
one
area
is
that
you
need
to
kind
of
see
this
as
in
code
as
a
sort
of
maybe
even
a
throwaway
mr.right
and
see
it
say
like
hey.
This
is
how
this
could
look,
have
a
discussion
in
the
team
and
then
when
that
is
a
little
bit
more
clear,
we
choose
a
first
data
source
where
we
actually
like
attempt
this
right,
whatever
that
may
be
and
start
iterating
yeah.
B
C
A
Because
I
think
what
I
mean
there
are
two
two
reasons
for
doing
it
operationally.
I
would
like
us
not
to
be
the
bottleneck
right,
that's
an
operational
concern,
but
also
the
realization
that
do
adding
things
in
the
way
we
are
right
now
is
too
cumbersome
and
slow
right,
and
if
we
then
propose
and
improved,
let's
say
architecture,
and
it
turns
out,
it
is
still
cumbersome
and
slow.
We
are
not
winning
on
that
end
right
and
so.
A
Okay.
That
sounds
very
good.
I
think
we
have
enough
here
in
the
pipeline
to
to
continue
for
the
next
week,
and
while
this
is
happening,
I
will
be
able
to
put
a
lot
more
definition
on,
for
example,
the
maintenance
mode.
You
know
the
pausing,
replication
and
30
are
items
so
that
will
become
more
defined
more
broken
down,
and
then
we
can
start
doing
that
as
well.
Fantastic.
B
And
also
during
the
week,
we
have
a
call
about
getting
started
with
the
project
about
the
admin
UI
changes
as
well.
So
yes
I'm
looking
forward
to
seeing
what
comes
of
that.
So
since
we've
got
enough
between
reviews
in
dev
and
ready
for
developments,
I
don't
think
we
need
to
schedule
any
more.
Oh
and.