)]}'
{"nova/context.py":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"3e8fa8f9722165e606986d0806840cd460176893","unresolved":false,"context_lines":[{"line_number":282,"context_line":"                          overwrite\u003dTrue,"},{"line_number":283,"context_line":"                          global_request_id\u003dcontext.generate_request_id())"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"def is_user_context(context):"},{"line_number":287,"context_line":"    \"\"\"Indicates if the request context is a normal user.\"\"\""},{"line_number":288,"context_line":"    if not context:"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_cb8a9b19","line":285,"updated":"2019-08-01 16:05:05.000000000","message":"FYI the reason we take care not overwrite the greenthread-local context here is because oslo.log uses the thread local context to log the request_id [1]. If it is overwritten by a get_admin_context or get_context call, then the request_id that could trace a request will get \"hijacked\" being overwritten by whatever called get_admin_context or get_context (if overwrite\u003dTrue). So let\u0027s say a request to boot an instance comes in, the request_id is traceable through the services, until, for example, a periodic task calls get_admin_context(overwrite\u003dTrue), then the request_id for the instance boot request will change to the new request_id that was generated by the RequestContext constructor [2] in the get_admin_context(overwrite\u003dTrue) call, thus breaking the consistency of one request_id per request in the logs. (see the first bug linked below)\n\nAnd request_id isn\u0027t the only issue either, if overwrite\u003dTrue then anything that calls get_admin_context or get_context would cause the original auth_token, project_id, etc from the request to be overwritten. For example, project_id of the request will be overwritten to None because project_id\u003dNone here. (see the second bug linked below)\n\nSee bugs:\n\nhttps://bugs.launchpad.net/nova/+bug/1773102\nhttps://bugs.launchpad.net/nova/+bug/1627838\n\nI\u0027m thinking maybe I should propose a change to add more code comments here explaining what\u0027s behind overwrite\u003dFalse, to let this not be a tribal knowledge situation going forward.\n\n[1] https://github.com/openstack/oslo.log/blob/b21efb5f7ad6aa268330f4bc3f6585bc8ba41c56/oslo_log/formatters.py#L74-L91\n[2] https://github.com/openstack/oslo.context/blob/07f068d8a2bf8420a419f806a22012ed8419d029/oslo_context/context.py#L176-L277","commit_id":"6673363e88670e8b05cf79a0197104a51e74f900"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"b7266ba3cc95b3807dbcc316784f8ddaaf5d5246","unresolved":false,"context_lines":[{"line_number":282,"context_line":"                          overwrite\u003dTrue,"},{"line_number":283,"context_line":"                          global_request_id\u003dcontext.generate_request_id())"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"def is_user_context(context):"},{"line_number":287,"context_line":"    \"\"\"Indicates if the request context is a normal user.\"\"\""},{"line_number":288,"context_line":"    if not context:"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_eb9af711","line":285,"in_reply_to":"7faddb67_cb8a9b19","updated":"2019-08-01 16:08:29.000000000","message":"\u003e I\u0027m thinking maybe I should propose a change to add more code comments here explaining what\u0027s behind overwrite\u003dFalse, to let this not be a tribal knowledge situation going forward.\n\nDefinitely.","commit_id":"6673363e88670e8b05cf79a0197104a51e74f900"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"e2bd830cfdd58a2b6b8a8131960d6255dafc4fcd","unresolved":false,"context_lines":[{"line_number":282,"context_line":"                          overwrite\u003dTrue,"},{"line_number":283,"context_line":"                          global_request_id\u003dcontext.generate_request_id())"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"def is_user_context(context):"},{"line_number":287,"context_line":"    \"\"\"Indicates if the request context is a normal user.\"\"\""},{"line_number":288,"context_line":"    if not context:"}],"source_content_type":"text/x-python","patch_set":1,"id":"7faddb67_7153586c","line":285,"in_reply_to":"7faddb67_eb9af711","updated":"2019-08-01 18:20:17.000000000","message":"OK, I think I need to correct myself after thinking more about efried\u0027s question in IRC about how periodic tasks should have their own thread, so how can they overwrite anything?\n\nIt\u0027s true, periodic tasks have their own threads, so I need to nix mention of periodic tasks in my above comment. Re-reading bug 1773102, it says that because of the bug, thread local variables were *not* actually local to threads and were being overwritten any time another thread created a context. So that is how periodic tasks were ever involved in any overwriting.\n\nSince that bug has been fixed, the problem of using overwrite\u003dTrue here should be limited to callers of get_admin_context and get_context in the same thread of a request only.\n\nNote that recently someone said in a bug comment that they saw periodic tasks taking on the request_id of user-initiated requests (causing confusion in the logs):\n\nhttps://bugs.launchpad.net/nova/+bug/1835958/comments/3\nhttps://bugs.launchpad.net/nova/+bug/1835958/comments/7\n\nBut I don\u0027t understand how that\u0027s possible given the periodics have their own threads and I don\u0027t find evidence of it in recent gate runs. If I take a request_id for a run of a periodic task and search the rest of the compute log, I don\u0027t find other appearances of it. It would seem like the only way they could be seeing that is if they still had bug 1773102 in their environment somehow? They\u0027re running queens and the fix was backported to queens and released in 17.0.6 on 2018-09-24.","commit_id":"6673363e88670e8b05cf79a0197104a51e74f900"}]}