<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Michael,<div><br></div><div>Sure, I'm open to an ad-hoc discussion on this at the summit. Perhaps one of the unconference time slots? </div><div><br></div><div>Responses inline below.</div><div><br></div><div>Thanks,</div><div>Brian</div><div><br><div><div>On Apr 12, 2013, at 6:22 PM, Michael J Fork <<a href="mailto:mjfork@us.ibm.com">mjfork@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><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></p></div></blockquote><div>I think we are on the same page here. However, I don't care for the term "transaction id" as it has a connotation of an operation capable of being rolled back. Naming is always a pain, but I'd lean towards "openstack request id" or "API request id" for the optional user-supplied/global identifier. Then internal to each service, it could simply be the "Nova request id" or "Glance request id."</div><br><blockquote type="cite"><div><p>
<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></p></div></blockquote><div>Yup, sounds pretty useful.</div><br><blockquote type="cite"><div><p>
<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></p></div></blockquote></div><br></div></body></html>