Bug 2040378
| Summary: | Don't allow Storage class conversion migration if source cluster has only one storage class defined [backend] | |||
|---|---|---|---|---|
| Product: | Migration Toolkit for Containers | Reporter: | vconzola | |
| Component: | UI | Assignee: | Pranav Gaikwad <pgaikwad> | |
| Status: | CLOSED ERRATA | QA Contact: | Prasad Joshi <prajoshi> | |
| Severity: | medium | Docs Contact: | Richard Hoch <rhoch> | |
| Priority: | medium | |||
| Version: | 1.7.0 | CC: | ernelson, mturley, prajoshi, rjohnson | |
| 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: | ||||
| : | 2082221 (view as bug list) | Environment: | ||
| Last Closed: | 2022-05-05 13:50:01 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2082221 | |||
|
Description
vconzola
2022-01-13 15:38:57 UTC
Assigning Pranav to this because, as discussed, this is going to require controller support in order to provide the list of storageclasses present on the source cluster for the UI to be able to filter the clusters. Spoke with Pranav about this, we have a chicken and the egg problem here in the UI. With the current UX, when the user is selecting the type of migration (storageclass conversion, state only etc.), they have not yet created a MigPlan yet. That means we have no way of knowing what storage classes are present on the cluster when we need to decide whether or not to disable the option. The right way to solve this is not trivial. We have precedent set that this type of data is surfaced via our discovery service, and it would require us to implement the functionality there. This is not an option for 1.7.1. Further, we have a validation on the MigPlan that ensures that an invalid MigPlan that is a storageclass conversion type cannot actually be migrated under these circumstances. It is pushed into a NotReady state. This is strictly a UI issue. I am going to push this to 1.7.2 so we can confer with UX about our options, since severity is low here. When in the wizard flow is the mig plan object created so the UI knows if more than one storage class is present on the cluster? One option, though not a great UX, is to throw an error at this point and send the user back to the migration type selection if necessary. This would be better than waiting until the wizard is complete and having the plan fail validation. @ @vconzola I believe the mig plan object gets created at the third wizard step, when PV discovery happens. So the UI would not be able to tell if more than one storage class is present on the cluster until then (assuming that data is reachable from the discovery request, which I'm not sure about). @mturley The discovery service must must no about available storage classes at this point because it's when storage class selection is done, correct? 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). 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.1 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:1734 Unfortunately I think by us linking to this bug in the controller side of the validations, this got shuffled along to the 1.7.1 release and the front-end UX has not been fixed. I'm going to open a new BZ to track, because I cannot reopen this bug apparently, and link to it. Clearing needinfo as the discussion is continuing in https://bugzilla.redhat.com/show_bug.cgi?id=2082221. |