►
From YouTube: Gitlab 16.4 Kickoff - Enablement:Geo
Description
Gitlab 16.4 Kickoff - Geo Group
Planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5092
Geo group past kickoff Videos: https://www.youtube.com/playlist?list=PL05JrBw4t0KoY_6FXXVgj7wPE9ZDS4cOw
Presentation by: Sampath Ranasinghe, Sr. Product Manager, Geo
A
Hello,
everyone
welcome
to
the
16.4
outlook
for
group
2.
My
name
is
ampad
Rana,
singer
and
I'm
the
product
manager
for
the
group.
So,
let's
start
with
gitlab
silent
mode,
gitlab,
silent
mode
suppresses
outline
communication
for
our
gitlab
instruments.
So
where
is
this
going
to
be
useful
for
yourselves?
This
is
this
will
be
useful
for
testing
your
Disaster
Recovery
mechanisms,
so
be
that
a
Geo
geodisaster
recovery
site
or
a
restore
from
a
backup
May.
A
Essentially,
for
example,
if
you
take
a
Geo,
Disaster
Recovery
site,
you
can
promote
a
disaster
recovery
site
and
turn
on
silent
mode
and
then
test
your
Disaster
Recovery
procedures
and
mechanisms
against
this
site.
This
also
allows
you
to
test
the
Integrity
of
the
data
of
that
site.
In
a
similar
vein,
you
can
do
the
same
with
a
restored
backup
by
turning
on
silent
mode.
It
gives
you
the
ability
to
test
your
recovery
processes
and
also
the
Integrity
of
the
backup,
to
give
you
confidence
that
you
can
successfully
recover
from
disaster
event.
A
The
next
up
is
a
verification
of
object.
Storage.
A
Geo
already
manages
a
replication
of
object,
storage
between
object,
storage,
buckets.
We
call
this
gitlab
managed
object,
storage
for
application,
however,
we
do
not
verify
at
this
data,
so
the
effort
here
is
to
add
verification
to
this
data
and
thus
completing
the
circle
of
for
for
object,
storage,
replication
and
verification.
A
This
also
brings
us
to
a
significant
Milestone
with
Geo,
where
we
will
be
with
the
completion
of
this.
We
will
be
verifying
a
hundred
percent
of
all
geo-replicated
data.
Verification
of
data
of
object.
Storage
data
in
this
context
will
protect
you
against
data
loss
in
the
event
of
failover
event
at
event,
and
it
will
also
speed
up
the
process
of
reattaching
a
demoted
primary
site
by
not
requiring
you
to
replicate
all
the
object.
A
Storage
data
that
may
already
be
present
on
that
secondary
site
that
that's
being
reattached
next
up
is
is
the
first
of
the
number
of
product
improvements
related
to
backup,
backups,
backup
and
restore
essentially
so
so.
The
first
first
of
all,
we'll
be
looking
depending
on
we'll
be
looking
to
unify
the
backup
into
backups
into
a
single
CLI
and,
depending
today,
depending
on
your
gitlab
installation.
There
are
different
ways
to
run
backups
so,
for
example,
Omnibus
or
Linux
package
requires
you
to
run
a
rake
task
or
or
a
script.
A
A
scripted
file,
the
helm,
chart
or
Cloud
native
deployment
require
you
to
use
the
backup
utility
and
investment
they
consolidate
and
simplify
the
backup
process.
We
will
Implement
a
single
CLI
that
supports
all
installations
and
all
use
cases.
A
Next
up
is
in
improving
this
capability
of
the
backups
themselves
by
leveraging
the
power
of
modern
multi-core
processes
along
with
parallel
compression
algorithms.
So
this
will
speed
up
the
the
compression
element
of
of
the
backups
and
thus
reducing
the
time
it
takes
to
complete
a
backup.
A
Next,
we
we
will
be
tackling
bringing
run
acceleration
via
geosites
to
to
General
availability.
So
we've
made
a
good
progress
on
plugging
a
number
of
gaps
with
this
essential
that
that
allows
us
to
to
bring
this
to
bring
this
to
your
bring
this
to
your
consumption.
A
Essentially,
what
this
provides
is
ability
to
reduce
the
demand
on
the
primary
site
by
off
offloading
Runner
traffic
to
geosecondary
sites.
It
also
allows
you
to
locate
getlab
data
closer
to
your
Runners
as
well
through
the
3go
secondary
sites.
A
Next
up
is
is
support
for
unified
URLs
with
about
Native
sites
outside
new
GPS
websites.
Unified
URL
is
already
fully
supported
on
Linux
package
or
Omnibus
deployments
or
sites.
A
However,
Cloud
native
sites
do
not
support
what
we
call
an
internal
URL
that
Geo
is
dependent
on
for
for
supporting
a
unified
URL,
unified
URL
allows
all
geosites
to
have
a
single
URL
that
that
users
will
use
to
access
that
data.
The
the
concept
will
allow
users
to
be
automatically
directed
to
the
closest
geocite
based
on
their
location.
A
So,
as
you
can
see,
it's
important
for
us
to
be
able
to
support
this
for
cloud
native
websites
as
well.
So
working
together
with
the
distribution
group
we
are,
we
will
be
adding
the
the
ability
to
configure
an
internal
URL
for
for
cloud
native
geosite
that
will
enable
these
sites
to
also
participate
in
the
unified
URL.
A
Next
up
is
support
for
resync
and
re-verify
all
actions
for
components.
So
what
this
essentially
does
is
level
up
the
self-service
framework
allowing
the
bulk
action
buttons
when
you
bring
forward
the
bulk
action
buttons
to
resync
and
re-verify
for
all
components
that
are
managed
by
Geo,
so
components
by
components,
I
mean
things
like
projects,
wikis
uploads,
lfs
objects,
etc,
etc.
A
So
this
helps
with
potentially
troubleshooting
issues
where
you
want
to
to
pick
off
above
re-verification
action
for
for
all
items
under
that
component,
or
also,
if
you
find
that
your
your
application
has
stalled.
This
is
a
manual
intervention
that
will
force
a
re-replication
process
between
between
the
primary
and
the
secondary
site.
A
Next
is
monthly,
unique,
secondary
site
users
forget
operation,
so
we
we
already
collect
a
metric,
full
monthly,
unique
secondary
users
that
access
secondary
sites
via
its
web
UI.
However,
this
this
metric
doesn't
account
for
git
operations
such
as
clone
Push,
Pull,
Etc
I,
know
in
this
metric
will
provide
us
a
quantitative
insight
into
how
much
these
these
secondary
sites
are
being
used
by
users
and
allow
us
to
to
make
informed
decisions
on
investments
in
this
area
going
forward,
and
then,
finally,
we
will
be
changing.
A
The
call
Pro
call
Flow
for
git
Fetch
and
clone
operations
by
SSH
that
are
made
to
the
secondary
site,
and
the
idea
here
is,
with
the
proxy,
from
the
secondary
site
to
the
primary
site
will
now
be
shifted
to
go
through
the
gitlab
shell.
A
We've
already
made
the
changes
to
to
to
push
our
operations
where
we
are
when
a
git
pushes
made
to
the
secondary
site.
Now
that
is
handled
by
the
gitlab
shell,
we've
seen
improvements
in
performance
as
well
as
it
has
given
us
the
ability
to
remove
a
certain
timeout
limitations
on
on
the
calls.
The
current
effort
here
is
to
consolidate
and
bring
the
opposite
flow,
so
the
pull
and
Fetch
and
clone
flow
also
to
the
gitlab
Shell.
A
It
does
consolidating
both
proxy
and
cold
flows
around
the
gitlab
shell,
and
this
is
this
effort
is
being
done
with
in
collaboration
with
the
source
code
group,
who
will
be
doing
most
of
the
heavy
lifting
in
this
case.
So
thank
you,
Social
Security
Group,
and
with
that
we
conclude
the
16.4
outlook
for
group
Geo.
Thank
you
for
listening
and
I
look
forward
to
seeing
you
next
time.