[Feature flag] Rollout of `ci_owned_runners_unnest_index`
Summary
ci_owned_runners_unnest_index
feature flag.
- Related to #336436
- Introduced in Make `User#ci_owned_runners` to use unnest inde... (!83843 - merged)
Owners
- Team: groupsharding
- Most appropriate slack channel to reach out to:
#g_sharding
- Best individual to reach out to: @ayufan
Expectations
What are we expecting to happen?
When is the feature viable?
We are expecting that User#ci_owned_runners
will start using the new ci-mirror tables instead of cross-joining.
What might happen if this goes wrong?
We can disable the feature flag.
What can we monitor to detect problems with this?
Response times:
- GET
/api/:version/runners
=> https://log.gprd.gitlab.net/goto/1eea3350-7d30-11ec-a649-b7cbb8e4f62e - GET
Projects::Settings::CiCdController#show
=> https://log.gprd.gitlab.net/goto/9e9dd9d0-7d30-11ec-a649-b7cbb8e4f62e
Error rates:
- GET
/api/:version/runners
=> https://log.gprd.gitlab.net/goto/167c2660-7d30-11ec-9dd2-93d354bef8e7 - GET
Projects::Settings::CiCdController#show
=> https://log.gprd.gitlab.net/goto/a381d5a0-7d30-11ec-9dd2-93d354bef8e7
Rollout Steps
Rollout on non-production environments
-
Enable the feature globally on non-production environments. -
/chatops run feature set ci_owned_runners_unnest_index true --staging
-
-
Verify that the feature works as expected. Posting the QA result in this issue is preferable.
Specific rollout on production
- If you're using user-actor, you must enable the feature on these entries:
-
/chatops run feature set --user=gitlab-qa ci_owned_runners_unnest_index true
-
-
Verify that the feature works on the specific entries. Posting the QA result in this issue is preferable.
Preparation before global rollout
-
Check if the feature flag change needs to be accompanied with a change management issue. Cross link the issue here if it does. -
Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the @sre-oncall
Slack alias. -
Ensure that documentation has been updated (More info). -
Announce on the feature issue an estimated time this will be enabled on GitLab.com. -
Ensure that any breaking changes have been announced following the release post process to ensure GitLab customers are aware. -
Notify #support_gitlab-com
and your team channel (more guidance when this is necessary in the dev docs).
Global rollout on production
For visibility, all /chatops
commands that target production should be executed in the #production
slack channel and cross-posted (with the command results) to the responsible team's slack channel (#g_TEAM_NAME
).
-
Incrementally roll out the feature. - If the feature flag in code has an actor, perform actor-based rollout.
-
/chatops run feature set <feature-flag-name> <rollout-percentage> --actors
-
- If the feature flag in code does NOT have an actor, perform time-based rollout (random rollout).
-
/chatops run feature set <feature-flag-name> <rollout-percentage> --random
-
- Enable the feature globally on production environment.
-
/chatops run feature set <feature-flag-name> true
-
- If the feature flag in code has an actor, perform actor-based rollout.
-
Announce on the feature issue that the feature has been globally enabled. -
Wait for at least one day for the verification term.
Rollback Steps
-
This feature can be disabled by running the following Chatops command:
/chatops run feature set ci_owned_runners_unnest_index false
Edited by Kamil Trzciński