Description of problem: When we migrate namespace A and we map this namespace to namespace B, if namespace B exists in the source cluster the UI reports an error and does not allow to create the migration plan. Version-Release number of selected component (if applicable): MTC 1.6.0 How reproducible: Always Steps to Reproduce: 1. In source cluster create 2 namespace bz-test-1 and bz-test-2 oc new-project bz-test-1 oc new-project bz-test-2 2. Create a migration plan to migrate namespace bz-test-1 3. When creating the migration plan, map the namespace to bz-test-2 bz-test-1:bz-test-2 Actual results: The UI reports this error: ''' A mapped target namespace with that name already exists. Enter a unique name for this target namespace. ''' Expected results: We should be able to map bz-test-1 namespace to bz-test-2. Additional info:
This is an interesting one: I think there actually is a valid use-case to migrate intra-*namespace* for storage class conversions on the same cluster. Nevertheless, this is not a regression to my knowledge and has been in place since we introduced namespace mapping. We're on the verge of a 1.6.0 blockers only milestone, and there is some broader work to be done here to outline exactly what permutations of cluster + namespace mappings should be valid. I filed a Jira here to dedicate some time to this task and will align this to 1.7.0.
The requirements for this validation does have some complexity to it. There is a duplication check that checks the currently edited namespace name against 1) the src cluster namespace list pulled from the discovery service api request & 2) the UI transient state for existing mappings within the current plan edit/add process. We make sure that we cannot have a namespace mapped to an existing mapped namespace in either of these lists. It is not clear to me what we are proposing here & if these changes are specific to state migrations or not.
I discussed this BZ with John: we need to ensure that as a user, I'm able to migrate from one namespace to another existing namespace on the same cluster. I might want to move an application from one namespace to another, already existing namespace. This is something we want to do for 1.6.0.
Verfied using SOURCE CLUSTER: AWS OCP 3.11 (MTC 1.5.1) NFS TARGET CLUSTER: AWS OCP 4.9 (MTC 1.6.0) OCS4 openshift-migration-rhel8-operator@sha256:ef00e934ed578a4acb429f8710284d10acf2cf98f38a2b2268bbea8b5fd7139c - name: MIG_CONTROLLER_REPO value: openshift-migration-controller-rhel8@sha256 - name: MIG_CONTROLLER_TAG value: 27f465b2cd38cee37af5c3d0fd745676086fe0391e3c459d4df18dd3a12e7051 - name: MIG_UI_REPO value: openshift-migration-ui-rhel8@sha256 - name: MIG_UI_TAG value: 558d4723e2a0e5e9c337062ec2dd27c52f9f3865a6e1847b26345e757c4356fe Moved to VERIFIED status.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Migration Toolkit for Containers (MTC) 1.6.0 security & bugfix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:3694