Convert performance_bar_stats to an ops feature flag
:performance_bar_stats feature flag introduced in !48149 (merged)
- Team: Plan
- Most appropriate slack channel to reach out to:
- Best individual to reach out to: jprovaznik
What are we expecting to happen?
Data are logged in performance_bar_log_json.log
What might happen if this goes wrong?
Increased load due to async job which proceses peek stats (in case there would be extreme amount of these stats) - which is low chance - we delete peek redis data after 30 minutes.
What can we monitor to detect problems with this?
Sidekiq job (app/workers/gitlab_performance_bar_stats_worker.rb), size of performance_bar_log_json.log file
If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.
This feature is enabled/disabled globally.
Roll Out Steps
Enable on staging (
/chatops run feature set feature_name true --staging)
Test on staging
Ensure that documentation has been updated
Enable on GitLab.com for individual groups/projects listed above and verify behaviour (
/chatops run feature set --project=gitlab-org/gitlab feature_name true)
Coordinate a time to enable the flag with the SRE oncall and release managers
Announce on the issue an estimated time this will be enabled on GitLab.com
Enable on GitLab.com by running chatops command in
/chatops run feature set feature_name true)
Cross post chatops Slack command to
#support_gitlab-com(more guidance when this is necessary in the dev docs) and in your team channel
Announce on the issue that the flag has been enabled
Remove feature flag and add changelog entry
After the flag removal is deployed, clean up the feature flag by running chatops command in
This feature can be disabled by running the following Chatops command:
/chatops run feature set --project=gitlab-org/gitlab performance_bar_stats false