)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"40f41acd9a6aec00cbbe4d6686712dab7c743f96","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Without those exit points, the agent proceeds with the whole loop, and"},{"line_number":12,"context_line":"waits for another 2 seconds, only to determine on the next loop entry"},{"line_number":13,"context_line":"check that there was a signal, and the agent should exit. The current"},{"line_number":14,"context_line":"behavior, combined with RPC client backoff mechanism, may turn the agent"},{"line_number":15,"context_line":"into a zombie that is not willing to stop after SIGTERM even after 3 to"},{"line_number":16,"context_line":"5 minutes of the signal being sent. This in turn messes with how popular"},{"line_number":17,"context_line":"daemon management software (like systemd) restarts services (sending"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"fa31d9ce_2e4f2f6c","line":14,"range":{"start_line":14,"start_character":10,"end_line":14,"end_character":52},"updated":"2017-02-13 21:32:21.000000000","message":"are you sure this is at fault? The RPC timeout is set to 0 as soon as SIGTERM is received, or are you saying that it does not affect pending waits?\n\nhttp://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#n2092","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"250b15108ed76771cf55b770040a542648674111","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Without those exit points, the agent proceeds with the whole loop, and"},{"line_number":12,"context_line":"waits for another 2 seconds, only to determine on the next loop entry"},{"line_number":13,"context_line":"check that there was a signal, and the agent should exit. The current"},{"line_number":14,"context_line":"behavior, combined with RPC client backoff mechanism, may turn the agent"},{"line_number":15,"context_line":"into a zombie that is not willing to stop after SIGTERM even after 3 to"},{"line_number":16,"context_line":"5 minutes of the signal being sent. This in turn messes with how popular"},{"line_number":17,"context_line":"daemon management software (like systemd) restarts services (sending"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"fa31d9ce_8e01fb6c","line":14,"range":{"start_line":14,"start_character":10,"end_line":14,"end_character":52},"in_reply_to":"fa31d9ce_2e4f2f6c","updated":"2017-02-13 21:41:24.000000000","message":"Not 0, but 10. But see https://review.openstack.org/#/c/432481/, it doesn\u0027t work. Even if it works, it\u0027s still 10 secs per RPC operation executed in the loop, which are quite a number right now.","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"57843a6f9f9b8c95c82fdf9eceae9b761b9ca74f","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Without those exit points, the agent proceeds with the whole loop, and"},{"line_number":12,"context_line":"waits for another 2 seconds, only to determine on the next loop entry"},{"line_number":13,"context_line":"check that there was a signal, and the agent should exit. The current"},{"line_number":14,"context_line":"behavior, combined with RPC client backoff mechanism, may turn the agent"},{"line_number":15,"context_line":"into a zombie that is not willing to stop after SIGTERM even after 3 to"},{"line_number":16,"context_line":"5 minutes of the signal being sent. This in turn messes with how popular"},{"line_number":17,"context_line":"daemon management software (like systemd) restarts services (sending"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"fa31d9ce_6e3f6787","line":14,"range":{"start_line":14,"start_character":10,"end_line":14,"end_character":52},"in_reply_to":"fa31d9ce_2e4f2f6c","updated":"2017-02-13 21:32:49.000000000","message":"Ok, I found my answer:\n\nhttps://review.openstack.org/#/c/432481/","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"}],"neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py":[{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"40f41acd9a6aec00cbbe4d6686712dab7c743f96","unresolved":false,"context_lines":[{"line_number":2000,"context_line":"                    tunnel_sync \u003d True"},{"line_number":2001,"context_line":""},{"line_number":2002,"context_line":"            # process a signal if received in the middle of the loop"},{"line_number":2003,"context_line":"            if not self._check_and_handle_signal():"},{"line_number":2004,"context_line":"                break"},{"line_number":2005,"context_line":""},{"line_number":2006,"context_line":"            ovs_restarted |\u003d (ovs_status \u003d\u003d constants.OVS_RESTARTED)"}],"source_content_type":"text/x-python","patch_set":1,"id":"fa31d9ce_8ef65bf7","line":2003,"updated":"2017-02-13 21:32:21.000000000","message":"rather than sprinkling this all over the place, have you considered to have the SIGTERM handler block whatever is executing by means of an exception and have the exception handler clean up? Alternatively, the addition to this gigaloop tells me that we should perhaps break this down, but I can see the appealing of the quick fix. That\u0027s the very reason this loop has become hundreds of lines long.","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"412b8ee650da3169bcd9e566b547945a3a94c6cb","unresolved":false,"context_lines":[{"line_number":2000,"context_line":"                    tunnel_sync \u003d True"},{"line_number":2001,"context_line":""},{"line_number":2002,"context_line":"            # process a signal if received in the middle of the loop"},{"line_number":2003,"context_line":"            if not self._check_and_handle_signal():"},{"line_number":2004,"context_line":"                break"},{"line_number":2005,"context_line":""},{"line_number":2006,"context_line":"            ovs_restarted |\u003d (ovs_status \u003d\u003d constants.OVS_RESTARTED)"}],"source_content_type":"text/x-python","patch_set":1,"id":"fa31d9ce_f99cd1c1","line":2003,"in_reply_to":"fa31d9ce_2e62cf3e","updated":"2017-02-14 20:06:30.000000000","message":"OK for what I found out, python signal handlers are not executed as part of async C handler code, instead they are handled in a loop of the interpreter state machine, which should give us safety to raise exceptions from inside (and execute other code as we see fit).\n\nI will then rework the patch to behave accordingly.","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"065c3fc662937406f696a4cd4503eff8d42be580","unresolved":false,"context_lines":[{"line_number":2000,"context_line":"                    tunnel_sync \u003d True"},{"line_number":2001,"context_line":""},{"line_number":2002,"context_line":"            # process a signal if received in the middle of the loop"},{"line_number":2003,"context_line":"            if not self._check_and_handle_signal():"},{"line_number":2004,"context_line":"                break"},{"line_number":2005,"context_line":""},{"line_number":2006,"context_line":"            ovs_restarted |\u003d (ovs_status \u003d\u003d constants.OVS_RESTARTED)"}],"source_content_type":"text/x-python","patch_set":1,"id":"fa31d9ce_2e62cf3e","line":2003,"in_reply_to":"fa31d9ce_8ef65bf7","updated":"2017-02-13 21:45:38.000000000","message":"Lemme read about python and exceptions raised inside signal handlers, and get back to you.","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"7f9d930e57e71df5f46135f811bc17582a6cf6f6","unresolved":false,"context_lines":[{"line_number":2000,"context_line":"                    tunnel_sync \u003d True"},{"line_number":2001,"context_line":""},{"line_number":2002,"context_line":"            # process a signal if received in the middle of the loop"},{"line_number":2003,"context_line":"            if not self._check_and_handle_signal():"},{"line_number":2004,"context_line":"                break"},{"line_number":2005,"context_line":""},{"line_number":2006,"context_line":"            ovs_restarted |\u003d (ovs_status \u003d\u003d constants.OVS_RESTARTED)"}],"source_content_type":"text/x-python","patch_set":1,"id":"fa31d9ce_df5feae2","line":2003,"in_reply_to":"fa31d9ce_f99cd1c1","updated":"2017-02-14 22:45:42.000000000","message":"ack. If you are happy to proceed and you think this will lead to a cleaner/more robust SIGTERM handling, then let\u0027s go for it.","commit_id":"9b547d6ba580c4b7f585683e99ed6e99e042f2a3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"e84fcd3e616d981618ec7dfd4cb85aaa7b0deae0","unresolved":false,"context_lines":[{"line_number":1945,"context_line":"            while True:"},{"line_number":1946,"context_line":"                self._check_and_handle_sighup()"},{"line_number":1947,"context_line":"                if self.fullsync:"},{"line_number":1948,"context_line":"                    LOG.info(_LI(\"rpc_loop doing a full sync.\"))"},{"line_number":1949,"context_line":"                    sync \u003d True"},{"line_number":1950,"context_line":"                    self.fullsync \u003d False"},{"line_number":1951,"context_line":"                port_info \u003d {}"}],"source_content_type":"text/x-python","patch_set":3,"id":"fa31d9ce_abc2fc31","line":1948,"updated":"2017-02-14 20:51:52.000000000","message":"really, there is no change inside the actual loop body here, except rewrapping some long lines, and indentation.","commit_id":"7a4bbf8eac442350f4e7ca265317ebd36a64d422"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"328feee17f37e2d4a8ab14a24853d853b5653e84","unresolved":false,"context_lines":[{"line_number":2098,"context_line":"    def _handle_sigterm(self, signum, frame):"},{"line_number":2099,"context_line":"        if self.quitting_rpc_timeout:"},{"line_number":2100,"context_line":"            self.set_rpc_timeout(self.quitting_rpc_timeout)"},{"line_number":2101,"context_line":"        raise SystemExit()"},{"line_number":2102,"context_line":""},{"line_number":2103,"context_line":"    def _handle_sighup(self, signum, frame):"},{"line_number":2104,"context_line":"        # Reload configuration after completion of the current loop iteration"}],"source_content_type":"text/x-python","patch_set":3,"id":"fa31d9ce_ce5d7e16","line":2101,"updated":"2017-02-14 21:10:59.000000000","message":"maybe worth using a new type for that?","commit_id":"7a4bbf8eac442350f4e7ca265317ebd36a64d422"}]}