Container dashboard utilization metrics - fix hourly metrics

[himdel]

Compute > Containers > Providers > pick a provider, dashboard view

---

When there is daily utilization data, there is no bug.

When no daily data is available, we get console errors:

TypeError: Cannot set property 'tooltipFn' of undefined
in app/assets/javascripts/controllers/ems_container_dashboard/utilization_trend_chart_controller.js:70

TypeError: Cannot read property 'layout' of undefined
in app/assets/javascripts/components/pf_charts/trends-chart.component.js:27

When no hourly data is available, the fallback to realtime or empty (... || realtime_utilization || empty_utilization_trend_data) would never get called, because hourly_utilization always returned data.

---

=> made sure hourly returns no data when empty, allowing the realtime fallback
=> fix the JS error by setting the tooltipFn on the right metricsDataStruct object.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1667986

[himdel]

Testing:

(In app/services/container_dashboard_service.rb, line ~237)

   def ems_utilization
-    daily_utilization || hourly_utilization || realtime_utilization || empty_utilization_trend_data
+    {"interval_name":"hourly","xy_data":{"cpu":{"used":1,"total":20,"xData":["2019-01-29T00:00:00.000Z","2019-01-29T01:00:00.000Z","2019-01-29T02:00:00.000Z","2019-01-29T03:00:00.000Z","2019-01-29T04:00:00.000Z","2019-01-29T05:00:00.000Z","2019-01-29T06:00:00.000Z","2019-01-29T07:00:00.000Z","2019-01-29T08:00:00.000Z","2019-01-29T09:00:00.000Z","2019-01-29T10:00:00.000Z","2019-01-29T11:00:00.000Z","2019-01-29T12:00:00.000Z","2019-01-29T13:00:00.000Z","2019-01-29T14:00:00.000Z"],"yData":[1.21,1.21,1.21,1.24,1.2,1.21,1.21,1.21,1.22,1.21,1.21,1.21,1.2,1.21,1.2]},"memory":{"used":17,"total":70,"xData":["2019-01-29T00:00:00.000Z","2019-01-29T01:00:00.000Z","2019-01-29T02:00:00.000Z","2019-01-29T03:00:00.000Z","2019-01-29T04:00:00.000Z","2019-01-29T05:00:00.000Z","2019-01-29T06:00:00.000Z","2019-01-29T07:00:00.000Z","2019-01-29T08:00:00.000Z","2019-01-29T09:00:00.000Z","2019-01-29T10:00:00.000Z","2019-01-29T11:00:00.000Z","2019-01-29T12:00:00.000Z","2019-01-29T13:00:00.000Z","2019-01-29T14:00:00.000Z"],"yData":[17.2,17.08,17.08,17.01,17.15,17.02,17.18,17.1,17.23,17.12,17.29,17.18,17.17,17.0,17.18]}}}
   end
 
   def network_metrics

Or, if you have data, try removing daily_utilization, then daily & hourly , etc. until only empty remains. None should give errors.

(If you don't have data, #519 (comment) might help.)

[himdel]

gaprindashvili/no because #2499 is also gaprindashvili/no

[himdel]

@miq-bot add_label wip

still TODO

daily:

angular.js:14961 TypeError: Cannot read property 'chartId' of undefined
    at lineChartController.vm.updateAll (line-chart.component.self-cbdb72da01a9e802cd650e3c3210738799a6bfabc36f49b924fe55dc53dbf9ee.js?body=1:28)
    at lineChartController.vm.$onChanges (line-chart.component.self-cbdb72da01a9e802cd650e3c3210738799a6bfabc36f49b924fe55dc53dbf9ee.js?body=1:108)
    at angular.js:10022
    at forEach (angular.js:426)
    at nodeLinkFn (angular.js:10018)
    at angular.js:10410
    at processQueue (angular.js:17330)
    at angular.js:17378
    at Scope.$digest (angular.js:18515)
    at Scope.$apply (angular.js:18903)

EDIT: fixed 👇

[himdel]

@miq-bot remove_label wip

When no data is available, we get {data: {dataAvailable: false}} instead of {data: ..., config: ...}.
Which means the pf-line-chart component got passed undefined config, and failed even before checking that dataAvailable is false and doing nothing.

[simaishi]

Hammer backport details:

$ git log -1
commit 44db7ff6240ee0abf3e89526ad3728bc3794868a
Author: Milan Zázrivec <[email protected]>
Date:   Mon Feb 11 09:30:07 2019 +0100

    Merge pull request #5232 from himdel/container-dashboard-bz1667986
    
    Container dashboard utilization metrics - fix hourly metrics
    
    (cherry picked from commit 2e054446e05694ddb51484e13a3bc60e1d6d95b9)
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1674585

[himdel]

Also fixes https://bugzilla.redhat.com/show_bug.cgi?id=1684226

EDIT: nope, there's #5310 for that one