GitLab GitLab 13.8 Kick off, 15 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.8 Kickoff - Create:Gitaly

Description

Gitaly Kickoff video for GitLab 13.8.

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

A

Hello, everyone and welcome to the giddily groups, 13.8 planning for git lab uh we're very excited about this release. We have some exciting features in store, uh given that this is the holiday season, we're ensuring that we're planning accordingly to not overwhelm our team during this season.

A

We want to be mindful that it's important to take time off, and we want to allow for that within our group, uh with gitly cluster being rolled out to gitlab.com, as well as some other key customers, we're getting some really really good feedback and there's been some few small reliability and performance issues that we that have come to surface, that we want to take care of right away.

A

Therefore, we're focusing this release heavily on reliability and performance and technical debt and bugs to ensure the optimal performance as we continue to roll out get a giddily cluster to other customers and internally to gitlab.com.

A

I've listed all the reliability and performance issues we're focusing on as well as the technical debt and bugs as well as the feature we're going to continue to develop toward which is the variable replication factory for specific repositories.

A

I want to talk about that first. This is a really exciting feature for gili cluster. It will enable our users to specify how often their repositories are replicated across the cluster, how many nodes they're replicated on, which allows them to be much more efficient in their use of storage. It also allows for exceptional, horizontal scaling and allows for high availability amongst all of those repositories that they deem critical or less high availability for those repositories that are not as critical.

A

That's a really important feature for gili cluster and we're excited to continue to work on that in this release.

A

Some of the other bug fixes and reliability issues we're looking to tackle this month. We do not want to continue querying the primary node when performing a read. There's no need for this and there's other ways of solving this problem, so in the interest of ensuring the best performance for our users, we have a solution in mind is where we can generalize the flow to get the data nodes and skip checking which node is the primary.

A

This will avoid extra database query. It will increase performance and we'll also serve reads. Only up from data nodes instead of nodes, which are the same generation as the primary, so this is very important as a performance increase.

A

Another thing we're looking to do is to add the fetch, sha abstraction to remote repository right now, fetching a single sha is done in multiple places along across the code base.

A

This can tend to be error prone if we don't catch all of them when we make updates so we're looking to have an easy to use function that will generalize this functionality and that can be called throughout our code base, which should eliminate code complexity and ensure higher availability and less errors, which is also very instrumental in our success.

A

I'll leave the rest of these for you to look through there's also, some security related issues that we're taking tackling as well. If there are any questions or you'd like to comment or reach out to the team, this issue will be linked down below. Please feel free to comment on any of the issues you feel strongly about, or if you have suggestions or questions. Thank you very much.