Add desired sharding keys for deployment_management

Add desired sharding keys for feature category deployment_management.

These tables have been identified as a cell local tables. All cell local tables require a sharding key or a desired sharding key

A desired sharding key has been automatically selected for these tables. These keys were chosen as the desired sharding keys because the table has a :belongs_to relationship to a table that itself has a NOT NULL sharding key.

Additionally, gitlab_schema has been set to gitlab_main_cell for any tables didn't use this schema already. For these tables we have also added allow_cross_joins, allow_cross_transactions and allow_cross_foreign_keys. These will silence any existing violations, allowing the pipeline to pass without requiring further changes. In the future, we'll remove these allow_... statements and fix any violations as they arise. You can read more about this in the documentation for multiple databases

We have assigned a random backend engineer from groupenvironments to review these changes.

Please confirm that:

• each of these tables can be classified as cell local
• the selected desired sharding key is appropriate
• the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger. If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you can use this link.

This change was generated by gitlab-housekeeper

added automation:gitlab-housekeeper-authored database groupenvironments maintenancescalability labels

requested review from @partiaga

added typemaintenance label

added devopsdeploy sectioncd labels

added databasereview pending label

	2 Warnings
	aaff6078: The commit body should not contain more than 72 characters per line. For more information, take a look at our Commit message guidelines.
	This merge request does not have any assignee yet. Setting an assignee clarifies who needs to take action on the merge request at any given time.

Reviewer roulette

Category	Reviewer	Maintainer
database	@bala.kumar (UTC+5.5, 4.5 hours ahead of author)	@dfrazao-gitlab (UTC+1, same timezone as author)

Please check reviewer's status!

• Reviewer is available!
• Reviewer is unavailable!

Please refer to documentation page for guidance on how you can benefit from the Reviewer Roulette, or use the GitLab Review Workload Dashboard to find other available reviewers.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

E2E Test Result Summary

allure-report-publisher generated test report!

e2e-test-on-gdk: test report for d6359cfa

expand test summary

+------------------------------------------------------------------+
|                          suites summary                          |
+-------------+--------+--------+---------+-------+-------+--------+
|             | passed | failed | skipped | flaky | total | result |
+-------------+--------+--------+---------+-------+-------+--------+
| Plan        | 53     | 0      | 0       | 0     | 53    | ✅     |
| Govern      | 65     | 0      | 1       | 0     | 66    | ✅     |
| Create      | 53     | 0      | 12      | 5     | 65    | ✅     |
| Verify      | 31     | 0      | 0       | 0     | 31    | ✅     |
| Monitor     | 7      | 0      | 0       | 0     | 7     | ✅     |
| Package     | 21     | 0      | 2       | 0     | 23    | ✅     |
| Data Stores | 29     | 0      | 3       | 0     | 32    | ✅     |
| Analytics   | 2      | 0      | 0       | 0     | 2     | ✅     |
| Release     | 5      | 0      | 0       | 0     | 5     | ✅     |
| Manage      | 0      | 0      | 1       | 0     | 1     | ➖     |
+-------------+--------+--------+---------+-------+-------+--------+
| Total       | 266    | 0      | 19      | 5     | 285   | ✅     |
+-------------+--------+--------+---------+-------+-------+--------+

added 1 commit

• d6359cfa - Revert changes for agent_activity_events

Compare with previous version

approved this merge request

Looks good to me

@dfrazao-gitlab can you please do the database maintainer review? Thanks

requested review from @dfrazao-gitlab and removed review request for @partiaga

@partiaga, thanks for approving this merge request.

This is the first time the merge request has been approved. To ensure we don't only run predictive pipelines, and we don't break master, a new pipeline will be started shortly.

Please wait for the pipeline to start before resolving this discussion and set auto-merge for the new pipeline. See merging a merge request for more details.

added pipeline:mr-approved label

changed milestone to %16.9

added databaseapproved label and removed databasereview pending label

resolved all threads

approved this merge request

enabled an automatic merge when all merge checks for d6359cfa pass

Hey, @DylanGriffith!

Can we update the gitlab-housekeeper gem to add the milestone when a merge request is opened?

merged

Hello @manojmj

The database team is looking for ways to improve the database review process and we would love your help!

If you'd be open to someone on the database team reaching out to you for a chat, or if you'd like to leave some feedback asynchronously, just post a reply to this comment mentioning:

@gitlab-org/database-team

And someone will be by shortly!

Thanks for your help!

This message was generated automatically. You're welcome to improve it.

mentioned in commit bccc5bc3

added workflowstaging-canary label

added workflowcanary label and removed workflowstaging-canary label

added workflowstaging label and removed workflowcanary label

added workflowproduction label and removed workflowstaging label

added workflowpost-deploy-db-staging label and removed workflowproduction label

added workflowpost-deploy-db-production label and removed workflowpost-deploy-db-staging label

added releasedcandidate label

mentioned in merge request kubitus-project/kubitus-installer!2763 (merged)

@tigerwnz so this is one of the tables I talked about on Slack.

Automation tries to create agent_activity_events.project_id as the desired sharding key, but project_id is already a null-able column on this table, so the spec fails - which is why this had to be reverted within this MR.

https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/27242/commands/84739 says there are indeed many rows where agent_activity_events.project_id is null.

Since this table belongs to deploy as well, I thought of asking you for advice on how to move forward: can project_id be backfilled to turn it into a non-nullable column. Or, should we put in a desired sharding key that's renamed, like, say sharding_project_id?

@manojmj the project_id column on this table is actually unused (it is NULL for all records). It was originally added for a feature that hasn't been implemented yet, and I'm not sure if it will ever be used.

Even so, it might be easier to just add a new sharding key column as that way it can be handled fully via automation (and the original project_id is then available if we do decide to use it).

added releasedpublished label and removed releasedcandidate label

added pipelinetier-3 label