First Pass categorization of Controllers to assign feature categories to web requests
Background
In #386 (closed), we created the ability to assign a feature category to a Controller or Action. This is similar to the work done to categorize Sidekiq workers.
We plan to use this information to be able to easily attribute usage to a stage group.
Alternatives we considered
- Announce this change and wait for stage groups to categorize their Controllers -> this creates a dependency on the stage groups who may not all respond quickly
- Create the MR and ask for approval from stage groups before merging -> this creates a big merge request with potentially a lot of threads to resolve as people spot incorrect assignments
- Create MRs in batches by feature category -> this is a smaller merge request than above, but require updates to two MRs when a Controller is allocated to the wrong feature category
Proposal
-
Create MRs we assign feature categories to Controllers and Actions on a best-guess basis -
B-F: gitlab-org/gitlab!43873 (merged) -
H-Z (excluding P): gitlab-org/gitlab!44150 (merged) -
A for Admin: gitlab-org/gitlab!44283 (merged) -
G for Groups: gitlab-org/gitlab!44288 (merged) -
P for Projects: gitlab-org/gitlab!44621 (merged)
-
-
Publicise this MR through -
Engineering Week In Review -
Backend Maintainers Channel -
Backend Channel
-
This approach seems the most efficient. Since we are not using this information for anything yet, having this wrong at the moment does not have a huge impact. We can rely on the engineers who own each area of the code to see our updates and make the changes necessary without having to involve a lot of people on a single MR. When we do start using this information to alert stage groups to interesting usage patterns, they will still be able to correct this assignment with little effort.
Edited by Sean McGivern