yahoo-eng-team team mailing list archive

[Thierry Carrez <thierry.carrez+lp@xxxxxxxxx>]

** Changed in: nova
       Status: Fix Committed => Fix Released

** Changed in: nova
    Milestone: None => liberty-3

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1488696

Title:
  Nova compute *.percent metrics are always 0

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  It seems that with the recent update to the Nova virt metrics
  framework in Liberty, the 'percent' related metrics always 0 now in
  the database.  After tracing through the code, I determined tha the
  virt_driver and resource tracker will still behaving properly and the
  compute_driver::get_host_cpu_stats work as expected.

  It seems that the root cause is:

  https://github.com/openstack/nova/blob/master/nova/objects/monitor_metric.py#L29

  This shows that the metric value is expected to be an integer in nova
  object, but the percentage metrics are all floating points and range
  in value from [0, 1] -- e.g., so 17.5% has been historically
  represented as 0.175 using the monitor framework.  This causes the
  percentage values to assume the value 0, as shown below in the snippet
  from `select metrics from compute_nodes`:

  "cpu.user.percent", "value": 0,
  "cpu.percent", "value": 0,

  ...so on and so forth.  By the time the metrics get to this spot in
  the resource tracker:

  https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L366

  ...the '*.percent' values are all 0.

  I'm not sure if the intended behavior here was to only support
  integer-style values.  If so, we probably need to do some "multiply by
  100" logic when putting them into the MonitorMetric object and then
  divide by 100 (we'll lose precision, though) when we convert back to
  the values stored in the compute_nodes.metrics column, otherwise we
  will break backwards compatibility in terms of what folks were
  expecting to find in the DB.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1488696/+subscriptions