►
From YouTube: 2021-03-03 Working group DR
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
All
right:
apologies
for
the
zoom
link,
again
it's
brent's
meeting,
so
he
didn't
transfer
ownership
to
me
all
right.
Henry.
You
have
first
items.
B
A
B
So
I
was
trying
to
think
about
the
next
steps
a
little
bit
and
also
what
we
discovered
so
far
and
to
try
to
trim
it
down
to
something
which
is
actionable
for
infrastructure,
at
least,
and
to
define
what
work
can
be
done
already
now,
as
next
steps
right-
and
I
think
of
this-
I
found
myself
it's
it's
nice
to
structure
things
in
a
way
that
it
becomes
clear
what
absolutely
is
necessary,
regardless
of
which
technical
solution
we
end
up
with,
and
by
thinking
about
this,
I
found
some
facts.
B
One
is
that,
regardless
of
what
we
are
doing
object
storage
is
always
the
cheapest
way
to
synchronize
things
across
multiple
region,
regions,
and
that
includes
these
snapshots,
and
the
second
thing
is:
if
we
want
to
get
an
rto
below
one
hour
like
for
premium
customers,
for
instance,
then
the
snapshots
wouldn't
be
the
way
to
go.
So
these
are
some
hard
facts
that
we
have
discovered,
I
think
for
possible
solutions,
and
regardless
of
which
solution
we
are
aiming
for
for
syncing
things.
I
think
what
anyway
needs
to
be
done.
B
This
work
is
first
that
we
need
to
build
down
a
scale
down
copy
of
gprod,
like
really
in
the
same
topology
like
we
have
at
ngprod,
because
we
need
to
be
able
to
do
deployments
to
it
to
upgrade
our
versions
and
things
like
that.
That
includes.
First,
I
need
to
do
this
for
staging.
B
So
this
is
work
that
we
know
that
needs
to
be
done,
regardless
of
what
we
are
planning
for
synchronization,
so
that
could
be
started
right
now
already
with
some
constraints,
and
we
had
a
meeting
with
marin
and
skavic
together
to
discuss
this
a
little
bit
and
we
try
to
put
the
actionable
work
of
that
into
an
epic
I
linked
it
below.
B
If
you
can
see
it
here
on
the
document
and
another
fact
that
I
also
want
to
point
out
is
if
you
want
to
get
a
better
rto
for
our
premium
customers,
then
we
need
to
come
up
with
a
thinking
solution.
B
Besides
just
snapshots
or
something
like
geo
is
doing
right
now
or
using
something
like
I
don't
know,
setup
as
streaming
application
or
other
technologies,
or
even
ideally
having
ghetto
using
object
storage,
but
I
think
that's
the
far
future
and
a
missing
piece
of
work,
for
that
would
also
be
that
we
have
the
ability
and
the
application
to
get
selective,
syncing
and
getting
for
my
plan,
and
I
think
this
is
the
condensed
discussion
we
had
over
the
last
few
weeks.
I
think
for
what
needs
to
be
done,
and
so
I
opened
up
this
epic
below.
A
B
In
some
points
of
what
could
be
started
right
now-
and
I
wanted
to
put
it
here
as
a
discussion
point
of
next
step
to
be
done
and
at
least
for
infrastructure,
I
think
there's
a
lot
of
work
falling
out
of
this
now
and
other
work
is
needed
to
be
done
by
development
like
in
our
application
for
selective
sync
for
geo.
I
guess
things
like
being
able
to
make
geo
work
and
kubernetes,
and
these
things
if
we
decide
to
go
with
the
solution.
B
So
that's
the
thing
we
are
waiting
on
from
infrastructure
site
so
to
say
yeah
before
going
over
to
the
next
point,
where
darius
had
a
lot
of
questions,
maybe
I
wait
first
for
feedback
for
the
things
I
mentioned
here.
A
If
you
don't
mind
henry
I'll,
I
just
want
to
summarize
the
the
recording
without
actually
saying
everything
that
we
talked
about
in
there.
You
can
watch
the
recording
and
check
the
epic
out,
but
the
general
discussion
we
had
was:
we
have
no
time
to
do
this.
We
have
no
people
assigned
to
do
this.
We
have
strict
restrictions
on
how
much
money
we
can
spend
on
this,
and
we
have
a
timeline
that
is
very
short,
so,
with
all
those
things
combined,
it's
really
hard
to
find.
A
You
know
these
big
discussions
or
fund.
Rather
these
big
discussions
of
what
will
happen
if
geo
has
selective
sync.
What
will
happen
if
italy
supports
object,
storage
right,
so
what
we
were
discussing
in
this
call
is:
what
can
we
do
right
now?
That
will
support
this
effort,
regardless
of
the
application
having
these
supports
to
get
us
to
a
point
where
we
have
some
sort
of
rtrt
or
rpo.
I
know
that
the
business
is
requesting
one
hour
one.
We
have
like
one
thousand
tower
one
right
now,
right
like
we
have
nothing.
A
So
what
can
we
do
right
now
to
start
going
towards
that
point,
to
see
how
much
money
we
will
spend
with
that
high
number
anyway,
and
whether
the
the
number
we
got
we
quoted
will
be
even
achievable,
and
then
we
can
talk
about
optimizations
and
so
on.
A
So
one
of
the
parts
that
we
were
talking
about
is
how
to
save
cost
is,
if
we
think
about
what
our
secondary
site
is
gonna
be
so
instead
of
talking
about
vms
on
the
secondary
site
in
general,
what
if
the
secondary
site
is
more
kubernetes
cluster
than
vm
oriented?
What
if
only
redis
and
the
database
is
the
vm
part
and
italy
is
still
part
of
the
the
kubernetes
class.
A
If
we
fail
over
to
a
secondary
site,
that
is
mostly
kubernetes,
we
can
roll
the
nodes
just
by
changing
configuration
and
kubernetes
would
handle
the
orchestration
for
us.
So
the
general
lines
of
work
we
talked
about
are:
let's
build
out
the
database
cluster
that
we
need
on
the
secondary
site
anyway,
whether
we
support
vms
or
kubernetes
from
the
gitlab
site.
We
need
the
database
we'll
need
redis
as
well,
and
then
at
that
point,
once
we
have
that
up
and
running,
we
would
test
a
couple
of
options.
A
A
In
a
failover
situation,
we
would
focus
only
on
restoring
the
italy
data
right,
rather
than
focus
on
also
scaling
the
application,
also
adding
more
nodes,
also
dealing
with
bunch
of
other
things.
So
that
would
save
us
a
lot
of
time
there
and
as
we
develop
that
story
and
as
we
get
more
information
of
where
we
can
say
what
we
can
invest
in,
that
is
the
track
that
infrastructure
theme
can
work
on,
while
the
development
teams
figure
out.
A
What
are
you
gonna
do
with
sinking
right
is
geo,
going
to
be
the
one
supporting
selective
thinking
or
italy
is
going
to
be
the
one
like
that,
I'm
leaving
up
to
the
development
side
to
figure
out.
How
are
you
going
to
figure
out
the
the
selective
repository
story
right
and
at
some
point
those
stories
are
going
to
start
overlapping
a
bit,
but
we
will
have
more
information
at
that
point,
so
we
can
inform
ourselves
a
bit
better.
A
This
also
means
that
scarbeck
and
henry
who
are
the
dris
for
the
kubernetes
migration,
will
first
and
foremost
focus
on
the
kubernetes
migration,
and
the
secondary
thing
will
be
the
build
out
of
the
secondary
site
components
that
we
need
unless
something
changes.
If
we
get
another
requirement
coming
our
way
to
do
some
other
work,
the
disaster
recovery
falls
from
that
line.
A
C
We
also
will
likely
need
features
built
by
gilly
and
possibly
geo.
So
I
think
that
that
makes
sense.
From
my
perspective.
E
D
Here
I
have
a
couple
of
comments,
so
I
like
that
we're
if
I
understand
correctly
we're
going
into
a
direction
where
we're
saying
some
disaster.
Recovery
capability
is
better
than
no
disaster
recovery
capability,
and
let's
do
that
first
right,
because
then
we
actually
have
something
that
we
believe
works.
I
think
that's
good.
D
D
I
think
nick
had
some
comment
on
that
as
well
right
like
because
the
realization
is
that,
given
the
cost
constraints,
the
current
capabilities
of
the
product,
any
other
combination
like
or
features
that
we
have
in
geo
would
require
us
or
gitly,
would
require
development
effort
right
to
go
to
production.
I
think
that
is
kind
of
where
we
are
at
right,
because
the
the
avenue
that
we
explored
theoretically
is
like
geo,
for
example,
can
actually
sync
selectively
right
on
shards,
and
we
could
do
that
for
premium
plus
data.
D
But
then
we
box
ourselves
in
with
the
free
users
right
and
reconciling
that
which
is
difficult
right.
If
we
just
use
geo,
as
is
it
would
be
too
expensive
on
a
storage
side,
so
it
falls
out
of
that
bucket.
D
So
what
we
really
need
to
come
up
with
is
a
solution
to
do
this
in
a
cost
efficient
way
at
scale
right
and
that
may
require
some
work
from
from
getaly,
for
example,
to
to
you
know,
object,
storage
or
whatever
it
ends
up
being
right.
So
the
shortcoming
here
is
really
on
controlling
cost
right
at
that
scale.
D
I
think
the
question
I
think
what
we
should
avoid
doing
is
when
we
do
something
in
production
to
like
deploy
it
in
such
a
way
that
it
is
incompatible
with
anything
that
we're
going
to
build.
You
know
out
in
hopefully
later
stages
that
we
can't
actually
migrate
or
like
iterate.
D
You
know
differentiating
this
for
premium
users,
so
we
need
to
have
a
way
to
bring
that
down
eventually,
and
I
think
that's
maybe
something
that
we
can
lay
out
a
little
bit
more
in
the
product
side
of
things.
In
terms
of
like
how
that
could
look
like.
But
I
think
that's
a
little
bit
further
down
the
line
like
six
months
or
something.
A
Yeah-
and
I
think
this
is
why
it's
important
for
you
folks
to
continue
building
out
the
staging
secondary
site
for
now
with
get
so
that
we
have
something
to
figure
out
to
test
with
as
you're
working
towards
things
right
together
with
what
we
are
doing
also
on
the
infrasight.
A
Have
to
show
us
we'll
still
have
to
do
failovers,
so
we
can
actually
see
what
happens
exactly
and
then
at
some
point
we'll
get
to
the
point
where
we
cross
and
say
like.
Okay,
now
we
know
the
whole
point
of
this
like
couple
of
tracks,
is
to
ensure
that
we
don't
go
down
the
route
of
snapshot
restoration
because
that
is
the
manual
part.
A
Rather,
let
me
rephrase
that
we
have
that
as
an
option,
but
we
haven't
really
investigated
whether
we
can
get
away
from
that
option,
so
basically
run
away
from
that
option
and
just
fall
back
on
it.
If
all
else
fails-
and
I
don't
want
us
to
like
formulate
a
solution
around
a
snapshot
right
now
and
that's
what
you're
saying
as
well
right,
that
is
where
we
kind
of
buying
ourselves
a
bit
of
time
by
running
these
things
in.
B
Epic
have
a
point
to
make
geo
work
with
kubernetes
because
we
are
planning,
for
you
know,
standing
up
as
much
as
we
can
in
community
needs,
and
we
want
to
have
geo
working
there
right.
B
So
we
could
use
it
as
a
solution,
so
we
would
love
to
use
it
because
right
now,
it's
I
think
the
best
working
solution
for
syncing
gitli
data
that
we
have
we
just
need
to
solve
the
selective
syncing
part
out,
of
course,
constraints
right,
and
we
can
just
right
now
start
working
setting
this
up
the
infrastructure
part
and
then
see
that
we
can
make
it
work
with
geo
when
it
is
ready
right
and
so
that's
the
goal
of
the
whole
discussion.
I
think.
D
Yeah,
I
think
I
think,
that's
fair.
I
do
think
we
should
I'll
connect
with
mark
woods
again.
You
know,
because
I
think
there
is-
I
think
there
is
this
interesting
intersection
of
state
likes
being
able
to
store
get
data
in
object.
Storage
may
still
like
maybe
a
very
beneficial
thing
to
do
for
many
use
cases
right
as
well.
So
maybe
there
is
an
opportunity
to
accelerate
that
as
well,
but
I
don't
know
how
how
that
looks.
D
I
have
another
quick
question:
that's
maybe
a
little
bit
too
technical,
but
building
out
the
secondary
site.
Even
if
you
don't
use
geo
for
syncing,
anything
right
may
actually
still
make
sense
to
build
it
as
a
geosecondary
site
right
as
in
a
read-only
state.
You
know,
with
everything
set
up
in
a
way
that
allows
you
to
like
replicate
data.
D
You
know
that
you
then
can
promote,
but
I
don't
know
if
that
is
sensible,
but
that
would
future
prove
it
to
some
extent
and
would
allow
us
to
help
with
you
know
streamlining
that
process,
which
is
something
that
we
would
need
to
do
anyways.
But
we
can
talk
about
that
at
a
different
time.
F
If
I
lost
the
context
here,
looks
like
looking
through
the
comments
to
my
question
looks
like
we
are
talking
about
having
a
geo
to
be
the
dr
solution
for
a
production
environment.
I
think
we
are.
This
working
group
is
to
the
dog
food
geo
as
a
as
a
solution
for
dr
and
starting
from
the
staging
environment
to
see
how
that
works,
and
we
still
have
don't
have
the
secondary
as
a
cluster
yet
and
then,
and
also
the
fact
is,
the
geo
is
not
enabled
for
production
environment
and
there
are
multiple
steps
towards
that
geo.
F
E
Yeah,
my
my
understanding
is
that
there's
kind
of
these
parallel
tracks
happening,
like
martin
described
like
on
one
like
we're
talking
about
dog
fooding
geo,
starting
with
staging
and
seeing
seeing
what
the
gaps
are.
But
my
understanding
is
also
from
the
infrasight
like
we
don't
really
have
any
disaster
recovery
right
now
and
and
and
infrastructure
is
figuring
out
what
they
can
do
to
to
get
something
in
place,
which
should
also
help
inform
what
gaps,
geo
or
getaly
as
well
might
might
need
to
fill.
Does
that
understanding
sound
correct?
E
So
I
think
I
think
that
I
think
maybe
at
the
outside
of
the
group,
we
were
specifically
focusing
on
geo
and
staging
and
kind
of
this
step-by-step
process
like
you're
describing
chun,
but
I
think,
along
the
way,
it's
kind
of
evolved
to
to
also
just
talk
about
the
more
general
disaster
recovery
on
production
requirement
and,
and
maybe
what
can
be
done
in
addition
like
knowing
that
that
identifying
these
gaps
that
geo
has
and-
and
you
know
what
needs
to
be
done-
the
development
side
will
take
a
while.
E
F
F
The
clarification
united
stands.
I
think
this
working
group
scope
is
expanded,
somehow
expanded.
D
I
think
what
I
think:
what
happened
is
that,
like,
I
think
what
happened
is
that
actually
the
working
group
really
served
as
a
forum
to
kick
start
some
of
these
discussions
and
to
think
a
little
bit
more
like
to
to
really
sort
of
explore?
What
what
can
we
can
we
do
when
like
right
now,
but
also
what?
Where
do
we
want
to
go?
So
I
think
yes,
it
has
maybe
expanded
a
little
bit
in
scope,
but
I
think
that's
actually
a
good
thing
because
it
triggered,
I
think,
some
discussions
around
hey.
F
Instead
of
I
mean
initially,
we
were
just
thinking
like
dog
food
in
the
geo
as
a
dr
solution
on
the
staging
and
see
how
geo
works
for
staging
and
then
make
a
conclusion,
identify
the
gaps
then
move
on
to
develop
the
solution
for
a
full
disaster
recovery
solution.
A
E
F
A
Right
right,
right:
right:
okay,
okay,
okay,
okay,
let's
clear
this
something
up!
This
is
why
I
mentioned
that
the
geo
team
nick
still
needs
to
continue
building
out
the
get
second
secondary
site
with
get
so
that
we
have
something
to
test.
This
is
also
why
I
said
that
we
still
need
to
build
out.
You
know
the
the
clusters
that
we
need
for
stateful
data
in
order
to
be
able
to
play
with
this,
like
actual
production
production
story
is
much
farther
away.
A
We
are
just
using
it
as
a
model
of
how
are
we
going
to
get
there
like?
We
can't
put
anything
in
production
right
now,
because
we.
G
F
A
Right,
but
in
infrastructure
you
can't
put
anything
in
production
directly.
It
needs
to
go
through
some
steps.
So
I
guess
that's
where
the
gap
is
coming
from
right,
like
any
service
that
we
put
forward,
it
goes
through
pre-staging
and
then
only
production.
So
for
I
think
for
us,
it's
not
even
a
discussion
like
it's
a
normal
set
of
steps
that
we
go
through.
F
Yeah
to
me,
this
working
group
is
to
identify
the
product
product
and
gaps
of
geo
and
experiment.
With
staging
to
find
those
gaps.
Then
the
development
teams
can
fill
those
functional
gaps
that
get
the
geo
ready
for
production.
That's
the
ultimate
goal,
but
this
working
group
we
are
using
staging
as
a
vehicle
to
test
our
solution.
A
B
I
think
to
evaluate
geo
as
a
solution
for
disaster
recovery.
We
need
to
think
about
what
our
disaster
recovery
needs
to
look
like
to
support.
Gitlab.Com
right
I
mean
because
that's
why
we
are
looking
to
evaluate
geo
and
for
that
we
need
to
think
about
how
we
would
fail
over
at
the
scale
of
gitlab.com,
and
this
discussion
happened
right.
B
So
we
discovered
the
problems
and
the
costs
and
also
what
that
would
mean
so
that
we
need
to
have
support
in
geo
for
selective
syncing
and
things
like
that,
and
now
that
we
thought
about
this
and
got
these
gaps
in
ngo,
for
instance,
or
maybe
it's
even
mostly
there.
Now.
We
know
that
we
can
try
to
do
this
in
staging
as
a
test
right
and
build
up
something
like
a
copy
of
staging
try
to
get
into
you
as
a
thinking
mechanism
for
selective
syncing,
build
up.
B
The
steps
of
you
know
orchestrating,
failing
over
failing
back
and
and
these
these
other
steps
that
we
need
to
test
before
we
can
can
go
to
production,
but
we
can
only
identify
the
gaps
in
geo
if
you
think
about
the
production
environment,
because
we
need
for
to
plan
for
the
scale
right.
So
I
think
we
just
need
to
meet
in
the
middle
now
and
we
need
to
come
from
both
sides
to
to
make
it
useful.
So
I
think
yes
thank.
B
F
A
Well,
there
is
a
simple
way
of
getting
of
the
geostory,
and
that
is
fabian
and
andrew
come
back
and
tell
us
that
product
doesn't
want
to
support
or
italy
part
doesn't
want
to
support
syncing,
to
object,
storage,
right,
syncing,
all
the
free
repositories
to
object,
storage
or
a
cost,
effective
way
of
handling
the
storage
story.
If
we
get
that
information,
this
working
group
moves
away
from
geo
because
we
have
a
constru.
A
Now
we
have
a
number
that
we
need
to
find
a
way
to
hit
and
if
geo
can't
offer
that,
we
need
to
find
an
alternative.
But
I
think
everyone
in
this
call
absolutely
wants
to
figure
out
how
to
get
this
from
geo.
D
Well,
I
think
I
think
actually
maybe
we
could
update
our
our
page
for
the
working
group,
because
I
think
the
main
two
gaps
that
were
identified
in
this
process
you
know-
were
the
controlling
the
cost
of
replicating
very
large
amounts
of
git
data.
I
think
that
is
it
it's
like,
because,
and
you
know
the
we
don't-
have
the
ability
to
sort
of
subset
data
and
reconcile
it
at
a
later
stage
without
issues,
but
I
think
that's
another
thing
that
that
we
can't
do
so.
D
These
are
two
things
that
are
difficult,
and
then
there
is
maybe
the
automation
piece
that
we
talked
about
right
like
how
to
actually
promote
you
know
with
not
as
much
manual
intervention
and
those
are,
I
think,
the
the
things
that
geo
slash
get
to
be
may
need
to
account
for
right,
because
the
the
business
requirements
as
we
have
them
right
now
for
controlling
the
cost
are
such
that
we
can't
just
replicate
everything
on
regular
gitly
storage.
D
I
think
that's
the
main,
the
main
thing
and
that
may
require
development,
either
with
ngo
or
within
italy,
more
likely
to
support
different
ways
of
of
doing
that,
and
I
think
this
is
this-
is
kind
of
some
really
good
findings.
I
think
for
sort
of
going
to
production
scale,
but
most
of
these
things
don't
apply
to
the
same
extent
in
staging
right.
So
it
doesn't
really
block
that
at
this
moment
to
like
set
these
things
up,
that's
how
I
see
it
at
least.
A
Yep
and
again
just
to
add
to
that
like,
if
none
of
that
works
out
the
work
that
info
is
doing
to
build
out
the
stateful
nodes.
We'll
have
to
do
that
anyway,
for
us
for
any
type
of
dr
story,
whether
that's
geo
or
not,
geo
right.
So
this
is
where
we're
kind
of
trying
to
parallelize
some
of
that
work
and
also
like
I'm
hoping
that
by
tying
this
to
the
kubernetes
migration,
we
actually
expose
also
how
important
that
migration
is
for
the
general
cost,
saving
efforts
and
performance
and
scaling
efforts
that
we
have.
A
I'll
I'll
put
something
forward
to
update
the
page
of
the
working
group
and
there
is
quite
a
lot
that
has
happened
actually
so.
A
G
Yeah,
I
think
we
emerged
next.
I
think
we
you
all
touched
on
it
when
you
were
talking
as
well-
and
I
think
I'll
talk
with
andrew
about
it
more
to
see
like
what
we
can
do
with
italy
around
this,
if
that's
reasonable,
because
it
does
sound
like
all
the
points
it
keeps
pointing
back
to
this,
this
problem
right
around
object,
storage
in
italy.
So
I
think
that's
it's
worth
the
discussion.
Probably
the
next
call,
but
also
wifi
as
well.