GitLab Geo Group, 16 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab Kickoff 13.5 - Enablement:Geo

Description

Learn what the Geo team has in store for the GitLab 13.5 release.

Planning issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4979

A

Hello, everyone: this is fabian the product manager for gitlab geo and I'm going to run you through the work that we're going to do in the next reviews get lab 13.5. Let me quickly share my screen.

A

Okay, so as a quick reminder, geo is gitlab's solution for distributed teams and for disaster recovery capabilities, specifically for the ability to fail over to a secondary node to restore operation after some form of service instruction on your primary gitlab instance, and so many of the issues that I'm going to go into more detail today are part of our effort to get geo's maturity from minimal to viable, especially in the disaster recovery arena.

A

So this has been an ongoing effort. As you can see, there are more than 130 issues that we need to close and if you recall from last time in 13.4, some of the items are going to carry over because we are not quite done in time for for this release so for 13.5.

A

The main theme here is to move many of these items that were very close to finishing in that epic and the first thing that I'm going to talk about is the self-service framework for application verification.

A

So geo replicates data from two from one instance to another, and geo is building out capabilities to make replicating easy and also accessible to other teams within gitlab. So one of the main things that we are working on at the moment is to establish a second replication strategy, specifically for git data, so this would be repositories and we're aiming to deliver this for versioned snippets. So that's something that we are working on right now and that will finish in gitlab 13.5.

A

So this is snippet replication in the form of the self-service framework. Excuse me, so verification is something that is structural for this release. First replication. So this is the first thing that we're going to focus on.

A

Then there are a number of unreplicated data types, so data that geo is not automatically replicating from your primary to your secondary. That's, obviously an issue for disaster recovery purposes. If data is not replicated, it may be lost, so we've been working on supporting terraform state files.

A

This is not going to be released in 13.4 as we planned. Initially, we've extended the scope here a little bit because, rather than just supporting terraform state files, the team behind the terraform state capability has merged the ability to replicate versioned, terraform state files and we're going to add those capabilities to geo in 13.5 as well.

A

So this is not only for terraform state files, but the slightly let's say improved version to actually sync them when they are versioned um and that's a lot more easy for us to do within iteration because of the self-service framework. That's going to be a focus for 13.5.

A

So those are the outstanding new data types except for one other one which is external emerge, request diffs. We intended to ship that in 13.4, but it's taking us a little bit longer. So this will also be added in 13.5 and then another effort overall and that's going to continue over a few releases is to improve our documentation.

A

So in 13.4 we're going to merge um a run book for a single node and then in 13.5 we are going to merge a run book for a failover with two sides, with multi-node installations, so slightly more scaled architecture, and I will be good and update the milestone because I forgot so that's going to um happen.

A

um I talked about blobs. Another thing that we've been working on, that's quite valuable for many of our larger customers is support for a fault, tolerant or highly available postgres deployment on your gitlab secondary.

A

So this is not something that we consider a part of viable maturity for the r, but for complete maturity and we're experimenting here with petroni a high availability template for postgres that is now experiment, experimentally supported in omnibus. So we're going to. We had an experiment in 13.4 that was successful, and now we are making the necessary changes to support that in omnibus and getting this generally available will take a while, but we are pushing iterations to add experimental support.

A

Another thing that we've picked up again is our work on a maintenance mode or a read-only mode. This is particularly important for the use case of a planned failover, where you essentially want your primary gitlab instance to become read-only, so users still have access to their data.

A

They can download git repositories and look at the web page, but they can't actually make any changes and that's really important so that your primary and your secondary can become fully synced and then, when you actually fail over there's no data loss so we're working on on this maintenance mode.

A

There's also a poc that we've started that will likely carry over into 13.5.

A

Where the goal is to make it a lot easier for systems administrators to execute a failover at the moment when you want to fail over to a secondary, you have to modify the gitlab rb file manually and remove configuration, and so we are exploring ways here to provide a single command that allows the configuration to be altered so that a systems administrator can essentially promote the primary with a single command. That makes a lot easier to automate with other tools like ansible and we work in this area here.

A

Lastly, we are in the process of validating a new design for our geo node page overview in the administrator interface.

A

So this means scheduling, interviews with systems, administrators understanding if our solution actually fits their their needs- and this is an a quick look at the the new design. It is more compact. It presents more information, it's more collapsible, so it allows more secondary nodes to be displayed and also, it provides a better overview for specific data types where verification and synchronization are grouped, which is a lot easier for for systems administrators to to see.

A

And lastly, we are working on enabling usage ping on geosecondaries.

A

This is particularly because we would like to understand how many users access secondary geo nodes, um so we're working on that that information will help us understand what impacts usage, how our features increase the usability of geo overall- and this is a bit technically involved, because geo secondaries have a read-only database and that's it for 13.5.

A

If we get all of this done, the stretch, goal and sort of the next step, maybe in 13.6, is to start working on file, verification and then, ultimately, on repository verification in the self-service framework. That's also highly important for the r applications, because not everything currently that is replicated is also verified.

A

Thanks for listening in and I'm looking forward to 13.5, I think a whole bunch of efforts are going to get shipped and provide value to you. So thank you.