Open Stack

On Tue, Jun 4, 2013 at 12:18 PM, Sandy Walsh <sandy.walsh at rackspace.com>wrote:

>
>
> 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.
>

Can't we do this now with a little bit of log parsing?  Every time nova
calls another service AFAIK we log the request ID to that service.


>
> 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
> >
>
> _______________________________________________
> 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/20130604/8d99f85d/attachment.html>