►
From YouTube: GitLab 13.12 Kickoff - Enablement:Geo
Description
Geo's PM walks through the team's upcoming 13.12 release plans. For more information, check out Geo's 13.12 planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5006
A
A
There
we
go
okay,
it's
a
bit
larger,
okay.
So
the
first
thing
to
note
is
that
in
13
point
or
during
13.11,
the
geo
team
helped
out
on
a
rapid
action
to
improve
the
overall
performance
of
our
database
queries,
which
meant
that
some
of
these
items
are
going
to
carry
over
from
13
11
to
13.12,
just
because
they
had
we
had
to
shift
priorities
a
little
bit.
A
So
the
first
thing
I
want
to
talk
about
is
geopatroni
support.
So
petroni
is
a
high
availability
template
for
postgres
databases,
and
it
is
the
replacement
in
gitlab
for
rep
manager
to
provide
high
availability
for
databases,
so
you
have
more
than
one
node
primary
node
and
second,
several
followers.
So
if
the
primary
node
fails,
you
can
switch
over
to
another
node
and
continue
your
service
without
interruption.
A
Where
you
have
a
standby
cluster
and
you
are
able
to
run
several
postgres
nodes
and
high
availability
on
your
geosecondary
site,
so
we're
hoping
to
shift
ship
beta
in
13.11,
but
there
are
still
some
outstanding
items
that
we
hope
to
ship
in
13.11,
but
there
is
very
likely
carryover,
especially
to
do
with
some
of
the
sort
of
reconfiguration
and
ensuring
that
the
entire
setup
process
is
smooth
for
new
users
if
you're
starting
fresh
and
you
don't
actually
have
patrony,
but
also
for
folks
that
are
migrating
from
existing
installations.
A
So,
as
I
said,
this
may
actually
complete.
But
given
the
timing
right
now,
I
anticipate
that
the
beta
support
will
potentially
slip
into
13.12
after
that,
there's
a
lot
of
testing
to
be
done
to
ensure
that
all
of
this
works
well
at
scale,
which
is
the
sort
of
the
most
important
part
of
the
work
for
general
availability,
we're
also
working
on
some
other
items.
A
A
A
So
again,
this
is
on
the
way
we
are
going
to
merge
some
changes
here
relatively
soon,
but
we
need
some
more
time
in
13.12
to
test
out
all
of
these
new
functionalities.
Make
sure
it
works.
Make
sure
that
the
migration
from
legacy
to
self-service
framework
works
well,
and
then
we
may
have
the
ability
to
actually
verify
lss
objects
after
that,
which
is
quite
exciting
I'll.
Keep
you
posted
on
that
one.
A
Next
up,
we
have
some
existing
data
that
we
already
replicate
so,
for
example,
merge
request,
divs
and
terraform
state
files,
and
they
replicate
happily
using
the
self-service
framework,
but
they're
not
currently
verified.
So
we
are
currently
working
on
that
merge
request.
Diffs
are
a
little
bit
more
work
than
anticipated,
so
we
are
going
to
ship
that
very
likely
in
13.12
terraform
state
files
are
still
targeted
to
13.11,
but
they
may
also
only
become
available
in
13.15.
A
So
this
is
sort
of
the
last
few
items
that
will
really
bring
snippet
verification
up
to
sort
of
the
the
standard
that
we
have
for
other
data
types
as
well,
and
the
next
item
is
so.
This
is
all
of
this.
Here
is
essentially
improvements
to
how
we
replicate
data,
how
we
verify
it
moving
geo
to
a
better
code
base
and
making
it
more
performant
and
easier
to
maintain,
which
in
turn
then
increases
the
velocity
and
our
ability
to
ship
more
exciting
new
features.
A
A
That
is
not
able
to
actually
allow
users
to
to
submit
any
kind
of
write
rights
through
that
web
interface,
the
user
experience
of
that
is
subpar,
and
so
we're
going
to
move
to
a
model
where
essentially
any
request
that
a
geosecondary
site
receives
should
be
able
to
be
handled
in
a
way
by
the
site
that
improves
the
user
experience
and
otherwise
we're
going
to
proxy
it
back
to
the
primary
side
that
will
make
the
user
experience
overall,
pretty
transparent
and
will
also
allow
systems
administrators
to
hide
secondary
sites
behind
a
unified
global
url.
A
So
if
you
have,
you
know,
let's
say
customer.gitlab.com
and
you
are
in
the
united
states,
you
will
get
to
the
primary
in
the
united
states.
If
you
are
let's
say
in
japan
or
in
germany,
you
would
get
to
a
secondary
geo
site,
but
you
wouldn't
actually
know
that
you're
there
things
would
just
perform
better
and
you
would
benefit
from
the
co-locality
of
the
data.
So
quite
excited
about
this.
A
We're
also
going
to
make
some
improvements
to
our
usage
ping,
hopefully
being
able
to
also
measure
how
many
push
requests
are
going
to
be
made
to
a
secondary
site
to
see
to
see
that
and
also
improve
the
overall
performance
of
of
geo.
Following
that
data,
the
implementation
of
the
new
geo
node
page
is
also
going
well
there's
a
lot
of
work
that
is
being
done
on
this
right
now.
This
is
how
it's
going
to
look
we're
excited
for
it.
A
The
reason
for
this
is
that
italy,
our
service
for
handling
git
data,
is
able
to
create
pool
repository.
So
when
you
fork
a
repository,
we
can
we
don't
have
to
re-replicate
all
the
data.
We
can
rely
on
a
pool
pull
repository
to
hold
most
of
the
data,
which
is
much
more
efficient,
but
our
backups
don't
support
pool
repositories.