)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":7,"context_line":"Only leader actions bump state_timestamp"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"The state of a shard range can be changed at different times in"},{"line_number":10,"context_line":"different processes, but should always make forwards progress. If one"},{"line_number":11,"context_line":"replica of a shard range has already moved to a state that is ahead"},{"line_number":12,"context_line":"that of another replica then the most advanced state should be"},{"line_number":13,"context_line":"preserved irrespective of the time at which each replica reached their"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bf659307_26b81fe3","line":10,"range":{"start_line":10,"start_character":44,"end_line":10,"end_character":61},"updated":"2018-04-02 22:07:24.000000000","message":"This makes perfect sense when in a nice linear section of the state machine -- particularly FOUND through ACTIVE.\n\nBut it gets a little ambiguous when going from ACTIVE to SHARDED -- what does \"forward\" mean when one copy says SHARDING and the other says SHRINKING? I suppose that\u0027s why getting out of ACTIVE is always a \"leader action\" and triggers a state_timestamp bump...","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":13,"context_line":"preserved irrespective of the time at which each replica reached their"},{"line_number":14,"context_line":"current state."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"The only time a shard range state needs to move \u0027backwards\u0027 is when a"},{"line_number":17,"context_line":"final shard range shrinks back to a root, when the root needs to"},{"line_number":18,"context_line":"change from sharded state to active state. This transition should only"},{"line_number":19,"context_line":"be performed by a single \u0027leader\u0027 process and it is therefore"},{"line_number":20,"context_line":"acceptable to increase the state_timestamp at that moment in time so"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bf659307_2611ff04","line":17,"range":{"start_line":16,"start_character":0,"end_line":17,"end_character":40},"updated":"2018-04-02 22:07:24.000000000","message":"Not strictly true until we get rid of EXPANDING later in the chain.","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":21,"context_line":"that the active state takes precedence over any other more advanced"},{"line_number":22,"context_line":"state with an older timestamp."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"In general, the state timestamp can be increased whenever a single"},{"line_number":25,"context_line":"\u0027leader\u0027 is singularly responsible for performing a state transition."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Change-Id: I0a38db0a56645fc5c0b0fcf2cbd89a3b5f31cebf"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bf659307_869d6b67","line":24,"range":{"start_line":24,"start_character":32,"end_line":24,"end_character":35},"updated":"2018-04-02 22:07:24.000000000","message":"\"Can\" or \"must\"?","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"c0f3c02539f10f1a2f3db2c5053dff3885d56e30","unresolved":false,"context_lines":[{"line_number":21,"context_line":"that the active state takes precedence over any other more advanced"},{"line_number":22,"context_line":"state with an older timestamp."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"In general, the state timestamp can be increased whenever a single"},{"line_number":25,"context_line":"\u0027leader\u0027 is singularly responsible for performing a state transition."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Change-Id: I0a38db0a56645fc5c0b0fcf2cbd89a3b5f31cebf"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bf659307_e1c19855","line":24,"range":{"start_line":24,"start_character":32,"end_line":24,"end_character":35},"in_reply_to":"bf659307_4c1a0a17","updated":"2018-04-03 17:34:56.000000000","message":"\u003e I prefer to also bump timestamp for the move sharding or shrinking\n\nBig +1 there -- it clears up what\u0027s meant by \"forward\" if we somehow manage to have two copies of a shard range in SHARDING and SHRINKING states.","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"45a32f0636f212f4fa4db8fe7723de8f97f39403","unresolved":false,"context_lines":[{"line_number":21,"context_line":"that the active state takes precedence over any other more advanced"},{"line_number":22,"context_line":"state with an older timestamp."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"In general, the state timestamp can be increased whenever a single"},{"line_number":25,"context_line":"\u0027leader\u0027 is singularly responsible for performing a state transition."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Change-Id: I0a38db0a56645fc5c0b0fcf2cbd89a3b5f31cebf"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bf659307_4c1a0a17","line":24,"range":{"start_line":24,"start_character":32,"end_line":24,"end_character":35},"in_reply_to":"bf659307_869d6b67","updated":"2018-04-03 09:11:36.000000000","message":"I think the only time it is a \u0027must\u0027 is going back to ACTIVE (given the presumption of EXPANDING going away) but for now I prefer to also bump timestamp for the move sharding or shrinking because there is only one actor for those transitions, and if nothing else it\u0027s helpful to track when changes happened.","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"}],"swift/common/utils.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":4583,"context_line":"            return False"},{"line_number":4584,"context_line":"        self.state \u003d state"},{"line_number":4585,"context_line":"        if state_timestamp:"},{"line_number":4586,"context_line":"            self.state_timestamp \u003d Timestamp.now()"},{"line_number":4587,"context_line":"        return True"},{"line_number":4588,"context_line":""},{"line_number":4589,"context_line":"    def set_deleted(self, timestamp\u003dNone):"}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_221a4816","line":4586,"range":{"start_line":4586,"start_character":35,"end_line":4586,"end_character":50},"updated":"2018-04-02 22:07:24.000000000","message":"Really? Not state_timestamp?\n\nLooks like (most? all?) callers pass Timestamp.now() anyway... maybe the param should be called is_leader_decision or something?","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"45a32f0636f212f4fa4db8fe7723de8f97f39403","unresolved":false,"context_lines":[{"line_number":4583,"context_line":"            return False"},{"line_number":4584,"context_line":"        self.state \u003d state"},{"line_number":4585,"context_line":"        if state_timestamp:"},{"line_number":4586,"context_line":"            self.state_timestamp \u003d Timestamp.now()"},{"line_number":4587,"context_line":"        return True"},{"line_number":4588,"context_line":""},{"line_number":4589,"context_line":"    def set_deleted(self, timestamp\u003dNone):"}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_4c752af9","line":4586,"range":{"start_line":4586,"start_character":35,"end_line":4586,"end_character":50},"in_reply_to":"bf659307_221a4816","updated":"2018-04-03 09:11:36.000000000","message":"Eeek. that deserved a -1 !","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"}],"swift/container/backend.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":291,"context_line":""},{"line_number":292,"context_line":"    if (existing[\u0027state_timestamp\u0027] \u003d\u003d shard_data[\u0027state_timestamp\u0027]"},{"line_number":293,"context_line":"            and shard_data[\u0027state\u0027] \u003e existing[\u0027state\u0027]):"},{"line_number":294,"context_line":"        new_content \u003d True"},{"line_number":295,"context_line":"    elif existing[\u0027state_timestamp\u0027] \u003e\u003d shard_data[\u0027state_timestamp\u0027]:"},{"line_number":296,"context_line":"        for k in (\u0027state\u0027, \u0027state_timestamp\u0027, \u0027epoch\u0027):"},{"line_number":297,"context_line":"            shard_data[k] \u003d existing[k]"}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_02a704bf","line":294,"updated":"2018-04-02 22:07:24.000000000","message":"...and we don\u0027t have to worry about epoch rolling backwards because changing epoch is one of those leader decisions that would bump state_timestamp. Right?","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"45a32f0636f212f4fa4db8fe7723de8f97f39403","unresolved":false,"context_lines":[{"line_number":291,"context_line":""},{"line_number":292,"context_line":"    if (existing[\u0027state_timestamp\u0027] \u003d\u003d shard_data[\u0027state_timestamp\u0027]"},{"line_number":293,"context_line":"            and shard_data[\u0027state\u0027] \u003e existing[\u0027state\u0027]):"},{"line_number":294,"context_line":"        new_content \u003d True"},{"line_number":295,"context_line":"    elif existing[\u0027state_timestamp\u0027] \u003e\u003d shard_data[\u0027state_timestamp\u0027]:"},{"line_number":296,"context_line":"        for k in (\u0027state\u0027, \u0027state_timestamp\u0027, \u0027epoch\u0027):"},{"line_number":297,"context_line":"            shard_data[k] \u003d existing[k]"}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_6c8caed6","line":294,"in_reply_to":"bf659307_02a704bf","updated":"2018-04-03 09:11:36.000000000","message":"correct. whichever has the greatest state or state timestamp has the desired epoch.","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"}],"swift/container/sharder.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":1036,"context_line":"                # do not want any subsequent shard ranges to be in created"},{"line_number":1037,"context_line":"                # state while this one is still in found state"},{"line_number":1038,"context_line":"                break"},{"line_number":1039,"context_line":"            shard_range.update_state(ShardRange.CREATED)"},{"line_number":1040,"context_line":"            created_ranges.append(shard_range)"},{"line_number":1041,"context_line":"            self.logger.increment(\u0027shard_ranges_created\u0027)"},{"line_number":1042,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_e28c5037","side":"PARENT","line":1039,"updated":"2018-04-02 22:07:24.000000000","message":"Right, \u0027cause we already did that up on L1017 and there shouldn\u0027t be anything to roll it back.","commit_id":"5c9a1b8511ebe0476ce38fdf434719394ac67e5b"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"45a32f0636f212f4fa4db8fe7723de8f97f39403","unresolved":false,"context_lines":[{"line_number":1036,"context_line":"                # do not want any subsequent shard ranges to be in created"},{"line_number":1037,"context_line":"                # state while this one is still in found state"},{"line_number":1038,"context_line":"                break"},{"line_number":1039,"context_line":"            shard_range.update_state(ShardRange.CREATED)"},{"line_number":1040,"context_line":"            created_ranges.append(shard_range)"},{"line_number":1041,"context_line":"            self.logger.increment(\u0027shard_ranges_created\u0027)"},{"line_number":1042,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_cc6b7aee","side":"PARENT","line":1039,"in_reply_to":"bf659307_e28c5037","updated":"2018-04-03 09:11:36.000000000","message":"I think the duplication perhaps crept in when resolving a merge conflict, or was my mistake.","commit_id":"5c9a1b8511ebe0476ce38fdf434719394ac67e5b"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"efb2a561f8fb3d783b5d2c6b6c0e30a0042c4968","unresolved":false,"context_lines":[{"line_number":1136,"context_line":"                # Set donor state to shrinking so that next cycle won\u0027t use it"},{"line_number":1137,"context_line":"                # as an acceptor; state_timestamp defines new epoch for donor"},{"line_number":1138,"context_line":"                # and new timestamp for the expanded acceptor below."},{"line_number":1139,"context_line":"                donor.epoch \u003d donor.state_timestamp \u003d Timestamp.now()"},{"line_number":1140,"context_line":"                modified_shard_ranges.append(donor)"},{"line_number":1141,"context_line":"            broker.merge_shard_ranges(modified_shard_ranges)"},{"line_number":1142,"context_line":"            if acceptor is not own_shard_range:"}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_a297383a","line":1139,"range":{"start_line":1139,"start_character":54,"end_line":1139,"end_character":69},"updated":"2018-04-02 22:07:24.000000000","message":"We don\u0027t just pass it to the update_state call?","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"45a32f0636f212f4fa4db8fe7723de8f97f39403","unresolved":false,"context_lines":[{"line_number":1136,"context_line":"                # Set donor state to shrinking so that next cycle won\u0027t use it"},{"line_number":1137,"context_line":"                # as an acceptor; state_timestamp defines new epoch for donor"},{"line_number":1138,"context_line":"                # and new timestamp for the expanded acceptor below."},{"line_number":1139,"context_line":"                donor.epoch \u003d donor.state_timestamp \u003d Timestamp.now()"},{"line_number":1140,"context_line":"                modified_shard_ranges.append(donor)"},{"line_number":1141,"context_line":"            broker.merge_shard_ranges(modified_shard_ranges)"},{"line_number":1142,"context_line":"            if acceptor is not own_shard_range:"}],"source_content_type":"text/x-python","patch_set":2,"id":"bf659307_4c2d2aa6","line":1139,"range":{"start_line":1139,"start_character":54,"end_line":1139,"end_character":69},"in_reply_to":"bf659307_a297383a","updated":"2018-04-03 09:11:36.000000000","message":"I want these steps to be idempotent, so only bump the timestamp once when the state changes. I thought about making update_state smart enough to do that but decided not to complicate the semantics of that method. I\u0027m 50/50 on it though.","commit_id":"8651725028e060fa6ea72451cf9cc2e9d999e007"}]}