Created attachment 1701199 [details] Cluster N/A stats Description of problem: The cluster stats in the UI shows always: NA I do have 1 DC and 3 Clusters. Attaching the screenshot. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
[root@ovirt-engine rex]# systemctl status ovirt-engine-dwhd.service ● ovirt-engine-dwhd.service - oVirt Engine Data Warehouse Loaded: loaded (/usr/lib/systemd/system/ovirt-engine-dwhd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-07-08 02:54:14 CEST; 1 weeks 0 days ago Main PID: 1688 (ovirt-engine-dw) CGroup: /system.slice/ovirt-engine-dwhd.service ├─1688 /usr/bin/python /usr/share/ovirt-engine-dwh/services/ovirt-engine-dwhd/ovirt-engine-dwhd.py --redirect-output --systemd=notify start └─1996 ovirt-engine-dwhd -Dorg.ovirt.engine.dwh.settings=/tmp/tmpNdWtEe/settings.properties -Xms1g -Xmx1g -classpath /usr/share/ovirt-engine-dwh/lib/*::/usr/share/java/dom4j.jar:/usr/share/java/apache-commons-collections.jar:/usr/share/java/postgresql-jdbc.j... Jul 08 02:54:12 ovirt-engine.mgmt.zg.pinguozzo.com systemd[1]: Starting oVirt Engine Data Warehouse... Jul 08 02:54:14 ovirt-engine.mgmt.zg.pinguozzo.com systemd[1]: Started oVirt Engine Data Warehouse.
Can you please attach sos report from the engine?
The N/A is expected, no data to be shown there. Maybe we can just remove the N/A string and leave it blank?
We can remove the "N/A" string and leave it as blank to avoid confusions on first phase for 4.4.2 since it's easy to implement and discuss other solutions later on for future releases.
Hi, Thanks for the feedback. @Sandro: Do you still need the sosreport from the Engine?
@Gianfranco the report is not needed
As quick fix we can leave the card blank. More work is needed in order to provide the same information as first column (Status) on Clusters screen. Currently we have 2 visual statuses: 1. exclamation mark - displayed when: a) cluster.isClusterCompatibilityLevelUpgradeNeeded() OR b) cluster.isDeprecated(object) OR c) cluster.object.hasHostWithMissingCpuFlags()) 2. broken link - displayed when cluster.getHostNamesOutOfSync() Ad 1a Calculated on the backend by simple comparison with current engine version (see SearchQuery.searchClusters()) Cost of duplicating the logic is low here - we can calculate it in SQL by extending existing ../dashboard/dao/ClusterEngineDao Ad 1b Detecting deprecated cluster version is currently implemented in the UI in ClusterAdditionalStatusColumn by comparing cluster compatibility version and cpu name with static hardcoded lists. It can be refactored to sharable utility and re-used in ../dashboard/dao/ClusterEngineDao. Ad 1c Calculated on the backend by calling GetHostsWithMissingFlagsForClusterQuery for each cluster in the list(see SearchQuery.searchClusters()). The best approach would be to re-use the existing logic. Ad 2 This flag is calculated by checking the status of all host interfaces (see NetworkImplementationDetailsUtils.getAllInterfacesOutOfSync()). The best approach here would be to re-use existing backend logic(see GetOutOfSyncHostNamesForClusterQuery). Refresh rate and performance impact needs to be determined. Web Admi UI implements this by periodically executing query per each cluster displayed in the list. However there seems to be an assumption that there are few clusters and that user does not stay very long on Clusters screen. @Scott Do we have a requirement that DashboardDataServlet is independent from the rest of the backend? Perhaps we can call some existing backend logic?
DashboardDataServlet is a bit more of an independent servlet / service to access DWH info. However, I don't see any problem with extending it to use the backend EJB. Dashboard is the first screen every admin sees when first logging in. So, we have to be careful with the servlet to make sure that expensive queries are cached. The caches are mostly defaulted to expire in line with how often the DWH is updated. It doesn't make sense to update queries more often than new data is available. As far as clusters go, adding meaningful status icons to that card has been a debate since the beginning of dashboard years ago.
(In reply to Scott Dickerson from comment #9) > DashboardDataServlet is a bit more of an independent servlet / service to > access DWH info. However, I don't see any problem with extending it to use > the backend EJB. > > Dashboard is the first screen every admin sees when first logging in. So, > we have to be careful with the servlet to make sure that expensive queries > are cached. The caches are mostly defaulted to expire in line with how > often the DWH is updated. It doesn't make sense to update queries more > often than new data is available. > > As far as clusters go, adding meaningful status icons to that card has been > a debate since the beginning of dashboard years ago. I would leave the current solution of setting the card as blank for now. If customers will complain then we can think of further investigating it. The cluster status includes too many queries and it's risky/complicated to add it, as mentioned on previous comments.
(In reply to Sharon Gratch from comment #10) > I would leave the current solution of setting the card as blank for now. > If customers will complain then we can think of further investigating it. > The cluster status includes too many queries and it's risky/complicated to > add it, as mentioned on previous comments. Agreed.
Steps: 1) Check cluster status in dashboards in Admin portal. Results: Blank card instead of N/A. Verified in: ovirt-engine-4.4.2.3-0.6.el8ev.noarch ovirt-engine-ui-extensions-1.2.3-1.el8ev.noarch
This bugzilla is included in oVirt 4.4.2 release, published on September 17th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.2 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.