get_server_diagnostics must define a hypervisor-independent API

[Bob Ball]

get_server_diagnostics currently returns an unrestricted dictionary, which is only lightly documented in a few places, e.g.:
http://docs.openstack.org/grizzly/openstack-compute/admin/content/configuring-openstack-compute-basics.html

That documentation shows explicit differences between libvirt and XenAPI.

There are moves to test + enforce the return values, and suggestions that Ceilometer may be interested in consuming the output, therefore we need an API which is explicitly defined and not depend on hypervisor-specific behaviour.

[Sean Dague (sdague)]

It's actually pretty problematic to have this data format completely unspecified, and vary wildly based on back end implementation. I think some commonality is needed here across hypervisors as this is a public facing interface. At minimum it should return the hypervisor type of the environment, so there could be per / hypervisor schema.

[Matt Riedemann (mriedem)]

Mailing list thread here: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016385.html

[Matt Riedemann (mriedem)]

Related tempest patch to skip the test until this is fixed: https://review.openstack.org/#/c/51412/

[Gary Kotton (garyk)]

This is being addressed by the blueprint https://blueprints.launchpad.net/openstack/?searchtext=diagnostics-namespace
xen support - https://review.openstack.org/#/c/61525/
vmware support - https://review.openstack.org/#/c/51404/
libvirt - https://review.openstack.org/61753
When all of the above are though I'll update the tempest tests ...

[Gary Kotton (garyk)]

Please see https://wiki.openstack.org/wiki/Nova_VM_Diagnostics

[Bob Ball (bob-ball)]

Following discussion on ML, new fixes are now at
libvirt (+generic support) https://review.openstack.org/#/c/61753/10
Xen https://review.openstack.org/#/c/66338/
VMWare https://review.openstack.org/#/c/62240/

[Matt Riedemann (mriedem)]

Dropping from icehouse since the blueprint was moved out:

https://blueprints.launchpad.net/nova/+spec/v3-diagnostics

[Gary Kotton (garyk)]

Resolved by https://blueprints.launchpad.net/openstack/?searchtext=v3-diagnostics

[Anna Babich (ababich)]

Since the fix released was targeted for V3 REST API, which is not supported currently, we still don't have consistent format of diagnostics data output for different virt drivers. At the moment, the nova diagnostics + libvirt returns:

Response - Headers: {'status': '200', 'content-length': '675', 'content-location': 'http://10.109.3.3:8774/v2.1/servers/d782a127-1648-4759-9c6d-639c39e70c4f/diagnostics', 'x-compute-request-id': 'req-301bd0d7-ebf4-4ef7-9e71-8b6e495cc5c9', 'vary': 'X-OpenStack-Nova-API-Version', 'connection': 'close', 'x-openstack-nova-api-version': '2.1', 'date': 'Wed, 29 Jun 2016 14:58:34 GMT', 'content-type': 'application/json'}
        Body: {"tap443f65b3-94_rx_errors": 0, "memory-available": 49056, "vda_write": 214016, "cpu0_time": 12490000000, "memory-major_fault": 11, "vdz_write": 0, "vdz_write_req": 0, "memory-swap_out": 0, "tap443f65b3-94_tx_packets": 9, "tap443f65b3-94_rx": 976, "tap443f65b3-94_tx_errors": 0, "tap443f65b3-94_rx_packets": 12, "vdz_errors": -1, "vda_read": 23142400, "vda_write_req": 36, "memory-actual": 65536, "memory-swap_in": 0, "vdz_read_req": 142, "tap443f65b3-94_tx_drop": 0, "vdz_read": 1731584, "memory-minor_fault": 21668, "tap443f65b3-94_tx": 999, "memory": 65536, "memory-rss": 127992, "memory-unused": 30472, "vda_read_req": 1076, "vda_errors": -1, "tap443f65b3-94_rx_drop": 0}

and nova diagnostics + xenapi returns:

Response - Headers: {'content-length': '669', 'status': '200', 'x-compute-request-id': 'req-c24610d8-c004-444f-8a86-7915e1caa045', 'date': 'Tue, 01 Mar 2016 07:35:45 GMT', 'content-location': 'http://192.168.33.1:8774/v2.1/49bed283a6ab4392a1fef3c1e562440d/servers/5488ffab-1ac2-4718-9da2-2d025bae1c09/diagnostics', 'content-type': 'application/json', 'vary': 'X-OpenStack-Nova-API-Version', 'connection': 'close', 'x-openstack-nova-api-version': '2.1'}
        Body: {"vbd_xvdd_iowait": "0.0", "vbd_xvdd_read": "0.0", "vbd_xvda_write": "0.0", "vbd_xvdd_iops_read": "0.0", "vbd_xvda_avgqu_sz": "0.0", "vbd_xvdd_io_throughput_total": "0.0", "vif_0_tx": "0.0", "vbd_xvda_io_throughput_total": "0.0", "cpu0": "0.0003", "vif_0_rx": "180.5545", "vbd_xvda_iowait": "0.0", "vbd_xvdd_avgqu_sz": "0.0", "memory_target": "67108864.0000", "vbd_xvda_iops_write": "0.0", "last_update": "1456817745", "vbd_xvda_read": "0.0", "vbd_xvdd_iops_total": "0.0", "vbd_xvda_iops_read": "0.0", "vbd_xvdd_inflight": "0.0", "memory": "67108864.0000", "vbd_xvdd_write": "0.0", "vbd_xvda_iops_total": "0.0", "vbd_xvda_inflight": "0.0", "vbd_xvdd_iops_write": "0.0"}

It would be nice do not bury what has been already done (at least, we have https://github.com/openstack/nova/blob/stable/mitaka/nova/virt/diagnostics.py etc.) and to implement a microversion with support of consistent format of diagnostics data

[Roman Podoliaka (rpodolyaka)]

I'll double check this on my devstack and see what we can do.

[Matt Riedemann (mriedem)]

Yes we need a spec in the nova-specs repo for ocata to add a microversion so that the os-diagnostics API uses the get_instance_diagnostics method in the compute API/manager, which is what was added for the now defunct v3 API.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY

[Roman Podoliaka (rpodolyaka)]

As Matt stated in https://bugs.launchpad.net/nova/+bug/1240043/comments/11 this was fixed in API v3, which we dropped, so we still need to fix this in API v2.1 by the means of a new micro version.

CONFIRMED FOR: NEWTON

[Sean Dague (sdague)]

There are no currently open reviews on this bug, changing
the status back to the previous state and unassigning. If
there are active reviews related to this bug, please include
links in comments.

[Sean Dague (sdague)]

Automatically discovered version grizzly in description. If this is incorrect, please update the description to include 'nova version: ...'