openstack team mailing list archive

[Salvatore Orlando <salv.orlando@xxxxxxxxx>]

+111 from me.
This would make a lot easier extracting info from logs and correlating
events in different logs. In the long run these association might also be
used by metering/billing applications.

This is probably out of scope, but I was wondering whether we can also add
a concept of "parent request", so that for each request in a given
transaction we would be immediately able to know which request generated
it.

Salvatore

On 13 June 2012 18:23, Jay Pipes <jaypipes@xxxxxxxxx> wrote:

> On 06/13/2012 01:21 PM, Gabe Westmaas wrote:
>
>>
>>
>> On 6/12/12 12:32 PM, "Jay Pipes"<jaypipes@xxxxxxxxx>  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
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>