►
From YouTube: GitLab 14.10 Kickoff - Enablement:Geo
Description
14.10 Outlook: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5031
A
A
We
have
a
new
priority
in
geo.
You've
maybe
heard
us
talk
about
the
self-service
framework
before
so
geo.
Self
service
framework
is
an
architecture
that
significantly
simplifies
geo's
code
base
and
also
ensures
that
all
data
types
are
replicated
and
verified
by
default,
which
is
the
customer
expectation
that
we
have
when
data
gets
transferred
between
the
primary
and
secondary
side.
The
performance
is
fast
and
we
have
verification
included.
A
It
also
empowers
other
developers
to
contribute
new
data
types,
ensuring
that
geo
features
or
the
new
features
actually
ship
with
jio
enables
by
default
right
when
they
get
released.
So
we've
already
moved
the
number
of
data
types
to
the
self-service
framework.
All
new
data
types
are
self-service
framework
enabled
by
default.
We
still
have
a
few
remaining
legacy
data
types
and
so
over
the
course
of
14.10
and
very
likely
also
the
next
release.
We
are
going
to
move
and
migrate.
A
The
existing
legacy
data
types
into
the
self-service
framework,
so
we're
almost
done
with
the
ci
drop
artifacts.
I've
included
it
here.
We
still
hope
to
ship
that
in
14.9,
but
the
remaining
other
data
types
are
projects
and
wikis,
which
are,
of
course
highly
valuable,
because
this
is
the
source
code
that
our
customers,
you
really
contribute
to
to
get
lab
designs,
specifically
design
repositories
and
the
container
registry.
A
A
In
particular,
this
will
also
unlock
the
verification
features
the
same
for
job
artifacts,
bringing
us
closer
to
100
verified
as
well
as
replicated.
So
this
is
the
new
main
priority
of
the
team.
We
also
have
a
few
ongoing
initiatives
that
are
still
happening
in
14.9,
but
they
will
carry
over
into
14.10
and
we
hope
to
complete
them.
A
So
there
are
a
few
bugs
that
we
need
to
fix
so,
for
example,
replicating
the
deletion
of
remote
stored
files
or
making
it
more
clear
that
we
don't
yet
support
verification
for
those
data
in
object,
storage,
buckets.
This
is
also
likely
something
that
we'll
add
in
another
iteration,
but
right
now
we're
just
testing
and
validating
object,
storage,
replication
performance
on
reference
architectures
and
on
various
providers,
including
amazon,
microsoft
and
google.
A
So
this
is
ongoing
and
we
hope
to
ship
this
very
soon.
The
next
point
is
support
for
geo
for
improved
support
for
our
proxy
feature,
so
we've
shipped
this
a
few
releases
ago,
but
we're
now
iterating.
So
one
of
the
additional
capabilities
that
we'd
like
to
support
better,
is
when
geo
actually
has
separate
urls
for
the
primary
and
the
secondary
sites,
so
with
the
unified
url,
which
is
also
an
obvious.
A
A
One
of
the
things
that
I'm
particularly
keen
on
is
completing
our
scorecard
for
the
category
maturity
for
disaster
recovery.
We
believe
that
the
offering
by
now
is
complete,
but
we
always
validate
this
with
actual
data
from
customers.
This
is
ongoing
and
then
lastly,
I'd
like
to
highlight
one
specific
area
here,
which
is
improving
the
performance
of
first
time
replication
for
git
data.
So
when
you
actually
enable
geo
on
your
secondary
all
of
the
data
from
the
primary
needs
to
be
replicated,
and
so
for
for
this
we
used
to
use
git
fetch.
A
It
works
really
well,
but
there
are
some
internal
differences
on
how
git
behaves
and
by
switching
to
git
clone
the
initial
replication.
So
the
first
time
we
download
the
repository
can
be
up
to
27
faster,
and
so
this
is
a
huge
time.
Saver
makes
geo
overall
perform
better
and
gabriel
is
working
on
this.
We
are
hoping
to
release
that
in
14.10
the
latest
and
that's
it
so
to
rehash.
A
We
are
aiming
to
complete
migrating
all
existing
data
types
into
the
self-service
framework,
so
that
all
of
that
follows
a
single
specific
way
and
ships
with
replication
and
verification
by
default,
and
then
there's
a
number
of
other
work
going
on,
including
object,
storage,
replication,
general
availability,
improving
our
proxy
features
and
behaving
ourselves
well
by
using
rail
six
many
database
support.
So
it's
an
exciting
release.