Skip to content

Draft: PoC for admin controls backend

Vijay Hawoldar requested to merge admin-controlled-limits-poc into master

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:

  1. 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

  2. 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.

Edited by Vijay Hawoldar

Merge request reports