Skip to content

Changes to the Geo Team frontpage

Rachel Nienaber requested to merge rnienaber-geo-front-page into master

This MR is to provide more background on the goals and priorities that I am proposing for the Geo team. Please let me know your thoughts.

Goals

The goal of the Geo Team is to provide an easily configurable read-only mirror of a GitLab installation that is complete, accurate, verifiable and efficient.

Geo is a feature of GitLab that we offer to our customers, so we need to make sure that it is easy to use and that it works properly. That should always be a high priority because we want to make something that customers like to use. Because it is a mirror, customers will rely on it if something goes wrong with their primary. We need to make sure that the mirror is accurate.

We are also our customer (gitlab.com), so the intention with this goal is also to capture that we want to have this running for gitlab.com.

Maybe vision is a better word than goal here? These are general goals and not OKR's. (OKR's should be more specific. measurable and timebound.)

In the longer term, our goal is to be able to promote any Geo Secondary to a Geo Primary state to support a Disaster Recovery situation.

This seems a natural progression from having a mirror. If the primary is unavailable, work could still continue. Having read the open issues, it seems that this is a longer term item as there are quite a few things that would need to happen first.

Priorities

1. [Hashed Storage GA], alleviating challenges from the [legacy storage solution].
2. To [deploy Geo in another GCP region], providing gitlab.com with resilience. 
3. Reduce the effort required to install, configure and maintain Geo secondaries.
4. Clear up any bugs concerning the accuracy of the replicated data, or the reporting on the state of a secondary.
5. Ensure that Geo runs efficiently.

The thoughts behind the ordering are:

  • hashed storage is going through the rollout now, so keeping it as the top priority means it will ship and start giving benefit soon
  • if we ask infrastructure to prioritize getting geo deployed for gitlab.com, then we will be using our work to support the production systems
  • asking infrastructure to install it means we can ask for their input for how to make the installation and administration easier for our customers
  • if we're using geo in production, we need to clear up any issues around replicated data or the state thereof
  • and if we're using it in production, we need to make sure it's efficient, and we can use gitlab.com to help identify any other areas where performance can be improved
Edited by Rachel Nienaber

Merge request reports