►
From YouTube: Gitlab 16.1 Kickoff - Enablement:Geo
Description
Gitlab 16.1 Kickoff - Geo Group
Planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5079
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
another
edition
of
the
Geo
groups
Outlook
this
time
it's
from
Milestone
16-1
and
my
name
is
sambad
ramasingha
and
I'm,
the
product
manager
for
the
Geo
Group.
So
we'll
start
with
moving
existing
data
types
into
the
self-service
framework.
The
self-service
framework
is
a
single
framework
under
through
which
we
can
manage
multiple
data
types.
All
the
goal
is
to
manage
all
data
types
that
Geo
replicates
and
verifies.
A
Through
this
framework
we
have
a
couple
of
data
types
that
precede
this
framework,
move
the
projects
and
and
design
repositories,
and
we
want
to
move
this
into
into
the
cell
service
framework
so
that
it
makes
it
easier
for
us
to
maintain
and
also
add
new
features
in
the
future.
The
cell
service
framework
also
makes
it
easier
for
us
to
add
new
data
types
in
the
future
as
well.
A
A
So,
while
keeping
that
keeping
the
primary
site
available
to
the
business
and
and
you
can
completely
function,
performing
testing
against
such
a
secondary
site,
as
you
can
imagine-
will
generate
outbound
traffic
such
as
email
notifications,
traffic
on
the
web
hooks
or
traffic
through
fresheners.
We
want
to
avoid
this
as
it
can
cause
Confusion,
And
A
disruption
to
our
Upstream
services
or
users.
A
Silent
mode
is
intended
to
suppress
these
communications
from
the
gitlab
instance
that
is
under
test.
This
is
across
cross
stage.
Effort
and
geot
will
be
coordinating
in
coordinating
the
effort
with
other
stage
groups
to
deliver
this
capability,
and
we
have
already
completed
the
API
setting
controls
and
implemented
blocking
of
outgoing
emails
over
the
next
couple
of
Milestones.
We'll
look
to
make
progress
on
blocking
other
outbound
Communications
such
as
mirroring
and
web
traffic
a
web
hook.
Traffic
next
is
improving
backups
and
restore
documentation
for
our
self-managed
customers.
A
Backups
are
an
important
part
of
any
good
Disaster
Recovery
strategy.
They
help
protect
against
malicious
or
unintentional
data
corruption
by
allowing
data
to
be
restored
at
a
particular
point
back
in
time,
backups
are
complementary
to
geost
Dr
solution,
providing
protection
against
corruption
that
may
be
replicated
from
the
primary
site
to
the
secondary
site.
A
Our
backup
solution,
documentation
has
grown
over
time
and
there
are
multiple
Solutions.
We
have
documented
across
multiple
pages,
so
we
hope
to
consolidate
the
documentation
and
provide
updated
guidance
on
best
practices
for
our
for
our
self-managed.
Customers
will
be
enhanced
in
the
documentation
to
cater
for
customers
on
large
reference
architecture.
So
that's
a
3K
and
above
a
reference
architecture,
and
also
customers
with
large
large
data
sets.
A
So
we
we
have
successfully
validated
our
proposed
approach
for
for
customers
with
large
data
sets
and
large
architectures.
Next
steps
will
be
to
review
the
results
with
the
internal
stakeholders
before
proceeding,
to
update
the
documentation
and
then
next
up
is
fixing
fixing
the
SSH
proxying
timeout
for
push
requests
So.
Currently,
there
is
a
60
second
timeout
when,
when
a
push
request
is
proxied
from
the
secondary
to
the
primary.
A
As
you
can
imagine,
this
timeout
is
too
low
for
large
push
requests
and
it
ends
up
in
a
field
transaction,
and
this
is
impeding
the
adoption
of
Geo
to
accelerate
remote
teams
at
some
customers.
So
the
solution
will
likely
be
a
solution
is
actually
an
architectural
change
where
we
are
shifting
the
workflow
from
Puma,
which
is
imposing
the
60
second
timer
to
gitlab
Shell
and
there's.
There's
lots
of
work
that
has
already
progressed
on
on
this
front.
A
Next
is
allowing
GA
Runners
to
we're
accelerating
gear
run,
accelerating
Runners
via
secondary
sites
of
secondary
geocites,
allowing
Runners
to
clone
and
retrieve
data
from
secondary
geosites
will
allow
customers
to
reduce
the
load
on
the
primary
site.
A
number
of
customers
have
shown
interest
in
doing
so,
and
in
previous
milestone.
In
one
of
the
previous
milestones
we
had,
we
undertook
to
test
the
ability
for
runners
to
clone
from
a
secondary
site
and
identified
a
number
of
issues
that
would
prevent
this
from
working
successfully.
A
We
are
we're
also
working
on
verifying
object.
Storage
gitlab
by
Geo,
already
replicates
object,
storage
where
its
own
native
mechanism.
This
is
something
we
G8
a
couple
of
Milestones
ago.
However,
we
do
not
support
object,
storage,
verification
to
complete
the
the
circle.
We
will
add.
Gitlab
manage
verification
to
go
to
complement
the
replication
capabilities.
We
already
have
a
verification
of
object.
Storage
will
protect
customer
data
against
customers
against
data
loss
in
the
event
of
a
failover.
A
It
will
also
help
speed
up
the
process
of
reattaching
a
demoted
primary
site
as
a
secondary
site
by
avoiding
the
need
to
re-replicate
object,
storage
data
from
the
new
new
primary
side
to
the
secondary
site
and,
as
we
make
progress
towards
100
completion,
a
hundred
percent
verification,
a
hundred
percent
verification
of
all
Colgate
life
data
that
we
have
replicated.
We
will
also
add
verification
to
group
wikis,
so
this
is
this
will
be
the
last
remaining
data
type.