Return request id to caller

Bug #1568776 reported by Ankit Agrawal
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack SDK
In Progress
Bhagyashri Shewale

Bug Description

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.

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.


>>> from openstack import connection
>>> auth_args = {
... 'auth_url': '',
... '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

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.

Changed in python-openstacksdk:
assignee: nobody → Ankit Agrawal (ankitagrawal)
status: New → In Progress
Revision history for this message
Brian Curtin (brian.curtin) wrote :

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

Revision history for this message
Ankit Agrawal (ankitagrawal) wrote :

Thanks for the inputs Brian !

Revision history for this message
Ankit Agrawal (ankitagrawal) wrote :

Hi Brian,

Adding request id support to 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 Please let me know if I can be of any help completing this task.

Thanks !

Revision history for this message
Brian Curtin (brian.curtin) wrote :

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.

Changed in python-openstacksdk:
assignee: Ankit Agrawal (ankitagrawal) → Abhishek Kekane (abhishek-kekane)
Changed in python-openstacksdk:
assignee: Abhishek Kekane (abhishek-kekane) → Bhagyashri Shewale (bhagyashri-shewale)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on python-openstacksdk (master)

Change abandoned by Monty Taylor (<email address hidden>) on branch: master
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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.