Return request id to caller

[Ankit Agrawal]

Most of the OpenStack Restful API returns X-Openstack-Request-Id in the API response header but this request id is not available to the caller from the openstacksdk. If there is any issue with the OS API and user wants to report this issue to the service provider, X-Openstack-Request-Id will come handy.

We are proposing to add 'request_ids' as an attribute to resource objects in python-openstacksdk.

Design:
When a caller make a call and get a response from the OpenStack service, it will extract X-Openstack-Request-Id from the api response header and add it as an attribute to the resource object. This resource object with request id is returned to the user from openstacksdk.

Also need to add 'request_ids' as attribute to exception object which will be raised from openstacksdk.

Example:

>>> from openstack import connection
>>>
>>> auth_args = {
... 'auth_url': 'http://172.31.21.76:35357/',
... 'project_name': 'admin',
... 'username': 'admin',
... 'password': 'admin',
... }
>>>
>>> conn = connection.Connection(**auth_args)
>>> server = conn.compute.get_server('eceeaf46-4817-4db7-bd33-e2620a2a4bd4')
>>> type(server)
<class 'openstack.compute.v2.server.Server'>
>>>
>>># Get request id from server resource object
>>> server.request_ids
['req-02232f93-fb02-46e1-899c-46c8e7492a6a']

NOTE: As openstacksdk is not an "official" project and currently does not accept blueprints so this launchpad bug will help to track the efforts made in order to complete this feature.

[Brian Curtin (brian.curtin)]

If you're going to add this, it has to go in the Resource class in openstack/resource2.py,*not* resource.py. We're transitioning to the one in the second module.

[Ankit Agrawal (ankitagrawal)]

Thanks for the inputs Brian !

[Ankit Agrawal (ankitagrawal)]

Hi Brian,

Adding request id support to resource2.py module requires refactoring the resources and _proxy for all the modules e.g. compute, image, block_store etc. I can see your patch [1] to refactor the compute resources and proxy to work with the newly refactored classes. Are you planning to refactor the other modules as well in order to use resource2.py. Please let me know if I can be of any help completing this task.
[1] https://review.openstack.org/#/c/298900/

Thanks !

[Brian Curtin (brian.curtin)]

Everything is going to be updated to go through the new resource and the new proxy, and once everything goes through those, the old ones will be deleted. However, adding this request ID stuff should not affect the proxy at all as that's just a higher level interface to the resource layer, and it should have to not touch each of the modules in a given service.

We should just add handling for X-Openstack-Request-Id on the base class in openstack.resource2.Resource, such as openstack.resource2.Resource._translate_response.

Do you have a list of all of the possible header values that contain this? It looks like compute went off and did their own thing, because I see X-Compute-Request-Id while looking at my recent logs of doing compute things.

Here's how I think it might be done:

1. Add "request_ids = None" as a class variable on openstack.resource2.Resource and add some kind of docstring explaining briefly what these request ids are for. In Resource.__init__, set it to an empty list.
3. Add a private "_request_id_header = "x-openstack-request-id"" as a class variable on openstack.resource2.Resource.
4. In openstack.resource2.Resource._translate_response, you can look at response.headers and find openstack.resource2.Resource._request_id_header inside it, and then append it to the request_ids list that was created in step 1.

That'll cover people using the usual x-openstack-request-id. When services deviate from that, like in the example of compute, you can just add a new base class to openstack.compute.v2, set "_request_id_header = "x-compute-request-id"" on it, and then have the compute resources inherit from that.

One thing it doesn't immediately cover is calls to openstack.resource2.Resource.list, as that's a classmethod and doesn't go through the _translate_response stuff. I guess I would leave that up to a v2 implementation of this bug for now.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Monty Taylor (<email address hidden>) on branch: master
Review: https://review.openstack.org/478143
Reason: I agree with Brian - this isn't a thing that's going to be able to land - the info is available via the keystoneauth logs, and the request-id isn't actually an attribute of the resources.