<html><body>
<p><font size="2" face="sans-serif">Brian - I too am interested in this topic and am glad to see someone else interested in moving this forward. Reading through the ML again, the blueprint appears to diverge on identifiers (commented on whiteboard as well). From </font><a href="https://lists.launchpad.net/openstack/msg13174.html"><font size="2" face="sans-serif">https://lists.launchpad.net/openstack/msg13174.html</font></a><br>
<br>
<font size="2" face="sans-serif">"</font><tt><font size="1" color="#333333">Seems like a likely line is when a new HTTP call is made, the request-id is reset. This allows us to disallow passing in a request-id for all web services, which would lend itself well to a common middleware. That is to say, users of an API can pass in a transaction ID (which means the transaction ID could originate from the customer, if that's helpful to them) and the request id would always get set to a random UUID any time it passed through this middleware.</font></tt><font size="2" face="sans-serif">"</font><br>
<br>
<font size="2" face="sans-serif">Following this approach would seem to answer the open questions regarding request-id values - middleware in the HTTP server could strip it off since it would always be re-generated on HTTP call boundaries. By contrast, the transaction id would be used for the life of the API invocation, crossing component boundaries. If the transaction id isn't specified by the customer, a UUID could be generated. </font><br>
<br>
<font size="2" face="sans-serif">I would also like to propose making this statement slightly more generic: "each service that touches the request will carry along this header value and use it in log messages and external notifications." Instead of just logging those values, what if all log calls included the request object being worked on. I believe having the request object would open up a much richer set of possibilities with log handlers, including 1) logging those IDs via the formatter, and 2) in-memory buffer of debug messages with those associated with a failed request being dumped to disk.</font><br>
<br>
<font size="2" face="sans-serif">Anyone else interested in an ad-hoc discussion on this at the summit?</font><br>
<br>
<font size="2" face="sans-serif">Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Architect, OpenStack Development<br>
IBM Systems & Technology Group</font><br>
<br>
<tt><font size="2">Brian Elliott <bdelliott@gmail.com> wrote on 04/12/2013 03:22:31 PM:<br>
<br>
> From: Brian Elliott <bdelliott@gmail.com></font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font></tt><br>
<tt><font size="2">> Date: 04/12/2013 03:33 PM</font></tt><br>
<tt><font size="2">> Subject: [openstack-dev] global request identifier</font></tt><br>
<tt><font size="2">> <br>
> Hi folks,</font></tt><br>
<tt><font size="2">> <br>
> I wrote up this blueprint to add in the debugging of requests that <br>
> span multiple OpenStack services:</font></tt><br>
<tt><font size="2">> <br>
> <a href="https://blueprints.launchpad.net/nova/+spec/cross-service-request-id">https://blueprints.launchpad.net/nova/+spec/cross-service-request-id</a></font></tt><br>
<tt><font size="2">> <br>
> There was a discussion back in June about this topic. Feedback at <br>
> the time was positive, but interest seems to have fallen off. (<br>
> <a href="https://lists.launchpad.net/openstack/msg13082.html">https://lists.launchpad.net/openstack/msg13082.html</a>) Please let me <br>
> know if there are any objections to proceeding down this path!</font></tt><br>
<tt><font size="2">> <br>
> Thanks,</font></tt><br>
<tt><font size="2">> Brian</font></tt><br>
<tt><font size="2">> <br>
> PS: The BP is filed under the Nova project, but it's obviously more <br>
> cross-project. Is there a better place to capture things like this?<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt></body></html>