<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 1:40 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/11/2013 04:17 PM, Chris Buccella wrote:<br>
> On 12/02/2013 10:18 AM, Joe Gordon wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> Thanks for bringing this up, and I'd welcome a patch in Swift that<br>
>> would use a common library to generate the transaction id, if it<br>
>> were installed. I can see that there would be huge advantage to<br>
>> operators to trace requests through multiple systems.<br>
>><br>
>> Another option would be for each system that calls an another<br>
>> OpenStack system to expect and log the transaction ID for the<br>
>> request that was given. This would be looser coupling and be more<br>
>> forgiving for a heterogeneous cluster. Eg when Glance makes a call<br>
>> to Swift, Glance cloud log the transaction id that Swift used<br>
>> (from the Swift response). Likewise, when Swift makes a call to<br>
>> Keystone, Swift could log the Keystone transaction id. This<br>
>> wouldn't result in a single transaction id across all systems, but<br>
>> it would provide markers so an admin could trace the request.<br>
>><br>
>><br>
>> There was a session on this at the summit, and although the notes are<br>
>> a little scarce this was the conclusion we came up with. Every time a<br>
>> cross service call is made, we will log and send a notification for<br>
>> ceilometer to consume, with the request-ids of both request ids. One<br>
>> of the benefits of this approach is that we can easily generate a tree<br>
>> of all the API calls that are made (and clearly show when multiple<br>
>> calls are made to the same service), something that just a cross<br>
>> service request id would have trouble with.<br>
>><br>
>> <a href="https://etherpad.openstack.org/p/icehouse-summit-qa-gate-debugability" target="_blank">https://etherpad.openstack.org/p/icehouse-summit-qa-gate-debugability</a><br>
>><br>
>><br>
>> With that in mind I think having a standard x-openstack-request-id<br>
>> makes things a little more uniform, and means that adding new services<br>
>> doesn't require new logic to handle new request ids.<br>
><br>
> Two questions here:<br>
><br>
> 1) The APIChangeGuidelines state that changing a header is frowned upon.<br>
> So I suppose that means we'll need to add x-openstack-request-id to nova<br>
> and cinder, keeping around x-compute-request-id for the time being?<br>
><br>
> 2) The deadline for blueprints for icehouse-2 is next week. This<br>
> blueprint [1] is still marked as "next"; should be move that up to<br>
> icehouse-2?<br></div></div></blockquote><div><br></div><div>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)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
</div></div>x-compute-request-id would need to go through the normal deprecation<br>
path. So deprecate for icehouse, remove in J. Adding<br>
x-openstack-request-id could happen right away, just mirror the ids<br>
across to it.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>