commit 87e1d8fab2b5888e711f07001025600fe709aaa7
Author: Joe Cropper <email address hidden>
Date: Tue Aug 25 20:53:55 2015 -0500
Convert percent metrics back into the [0, 1] range
With the recent revamp of the Nova metrics framework in the Liberty
cycle, there was a problem introduced in terms of how the percentage-
based metrics (e.g., cpu.percent) are represented. That is, prior to
Liberty, we stored the percentages in compute_nodes.metrics as a
floating point value in the range [0, 1]. For example, 17.5% was
represented as 0.175.
The revamped framework expects the MonitorMetric.value properties to
be integers, so when the percentages such as 0.175 are stored in this
object, they're erroneously converted to 0.
This patch multiplies the 'problematic' fields by 100 in preparation
for storage within the MonitorMetric object and then divides the
same problematic fields by 100.0 when converting back to their JSON
format, which will preserve RPC notifier and database compatibility.
Added some unit tests to test the conversions as well as making some
of the unit tests more explicit so this doesn't happen again.
Reviewed: https:/ /review. openstack. org/216923 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=87e1d8fab2b 5888e711f070010 25600fe709aaa7
Committed: https:/
Submitter: Jenkins
Branch: master
commit 87e1d8fab2b5888 e711f0700102560 0fe709aaa7
Author: Joe Cropper <email address hidden>
Date: Tue Aug 25 20:53:55 2015 -0500
Convert percent metrics back into the [0, 1] range
With the recent revamp of the Nova metrics framework in the Liberty nodes.metrics as a
cycle, there was a problem introduced in terms of how the percentage-
based metrics (e.g., cpu.percent) are represented. That is, prior to
Liberty, we stored the percentages in compute_
floating point value in the range [0, 1]. For example, 17.5% was
represented as 0.175.
The revamped framework expects the MonitorMetric.value properties to
be integers, so when the percentages such as 0.175 are stored in this
object, they're erroneously converted to 0.
This patch multiplies the 'problematic' fields by 100 in preparation
for storage within the MonitorMetric object and then divides the
same problematic fields by 100.0 when converting back to their JSON
format, which will preserve RPC notifier and database compatibility.
Added some unit tests to test the conversions as well as making some
of the unit tests more explicit so this doesn't happen again.
Change-Id: I17a9412c63eeeb 78ba2b2600f9007 e9b58fcbf68
Closes-Bug: #1488696