►
From YouTube: Gitlab 16.3 Kickoff - Enablement:Geo
Description
Gitlab16.3 Kickoff - Geo Group
Planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5089
Geo group past kickoff Videos: https://www.youtube.com/playlist?list=PL05JrBw4t0KoY_6FXXVgj7wPE9ZDS4cOw
Presentation by: Sampath Ranasinghe, Sr. Product Manager, Geo
Ian Baum - Sr. Engineer, Geo
A
A
A
It
does
ensuring
your
testing,
your
processes,
but
also
testing
the
Integrity
of
that
secondary
site.
You
can
also
use
this
feature
for
backup
and
restore
where
you
can
restore
gitlab
instance
from
from
a
backup
and
also
perform
testing
against
against
that
instance
as
well.
This
is
a
cross-stage
effort,
so
we
we
are
roping
in
our
colleagues
from
other
groups
to
help
us
suppress
the
outbound
Communications.
A
A
And
next
up
is
improving,
backup
and
restore
documentation.
Backup
and
restore
documentation
has
has
grown
quite
large
over
the
over
the
last
couple
of
years.
We've
also
have
a
number
of
different
solutions
for
different
scenarios,
and
also
our
customers
have
a
much
larger
data
sets
as
well,
since
some
of
this
documentation
has
been
updated.
A
A
And
the
next
item
is
allowing
verification
of
object,
storage.
We
we
verify
a
large
number
of
components
already
through
Geo.
We
also
support
replication
of
object,
storage
via
natively
VIA
gitlab,
as
as
well
as
well
as
supporting
object,
storage
replication
through
via
the
the
provider's
tool
chain
as
well.
However,
the
verification
in
this
case
is
specifically
targeting
gitlab
managed
object,
storage
replication,
so
this
basically
completes
the
circle
where
we'll
add
gitlab
managed
object,
storage,
verification
that
will
complement
the
the
replication
piece.
A
B
We
are
working
on
improving
the
performance
of
so
you
can
run
a
second
runners
in
the
secondary
sites.
This
should
offset
some
of
the
load
on
the
primary
as
well
as
speed
up
some
folks
who
are
working
in
remote
sites.
There
are
some
some
hiccups
there
that
we
need
to
work
through
So,
currently
in
progress.
We
have
lfs
objects
where
we're
fixing
the
proxy
there
so
it'll
download
from
the
secondary
and
not
the
primary
all
the
time,
and
our
next
step
will
be
to
work
on
the
repositories
themselves.
B
Runners
pick
up
jobs
pretty
quickly,
so
we
don't
always
have
time
to
sync,
so
we
need
to
kind
of
come
up
with
a
good
plan
so
that
we
can
still
pull
from
the
secondary
and
not
overload
the
primary
with
all
of
the
requests
for
the
code
when
jobs
are
running.
That's
currently,
where
we
stand
right
now
back
to
you.
A
A
We'll
move
on
to
verifying
group
wikis.
Just
referring
back
to
my
previous
comment,
where
we
are
making
progress
towards
being
able
to
verify
a
hundred
percent
of
everything
we
replicate,
and
this
is.
This-
is
going
to
be
the
last
remaining
component.
Once
we've
completed
object
storage
for
us
to
meet
that
100
Target,
so
we
will
be
looking
to
make
progress
here
and
be
able
to
claim
that
we
do
verify
100
of
the
data
that
we
we
replicate.
A
Then
we
moved
to
Gathering
monthly,
unique
secondary
site
users
for
git
operations.
We
we
already
have
a
metric
to
pull
for
for
users
who
log
in
to
the
UI
on
the
secondary
site.
We
can
identify
unique
users
who
who
log
in
each
month
from
account
of
unique
users
who
log
in
each
month
in
into
that
secondary
site.
A
However,
we
do
not
have
visibility
in
terms
of
how
many
unique
users
perform
git
operations
against
those
secondary
sites,
so
this
effort
is
to
help
us
capture
that
metric
to
help
us
understand
how
better
understand
how
our
customers
use
those
secondary
sites
when
it
comes
to
get
operations.
This
will
also
help
inform
future
decisions
on
enhancements
around
these
capabilities
that
we
we
build
out
for
for
the
secondary
sites
as
well.
So
this
this
this
is.
A
This
is
something
that's
in
progress
and
I
am
looking
forward
to
getting
some
of
the
some
of
the
metrics
out
from
from
this
this
development
and
then,
lastly,
we've
got
proxy,
get
fetch
and
clove
get
fetch
clone
pull
operations
over
SSH
via
gitlab
shell.
We
want
we
in
the
previous
Milestone,
we
shifted.
The
call
Flow
forget
push
operations
to
go
through
the
gitlab
shell.
A
This
helped
us
get
over
some
of
the
challenges
with
regard
to
timeouts,
where
large
push
requests
were
failing
and
we
moved
the
call
Flow
from
Puma
to
to
gitlab
shower,
which
is
consequently
provided
us
as
a
50
performance
Improvement
in
certain
cases,
and
also
remove
the
the
timeout
limitations
that
we
were
hitting
now.
With
the
current
effort
to
consolidate
around
gitlab
shell,
we
want
to
move
fetch
clone
and
pull
operations
via
the
gitlab
shell
as
well,
so
we
have
both
both
directional.
A
A
This
call
Flow,
particularly
when
it
comes
to
managing
options
when
you
use
git,
fetch
or
clone
by
a
secondary
site,
so
looking
forward
to
changing
the
call
Flow
and
changing
adjusting
the
architecture
to
go
through
gitlab
shell.
With
this,
with
this
effort,
and
with
that,
we
conclude,
the
16
3
Geo
Outlook
I,
look
forward
to
seeing
you
next
time,
Ian
thanks
again
for
joining
us
and
I
look
forward
to
having
you
on
an
another
call
in
the
future.