Geo is a Premium feature, built to help speed up the development of distributed teams by providing one or more read-only mirrors of a primary GitLab instance. This mirror (a Geo secondary node) reduces the time to clone or fetch large repositories and projects, can be used to run automated tests, or can be part of a Disaster Recovery solution.
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.
In the longer term, our goal is to be able to promote any secondary node to a primary node state to support a Disaster Recovery situation.
We are also considering what a read-write mirror would involve and where this would fit on our roadmap.
To that end, our priorities are:
Disaster Recovery (DR) is a set of policies, tools and procedures put in place to be able to recover from a disaster.
Geo provides data redundancy. The customer will have a redundant copy of data in a separate location. If anything were to happen to their primary instance, a secondary instance still retains a copy of the data.
However, data redundancy is one part of a complete DR strategy.
High Availability (HA) is also a step towards Disaster Recovery. At the moment Geo does not provide true HA because if the primary instance is not available, certain actions are not possible.
#g_geochat channel for questions that don't seem appropriate to use the issue tracker for.
|Geo||The product name given to the feature that provides the ability to create one or more read-only mirrors for the main/primary instance|
|Primary||The main, primary instance where read-write operations are allowed|
|Secondary||An instance that synchronizes with the Primary node where only read-only operations are permitted|
Discussions are documented separately.
We use issue boards to focus on each milestone and a planning board to look further ahead.
Here you can find the Epics for Geo.
We start planning the new milestone around the 15th of each month. During this week we open up the new board and start adding issues.
This link is pasted into our Slack channel and the team start to review the issues added. This way we can prevent starting a milestone with blocked issues.
In the week before the cut-off, the board for the new milestone is finalized. Issues that are not ready for the milestone are removed, and remaining issues are prioritized.
The demos are recorded and should be stored in Google Drive under "GitLab Videos –> Geo Demos". If you recorded the demo, please make sure the recording ends up in that folder.