Roll out deprecation logger via environment variable
Production Change
Change Summary
See gitlab-org/gitlab#333330 (closed)
We are looking to make GitLab compatible with Ruby 3. A common source of incompatibility is the use of functionality that was deprecated in Ruby 2.7, and is an error in Ruby 3.
To that end, we are looking to add a new log file, deprecation_json
, which will accumulate deprecation warnings emitted from Ruby and Rails and will serve as input for where we need to fix existing issues. The change has been merged into master and is sitting behind an environment variable GITLAB_LOG_DEPRECATIONS
, which we are looking to roll out gradually in production.
The main challenge is that the log volume is unknown, since we do not know how which code paths will end up emitting deprecation warnings. We are already logging deprecations in our test suite, and have fixed many of those, but there might be remaining issues that we are not catching in spec runs.
Change Details
- Services Impacted - All Rails nodes: ServiceAPI ServiceWeb ServiceWebsockets ServiceGit ServiceGitLab Rails
- Change Technician - DRI for the execution of this change
- Change Reviewer - DRI for the review of this change
- Time tracking - Time, in minutes, needed to execute all change steps, including rollback
- Downtime Component - If there is a need for downtime, include downtime estimate here
Detailed steps for the change
Change Steps - steps to take to execute the change
Estimated Time to Complete (mins) - Estimated Time to Complete in Minutes
-
Enable env var for gstg
-
Enable env var for cny
-
Enable env var everywhere
Post-Change Steps - steps to take to verify the change
Estimated Time to Complete - a few days
-
Let enough time pass to see if any warnings emitted via json.subcomponent: deprecation_json
Rollback
Rollback steps - steps to be taken in the event of a need to rollback this change
Estimated Time to Complete (mins) - Estimated Time to Complete in Minutes
-
Remove or disable GITLAB_LOG_DEPRECATIONS
for production fleet -
Remove or disable GITLAB_LOG_DEPRECATIONS
for staging
Monitoring
Key metrics to observe
- Metric:
json.subcomponent: deprecation_json
- Rails: https://log.gprd.gitlab.net/goto/12c81fb4efcaa2429454d2d7381def49
- Sidekiq: https://log.gprd.gitlab.net/goto/d7dc03991953e2ada4b744510a64ac95
- What changes to this metric should prompt a rollback: -
Changes checklist
-
This issue has a criticality label (e.g. C1, C2, C3, C4) and a change-type label (e.g. changeunscheduled, changescheduled) based on the Change Management Criticalities. -
This issue has the change technician as the assignee. -
Pre-Change, Change, Post-Change, and Rollback steps and have been filled out and reviewed. -
This Change Issue is linked to the appropriate Issue and/or Epic -
Necessary approvals have been completed based on the Change Management Workflow. -
Change has been tested in staging and results noted in a comment on this issue. -
A dry-run has been conducted and results noted in a comment on this issue. -
SRE on-call has been informed prior to change being rolled out. (In #production channel, mention @sre-oncall
and this issue and await their acknowledgement.) -
Release managers have been informed (If needed! Cases include DB change) prior to change being rolled out. (In #production channel, mention @release-managers
and this issue and await their acknowledgment.) -
There are currently no active incidents.