GitLab 13.11 Release Kickoff, 17 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.11 Kickoff - Create:Gitaly

Description

Kickoff video introducing the features that Gitaly is planning in releasing as part of GitLab 13.11.

Gitaly Planning Issue - https://gitlab.com/gitlab-org/create-stage/-/issues/12818

A

Good day, everyone and welcome to the giddily 13.11 planning issue for the kickoff for get lab 13.11..

A

uh This issue represents the release planning for the gilly group and we have a few ongoing initiatives right now, uh the first of which is to prepare for the fortino release of giddily with gitlab 14 on the horizon. We want to ensure that there's a seamless transition for our giddily users and one of the most notable changes that impacts giggly coming up is the removal of nfs support.

A

This means that gitlab will no longer be supporting issues and architectural problems with nfs storage for gili cluster. Because of that one of our big things we want to make sure happens. We want to make sure the documentation is up to date and there's a very clear migration path, so we're working toward that here in 1311, with the idea of being able to release that into the release post for the 1311 release post and give everybody a full month during the 1312 release cycle to ensure that they are migrated if they so desire.

A

Another one of our initiatives is variable replication factor. There are a couple issues here that further this goal of having a seamless variable, replication factor for our users, one of the things we want to make sure we do is roll out repository specific primaries.

A

All right now thing the primary is decided on a cluster basis, so there's a single repository and we're looking to ensure that there's no longer an assumption that every repository is stored on every virtual storage, and this is important as we move forward in variable replication factor, because if there's a cluster of seven or eight storage nodes, it is not reasonable to expect that everybody will want each repository on all eight nodes.

A

In fact, they probably won't amount to three of those eight nodes, which means that the primary would have to be one of the three nodes where the storage was actually resident. So this is another step toward our variable replication factor.

A

The other step we're taking forward is with variable replication factor, is to ensure that the reconciler can commit to having the desired replication factor even after storage removals. So right now, if you have four nodes in your cluster and you remove one, if something will start on all four nodes, it will now be stored on three nodes and if you remove a second it'll, be stored on two, if you were to add a node back in to make sure that there were three nodes, it wouldn't automatically say.

A

Oh, we need to ensure that this is rolled out to all three, because that's what the replication factor is set at.

A

So this will be a great step forward and, coupled with the other issue, I just discussed will allow for us to have a true cluster configuration with numerous nodes and repositories replicated on the correct number of nodes across that cluster for features we're looking to upgrade to get version 2.31.

A

So that's ongoing. We also have a couple infradev issues ongoing to ensure performance for our getlab.com users. These are issues that we've noticed that could result in a degradation of performance. So we're prioritizing these in this release to ensure that the performance for our dot com users is as good as can be.

A

I will include a link to the kickoff video here and I will include a link to this issue from the kickoff video. I also have a link to our issue board. If there are any questions or comments, please let me know, and we would love to see you collaborating on these issues. If these are important to you, come in and leave a comment. Let us know you know how we're doing and if there's anything else we can do feel free to to open up an issue. Thank you again for your time.