Administrative tags for Users and Projects
Background
When running a large GitLab instance, administrators and operators may need to perform operations on a set of projects or users.
At present, we have an administrative notes field on projects and users, these can be used for this purpose.
This is a free text field and the T&S team, support personal and SREs use it to keep notes on projects.
Having this is great, but unfortunately it's fairly limited in applicability, particularly since the text is not considered machine readable.
Proposal: Add Administrative Tags for Users and Project
Tags would apply to users and projects (and possibly other objects in future too). Each user or project could have zero or more administrative tags, and each tag would be a string value.
These would be very similar to the existing tags that we apply to projects, with one major difference: the tags would only be readable and writable by instance administrators.
The tags would be accessible through the API, and optionally the Admin UI. Administrators would need to be able to add perform CRUD operations for tags.
Importantly, administrators would need to be able to list all projects/users for a given tag, via the API. This could be done using GraphQL or a REST endpoint.
Examples of how this could be used
Migrating repositories to different Gitaly instances
At present on GitLab.com we generate a CSV file of repositories that we would like to move to another instance. In the case of CIrepoM, this CSV loaded into a separate datastore for further processing.
With an administrative tagging system, repositories could be marked with specific tags instead of relying on CSV files and external databases for this purpose. The repositories would be marked with a specific tag, and then a migration process could query for that tag and issue move commands, removing the tag when the migration is complete.
Flagging repositories or users for T&S issues
When T&S processes pick up an issue with a user or project, these could be flagged using tags. The T&S team could then review all projects marked with a specific tag before taking further action, such as blocking an account.
While our T&S team have sophisticated processes for handling, including their own applications, allowing projects and repositories to be flagged would provide a mechanism for other GitLab self-managed operators to automate their own processes.
Automatic Gitaly Shard Selection
This would require some further development, but when a new user creates a repository, it could automatically target a specific Gitaly shard based on tag matching, similarly to how CI jobs and CI runners are matched at present.
This would allow certain projects to be matched with specific hardware, based on performance requirements for that customer.