Open Stack

On 5/27/15 3:06 AM, Kekane, Abhishek wrote:
>
> Hi Devs,
>
> Each OpenStack service sends a request ID header with HTTP responses. 
> This request ID can be useful for tracking down problems in the logs. 
> However, when operation crosses service boundaries, this tracking can 
> become difficult, as each service has its own request ID. Request ID 
> is not returned to the caller, so it is not easy to track the request. 
> This becomes especially problematic when requests are coming in 
> parallel. For example, glance will call cinder for creating image, but 
> that cinder instance may be handling several other requests at the 
> same time. By using same request ID in the log, user can easily find 
> the cinder request ID that is same as glance request ID in the g-api 
> log. It will help operators/developers to analyse logs effectively.
>
> To address this issue we have come up with following solutions:
>
> Solution 1: Return tuple containing headers and body from respective 
> clients (also favoured by Joe Gordon)
>
> Reference: 
> https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst
>

I like solution 1 as well as solution 3 at the same time, in fact. 
There's usefulness to being able to easily identify a set of requests as 
all part of the same operation as well as being able to identify a 
call's location in the hierarchy.

In fact does solution #1 make the hierarchy apparent ?   I'd want it to 
do that, e.g. if call A calls B, which calls C and D, I'd want to know 
that the dependency tree is A->B->(C, D), and not just a bucket of (A, 
B, C, D).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150527/37421a2c/attachment.html>