[openstack-dev] [all] cross project communication: Return request-id to caller

Joe Gordon joe.gordon0 at gmail.com
Wed May 27 18:58:41 UTC 2015


On Wed, May 27, 2015 at 10:31 AM, Mike Bayer <mbayer at redhat.com> wrote:

>
>
> 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).
>

#1 should make the hierarchy apparent. That IMHO is the biggest pro for #1.


>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150527/8a52fde6/attachment.html>


More information about the OpenStack-dev mailing list