[openstack-dev] global request identifier
Michael J Fork
mjfork at us.ibm.com
Sat Apr 13 02:12:42 UTC 2013
Brian Elliott <bdelliott at gmail.com> wrote on 04/12/2013 09:44:43 PM:
> From: Brian Elliott <bdelliott at gmail.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 04/12/2013 09:53 PM
> Subject: Re: [openstack-dev] global request identifier
> Hi Michael,
> Sure, I'm open to an ad-hoc discussion on this at the summit.
> Perhaps one of the unconference time slots?
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).
> Responses inline below.
> > On Apr 12, 2013, at 6:22 PM, Michael J Fork <mjfork at us.ibm.com> wrote:
> > 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
> > "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
> > 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
> 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."
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.
> > 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.
> Yup, sounds pretty useful.
> > Anyone else interested in an ad-hoc discussion on this at the summit?
> > Michael
> > -------------------------------------------------
> > Michael Fork
> > Architect, OpenStack Development
> > IBM Systems & Technology Group
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
Architect, OpenStack Development
IBM Systems & Technology Group
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev