Draft: PoC for admin controls backend
What does this MR do and why?
I decided to put together a super dirty PoC for how the BE changes might look for the admin controls to try and uncover any potential problems we might hit or alternatives we might want to investigate, or even provide a basis to start work from in future.
I think the biggest outcomes are:
-
AuditEvents
might not be best approach for tracking limit changes / exclusions. I feel like we're attempting to use them in a non-standard way, i.e. rather than streaming the events, we want to query all events for a plan limit or namespace exclusion so that we can render a list in the UI. Without diving in too far, this felt like it might spiral into a large effort and might ultimately be incredibly inefficient.The AuditEvents table is large enough that it's partitioned on a monthly basis. Given we're only expecting a handful of changes to either
PlanLimits
or inclusion/exclusion changes, perhaps we should just introduce a dedicated tracking table for this purpose?Regardless of approach, I think the tracking needs to be split into separate issues, as I suspect it'll be more effort than originally anticipated.
Due to this finding, I didn't tackle https://gitlab.com/gitlab-org/gitlab/-/issues/385755+ in this effort
-
GraphQL feels a little ...clunky for this. Besides that, I'm also not sure we want to be updating the schema to have gitlab.com/admin only queries/mutations. Perhaps REST API endpoints would suit this better
Otherwise, I think this approach looks straight forward enough
I've split the PoC into commits by issue, so folks may find it helpful to view by commit.