<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/02/2013 10:18 AM, Joe Gordon
wrote:<br>
</div>
<blockquote
cite="mid:CAHXdxOcGRC=U5=bSYLXTop2xJrhAcQFNnixJ-0iBbe111byyLA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<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"><br>
Thanks for bringing this up, and I'd welcome a patch in
Swift that would use a common library to generate the
transaction id, if it were installed. I can see that there
would be huge advantage to operators to trace requests
through multiple systems.<br>
<br>
Another option would be for each system that calls an
another OpenStack system to expect and log the transaction
ID for the request that was given. This would be looser
coupling and be more forgiving for a heterogeneous
cluster. Eg when Glance makes a call to Swift, Glance
cloud log the transaction id that Swift used (from the
Swift response). Likewise, when Swift makes a call to
Keystone, Swift could log the Keystone transaction id.
This wouldn't result in a single transaction id across all
systems, but it would provide markers so an admin could
trace the request.<br>
</blockquote>
<div><br>
</div>
<div>There was a session on this at the summit, and although
the notes are a little scarce this was the conclusion we
came up with. Every time a cross service call is made, we
will log and send a notification for ceilometer to
consume, with the request-ids of both request ids. One of
the benefits of this approach is that we can easily
generate a tree of all the API calls that are made (and
clearly show when multiple calls are made to the same
service), something that just a cross service request id
would have trouble with.</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/icehouse-summit-qa-gate-debugability">https://etherpad.openstack.org/p/icehouse-summit-qa-gate-debugability</a> </div>
<div><br>
</div>
<div><br>
</div>
<div>With that in mind I think having a standard
x-openstack-request-id makes things a little more uniform,
and means that adding new services doesn't require new
logic to handle new request ids.</div>
</div>
</div>
</div>
</blockquote>
<br>
Two questions here:<br>
<br>
1) The APIChangeGuidelines state that changing a header is frowned
upon. So I suppose that means we'll need to add
x-openstack-request-id to nova and cinder, keeping around
x-compute-request-id for the time being?<br>
<br>
2) The deadline for blueprints for icehouse-2 is next week. This
blueprint [1] is still marked as "next"; should be move that up to
icehouse-2?<br>
<br>
<br>
-Chris Buccella<br>
</body>
</html>