Bug 2082221

Summary:	Don't allow Storage class conversion migration if source cluster has only one storage class defined [UI]
Product:	Migration Toolkit for Containers	Reporter:	Erik Nelson <ernelson>
Component:	UI	Assignee:	Mike Turley <mturley>
Status:	CLOSED ERRATA	QA Contact:	Prasad Joshi <prajoshi>
Severity:	medium	Docs Contact:	Richard Hoch <rhoch>
Priority:	medium
Version:	1.7.1	CC:	ernelson, mturley, pgaikwad, prajoshi, rhoch, rjohnson, vconzola
Target Milestone:	---
Target Release:	1.7.2
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	2040378	Environment:
Last Closed:	2022-07-01 09:53:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2040378
Bug Blocks:

Comment 1 Erik Nelson 2022-05-05 15:25:24 UTC

@Vince

> The discovery service must must no about available storage classes at this point because it's when storage class selection is done, correct?

Yes, correct. We know the storageclasses present on the selected cluster once PV discovery has concluded with a result (3rd step of the wizard).

> So then I believe we have two choices: (1) ignore the fact there's only one storage class to choose from in the drop down, allow the user to select it (or hopefully they'll realize their problem), and let them go on their merry way until they reach the end of the wizard and validation fails, or (2) as soon as the discovery service returns only one storage class throw a warning (Warn, don't Block) saying "Hey dummy - you chose a cluster with only one storage class. Go back and select another cluster or choose another migration type." I vote for (2).

(1) happens already today as of Pranav's 1.7.1 fix. I agree with you Vince, I think 2 is a better experience and that's something we can add without any technical limitation. It's a UI-only change.

@mturley Make sense to you?

Comment 2 Mike Turley 2022-05-05 15:32:23 UTC

Yep, sounds good to me. I'll self-assign this and work on it next.

Comment 3 Mike Turley 2022-05-09 16:10:23 UTC

Attached PRs.

IMPORTANT VERIFICATION NOTE: because this PR reverts some of the logic that was part of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=2071000, we should re-verify that bug fix as part of verifying this one to ensure we don't have a regression.

Comment 4 Mike Turley 2022-05-10 17:01:30 UTC

Fixed an issue introduced by the prior PR, moving back to POST.

Comment 5 Mike Turley 2022-05-11 16:08:21 UTC

One last change to fully resolve this.

Comment 9 Ian 2022-06-15 14:01:03 UTC

*** Bug 2079549 has been marked as a duplicate of this bug. ***

Comment 10 Prasad Joshi 2022-06-16 11:58:39 UTC

Verified with MTC 1.7.2

metadata_nvr: openshift-migration-operator-metadata-container-v1.7.2-11

I see the expected behavior mentioned above. Also verified https://bugzilla.redhat.com/show_bug.cgi?id=2071000, No issues found

Moving this to verified status.

Comment 16 errata-xmlrpc 2022-07-01 09:53:11 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.7.2 security and bug fix 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-2022:5483