Abuse report labels are currently implemented as Labels and stored in labels DB table. Since these labels are for abuse reports they do not have a project_id or a group_id and should be under gitlab_main_clusterwide schema (labels is under gitlab_main_cell).
The goal is to introduce a separate model and database table for abuse report labels so that both labels and abuse report labels features are compatible with Cells 1.0.
What does this MR do and why?
This MR introduces AntiAbuse::Reports::Label and AntiAbuse::Reports::LabelLink models backed by abuse_report_labels and abuse_report_label_links DB tables. It also updates the label_links and labels association of AbuseReport to use these new models as follows:
Finally, Admin::AbuseReportLabel < Label model is removed and all references to it are updated to use the new AntiAbuse::Reports::Label model so abuse report labels records go to abuse_report_labels table.
Questions
Do we need to migrate any abuse report label data from labels to abuse_report_labels?
No. The feature is currently not actively used by T&S and is behind a disabled feature flag. There is one abuse report record created in labels table in production that was created for testing and is planned to be deleted through a change request.
What is the anticipated growth for the new table over the next 3 months, 6 months, 1 year? What assumptions are these based on?
Abuse report labels will be used by T&S team (instance admins) in Gitlab.com. There is no limit but with normal use we expect at most a few hundred (overestimate) records in this table.
How many reads and writes per hour would you expect this table to have in 3 months, 6 months, 1 year? Under what circumstances are rows updated? What assumptions are these based on?
We expect labels to be created in bulk or a few at a time and updated rarely (maybe update description, title, color). Reads will happen only when visiting the abuse reports list and abuse report show page.
Based on the anticipated data volume and access patterns, does the new table pose an availability risk to GitLab.com or self-managed instances?
No.
Does the proposed design scale to support the needs of GitLab.com and self-managed customers?
Yes.
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.
