metering line charts not always scaled for duration selected
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Dashboard (Horizon) |
Fix Released
|
Medium
|
Ladislav Smola |
Bug Description
When the duration requested for charting a meter exceeds the time-range over which samples are actually available, the resource usage chart isn't scaled over the actual duration selected.
For example, suppose samples for a particular meter have only been gathered by ceilometer over the past 6 days (such a scenario would not be atypical for a relatively fresh openstack deployment).
If the user requests that this meter is graphed over the Last Week, they see the entire width of the chart taken up by the 6 days for which there is actual data. Not a big issue as 6 days is a close approximation of a week.
If they then change the duration requested to the next option in the Period dropdown, i.e. Last 15 days, the data is still charted over the same approximate 6 day duration. The shape of the graph changes somewhat, but only because the timeslice length requested of ceilometer has changed (as horizon arbitrary sets this to 1/400th of the duration).
If the users continues to choose progressively longer durations (Last 30 Days, Last Year) the pattern is repeated.
So in effect, changing the duration just gives a more coarse-grained representation of the *same* data. Intuitively the expectation would be for the x-axis of the graph to be scaled to the entire duration selected, and if there isn't data available for the entire duration, then the trend line should be rendered only for a portion of this width.
I'll attach screenshots illustrating this trend.
Proposed solutions:
1. Scale the x-axis of the line chart over the entire duration requested, but only render the trend line over the subset of time for which there is actual data available. If the rickshaw toolkit doesn't support this behaviour directly, maybe it could be tricked into doing so by injecting invisible datapoints across the entire time range.
2. Pre-query for the first and last datapoints within each range, then make the Period dropdown list context sensitive, such that the options available only reflect the durations for which there is actual data. In the example scenario above, this would be Last Day, Last Week and Other (whereas Last 15 Days, Last 30 Days and Last Year add nothing to the mix).
Option #1 would be preferred I think, whereas option #2 is suggested only as a fallback if rickshaw is too inflexible.
tags: | added: metering-ui |
Changed in horizon: | |
assignee: | nobody → Sayali Lunkad (sayalilunkad) |
Changed in horizon: | |
assignee: | Sayali Lunkad (sayalilunkad) → nobody |
Changed in horizon: | |
assignee: | nobody → Anuj Deshpande (anujdeshpande92) |
Changed in horizon: | |
milestone: | none → juno-3 |
Changed in horizon: | |
importance: | Undecided → Medium |
Changed in horizon: | |
status: | Fix Committed → Fix Released |
Changed in horizon: | |
milestone: | juno-3 → 2014.2 |
Yes I am aware of that, it's a feature of the Rickshaw, it shows chart axis according to data. :-)
2. Not sure if we can easily grab first sample, also there can be holes in the data, that would cause the same behaviour.
1. Yes, this seems like a valid option. We should be able to switch of the axis autoscaling. If not, we can hack it as you say.