Add cluster_wide schema to add_ons
What does this MR do and why?
Add cluster_wide schema to add_ons
The subscriptions_add_ons table is very much similar to plans table.
In that sense it should have: gitlab_schema: gitlab_main_clusterwide
For each new add-on, we would create a new record. Currently, it only has 1 record
for code_suggestions
add-on in production, and 2 records
in staging.
The number of record would increase in proportion to number of add-ons we add in future. A good guess would be not more than hundreds.
[ gstg ] production> GitlabSubscriptions::AddOn.all
=>
[#<GitlabSubscriptions::AddOn:0x00007f80bcfe51e8
id: 1,
created_at: Fri, 16 Jun 2023 11:21:46.796081000 UTC +00:00,
updated_at: Fri, 16 Jun 2023 11:21:46.796081000 UTC +00:00,
name: "code_suggestions",
description: "[FILTERED]">,
#<GitlabSubscriptions::AddOn:0x00007f80bcfe5120
id: 34,
created_at: Fri, 19 Jan 2024 12:32:58.042233000 UTC +00:00,
updated_at: Fri, 19 Jan 2024 12:32:58.042233000 UTC +00:00,
name: "product_analytics",
description: "[FILTERED]">]
[ gstg ] production> GitlabSubscriptions::AddOn.count
=> 2
[ gstg ] production>
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Related to #441399