►
From YouTube: GitLab 14.8 Kickoff - Enablement:Geo
Description
14.8 Outlook - https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5025
Geo Build Board - https://gitlab.com/groups/gitlab-org/-/boards/1181257?label_name[]=geo%3A%3Aactive
A
Our
next
release,
I'm
covering
for
nick
who
is
taking
a
well-deserved
vacation.
I'm
hope,
I'm
hoping
that
you
have
a
great
time.
So,
let's
get
started,
there
are
some
really
exciting
features
and
improvements
coming
up
for
the
next
release
and
they'll
walk
you
through
that.
You
can
always
look
at
the
planning
issue
as
well
for
more
details.
A
So
the
first
thing
is:
we
are
working
on
general
availability
of
jio's
built-in
object,
storage,
replication
framework.
As
a
great
reminder,
geo
is
gitlab
solution
for
distributed
teams
and
disaster
recovery,
and
one
of
the
core
and
important
features
of
geo
is
to
replicate
data
from
one
location
to
another.
Many
of
our
customers
by
now
use
object,
storage
so,
for
example,
amazon,
backed
or
backed
by
google
like
gcp
or
s3.
A
They
store
data
in
object.
Storage
gitlab
has
a
number
of
data
types
that
you
can
store
there
and
it's
cost
efficient
and
fast.
So
cloud
providers
like
amazon
actually
provide
mechanisms
to
replicate
data
natively
between
buckets
located
in
different
locations,
so,
let's
say
the
u.s
east
coast
and
the
u.s
west
coast.
A
However,
there
are
a
couple
of
limitations
with
this.
First,
you
need
to
actually
use
such
a
cloud
provider
to
benefit
from
this.
So
if
you're
self-managed
and
you
use
object
storage
that
may
not
be
available
to
you
and
also
you
can
do
this
across
different
providers.
So
if
you
use
amazon,
you
can
only
replicate
to
another
amazon
based
object,
storage
solution,
so
geo
also
provides
native
replication.
Where
geo
manages
the
replication
between
two
object-
storage-
buckets.
A
We
do
this
already,
but
there
are
a
number
of
improvements
that
we
want
to
make
before
actually
moving
this
from
beta
to
general
availability.
So
the
first
thing
that
we're
working
right
now
is
validating
some
specific
cloud
providers
like
azure
in
14.8.
We
also
want
to
replicate
the
deletion
of
remotely
stored
files.
We
don't
do
this
at
the
moment.
So
if
your
source
bucket
deletes
data,
it
doesn't
actually
get
deleted
on
the
on
the
other
end.
A
We
also
want
to
start
working
on
verifying
files
in
object
storage
to
ensure
that
everything
made
it
across
in
one
piece,
and
you
can
check
out
the
epic
to
understand
the
specifics
about
what
we
believe
is
still
required
for
option
source
verification.
The
feature
is
very
stable
already,
but
we
want
to
challenge
ourselves
and
do
a
bit
more
next
piece
of
work.
A
Here
is
a
little
bit
more
back-end
focused
to
do
with
rails
6,
which
we
use
to
actually
develop
gitlab,
so
geo
already
has
to
manage
more
than
one
database,
for
example,
the
tracking
database
to
keep
state
and
right
now
geo
does
a
lot
of
work
to
manage
connections,
to
different
databases
and
with
rails
6.
A
All
of
this
is
a
lot
simpler,
so
we
are
migrating
to
the
new
and
easier
world
of
managing
multiple
databases
which
reduces
the
overall
technical
debt
and
makes
geo
also
significantly
easier
to
configure-
and
this
is
also
related
to
another
effort
to
do
with
scalability
and
douglas.
One
of
our
engineers
is
working
on
this,
and
hopefully
this
will
result
in
significantly
simpler
configuration
of
geo
in
the
future.
A
This
is
really
important
for
for
geo,
because
geo
is
such
a
critical
component
to
many
our
customers.
So
we
want
to
be
in
a
position
where
we
can
spin
up
geo
automatically
in
various
configurations
and
test
all
of
our
changes
in
a
sort
of
real
environment
running
our
qa
test.
Suite
automatically
there's
still
a
few
issues
to
iron
out,
but
it's
looking
pretty
good
and
we
hope
to
have
this
fully
enabled
in
14.8.
A
A
A
The
way
git
git
works
is
slightly
different,
depending
on
the
commands
that
you
use
and
so
right
now
geo
fetches
data
with
it
fetch
on
the
first
time
it
clones-
and
you
can
already
see
this
is
this-
is
the
difficulty.
So
you
can
get
fetch
and
you
can
get
clone.
They
do
slightly
different
things
and
they
have
they
exhibit
slightly
different
behaviors,
and
so
one
of
our
engineers,
gabriel,
is
exploring
if
using
git
clone
to
retrieve
data
is
significantly
faster
for
the
first
time
when
we
actually
replicate
git
data
to
a
secondary.
A
This
is
quite
relevant
when
we
backfill
a
new
secondary,
and
we
have
to
do
this
swiftly
and
efficiently.
So
when
a
customer,
for
example,
has
thousands
of
repositories,
we
want
to
actually
backfill
our
secondary
as
fast
as
we
can
and
using
git
clone
may
actually
be
significantly
faster
than
git
fetch.
So
we're
exploring
that-
and
hopefully
this
will
result
in
quite
a
few
performance
improvements,
so
stay
tuned.