<br><br><div class="gmail_quote">On Mon, Jun 11, 2012 at 10:27 PM, Gabe Westmaas <span dir="ltr"><<a href="mailto:gabe.westmaas@rackspace.com" target="_blank">gabe.westmaas@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

In nova we use a request ID to to help in finding all logs associated with<br>
a particular request, and this has proven to be extremely useful when<br>
debugging issues.  This should be taken a bit further, in two different<br>
directions.<br>
<br>
First, I'd like to see the request ID stored along with the any faults<br>
that are registered, and I'd like to see that request ID returned in the<br>
fault data.  Returning it in the fault data can start as an extension for<br>
now, and that should be able to move forward into the API pretty easily.<br>
<br>
Second, I'd like to figure out how we can extend this concept to all the<br>
openstack services.  I see two competing desires here.  First, we want to<br>
know about a particular request to a given service and second we want to<br>
know about an overall transaction across all services.  So, for example, a<br>
single create server request may cause multiple requests to glance, and<br>
depending on the issue, it would be great to both tie those together or<br>
investigate separately.  To this end, I'd like to see both a request ID<br>
and a transaction ID.  I'd like to see both these items in log, and I'd<br>
like all OpenStack services to obey the rule that if the transaction ID is<br>
set, don't reset it to anything else, but always add a request ID.<br>
<br>
Thoughts?  Do you buy the need for both a request ID and a transaction ID?<br>
I think the biggest change would be for swift, which already has a tx-<br>
header that gets set randomly no matter what (if that middleware is<br>
enabled).  I can make blueprints for both the points above if yes.<br>
<br>
I'd love to get request IDs into glance, melange and quantum (maybe<br>
already there?) in particular as quickly as possible.<br></blockquote><div><br></div><div>Hi Gabe,</div><div><br></div><div>I'm definitely in support of an ID that could help tie together both requests within a service, and requests between services (e.g., when Nova contacts Quantum to create a port when a VM is provisioned). </div>

<div><br></div><div>Dan</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Gabe<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>