MR: Pending <!-- The first line of the MR must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, and the first description line of the MR should be `Issue: <Issue link with trailing +>` 3. `MR: No MR` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description This is a followup to [a point raised](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/merge_requests/44#note_1752760102) during the TD review for implementing group-agent mappings for RD. ### Agent project is migrated out of mapped group - Say we have a agent `agent1` in a project with path `group1/group2/project` - Now, let's say `agent1` was mapped to `group2` under Group-level Remote Development/Workspace settings - What should happen if someone tries to migrate `project` out of `group2`? - Should the behavior be different if the destination group of `project` remains within `group2`? This potential issue is not unique to projects. Using the setup of the above example, say `agent1` is mapped to `group1` instead of `group2` and `group2` is migrated out of `group1` to another namespace. The same problem presents itself and demonstrates the complexity of the issue i.e. when migrating a group, any agent anywhere in its subgroups can be at the risk of being migrated out of its mapped namespace. ### Current approach The current favored approach is to block any such migration until all agent mappings for this project's cluster agents have been deleted. However, further investigation is required into the technical feasibility of this approach with careful attention to the edge cases involved. More details on how groups can be transferred can be found [here](https://docs.gitlab.com/ee/user/group/manage.html#transfer-a-group) ## Acceptance Criteria - [ ] Investigate and outline the technical feasibility of blocking project/group migration if project's cluster agents are mapped to ancestor groups ## Technical Requirements NA ## Design Requirements NA ## Impact Assessment NA ## User Story NA <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->