<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>The following are the blue prints available <br><br>For Nova: <a href="https://blueprints.launchpad.net/nova/+spec/cross-service-request-id" target="_blank">https://blueprints.launchpad.net/nova/+spec/cross-service-request-id</a> (with major part of the discussion)<br>For Glance: <a href="https://blueprints.launchpad.net/glance/+spec/use-unified-request-identifier" target="_blank">https://blueprints.launchpad.net/glance/+spec/use-unified-request-identifier</a> (which I created it for implementing the correlation_id for glance)<br><br>P.S: Even though I proposed using RequestContext to hold the correlation_id in my blueprint. After going through the code base, I realized that RequestContext might not be available in for all the middleware's in the pipeline. Hence thought using TLS holding the correlation_id might be a better option.<br><br>Regards,<br>Venkatesh <br><br><br><div>> Date: Tue, 4 Jun 2013 22:03:56 -0400<br>> From: rbryant@redhat.com<br>> To: openstack-dev@lists.openstack.org<br>> Subject: Re: [openstack-dev] Using thread local storage for correlation_id<br>> <br>> On 06/04/2013 02:45 PM, Sandy Walsh wrote:<br>> > <br>> > <br>> > On 06/04/2013 02:24 PM, Venkatesh Sampath wrote:<br>> >> Hi Everyone,<br>> >><br>> >> We are planning to introduce a correlation_id across for effective<br>> >> debugging of requests that span across services.<br>> >><br>> >> The idea is to pass the correlation_id as part of the request header<br>> >> across services. The job of generating/capturing the correlation_id and<br>> >> setting it as part of the request header is done through the<br>> >> correlation_id.py middleware available through oslo incubator.<br>> > <br>> > Why not use the existing Request ID? It's already stored in the Context<br>> > object.<br>> <br>> Is there a document about this feature, including how it relates to the<br>> existing request ID, that we can all review?<br>> <br>> <br>> > <br>> >><br>> >> The services that uses the correlation_id middleware can in turn obtain<br>> >> the correlation_id from the request header and use it as part of logging<br>> >> & notification purposes.<br>> >><br>> >> We are planning to make the correlation_id available for logging through<br>> >> thread local storage especially using the existing 'local.strong_store'<br>> >> reference. ( available from oslo-incubator/openstack/common/local.py).<br>> >> ie., by setting the correlation_id as attribute to 'local.strong_store'<br>> >> in the correlation_id middleware.<br>> >><br>> >> Wish to know if its good idea to use the thread local storage from<br>> >> local.py for correlation_id so that it could be used by respective services.<br>> >><br>> >> Thoughts?<br>> <br>> <br>> -- <br>> Russell Bryant<br>> <br>> _______________________________________________<br>> OpenStack-dev mailing list<br>> OpenStack-dev@lists.openstack.org<br>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div> </div></body>
</html>