Bug 1868426 - flavor and workload type should not filter OS selection dropdown
Summary: flavor and workload type should not filter OS selection dropdown
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.6.0
Assignee: Tomas Jelinek
QA Contact: Guohua Ouyang
Depends On:
TreeView+ depends on / blocked
Reported: 2020-08-12 15:42 UTC by Matt
Modified: 2020-10-27 16:28 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-10-27 16:28:06 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift console pull 6316 0 None closed Bug 1868426: Unfilter OS dropdown in VM wizard when choosing flavor or workload 2020-09-04 01:57:36 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:28:24 UTC

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:

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.


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

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.


Note You need to log in before you can comment on or make changes to this bug.