<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 5/27/15 3:06 AM, Kekane, Abhishek
wrote:<br>
</div>
<blockquote
cite="mid:E1FB4937BE24734DAD0D1D4E4E506D7889FF9558@MAIL703.KDS.KEANE.COM"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi Devs,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To address this issue we have come up with
following solutions:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Solution 1: Return tuple containing headers
and body from respective clients (also favoured by Joe Gordon)<o:p></o:p></p>
<p class="MsoNormal">Reference:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst">https://review.openstack.org/#/c/156508/6/specs/log-request-id-mappings.rst</a><o:p></o:p></p>
</div>
</blockquote>
<br>
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>
<br>
</body>
</html>