►
From YouTube: GitLab 13.6 Kickoff - Enablement: Geo
Description
Geo's EM walks through the team's upcoming 13.6 release plans. For more information, check out Geo's 13.6 planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4982
A
A
Track
we're
also
going
to
be
adding
verification
for
package
files
with
the
self-service
framework
and
much
like
snippet
replication
with
the
self-service
framework.
Not
only
is
this
going
to
add
verification
for
package
files,
but
it's
going
to
make
it
a
lot
easier
to
add
verification
for
future
blob
data
types
that
are
added
with
the
self-service
framework.
A
A
few
months
ago,
we
enabled
geo
on
the
getlab.com
staging
environment,
and
this
has
really
helped
us
improve
the
performance
and
scalability
of
geo,
as
we've
been
able
to
develop
and
test
geo
at
scale.
Now
that
it's
enabled
on
staging.
We
also
want
to
investigate
what
would
be
required
to
perform
a
planned
failover
on
the
staging
environment.
A
With
the
self-service
framework,
we
made
it
easier
to
add
new
replicables,
such
as
package
files,
external
mr
diffs
and
terraform
state
files.
Now
we
want
to
move
things
that
we
previously
replicated
over
to
use
this
framework
as
well.
This
is
going
to
improve
the
overall
maintainability
of
the
geo
code
base
and
ultimately
make
it
easier
for
and
faster
for
us
to
deliver.
Improvements
and
features
to
our
customers
also
excited
to
be
adding
support
for
postgresql.
A
This
is
problematic
if
go
is
used
as
part
of
a
disaster
recovery
strategy,
because
it
means
that,
failing
over
to
a
designated
secondary,
can't
utilize.
The
same
high
availability
database
configuration
immediately,
so
this
is
going
to
make
it
easier
for
customers
to
have
a
secondary
that
exactly
mirrors
their
primary
and
we're
going
to
be
using
petroni,
which
is
currently
experimentally,
supported
in
omnibus.
A
So
we're
planning
to
release
this
as
experimental
support
and
will
continue
to
improve
the
documentation
as
well
as
limitations,
and
follow
up
with
improvements
to
make
petroni
on
geosecondaries
more
production
ready
in
13.6.
We're
also
going
to
be
releasing
support
for
a
read-only
mode,
currently
system
administrators
have
no
way
of
enabling
a
maintenance
or
read-only
mode
for
git
lab,
and
this
could
be
useful
in
a
few
different
scenarios.
A
For
example,
if
you're
doing
a
plan
failover
from
a
primary
to
secondary,
you
may
want
to
block
write
access
to
a
gitlab
installation
in
order
to
make
sure
that
the
state
between
the
primary
and
secondary
is
fully
synced,
so
having
a
read,
only
mode
would
be
really
useful.
In
this
scenario,
one
of
the
pain
points
with
the
disaster
recovery
process
for
geo
is
that
it's
a
highly
manual
process
with
a
lot
of
steps
involving
modifying
configuration
files,
reconfiguring,
gitlab
and
running
a
command
to
promote
a
secondary
to
a
primary
in
13
5.
A
We
released
a
proof
of
concept
for
with
a
for
a
single
command
that
could
be
run
on
any
node
to
promote
a
secondary
to
primary.
That
would
handle
the
modification
that
would
handle
modifying
the
configuration
needed
to
promote
the
secondary
and
in
136
we're
going
to
expand
on
this
to
support
larger
multi-node
geo
installations,
and
this
is
a
big
step
towards
reducing
the
amount
of
steps
needed
to
fail
over
for
larger
geo
installations.
A
We're
also
planning
to
investigate
some
issues
that
came
from
testing
upgrades
on
geo
multi-node
installations.
We
want
to
make
sure
that
zero
downtime
upgrades
with
minor
versions
are
also
supported
when
using
geo.
There
are
a
couple
instances
where
we
found
some
disruption
and
we
want
to
make
sure
that
these
are
either
documented
or
fixed.