https://gitlab.com/gitlab-org/gitlab/issues/15536#note_251075188 ### Resource Groups I consider the following example: 1. You have resource group: `iOS`, 1. You have 10 `iOS` devices in resource group, 1. Each of these devices have unique `UUID` and some other address assigned as a variable that is injected into CI, 1. You that receives that resource can access individual, described resource, in this case one of the `iOS` devices, it receives exact parameters of that device. I can consider another example of 10 different review apps environments: 1. You have resource group: `review apps`, 1. You allow to run at most 10 review apps at a time, so you have to resources assigned, 1. Each resource defines the parameters of the target set of nodes where to deploy the given review, 1. We define by CI that each resource is not freed after the job finishes, but rather after some given timeout, like 10h. It means that you can have 10 review apps, each of them living at most 10h until it is used by another MR to use. I can consider another example of canary type deployments, where canary is an limited resource: 1. You have resource group: `production`, 1. This `production` defines a set of two types of canary deployments (or just one) as an resource, 1. This is uses to ensure that you hold the given slot for canary deployment, as each of these resources can have an explicit `HOSTNAME` defined where you deploy, vs generic `canary` environment, 1. Timeout defines for how long the given resource is being held, like: each canary deployment of MR can be on canary for as long as 1h and after that time is automatically freed. Then from the perspective of Resource Groups: 1. You see a list of resources groups, 1. You can create new resource group, 1. If you go to resource groups, you can add additional resource, 1. Each resource is named, 1. You see who is holding the lock: can be job, or pipeline, and for how long this lock is still gonna be hold. 1. You can edit resource to give it a name and a list of parameters describing the resource, 1. You can see who held the given resource in the past, 1. You could see the same from the perspective of resource groups, who held and for how long the given resource of that resource group, 1. Likely we allow to pre-create a given amount of resources in resource group with some predefined naming like: `iOS#1`, `iOS#2`, as this is how user defines concurrency. As for the MVC: 1. I would only see the backing structure to use a terminology of `Resource Groups` instead of `Locks`, if this idea is appealing, 1. I would only ensure that we can define `resource_group: name` as part of `YAML`, 1. I would think about ~frontend later.