)]}'
{"zuul/model.py":[{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"cf40eb0579fd32cb5460081707ac79ea030ddb87","unresolved":true,"context_lines":[{"line_number":642,"context_line":"                        p.canonical_name for p in cq_manager.projects"},{"line_number":643,"context_line":"                    }"},{"line_number":644,"context_line":"                    if project_cname in managed_projects:"},{"line_number":645,"context_line":"                        cq_manager.created_for_branches[branch] \u003d queue"},{"line_number":646,"context_line":"                        break"},{"line_number":647,"context_line":""},{"line_number":648,"context_line":"        data.update({"}],"source_content_type":"text/x-python","patch_set":8,"id":"dfba8138_88893bde","line":645,"updated":"2021-10-29 15:49:45.000000000","message":"Thinking out loud here would it be safer to serialize and deserialize these queues with an explicit association rather than inferring it from a project + branch name?\n\nI wonder what would happen if you reconfigure to move a project from one queue to another and that doesn\u0027t get serialized properly due to an outage. I guess the second scheduler would read the old data and reconcile it against the new config and then write that out to zookeeper? So for a (short) period of time you may run the old config for queues?","commit_id":"f47cf3d6c2f0c6606ddfe93eca3365271cdcd782"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"13b1a5346c2bb4a3b715027379eff58c1f178317","unresolved":false,"context_lines":[{"line_number":642,"context_line":"                        p.canonical_name for p in cq_manager.projects"},{"line_number":643,"context_line":"                    }"},{"line_number":644,"context_line":"                    if project_cname in managed_projects:"},{"line_number":645,"context_line":"                        cq_manager.created_for_branches[branch] \u003d queue"},{"line_number":646,"context_line":"                        break"},{"line_number":647,"context_line":""},{"line_number":648,"context_line":"        data.update({"}],"source_content_type":"text/x-python","patch_set":8,"id":"200dbc21_608fce12","line":645,"in_reply_to":"dfba8138_88893bde","updated":"2021-10-29 16:07:19.000000000","message":"https://review.opendev.org/c/zuul/zuul/+/814773/ hints at the expected behavior here if there is a failure. Basically to move the shared state would have to be updated. This means if sched1 fails then the project hasn\u0027t moved yet and sched2 can recover things and do the move. We shouldn\u0027t flip flop. For this reason this code should be sufficient.","commit_id":"f47cf3d6c2f0c6606ddfe93eca3365271cdcd782"}]}