[ci_pending_builds_maintain_ci_minutes_data] Rollout ci minutes writing denormalization for new queuing system
Summary
This issue is to rollout ci minutes writing denormalization on production,
that is currently behind the ci_pending_builds_maintain_ci_minutes_data
feature flag.
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 write new denormalized data without slowing down the system.
What might happen if this goes wrong?
The new queuing could slow down our system.
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_pending_builds_maintain_ci_minutes_data true --staging
-
-
Enable for the group gitlab-org -
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data --group=gitlab-org true
-
-
Enable for 5% of calls on gitlab.com -
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data 5
-
-
Enable for 10% of calls on gitlab.com -
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data 10
-
-
Enable for 50% of calls on gitlab.com -
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data 50
-
-
Enable for 100% of calls on gitlab.com -
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data 100
-
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data true
-
Rollback Steps
-
This feature can be disabled by running the following Chatops command:
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data 0
/chatops run feature set ci_pending_builds_maintain_ci_minutes_data false
cc @grzesiek
Edited by Max Orefice