Bug 1868426

Summary:	flavor and workload type should not filter OS selection dropdown
Product:	OpenShift Container Platform	Reporter:	Matt <mcarleto>
Component:	Console Kubevirt Plugin	Assignee:	Tomas Jelinek <tjelinek>
Status:	CLOSED ERRATA	QA Contact:	Guohua Ouyang <gouyang>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.6	CC:	aos-bugs, fkrepins, gouyang, irosenzw, yzamir
Target Milestone:	---
Target Release:	4.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:	2020-10-27 16:28:06 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 Matt 2020-08-12 15:42:23 UTC

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.

Comment 1 Filip Krepinsky 2020-08-13 07:25:43 UTC

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.

Comment 2 Ido Rosenzwig 2020-08-13 08:23:57 UTC

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.

Comment 3 Filip Krepinsky 2020-08-13 08:59:55 UTC

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

Comment 4 Ido Rosenzwig 2020-08-13 09:07:21 UTC

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.

Comment 5 Filip Krepinsky 2020-08-13 09:52:43 UTC

1. this fix is not doing that, please test it first

Comment 6 Yaacov Zamir 2020-08-13 09:56:00 UTC

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 ?

Comment 7 Filip Krepinsky 2020-08-13 10:18:45 UTC

+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

Comment 8 Filip Krepinsky 2020-08-13 10:21:43 UTC

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

Comment 11 Guohua Ouyang 2020-09-04 02:10:36 UTC

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.

Comment 13 errata-xmlrpc 2020-10-27 16:28:06 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 (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