►
From YouTube: GitLab 13.11 Kickoff - Enablement:Geo
Description
Geo's PM walks through the team's upcoming 13.11 release plans. For more information, check out Geo's 13.11 planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5005
A
A
A
As
a
reminder,
petroni
is
a
high
availability
template
for
postgres,
so
this
allows
customers
to
deploy
a
highly
available
post
with
cluster
on
their
geo,
secondary,
which
then,
in
the
case
of
failover,
would
immediately
restore
high
availability
to
the
postgres
cluster.
So
we're
working
on
this
and
the
work
will
continue
in
1311..
A
We
do,
however,
need
to
move
some
of
the
data
types
that
we
support.
Already
into
the
framework
to
reduce
technical
debt
and
for
them
to
be
able
to
benefit
from
the
self-service
framework,
so,
for
example,
for
files,
this
would
add
verification
capabilities
almost
for
free.
It
also
moves
to
an
event-based
system,
so
the
performance
is
better
compared
to
what's
happening
before
so
we're
currently
working
on
moving
lfs
files
to
the
self-service
framework
and
the
main
benefit
here
of
doing
that.
A
Other
than
reducing
technical
debt
is
really
increased
performance
and
then,
in
another
step,
this
would
be
actually
having
verification
of
lfs
files,
which
is
pretty
simple
to
add.
Once
we've
completed
that
work,
which
is
a
little
bit
more
involved,
we
are
also
going
to
add
verification
capabilities
to
already
existing
blob
replicators.
A
So
one
of
them
is
actually
merge,
request
divs,
the
other
one
is
terraform
state
files
and
then,
as
I
said,
lfs
files.
So
these
items
here
are
quite
specked
out:
it's
essentially
adding
verification
capabilities
to
those
types
following
our
framework
definitions,
which
should
be
relatively
straightforward,.
A
Close
this.
Finally,
we
actually
discovered
that
verification
for
git
based
data,
including
that
is
quite
important
for
for
the
self-service
framework
as
well.
It
doesn't
support
that
right
now,
but
we
do
support
verification
already
for
other
git
based
data
types,
mainly
projects,
so
we're
going
to
add
that
functionality
in
13.11
and
it
looks
to
be
a
lot
simpler
than
we
initially
anticipated.
So
that's
good
news
and
we're
going
to
essentially
do
a
lot
of
sort
of
self-service
framework
work
here.
A
We're
kind
of
at
the
end
of
that
effort
and
we're
wanting
to
make
sure
that
we
put
you
here
on
a
really
solid,
solid
ground
in
order
to
build
out
new
feature
capabilities.
On
top
of
that,
and
the
one
thing
that
I'm
really
very
excited
about
is
that
in
parallel
to
this
work,
we're
going
to
start
working
on
making
improvements
to
geo-replication,
specifically
we're
going
to
work
on
something
that
we
call
secondary
mimicry.
A
So
what
this
is
is
essentially
the
the
thinking
behind
this
is
that
currently
geo
has
a
read
only
secondary
web
interface.
So
if
users
actually
go
to
a
secondary
web
interface,
they
are
not
able
to
make
changes
to
to
that.
You
can
already
push
to
a
secondary
when
you
use
git
data
which
gets
automatically
proxied,
but
that's
not
the
case
in
the
web
ui.
So
we
ran
a
proof
of
concept
here
in
in
workhorse.
A
That
actually
is
our
reverse
proxy
implementation
for
for
gitlab,
and
the
idea
is
that
we're
going
to
move
to
a
model
where
secondary
sites
will
proxy
information
to
the
primary
unless
they
can
significantly
increase
the
usability
by
providing
those
requests
themselves
and
for
the
web
interface.
That
actually
means
that
any
anything
that
we
can
serve
will
be
proxied
to
the
primary
site,
and
there
are
some
some
demos
here
that
you
can
check
out,
and
this
is
actually
you
know,
kind
of
the
intention.
A
A
For
this.
So
quite
excited
about
that
one.
We
are
also
almost
done
insulating
usage
ping.
The
only
bit
that
is
left
is
push
counters
from
geosecondary
nodes
that
allows
us
to
see
how
many
folks
actually
push
through
your
secondaries
and
get
proxy
to
the
to
the
primary
I've
spoken
about
the
new
design
of
the
geo
node
pages
before
that's
still
ongoing,
hopefully
going
to
wrap
up
relatively
soon
and
then-
and
this
is
something
that
happens
partially,
because
we
are
getting
closer
to
a
major
release.
A
We
have
to
prepare
a
few
items
for
that
release
so,
for
example,
preventing
upgrades
to
14.0
without
hash
storage.
We
also
need
to
improve
the
support
for
handling
fork
networks
for
backup
and
restore,
because
fork
networks
tend
to
actually
really
bloat
the
backup
size.
So
that's
something
that
we're
going
to
investigate,
and
then
here
is
just
a
number
of
overall
documentation
improvements,
some
bugs
that
we're
going
to
to
address.