[openstack-dev] request-id in API response
Chris Buccella
buccella at linux.vnet.ibm.com
Wed Dec 11 21:17:50 UTC 2013
On 12/02/2013 10:18 AM, Joe Gordon wrote:
>
>
> Thanks for bringing this up, and I'd welcome a patch in Swift that
> would use a common library to generate the transaction id, if it
> were installed. I can see that there would be huge advantage to
> operators to trace requests through multiple systems.
>
> Another option would be for each system that calls an another
> OpenStack system to expect and log the transaction ID for the
> request that was given. This would be looser coupling and be more
> forgiving for a heterogeneous cluster. Eg when Glance makes a call
> to Swift, Glance cloud log the transaction id that Swift used
> (from the Swift response). Likewise, when Swift makes a call to
> Keystone, Swift could log the Keystone transaction id. This
> wouldn't result in a single transaction id across all systems, but
> it would provide markers so an admin could trace the request.
>
>
> There was a session on this at the summit, and although the notes are
> a little scarce this was the conclusion we came up with. Every time a
> cross service call is made, we will log and send a notification for
> ceilometer to consume, with the request-ids of both request ids. One
> of the benefits of this approach is that we can easily generate a tree
> of all the API calls that are made (and clearly show when multiple
> calls are made to the same service), something that just a cross
> service request id would have trouble with.
>
> https://etherpad.openstack.org/p/icehouse-summit-qa-gate-debugability
>
>
> With that in mind I think having a standard x-openstack-request-id
> makes things a little more uniform, and means that adding new services
> doesn't require new logic to handle new request ids.
Two questions here:
1) The APIChangeGuidelines state that changing a header is frowned upon.
So I suppose that means we'll need to add x-openstack-request-id to nova
and cinder, keeping around x-compute-request-id for the time being?
2) The deadline for blueprints for icehouse-2 is next week. This
blueprint [1] is still marked as "next"; should be move that up to
icehouse-2?
-Chris Buccella
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/6f46e543/attachment.html>
More information about the OpenStack-dev
mailing list