[ci_queueing_denormalize_shared_runners_information] Rollout shared runners denormalization for new queuing system
Summary
This issue is to rollout shared runners denormalization on production,
that is currently behind the ci_queueing_denormalize_shared_runners_information
feature flag.
This feature will speed up our existing query the ci_builds and use denormalize data from our new queuing system to determine which build with shared runners will get pick up by runners.
Owners
- Team: grouppipeline execution
- Most appropriate slack channel to reach out to:
#g_pending_builds_table
- Best individual to reach out to: @morefice @grzesiek
Expectations
What are we expecting to happen?
The new queuing system should query builds faster.
What might happen if this goes wrong?
The new queuing system will query builds slower.
What can we monitor to detect problems with this?
What can we monitor to detect problems with this?
Sentry, PostgreSQL triage dashboard.
Rollout Steps
-
Enable the FF fully on Staging -
/chatops run feature set ci_queueing_denormalize_shared_runners_information true --staging
-
-
Enable for 5% of calls on gitlab.com -
/chatops run feature set ci_queueing_denormalize_shared_runners_information 5
-
-
Enable for 10% of calls on gitlab.com -
/chatops run feature set ci_queueing_denormalize_shared_runners_information 10
-
-
Enable for 50% of calls on gitlab.com -
/chatops run feature set ci_queueing_denormalize_shared_runners_information 50
-
-
Enable for 100% of calls on gitlab.com -
/chatops run feature set ci_queueing_denormalize_shared_runners_information 100
-
/chatops run feature set ci_queueing_denormalize_shared_runners_information true
-
Rollback Steps
-
This feature can be disabled by running the following Chatops command:
/chatops run feature set ci_queueing_denormalize_shared_runners_information 0
/chatops run feature set ci_queueing_denormalize_shared_runners_information false
cc @grzesiek