Skip to content

Remove the `repack_after_shard_migration` feature flag

What

Remove the :repack_after_shard_migration feature flag ...

Owners

  • Team: groupsource code
  • Most appropriate slack channel to reach out to: #g_create_source-code-be
  • Best individual to reach out to: @nick.thomas

Expectations

### What are we expecting to happen?

Acute IOPS load during shard migrations are increased, with the benefit of reduced chronic I/O load post-migration. This has been validated for a single project via the 50k environment.

What might happen if this goes wrong?

Acute load may be too high to tolerate in a mass migration scenario. I'd like to test that specifically, and have opened gitlab-com/gl-infra/production#1544 (moved)

What can we monitor to detect problems with this?

Roll Out Steps

  • Enable on staging
  • Test on staging
  • Ensure that documentation has been updated
  • Enable on GitLab.com for individual groups/projects listed above and verify behaviour
  • Coordinate a time to enable the flag with #production and #g_delivery on slack.
  • Announce on the issue an estimated time this will be enabled on GitLab.com
  • Enable on GitLab.com by running chatops command in #production
  • Cross post chatops slack command to #support_gitlab-com 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 #production channel