Description of problem: In the VM wizard you can filter the OS options available with the fields that follow it (Flavor and workload profile). This is not discoverable at all and we don't have any actionable data that suggests a user is more interested in those settings than a specific OS selection. How reproducible: very Steps to Reproduce: 1. create VM 2. select flavor 3. See filtered list of OS options Actual results: If the user chooses to select a flavor/workload type before they choose an OS their OS options will be limited by their flavor/workload type. This is not obvious and a poor experience in general. Expected results: A user should be able to choose their OS without any impact by the flavor/workload type selection. Additional info: More long term it would benefit the user to hide/disable the flavor/workload type options until they've chosen their OS. We could then provide defaults for each for each based on the OS selection.
There is a reason behind this behaviour. The selection of os/flavor/workload will result in selecting a common template. meaning when you select Windows 10/Large/server it will result in the selection of windows-server-large template if we allow unfiltered selection, we could arrive to a combination Windows 10/Tiny/server which is invalid and no such template exist. And thus we cannot comply with the user requirements on the VM. This filtering behaviour would make more sense to the final user, if he was aware of common templates, and if we could show a label in the wizard of a currently selected template.
We cannot end-up with an invalid combination, if you pick a flavor and then switch an OS without this flavor the flavor dropdown will change to the allowed values. Additionally, I don't think it is mandatory for the end user to be aware of the common-templates as well as it shouldn't dictates the order of picking OS/Flavor/Workload.
so are we okay with forcefully changing user decisions regarding flavor/workload? I know the current behaviour is not nice, but we need an algorithm to resolve this. Common template are not mandatory, but they are nice to have them visible + it educates the users. I think Ran is working on exposing the common template now. so we can do one of these to fix it 1. override the user selection of flavor/workload upon OS selection 2. disabling flavor/workload until OS is selected
These 2 sounds OK to me. option 1 is what the fix for this bug is doing. option 2 involves more logic and can be opened as another bug and can follow Ran's design. also, I suggest we hide it instead of disabling it.
1. this fix is not doing that, please test it first
As @Ido and @Filip agree on option 1: "override the user selection of flavor/workload upon OS selection" We can continue with implement it in the PR p.s. Can we reset to null the values of flavor/workload to "null" instead of overriding it to the nearest value (as Ido's fix currently does) Override the value to "null" will make sure the user know that this fields whare changed and they need to re-enter new values WDYT ?
+1, sounds good regarding the current fix: - currently it is not overriding it to the nearest value (the value in redux stays the same - open Redux DevTools to double check you have the right values) - let's revert it to null, only when we cannot find the suitable template (both flavor/workload) - thus the OS will have a preference between these fields
I think we still should filter the flavor/workload since it result in a weird flow. Select OS -> Select Invalid Flavor -> resets OS -> Select OS -> resets Flavor
verified on master. Steps: 1. select Fedora OS, flavor "tiny" work profile 'desktop'. 2. switch OS to Windows 10, the flavor and work profile are resetting to null.
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 (OpenShift Container Platform 4.6 GA Images), 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/RHBA-2020:4196