►
From YouTube: GitLab 14.0 Kickoff - Enablement: Geo
Description
Geo 14.0 Planning Issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5007
A
A
One
of
our
highest
priorities
for
geo
in
14.0
is
generally
available.
Support
for
petroni
on
geosecondaries,
with
postgres
12
becoming
the
minimum
required
version
in
14.0
rep
manager
will
no
longer
be
supported
as
the
solution
for
highly
available
postgres
in
get
lab
and
petroni
will
be
required,
and
this
is
actually
very
beneficial
for
geo.
A
As
with
rep
manager
3,
we
weren't
able
to
support
a
highly
available
postgres
cluster
on
geosecondaries,
whereas
with
petroni
we
will
be
able
to
support
this,
and
this
makes
it
a
lot
easier
for
customers
to
fail
over
to
a
secondary
that
more
closely
mirrors
their
primary
and
thereby
reduces
overall
recovery
time
in
the
event
of
a
failover.
A
Next,
we
want
to
make
sure
that
we're
supporting
any
work,
that's
needed
to
make
sure
that
hash
storage
is
the
only
storage.
So
in
13.0
we
deprecated
support
for
legacy
storage
and
began
automatically
migrating
users
over
to
over
to
hash
storage,
and
we
announced
removal
for
for
14.0
and
so
we'll
be
making
sure
that
we
prevent
any
upgrades
of
14.0.
If
legacy
storage
is
enabled
and
then
we'll
begin,
removing
legacy
storage
support
in
the
code
base,
which
will
greatly
help
with
overall
maintainability.
A
Next,
we
want
to
keep
making
progress
on
our
complete
maturity
goal
for
disaster
recovery,
and
one
of
the
key
components
of
this
is
to
ensure
that
geo
is
verifying
more
data
types.
So
in
even
just
a
year
ago,
geo
only
verified
a
little
over
20
of
data
types
and
within
that
year
we've
made
a
lot
of
progress
and
we
now
verify
around
45
of
the
data
that
geo
replicates.
A
We
want
to
continue
expanding
on
that,
so
we
expect
that
verification
for
terraform
state
files
will
ship
in
13.12
and
we
plan
to
add
verification,
support
for
merge,
request
diffs
in
14.0,
and
we're
able
to
do
this
a
lot
faster
now,
because
we've
added
verification
support
to
the
self-service
framework
for
blob
and
repository
data
types.
A
We're
also
really
excited
to
keep
making
progress
on
our
secondary,
mimicry,
f,
epic,
by
adding
support
for
proxying
write
operations
on
a
secondary
site
to
a
primary.
This
is
going
to
greatly
improve
the
usability
of
the
web
ui
on
a
secondary
and
eventually
set
us
up
to
be
able
to
support
a
single
url
for
gitlab
that
hides
the
details
of
to
regular
users
and
allows
sysadmins
to
set
up
load
balancing
that
that
automatically
directs
users
to
to
the
gitlab
site.
That
makes
the
most
sense
for
them.
A
One
we've
reorganized
the
existing
information
on
that
page
to
to
make
it
easier
to
understand
and
and
surface
important
information
about
the
the
health
of
of
your
geo
sites
and
as
well
as
replication
status,
and
we've
also
added
some
additional
useful
information,
such
as
easy
to
to
digest
summaries
of
synchronization
and
verification
status,
as
well
as
the
verification
status
for
data
types
that
we
replicate.
A
And
finally,
if
we
have
some
capacity
in
the
milestone,
we
want
to
continue
making
progress
on
improving
the
promotion
process
by
expanding
support
for
a
single
command
to
other
node
types
beyond
just
the
application
node.
A
We
also
want
to
move
more
data
types
to
use
our
self-service
framework,
which
will
improve
performance
and
maintainability
of
geo-replication,
and
we
want
to
keep
improving
our
documentation,
better,
clarifying
the
use
of
of
node
and
site
in
our
docs
to
align
with
the
terminology
in
our
glossary
all
right,
so
that
does
it
for
an
overview
of
14.0,
a
lot
of
very
exciting
things
in
store.
As
always,
we
work
continuously
and
iteratively,
and
you
can
follow
our
progress
in
relevant
issues
and
epics.