Description of problem: The default cluster has an empty CPU type. Upon adding the first host, the CPU type will be detected. This option is not available for new clusters. It is unfortunate, because the default CPU type is the oldest one (conroe for x86) which is way too old. The fix should be only about removing all validations regarding cpu type so if a new cluster is created, by default the detection of the cpu type will be postponed until the first host is added.
I tried to verify it on the 4.2.2-0.1.el7 version, and results are quite strange. Steps: 1. Add new cluster with name "test_1". 2. Select CPU architecture as "undefined" and CPU type as "Auto detect" and press "ok". (step 1 and 2 configuration are in screen_1 file in the attachments.) 3. Select "Configure later" for hosts in the "Cluster - Guide Me" pop-up. 4. Cluster indeed is created without any CPU Type. (screen_2 in attachments) 5. Press "Edit" button for test_1 cluster to see if this is indeed true. 6. CPU architecture remains "undefined" but "CPU type" is automatically selected as "Intel Conroe Family" and can not be deselected as option "Auto detect" disappears from the list. (screen_3 in attachments) Also if you select a CPU architecture, system will automatically set the CPU type for "Intel Conroe Family" for x86_64 or "IBM POWER8" for ppc64 without "Auto detect" option. Considering all this I am not sure if the flow works as expected, even tho you can add the cluster with auto detect, but user can not edit other cluster options with cluster to remain with "Auto detect" flag for CPU type through the "Edit" functionality. When user press the "Edit" button - CPU type is selected to be "Intel Conroe Family" and "Auto detect" option is removed from the drop down menu for cpu type, but the line in main description on the page for cluster is still left empty. Can be observed in attachments (screen_4). If you select "Cancel" on edit window Cluster CPU type will remain empty on main page, but changing anything else in the edit window or just pressing "ok" will set CPU type to "Intel Conroe Family". So basically problem is that when you press Edit "Auto detect" option is no longer available. I wonder if this should be considered as a new bug, or should we reopen this one?
Created attachment 1399482 [details] Screen shot screen_1 of cluster window
Created attachment 1399483 [details] Screen shot screen_2 of cluster window
Created attachment 1399484 [details] Screen shot screen_3 of cluster window
Created attachment 1399485 [details] Screen shot screen_4 of cluster window
(In reply to Vitalii Yerys from comment #1) > I wonder if this should be considered as a new bug, or should we reopen this > one? So this RFE adds a new flow that imitates the creation of the Default cluster by making the CPU type of new clusters auto-detectable. It is mainly targeted for REST-API (e.g., ManageIQ) and therefore editing the cluster from the UI is not something that is likely to happen before one of the hosts in the cluster is activated (and then the CPU architecture and type are defined). As for seeing "Intel Conroe Family" in the edit dialog of a cluster that is set with auto-detectable CPU type and without being able to change it to 'auto detect', please check if that is also the case for the Default cluster of a newly deployed data center. I suspect the answer will be positive and so it is a low priority issue that already exists and should be handled separately. As for the inability to define a new cluster with a specific architecture plus CPU type that is auto-detected, there is no much point in pre-defining the architecture without defining the CPU as the architecture will be set according to the CPU type that will be detected. When you specify an explicit CPU type, the architecture field filters the relevant types for the chosen architecture - that is irrelevant for auto-detected CPU type. There is a little to no benefit in supporting that combination IMHO.
(In reply to Arik from comment #6) > (In reply to Vitalii Yerys from comment #1) > > I wonder if this should be considered as a new bug, or should we reopen this > > one? > > So this RFE adds a new flow that imitates the creation of the Default > cluster by making the CPU type of new clusters auto-detectable. It is mainly > targeted for REST-API (e.g., ManageIQ) and therefore editing the cluster > from the UI is not something that is likely to happen before one of the > hosts in the cluster is activated (and then the CPU architecture and type > are defined). > > As for seeing "Intel Conroe Family" in the edit dialog of a cluster that is > set with auto-detectable CPU type and without being able to change it to > 'auto detect', please check if that is also the case for the Default cluster > of a newly deployed data center. I suspect the answer will be positive and > so it is a low priority issue that already exists and should be handled > separately. > > As for the inability to define a new cluster with a specific architecture > plus CPU type that is auto-detected, there is no much point in pre-defining > the architecture without defining the CPU as the architecture will be set > according to the CPU type that will be detected. When you specify an > explicit CPU type, the architecture field filters the relevant types for the > chosen architecture - that is irrelevant for auto-detected CPU type. There > is a little to no benefit in supporting that combination IMHO. In such case we can consider this bug verified. Thanks.
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.