<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 10:31 AM, Mike Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <div>On 5/27/15 3:06 AM, Kekane, Abhishek
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      
      <div>
        <p class="MsoNormal">Hi Devs,<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">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.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">To address this issue we have come up with
          following solutions:<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Solution 1: Return tuple containing headers
          and body from respective clients (also favoured by Joe Gordon)<u></u><u></u></p>
        <p class="MsoNormal">Reference:
<a href="https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst" target="_blank">https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst</a><u></u><u></u></p>
      </div>
    </blockquote>
    <br></span>
    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.  <br>
    <br>
    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).     <br></div></blockquote><div><br></div><div>#1 should make the hierarchy apparent. That IMHO is the biggest pro for #1. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
  </div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>