►
From YouTube: GitLab 13.10 Kickoff - Enablement:Geo
Description
Geo's PM walks through the team's upcoming 13.10 release plans. For more information, check out Geo's 13.10 planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4999
A
A
So
I've
left
it
in
here
because
this
is
not
merged,
but
there's
still
a
little
bit
of
time
until
13.9
gets
you
east,
I'm
quite
confident
that
we'll
get
it
in,
but
nevertheless
so
geo
replicates
data
from
a
secondary
to
one
or
several
primaries,
and
at
the
moment
we
verify
data
that
is
stored
in
git,
which
is
important
because
it
means
that
any
data
that
gets
replicated
is
actually
not
corrupted
when
it
arrives
so
far
for
files.
We
were
not
able
to
do
this
dynamically.
A
A
So
with
that
being
said,
we
already
replicate
a
number
of
files,
for
example
lfs
files
or
uploads
that
are
not
yet
part
of
the
self-service
framework.
So
one
of
the
downsides
of
that
is
that
these
data
don't
get
verified,
but
with
this
merging
we'll
actually
just
need
to
move
these
file
types
into
the
self-service
framework
to
support
verification,
get
it
into
our
standard
framework.
There's
also
likely
some
performance
benefits
so
with
this
wrapping
up
in
13.10,
we'll
continue
moving
nfs
files,
but
we'll
also
start
moving
uploads
or
attachments,
as
they
are
called
in
other
places.
A
This
will
take
us
at
least
a
couple
of
releases
for
the
database
migrations,
but
this
is
something
that
we
we
understand
how
to
do
and
we're
quite
confident
that
we
can
complete,
and
this
then
will
mean
that
nfs
files
are
also
verified.
Uploads
are
verified,
job
artifacts
may
come
in,
so
this
is
something
here.
It's
really
important
just
to
improve
the
overall
completeness
of
our
replication.
A
Offering
another
thing
that
I
would
like
to
talk
about
a
little
bit
more
in
detail
is
petroni
support,
so
petroni
is
a
high
availability
template
for
post
with
this
means
that
you
can
stand
up
a
cluster
of
postgres
nodes.
We
use
petroni
in
production
on
github.com
already,
and
we've
used
rep
manager
in
the
past
to
provide
the
same
functionality
for
our
self-managed
customers.
A
One
of
the
downsides
of
using
rep
manager
was
that
we
were
not
able
to
provide
a
secondary
standby
cluster
for
disaster
recovery
purposes,
which
then
means,
if
you
fail
over
to
a
secondary
in
a
planned
failover
or
a
disaster
situation.
You
have
to
essentially
re-initialize
an
entire
highly
available
post
cluster,
which
is
tedious
and
takes
time,
and
a
better
solution
here
would
be
to
provide
a
high
availability,
postgres
cluster
on
a
secondary
and
we'll
use
petroleum
for
this
we've
released
alpha
in,
I
believe,
13.5.
A
A
That
sort
of
keeps
the
state
for
for
geo,
and
people
may
be
interested
in
actually
having
a
highly
available
system
here
as
well.
So
we
are
going
to
look
at
supporting
petroni
for
this
too
yeah,
and
we
intend
to
finish
this
in
1310
and
then
we're
planning
for
general
availability
in
14.0
and
that's
quite
exciting
for
us,
because
that
would
allow
many
of
our
large
customers
to
actually
you
know
have
a
secondary
setback.
Cluster.
A
A
What
I
mean
by
that
is
fixing
some
bugs
improving.
For
example,
you
know
some
of
the
output
for
some
of
our
commands
to
make
them
more
user-friendly,
small
incremental
improvements
that
don't
neatly
fit
in
our
epic
hierarchy,
but
that
are
valuable
and
also
give
us
a
chance
to.
Overall
increase
the
polish
of
geo,
that's
it
for
13.10.