<html><body>
<p><tt><font size="2">Brian Elliott <bdelliott@gmail.com> wrote on 04/12/2013 09:44:43 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 09:53 PM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] global request identifier</font></tt><br>
<tt><font size="2">> <br>
> Hi Michael,</font></tt><br>
<tt><font size="2">> <br>
> Sure, I'm open to an ad-hoc discussion on this at the summit. <br>
> Perhaps one of the unconference time slots? </font></tt><br>
<br>
<tt><font size="2">Sounds good to me. Whoever can grab a slot on the schedule when the Unconference board is posted and send out. (As an aside, it would be great if the unconference schedule was also on-line or on the main path - at the Grizzly summit it was at the end of the hall and I never thought to walk down to check out what was going on)</font></tt><tt><font size="2">.</font></tt><br>
<tt><font size="2"><br>
> Responses inline below.</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>
> > On Apr 12, 2013, at 6:22 PM, Michael J Fork <mjfork@us.ibm.com> wrote:</font></tt><br>
<tt><font size="2">> > <br>
> > Brian - I too am interested in this topic and am glad to see someone<br>
> > else interested in moving this forward. Reading through the ML <br>
> > again, the blueprint appears to diverge on identifiers (commented on<br>
> > whiteboard as well). From <a href="https://lists.launchpad.net/openstack/msg13174.html">https://lists.launchpad.net/openstack/msg13174.html</a><br>
> > <br>
> > "Seems like a likely line is when a new HTTP call is made, the <br>
> > request-id is reset. This allows us to disallow passing in a <br>
> > > request-id for all web services, which would lend itself well to a <br>
> > common middleware. That is to say, users of an API can pass in a <br>
> > transaction ID (which means the transaction ID could originate from <br>
> > the customer, if that's helpful to them) and the request id would <br>
> > always get set to a random UUID any time it passed through this middleware."<br>
> > <br>
> > Following this approach would seem to answer the open questions <br>
> > regarding request-id values - middleware in the HTTP server could <br>
> > strip it off since it would always be re-generated on HTTP call <br>
> > boundaries. By contrast, the transaction id would be used for the <br>
> > life of the API invocation, crossing component boundaries. If the <br>
> > transaction id isn't specified by the customer, a UUID could be generated. <br>
></font></tt><br>
<tt><font size="2">> I think we are on the same page here. However, I don't care for the<br>
> term "transaction id" as it has a connotation of an operation <br>
> capable of being rolled back. Naming is always a pain, but I'd lean<br>
> towards "openstack request id" or "API request id" for the optional <br>
> user-supplied/global identifier. Then internal to each service, it <br>
> could simply be the "Nova request id" or "Glance request id."</font></tt><br>
<br>
<tt><font size="2">I would really like to see 2 IDs (with an optional 3rd). The "OpenStack Request ID" is a global identifier generated by OpenStack and lives for the entire lifespan, including cross-component. The "<project> Request ID" is an identifier generated by OpenStack that lives for the lifespan of a single HTTP call to a component. Finally, building off Mike Pittaro's comment, a customer supplied identifier would be optional and not mixed with OpenStack generated IDs. Rather, it would be really be stored and used for cross-referencing purposes instead of logging purposes.</font></tt><br>
<tt><font size="2"> <br>
> > I would also like to propose making this statement slightly more <br>
> > generic: "each service that touches the request will carry along <br>
> > this header value and use it in log messages and external <br>
> > notifications." Instead of just logging those values, what if all <br>
> > log calls included the request object being worked on. I believe <br>
> > having the request object would open up a much richer set of <br>
> > possibilities with log handlers, including 1) logging those IDs via <br>
> > the formatter, and 2) in-memory buffer of debug messages with those <br>
> > associated with a failed request being dumped to disk.</font></tt><br>
<tt><font size="2">></font></tt><br>
<tt><font size="2">> Yup, sounds pretty useful.</font></tt><br>
<tt><font size="2">> <br>
> > <br>
> > Anyone else interested in an ad-hoc discussion on this at the summit?<br>
> > <br>
> > Michael<br>
> > <br>
> > -------------------------------------------------<br>
> > Michael Fork<br>
> > Architect, OpenStack Development<br>
> > IBM Systems & Technology Group<br>
</font></tt><br>
<tt><font size="2">> _______________________________________________<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><br>
</font></tt><br>
<font size="2" face="sans-serif">Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Architect, OpenStack Development<br>
IBM Systems & Technology Group</font></body></html>