Application Performance Group - 15.5 Planning
This page may contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Capacity
List any noteworthy PTO that may impact the capacity for the planned milestone
Planning
Indicate major efforts by linking to the appropriate epic. Under each epic indicate who is focusing on these efforts and list the individual issues assigned for this milestone.
%15.5
Top Priorities forUpdate supported Ruby version to 3.0
Who: @mkaeppler
As Ruby 2.7 EOL is expected to be March 2023 based on life expectancy of previous major releases, the ~"group::application performance" has been putting a lot of effort into the upgrade and reached a point where we were about to run the Ruby 3 pipeline on the main branch. As we are approaching the expected Ruby 2.7 EOL, we hope to finish the whole rollout in the next few milestones.
- In %15.4, we started an audit process for gitlab-rails dependencies for Ruby 3 compatibility. We expect the work to continue in %15.5.
- We have started Ruby 3 pipeline. We expect to spend time triaging the potential issues or routing the issues to other teams who own these specific features.
- Make sure to add Ruby 3 builds for all GitLab libraries.
Investigate Puma long-term memory use
Who: @alipniagov
In prior releases, we have added abilities to collect more metrics and diagnostic reports to help us troubleshoot GitLab instances memory issues. In %15.4, we have been doing PoC to find out a proper way of uploading the diagnostic reports to GCS. And we have decided to go with one approach that's described here.
- In %15.5, we plan to finish the work of the uploader, and roll it out on GitLab.com.
- We may also resolve remaining open issues in Upload diagnostic reports to GCS
Roll out the gitlab-metrics-exporter on GitLab.com
Who: @mkaeppler
Per the project description, GitLab Metrics Exporter (GME) is meant to subsume the functionality of gitlab-exporter and in-app Ruby Prometheus exporters distributed with and running in gitlab-rails. We have finished most of the work in phase 1, and we plan to roll it out on GitLab.com as the next step.
- The rollout is tracked in Roll out gitlab-metrics-exporter for gitlab-rails (gitlab-org/gitlab#355460 - closed)
- There are also some open issues in GME phase 1: sidecar mode (gitlab-org&8042 - closed). We may consider to resolve them in %15.5
- For knowledge sharing purposes, we may also consider onboarding more team members in this project along with other development activities.
Fixing and fine-tuning the Sidekiq memory killer
Who: @nmilojevic1
At the moment, we still have open questions to answer before we can write down the details of the future work. We should discuss our options and set exit criteria for this work. The detailed steps will depend on the decisions to those open questions.