2011-12-02 18:04:26 |
Unmesh Gurjar |
bug |
|
|
added bug |
2011-12-06 13:11:14 |
Unmesh Gurjar |
description |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, all the log messages after this call do not have the context (request_id) information in it. Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
|
2011-12-06 13:15:02 |
Unmesh Gurjar |
description |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, all the log messages after this call do not have the context (request_id) information in it. Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, all the log messages after this call do not have the request_id information in it. Therefore, the '_log' method in NovaLogger fails to find the context and logs the messages without the request_id field.
Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
|
2011-12-06 13:17:19 |
Unmesh Gurjar |
description |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, all the log messages after this call do not have the request_id information in it. Therefore, the '_log' method in NovaLogger fails to find the context and logs the messages without the request_id field.
Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, the '_log' method in NovaLogger fails to find the context and logs the messages without the request_id field. This results in the log messages after the call to 'get_admin_context' getting logged with request_id in it.
Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
|
2011-12-06 13:17:45 |
Unmesh Gurjar |
description |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, the '_log' method in NovaLogger fails to find the context and logs the messages without the request_id field. This results in the log messages after the call to 'get_admin_context' getting logged with request_id in it.
Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
While testing the Create server API with the master branch, I noticed from the (Compute server) logs that the context was getting set to None intermittently. After digging more into the issue, it looks like the calls to the 'get_admin_context( )' method in nova.context module is causing this.
If we trace the a request's path from the server logs, the context information needs to be available throughout the processing cycle of the request. However, since the calls to 'get_admin_context' sets the context to None, the '_log' method in NovaLogger fails to find the context and logs the messages without the request_id field. This results in the log messages after the call to 'get_admin_context' getting logged without request_id in it.
Same is also the case with the log messages after 'elevated' method is called.
This method needs to be fixed, so that a request path can be easily traced from the server logs. |
|
2011-12-16 21:32:39 |
Vish Ishaya |
nova: status |
New |
Triaged |
|
2011-12-16 21:32:45 |
Vish Ishaya |
nova: importance |
Undecided |
Medium |
|
2012-01-09 23:59:21 |
Vish Ishaya |
nova: assignee |
|
Vish Ishaya (vishvananda) |
|
2012-01-09 23:59:24 |
Vish Ishaya |
nova: status |
Triaged |
In Progress |
|
2012-01-11 22:35:21 |
OpenStack Infra |
nova: status |
In Progress |
Fix Committed |
|
2012-01-25 09:54:44 |
Thierry Carrez |
nova: status |
Fix Committed |
Fix Released |
|
2012-01-25 09:54:44 |
Thierry Carrez |
nova: milestone |
|
essex-3 |
|
2012-04-05 10:00:42 |
Thierry Carrez |
nova: milestone |
essex-3 |
2012.1 |
|