Hide Forgot
Description of problem: ----------------------- The 'CPU Used' and 'CPU Used cost' is reported to be zero for OSP instances in Chargeback reports. vmdb_production=# select * from metric_rollups where resource_name = 'nachandr_testing'\x\g\x -[ RECORD 1 ]--------------------------+--------------------- id | 1 timestamp | 2016-08-22 15:00:00 capture_interval | resource_type | VmOrTemplate resource_id | 16 cpu_usage_rate_average | 2.5993365658988 cpu_usagemhz_rate_average | 0 In the metric_rollups table, the cpu_usage_rate_average has a non-zero value and cpu_usagemhz_rate_average has a zero value. 1)Is this working as designed?Is the intent to report CPU utilization in percentage and not MHz(for infra providers, CPU utilization is reported in MHz and not percent). 2)If this is working as designed, what value should be used for calculating Chargeback costs? Version-Release number of selected component (if applicable): --------------------------------- 5.6.1.2 How reproducible: ----------------- Always Steps to Reproduce: ------------------- 1.Manage OSP provider.Enable C&U collection for the provider. 2.Generate a Chargeback report for a few instances. Actual results: ---------------- CPU Used and CPU Used cost reported zero for OSP instances in Chargeback Reports. Expected results: ----------------- Accurate values should be reported for CPU Used and CPU Used cost for OSP instances in Chargeback Reports. Additional info: ----------------
I talked to Ladislav a bit about this one, and he mentioned that cpu_usagemhz_rate_average is derived from undercloud data. If so, then you may be affected by this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1364584 Ladislav, are there additional factors I may be missing?
I did wrote a nice response, the BZ crashed and didn't save it. :-) Right, so we might need to revisit if the cpu speed is not available in the new versions of OpenStack, the code is like 1.5 years old. right now, we compute the cpu_usagemhz_rate_average from cpu_usage_rate_average https://github.com/Ladas/manageiq/blob/5be79d08113b52daa183453fdd709aba73cf7e62/app/models/metric/processing.rb#L95-L95 cpu_usage_rate_average should be normalized on OpenStack side to 0-100%. It divides it by number of cores I think. Then on our side the cpu_usagemhz_rate_average = number_of_cores * cpu_speed * cpu_usage_rate_average
Btw. the info we take from Undercloud is the cpu_speed, which came from Ironic extra data at that time.
Hi, I see this is targeted for 5.7, but we are still seeing this in the latest release (5.7.2). Any update on this issue? Thanks.
Tzu-Mainn Chen spent some time helping me look into this, and we have a theory. It looks as if the chargeback columns are based on the cpu_usagemhz_rate_average metric. In https://github.com/ManageIQ/manageiq/blob/master/app/models/metric/processing.rb, this value is calculated from cpu_usage_rate_average (which we have) and total_cpu. total_cpu is calculated in https://github.com/ManageIQ/manageiq/blob/master/app/models/vim_performance_state.rb#L163 from cpu_speed. cpu_speed apparently comes from https://github.com/ManageIQ/manageiq-providers-openstack/blob/master/app/models/manageiq/providers/openstack/infra_manager/refresh_parser.rb#L238. You'll note that last value comes from an infra provider. In this deployment (as in many non-Directory deploymens) there is no undercloud, hence no infra provider, so it looks like this value is going to be zero. --- This may be fixable: even without an undercloud we are already collecting what appears to be an equivalent metric. There is a "compute.node.cpu.frequency" metric attached to each Nova hypervisor when properly configured. It seems as if this would actually be a better source of the information, since it's reported in the overcloud.
I note that OpenStack also provides "cpu" and "cpu.delta" metrics, both of which track the actual amount of CPU time used (in nanoseconds), which seems like it may be more directly applicable to billing (via https://docs.openstack.org/ceilometer/latest/admin/telemetry-measurements.html#openstack-compute).
Bug Closure Dear customer, The CloudForms team is reviewing the current CloudForms Bug(defect) backlog in order to target engineering efforts. We are closing any bugs for versions that no longer have an active errata stream or that have hit their age limit. We are committing to better management of the backlog as we move forward. If you have an bug that you are still able to reproduce on a current version of CloudForms please open a new bug. If you have any concerns about this, please let us know. Thanks and regards!