GSTG: Create a bucket for SQL Capture (part of SQL Traffic Capture and Replay)

Production Change

Change Summary

This change creates a bucket for SQL Capture (part of SQL Traffic Capture and Replay) in gstg. gitlab-org/gitlab#562377 (closed)

Change Details

1. Services Impacted - Nothing will be impacted, but this is the first piece of infrastructure for what will eventually be the SQL Traffic Capture and Replay service.
2. Change Technician - @zbraddock
3. Change Reviewer - @l.rosa
4. Scheduled Date and Time (UTC in format YYYY-MM-DD HH:MM) - 2025-08-08 02:30
5. Time tracking - 30m
6. Downtime Component - None

Detailed steps for the change

Pre-execution steps

• Make sure all tasks in Change Technician checklist are done
• There are currently no active incidents that are severity1 or severity2

Change steps - steps to take to execute the change

Estimated Time to Complete (mins) - 15min

• Set label changein-progress /label ~change::in-progress
• Merge the config-mgmt MR https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/11923
• Set label changecomplete /label ~change::complete

Rollback

Rollback steps - steps to be taken in the event of a need to rollback this change

Estimated Time to Complete (mins) - 15min

• Revert the config-mgmt MR https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/11923
• Set label changeaborted /label ~change::aborted

Monitoring

Key metrics to observe

• Metric: Eyeball that the bucket was created with the expected permissions etc
  • Location: gitlab-staging-1 in the GCP Console
  • What changes to this metric should prompt a rollback: If the bucket was not created as expected

Change Reviewer checklist

C4 C3 C2 C1:

• Check if the following applies:
  • The scheduled day and time of execution of the change is appropriate.
  • The change plan is technically accurate.
  • The change plan includes estimated timing values based on previous testing.
  • The change plan includes a viable rollback plan.
  • The specified metrics/monitoring dashboards provide sufficient visibility for the change.

Change Technician checklist

• The change plan is technically accurate.
• This Change Issue is linked to the appropriate Issue and/or Epic
• The change execution window respects the Production Change Lock periods.