Activity log for bug #899302

Date Who What changed Old value New value Message
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