On Wed, May 27, 2015 at 10:31 AM, Mike Bayer <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
