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).
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
