Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

request and transaction IDs across all projects

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


gabe.westmaas at RACKSPACE

Jun 11, 2012, 10:27 PM

Post #1 of 9 (270 views)
Permalink
request and transaction IDs across all projects

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.

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.

Thoughts? Do you buy the need for both a request ID and a transaction ID?
I think the biggest change would be for swift, which already has a tx-
header that gets set randomly no matter what (if that middleware is
enabled). I can make blueprints for both the points above if yes.

I'd love to get request IDs into glance, melange and quantum (maybe
already there?) in particular as quickly as possible.

Gabe


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


ueno.nachi at nttdata-agilenet

Jun 11, 2012, 10:43 PM

Post #2 of 9 (265 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

+1

In addition, Nova itself should accept request ID as a transaction ID.
Nova is also one of callee in the sequence of transaction.

Nachi

2012/6/11 Gabe Westmaas <gabe.westmaas [at] rackspace>:
> 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.
>
> 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.
>
> Thoughts?  Do you buy the need for both a request ID and a transaction ID?
> I think the biggest change would be for swift, which already has a tx-
> header that gets set randomly no matter what (if that middleware is
> enabled).  I can make blueprints for both the points above if yes.
>
> I'd love to get request IDs into glance, melange and quantum (maybe
> already there?) in particular as quickly as possible.
>
> Gabe
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


jaypipes at gmail

Jun 12, 2012, 9:32 AM

Post #3 of 9 (263 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

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?

> Thoughts? Do you buy the need for both a request ID and a transaction ID?

Sure. Just curious where you think the dividing line is -- the project
(Nova, Glance) or the service/workers (nova-api, nova-compute, etc).

Best,
-jay

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


dan at nicira

Jun 12, 2012, 10:35 AM

Post #4 of 9 (262 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

On Mon, Jun 11, 2012 at 10:27 PM, Gabe Westmaas <gabe.westmaas [at] rackspace
> 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.
>
> 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.
>
> Thoughts? Do you buy the need for both a request ID and a transaction ID?
> I think the biggest change would be for swift, which already has a tx-
> header that gets set randomly no matter what (if that middleware is
> enabled). I can make blueprints for both the points above if yes.
>
> I'd love to get request IDs into glance, melange and quantum (maybe
> already there?) in particular as quickly as possible.
>

Hi Gabe,

I'm definitely in support of an ID that could help tie together both
requests within a service, and requests between services (e.g., when Nova
contacts Quantum to create a port when a VM is provisioned).

Dan




>
> Gabe
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


ueno.nachi at nttdata-agilenet

Jun 12, 2012, 11:20 AM

Post #5 of 9 (269 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

>> Thoughts?  Do you buy the need for both a request ID and a transaction ID?
>
>
> Sure. Just curious where you think the dividing line is -- the project
> (Nova, Glance) or the service/workers (nova-api, nova-compute, etc).

IMO, we should use one single id to track transaction for all project.
Instead, we should manage relationship between per project request id
and inter project transaction id.


> Best,
> -jay
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


gabe.westmaas at RACKSPACE

Jun 13, 2012, 10:21 AM

Post #6 of 9 (260 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

On 6/12/12 12:32 PM, "Jay Pipes" <jaypipes [at] gmail> 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.

>
>> Thoughts? Do you buy the need for both a request ID and a transaction
>>ID?
>
>Sure. Just curious where you think the dividing line is -- the project
>(Nova, Glance) or the service/workers (nova-api, nova-compute, etc).
>
>Best,
>-jay
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack [at] lists
>Unsubscribe : https://launchpad.net/~openstack
>More help : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


jaypipes at gmail

Jun 13, 2012, 10:23 AM

Post #7 of 9 (262 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

On 06/13/2012 01:21 PM, Gabe Westmaas wrote:
>
>
> On 6/12/12 12:32 PM, "Jay Pipes"<jaypipes [at] gmail> 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
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


salv.orlando at gmail

Jun 14, 2012, 4:15 PM

Post #8 of 9 (251 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

+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 [at] gmail> wrote:

> On 06/13/2012 01:21 PM, Gabe Westmaas wrote:
>
>>
>>
>> On 6/12/12 12:32 PM, "Jay Pipes"<jaypipes [at] gmail> 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 [at] lists
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>


gabe.westmaas at RACKSPACE

Jun 14, 2012, 4:21 PM

Post #9 of 9 (250 views)
Permalink
Re: request and transaction IDs across all projects [In reply to]

Interesting idea! Do you think we could get this by just logging the request ID in the service that initiated the request? It does require one extra lookup when trying to figure it out, but I bet a log analyzer could be written to take care of that no problem.

Gabe

From: Salvatore Orlando [mailto:salv.orlando [at] gmail]
Sent: Thursday, June 14, 2012 7:15 PM
To: Jay Pipes
Cc: Gabe Westmaas; openstack [at] lists
Subject: Re: [Openstack] request and transaction IDs across all projects

+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 [at] gmail> wrote:
On 06/13/2012 01:21 PM, Gabe Westmaas wrote:


On 6/12/12 12:32 PM, "Jay Pipes"<jaypipes [at] gmail>  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
Post to     : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.