Just to add to the story, Swift uses "X-Trans-Id" and generates it in the 
outer-most "catch_errors" middleware.

Swift's catch errors middleware is responsible for ensuring that the 
transaction id exists on each request, and that all errors previously uncaught, 
anywhere in the pipeline, are caught and logged. If there is not a common way 
to do this, yet, I submit it as a great template for solving this problem. It's 
simple, scalable, and well-tested (ie tests and running in prod for years).


Leaving aside error handling and only focusing on the transaction id (or 
request id) generation, since OpenStack services are exposed to untrusted 
clients, how would you propose communicating the appropriate transaction id to 
a different service? I can see great benefit to having a glance transaction ID 
carry through to Swift requests (and so on), but how should the transaction id 
be communicated? It's not sensitive info, but I can imagine a pretty big 
problem when trying to track down errors if a client application decides to set 
eg the X-Set-Transaction-Id header on every request to the same thing.

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.


On Dec 1, 2013, at 5:48 PM, Maru Newby <ma...@redhat.com> wrote:

> On Nov 30, 2013, at 1:00 AM, Sean Dague <s...@dague.net> wrote:
>> On 11/29/2013 10:33 AM, Jay Pipes wrote:
>>> On 11/28/2013 07:45 AM, Akihiro Motoki wrote:
>>>> Hi,
>>>> I am working on adding request-id to API response in Neutron.
>>>> After I checked what header is used in other projects
>>>> header name varies project by project.
>>>> It seems there is no consensus what header is recommended
>>>> and it is better to have some consensus.
>>>> nova:     x-compute-request-id
>>>> cinder:   x-compute-request-id
>>>> glance:   x-openstack-request-id
>>>> neutron:  x-network-request-id  (under review)
>>>> request-id is assigned and used inside of each project now,
>>>> so x-<service>-request-id looks good. On the other hand,
>>>> if we have a plan to enhance request-id across projects,
>>>> x-openstack-request-id looks better.
>>> My vote is for:
>>> x-openstack-request-id
>>> With an implementation of "create a request UUID if none exists yet" in
>>> some standardized WSGI middleware...
>> Agreed. I don't think I see any value in having these have different
>> service names, having just x-openstack-request-id across all the
>> services seems a far better idea, and come back through and fix nova and
>> cinder to be that as well.
> +1 
> An openstack request id should be service agnostic to allow tracking of a 
> request across many services (e.g. a call to nova to boot a VM should 
> generate a request id that is provided to other services in requests to 
> provision said VM).  All services would ideally share a facility for 
> generating new request ids and for securely accepting request ids from other 
> services.
> m.
>>      -Sean
>> -- 
>> Sean Dague
>> http://dague.net
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

OpenStack-dev mailing list

Reply via email to