Open Stack

On 06/13/2012 01:21 PM, Gabe Westmaas wrote:
>
>
> On 6/12/12 12:32 PM, "Jay Pipes"<jaypipes at gmail.com>  wrote:
>
>> On 06/12/2012 01:27 AM, Gabe Westmaas wrote:
>>> In nova we use a request ID to to help in finding all logs associated
>>> with
>>> a particular request, and this has proven to be extremely useful when
>>> debugging issues.  This should be taken a bit further, in two different
>>> directions.
>>>
>>> First, I'd like to see the request ID stored along with the any faults
>>> that are registered, and I'd like to see that request ID returned in the
>>> fault data.  Returning it in the fault data can start as an extension
>>> for
>>> now, and that should be able to move forward into the API pretty easily.
>>
>> This is a no-brainer. ++
>>
>>> Second, I'd like to figure out how we can extend this concept to all the
>>> openstack services.  I see two competing desires here.  First, we want
>>> to
>>> know about a particular request to a given service and second we want to
>>> know about an overall transaction across all services.  So, for
>>> example, a
>>> single create server request may cause multiple requests to glance, and
>>> depending on the issue, it would be great to both tie those together or
>>> investigate separately.  To this end, I'd like to see both a request ID
>>> and a transaction ID.  I'd like to see both these items in log, and I'd
>>> like all OpenStack services to obey the rule that if the transaction ID
>>> is
>>> set, don't reset it to anything else, but always add a request ID.
>>
>> OK, so the request ID would be specific to a service (e.g. Nova, Glance,
>> but not nova-api and nova-compute) and the transaction ID would be
>> across all services?
>>
>> Or would the request ID change from nova-api to nova-scheduler to
>> nova-compute?
>
> I was definitely thinking the first of these two options, but I suppose we
> should talk that out a little bit.  Seems like a likely line is when a new
> HTTP call is made, the request-id is reset.  This allows us to disallow
> passing in a request-id for all web services, which would lend itself well
> to a common middleware.  That is to say, users of an API can pass in a
> transaction ID (which means the transaction ID could originate from the
> customer, if that's helpful to them) and the request id would always get
> set to a random UUID any time it passed through this middleware.
>
> Thus the request ID is the same from nova api to scheduler to compute to
> network.  However, glance api and glance registry would each have unique
> request IDs, but a common transaction ID.

OK, I could definitely go along with this.

-jay