get_server_diagnostics must define a hypervisor-independent API

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.

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

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

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 ...

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

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/

Dropping from icehouse since the blueprint was moved out:

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

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

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

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

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.

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

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

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.

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