Open Stack

----- Original Message -----
> From: "Abhijeet Malawade" <Abhijeet.Malawade at nttdata.com>
> To: openstack-dev at lists.openstack.org
> Sent: Friday, 12 December, 2014 3:54:04 PM
> Subject: [openstack-dev] [python-cinderclient] Return request ID to caller
> 
> 
> 
> HI,
> 
> 
> 
> I want your thoughts on blueprint 'Log Request ID Mappings’ for cross
> projects.
> 
> BP: https://blueprints.launchpad.net/nova/+spec/log-request-id-mappings
> 
> It will enable operators to get request id's mappings easily and will be
> useful in analysing logs effectively.
> 
> 
> 
> For logging 'Request ID Mappings', client needs to return
> 'x-openstack-request-id' to the caller.
> 
> Currently python-cinderclient do not return 'x-openstack-request-id' back to
> the caller.
> 
> 
> 
> As of now, I could think of below two solutions to return 'request-id' back
> from cinder-client to the caller.
> 
> 
> 
> 1. Return tuple containing response header and response body from all
> cinder-client methods.
> 
> (response header contains 'x-openstack-request-id').
> 
> 
> 
> Advantages:
> 
> A. In future, if the response headers are modified then it will be available
> to the caller without making any changes to the python-cinderclient code.
> 
> 
> 
> Disadvantages:
> 
> A. Affects all services using python-cinderclient library as the return type
> of each method is changed to tuple.
> 
> B. Need to refactor all methods exposed by the python-cinderclient library.
> Also requires changes in the cross projects wherever python-cinderclient
> calls are being made.
> 
> 
> 
> Ex. :-
> 
> From Nova, you will need to call cinder-client 'get' method like below :-
> 
> resp_header, volume = cinderclient(context).volumes.get(volume_id)
> 
> 
> 
> x-openstack-request-id = resp_header.get('x-openstack-request-id', None)
> 
> 
> 
> Here cinder-client will return both response header and volume. From response
> header, you can get 'x-openstack-request-id'.
> 
> 
> 
> 2. The optional parameter 'return_req_id' of type list will be passed to each
> of the cinder-client method. If this parameter is passed then cinder-client
> will append ‘'x-openstack-request-id' received from cinder api to this list.
> 
> 
> 
> This is already implemented in glance-client (for V1 api only)
> 
> Blueprint :
> https://blueprints.launchpad.net/python-glanceclient/+spec/return-req-id
> 
> Review link : https://review.openstack.org/#/c/68524/7
> 
> 
> 
> Advantages:
> 
> A. Requires changes in the cross projects only at places wherever
> python-cinderclient calls are being made requiring 'x-openstack-request-id’.
> 
> 
> 
> Dis-advantages:
> 
> A. Need to refactor all methods exposed by the python-cinderclient library.
> 
> 
> 
> Ex. :-
> 
> From Nova, you will need to pass return_req_id parameter as a list.
> 
> kwargs['return_req_id'] = []
> 
> item = cinderclient(context).volumes.get(volume_id, **kwargs)
> 
> 
> 
> if kwargs.get('return_req_id'):
> 
> x-openstack-request-id = kwargs['return_req_id'].pop()
> 
> 
> 
> python-cinderclient will add 'x-openstack-request-id' to the 'return_req_id'
> list if it is provided in kwargs.
> 
> 
> 
> IMO, solution #2 is better than #1 for the reasons quoted above.
> 
> Takashi NATSUME has already proposed a patch for solution #2. Please review
> patch https://review.openstack.org/#/c/104482/.
> 
> Would appreciate if you can think of any other better solution than #2.
> 
> 
> 
> Thank you.
> 
> 

Abhijeet

So option 1 is a massive compatibility break. There's no way you can pull of a change in the return value like that without a new major version and every getting annoyed. 

My question is why does it need to be returned to the caller? What is the caller going to do with it other than send it to the debug log? It's an admin who is trying to figure out those logs later that wants the request-id included in that information, not the application at run time. 

Why not just have cinderclient log it as part of the standard request logging: https://github.com/openstack/python-cinderclient/blob/master/cinderclient/client.py#L170



Jamie

> ______________________________________________________________________
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>