Description of problem: UI Uncaught exception on New Cluster flow when choosing DC lower than 4.3 from the DC drop down list. When creating a new cluster for an existing DC and selecting a DC version 4.2 for example from the drop down list, usually the default cluster will be the default(in the current version it is 4.3 cluster) and switching the DC in the drop down list will cause this UI exceptions once the the CPU type is selected for the cluster. So basically this UI exceptions some how related to the fact that clusters version 4.3 have no more the lower intel family such as Conroe and Penryn. So once opening the new cluster, choosing a CPU type and then choosing a DC lower 4.3, the default 4.3(Nehalim) is different from the default CPU type in 4.2 cluster(Conroe) and this is lead to the UI exceptions. The reproduction steps are pretty clear. 2018-10-17 09:59:54,555+03 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-11) [] Permutation name: 998E0646E500DC06719EA5D18A8AD3D1 2018-10-17 09:59:54,555+03 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-11) [] Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot read property 'b' of null at org.ovirt.engine.ui.uicommonweb.Linq$ServerCpuPredicate.$test(Linq.java:139) at org.ovirt.engine.ui.uicommonweb.Linq$ServerCpuPredicate.test(Linq.java:139) at java.util.stream.Stream$FilterSpliterator.$lambda$0(Stream.java:632) [:1.8.0_181] at java.util.stream.Stream$FilterSpliterator$lambda$0$Type.accept(Stream.java:632) [:1.8.0_181] at java.util.Spliterators$IteratorSpliterator.$tryAdvance(Spliterators.java:459) [rt.jar:1.8.0_181] at java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:459) [rt.jar:1.8.0_181] at java.util.stream.Stream$FilterSpliterator.tryAdvance(Stream.java:628) [:1.8.0_181] at java.util.stream.Stream$StreamSource.$findFirst(Stream.java:799) [:1.8.0_181] at org.ovirt.engine.ui.uicommonweb.Linq.firstOrNull(Linq.java:75) at org.ovirt.engine.ui.uicommonweb.models.clusters.ClusterModel.$populateCPUList(ClusterModel.java:1928) at org.ovirt.engine.ui.uicommonweb.models.clusters.ClusterModel.$lambda$19(ClusterModel.java:1766) at org.ovirt.engine.ui.uicommonweb.models.clusters.ClusterModel$lambda$19$Type.onSuccess(ClusterModel.java:1766) at org.ovirt.engine.ui.frontend.Frontend$1.$onSuccess(Frontend.java:227) [frontend.jar:] at org.ovirt.engine.ui.frontend.Frontend$1.onSuccess(Frontend.java:227) [frontend.jar:] at org.ovirt.engine.ui.frontend.communication.OperationProcessor$1.$onSuccess(OperationProcessor.java:133) [frontend.jar:] at org.ovirt.engine.ui.frontend.communication.OperationProcessor$1.onSuccess(OperationProcessor.java:133) [frontend.jar:] at org.ovirt.engine.ui.frontend.communication.GWTRPCCommunicationProvider$5$1.$onSuccess(GWTRPCCommunicationProvider.java:270) [frontend.jar:] at org.ovirt.engine.ui.frontend.communication.GWTRPCCommunicationProvider$5$1.onSuccess(GWTRPCCommunicationProvider.java:270) [frontend.jar:] at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.onResponseReceived(RequestCallbackAdapter.java:198) [gwt-servlet.jar:] at com.google.gwt.http.client.Request.$fireOnResponseReceived(Request.java:233) [gwt-servlet.jar:] at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:409) [gwt-servlet.jar:] at Unknown.eval(webadmin-0.js) at com.google.gwt.core.client.impl.Impl.apply(Impl.java:236) [gwt-servlet.jar:] at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:275) [gwt-servlet.jar:] at Unknown.eval(webadmin-0.js) Version-Release number of selected component (if applicable): 4.3.0-0.0.master.20181016132820.gite60d148.el7 How reproducible: Steps to Reproduce: 1. Have ovirt 4.3 with default DC 4.3 2. Create new DC with compatibility version 4.2 and approve operation without choosing a cluster(choose configure later) 3. Go to Clusters main tab and create new cluster 4. The default DC in the cluster will be Deafult(4.3) 5. Set arch x86_64 - This will set a default CPU type(Nehalim) 6. Choose the 4.2 DC from the DC drop down list - This will trough the UI exception right away. Actual results: 2018-10-17 09:59:54,555+03 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-11) [] Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot read property 'b' of null Expected results: No UI exceptions in the system
Created attachment 1494721 [details] ui log
Verified on: ovirt-engine-4.3.0-0.0.master.20181116185756.gite19db6e.el7.noarch Steps of verification: 1. Create a new DC with compatibility version 4.2 2. Go to Clusters main tab and create new cluster 3. The default DC in the cluster will be Deafult(4.3) 4. Set the cluster arch to x86_64 - This will set a default CPU type(Nehalim) 6. Change the cluster to the 4.2 DC from the DC drop down list 7. Check the CPU types in the drop down list Result: No UI error/exception. The CPU types in the cluster included the Conroe/Penryn families.
Please review this for doc text: "In the Edit Cluster dialog, changing the cluster compatibility version from 4.2 to 4.3 when the CPU Architecture is set to the default caused the CPU Type to be set to an invalid setting, resulting in an exception. Now the CPU Type defaults to a valid entry and no exception occurs."
Hi Steve: It is not only when editing an existing Cluster, but also when creating a new Cluster. The failure is due to the default CPU Type being deprecated in 4.3.
So how about this: "The default CPU type in Red Hat Virtualization 4.2 is deprecated in Red Hat Virtualization 4.3. When creating a new cluster or editing an existing cluster, in the Edit Cluster dialog, changing the cluster compatibility version from 4.2 to 4.3 when the CPU Architecture is set to the default caused the CPU Type to be set to an invalid setting, resulting in an exception. Now the CPU Type defaults to a valid entry and no exception occurs."
Almost. Let's say this: "The default CPU type in Red Hat Virtualization 4.2 was deprecated in Red Hat Virtualization 4.3. When creating a new cluster or editing an existing cluster, in the Edit Cluster dialog, changing the cluster compatibility version from 4.2 to 4.3 when the CPU Architecture was set to x86_64 caused the CPU Type to be set to an invalid setting, resulting in an exception. Now the CPU Type defaults to a valid entry and no exception occurs." Should be past tense, and the problem was with Architecture x86_64 (Intel Family of Processors).
In general, we use the present tense in technical documentation, unless there's a very clear reason not to. In this case, I don't see that using the past tense is a better choice, and in fact, considering that 4.3 is going to be new, it's kind of confusing to say that it "was" deprecated in 4.3 instead of "is" deprecated. If you were talking about a past version, like 4.2 or 4.1, it could make more sense. So I'm going to stick with the present tense, use the x86_64 setting you mentioned, and I slightly rewrote the sentence to make it a bit easier to read. I put the changes in the doc_text field.
"has been deprecated" would be more accurate, but as you wish.
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.0 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.