[openstack-dev] Using thread local storage for correlation_id

Sandy Walsh sandy.walsh at rackspace.com
Tue Jun 4 19:18:48 UTC 2013



On 06/04/2013 04:10 PM, Brian Elliott wrote:
> Brian,
> 
> On Jun 4, 2013, at 1:39 PM, Brian Lamar <brian.lamar at rackspace.com> wrote:
> 
>> I'm going to refrain on commenting on thread local storage, but I have one question: Is this going to replace the request_id concept we've had in Nova/Glance for a while? I've been out of development for a bit but this seems like it's a similar concept. I'm all for having IDs to track across all projects.
>>
>> Brian
>>
>>
> 
> No, it will not replace the Nova/Glance request_id.  It is intended instead to serve as a single identifier that carries across multiple services through the lifespan of a user request.  It is intended to be service-agnostic and will hopefully get implemented in every project.
> 
> Correlation_id and request_id could be the same identifier, but it could get hairy if they were.  Imagine a single call to service A results in two calls to service B.  I think you want each request to B to retain a separate request identifier for tracking purposes (like it is now), but then you want a second correlation_id that gives you simplified tracking across the entire surface of the call originating at A.

That would be useful. If Correlation could include multiple Request ID's
we could track a call from Keystone all the way down.

Per User Action = Correlation ID
Per Service = Request ID

Is the purpose of using TLS for tracking those calls that don't pass the
context? If so, could we use TLS for the Context object instead of
explicitly passing it as a parameter?

-S

> 
> Thanks,
> Brian
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list