Open Stack

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.
>
> Thanks,
> Brian
>
> > 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
https://lists.launchpad.net/openstack/msg13174.html
> >
> > "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."
> >
> > 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.
>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Michael

-------------------------------------------------
Michael Fork
Architect, OpenStack Development
IBM Systems & Technology Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130412/f10cd6a5/attachment.html>