BE: Investigate how project/group migration can be blocked if cluster agents are mapped to a group for RD
MR: Pending
Description
This is a followup to a point raised during the TD review for implementing group-agent mappings for RD.
Agent project is migrated out of mapped group
- Say we have a agent
agent1in a project with pathgroup1/group2/project - Now, let's say
agent1was mapped togroup2under Group-level Remote Development/Workspace settings - What should happen if someone tries to migrate
projectout ofgroup2?- Should the behavior be different if the destination group of
projectremains withingroup2?
- Should the behavior be different if the destination group of
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
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