GitLab Geo Group, 16 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.6 Kickoff - Enablement:Geo

Description

14.6 Planning Issue: https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/5019

Geo Kanban Board: https://gitlab.com/groups/gitlab-org/-/boards/1181257?label_name[]=geo%3A%3Aactive&group_by=epic

A

Hello and welcome to the get lab 14 6 kickoff for the geo team, I'm nick nguyen engineering manager and acting product manager for geo before we get into what's ahead in 14 6. I just want to go over a couple of important deprecations for 14.5, so in 14.5 we released a single command to promote any type of secondary node to a primary uh greatly simplifying the failover process. This command is get lab, ctl geopromote.

A

Now that this command is available, we are deprecating. The two previous failover commands, uh gitlab ctl, promote to primary node and get lab ctl, promote db, uh we're deprecating, those in 14.5 and they're, scheduled for removal in get lab 15..

A

So please plan accordingly make sure that you take the chance before get lab 15 to test the gitlab ctl geopromote command and incorporate into your failover workflow all right.

A

The main thing that we're excited about in 14 6 is continuing to make progress on increasing our disaster recovery capability from viable maturity to complete one of the key aspects of this is increasing the amount of data the amount of replicated data that we verify from 50 to seventy percent and we'll increase it to seventy percent by adding verification, support for external merge request, diffs lfs objects, uploads and pages deployments.

A

Verification is important because, when you're replicating data from primary to secondary, you want to make sure that the data hasn't been corrupted or changed during replication to ensure data integrity upon failover in a disaster recovery scenario.

A

Next we're also going to start migrating ci job artifact replication to use the geo self-service framework. There are a couple benefits to doing this. One is that we'll be able to quickly then follow up with adding support for ci job artifact verification.

A

We'll also be able to take advantage of the performance benefits that the self-service framework provides and we'll be able to increase maintainability of the feature and remove over a thousand lines of legacy code.

A

In 14 6 we're also going to start working on an important ux improvement to our synchronization status. Progress bars right now in the geosite's admin ui. We display the sync status for each data component for large active git lab instances. It's possible that even without any sync failures and replication in a healthy state that the progress bar would regularly stay at 99 and never reach 100, because there are always new changes in the replication queue.

A

This can be a problem uh one because uh it can be confusing to systems administrators who aren't familiar with how that progress is calculated and two in highly regulated industries. Auditors may want to use this feature and use the progress bar to get a sense of whether a customer's disaster recovery solution is working as intended. So we want to improve the progress bar user experience by making the information more transparent and easy to understand when replication is healthy and working as intended and within a customer's designated recovery. Point objective.

A

Those are a couple of things that we are looking forward to in 14 6.. uh There are quite a few more items and you can find those in the 14 6 planning issue linked in the description of this video.

A

As always, we work in a continuous and kanban style, so this is just a outlook of what we have planned and not a guarantee of. What's going to make the 14-6 release to keep to keep up with the current status of our planned work, you can follow along in the issues linked in the planning issue or uh follow along in our geo kanban board.

A

All right. Thank you. So much for watching and we'll see you next time, bye.