Bug 2000218

Summary:	Validation incorrectly blocks namespace mapping if a source cluster namespace is the same as the destination namespace
Product:	Migration Toolkit for Containers	Reporter:	Sergio <sregidor>
Component:	UI	Assignee:	Ian <ibolton>
Status:	CLOSED ERRATA	QA Contact:	Xin jiang <xjiang>
Severity:	urgent	Docs Contact:	Avital Pinnick <apinnick>
Priority:	urgent
Version:	1.6.0	CC:	ernelson, rjohnson
Target Milestone:	---
Target Release:	1.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-09-29 14:35:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sergio 2021-09-01 15:26:36 UTC

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:

Comment 1 Erik Nelson 2021-09-02 12:18:36 UTC

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.

Comment 2 Ian 2021-09-02 14:41:30 UTC

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.

Comment 3 Erik Nelson 2021-09-03 12:39:48 UTC

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.

Comment 7 Sergio 2021-09-08 10:20:13 UTC

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.

Comment 9 errata-xmlrpc 2021-09-29 14:35:38 UTC

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