Open Stack

On Thu, Dec 12, 2013 at 1:40 AM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/64946962/attachment.html>