On Thu, Dec 12, 2013 at 1:40 AM, Sean Dague <s...@dague.net> wrote: > On 12/11/2013 04:17 PM, Chris Buccella wrote: > > 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? >
I can't seem to find footnote [1], but yes it sounds like this should be moved to icehouse-2. Also we will need at least two blueprints (nova and cinder) > > x-compute-request-id would need to go through the normal deprecation > path. So deprecate for icehouse, remove in J. Adding > x-openstack-request-id could happen right away, just mirror the ids > across to it. > +1 > > -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
