)]}'
{"specs/mitaka/set-replication-status.rst":[{"author":{"_account_id":1207,"name":"Duncan Thomas","email":"duncan.thomas@gmail.com","username":"duncan-thomas"},"change_message_id":"d1e9a17a22c5787b7cf22976fffc3c99c8548735","unresolved":false,"context_lines":[{"line_number":17,"context_line":"sync with what Cinder thinks (whether that\u0027s enabled, disabled, failed over,"},{"line_number":18,"context_line":"etc) an admin would have to go modify the database to get it back to the"},{"line_number":19,"context_line":"right state. This is not a very great user experience, and has been solved for"},{"line_number":20,"context_line":"the normal volume status via the os-reset_state admin action."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Use Cases"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa69d971_2f73d816","line":20,"updated":"2016-01-05 11:25:02.000000000","message":"I think calling this \u0027solved\u0027 in the volume status case is ignoring the experiences of users. Updating the DB without actually verifying that the supplied value is correct does *not* match user expectations. I\"d much rather see a \u0027sync\u0027 call that queries the backend status and updates the DB with the right value, if that is at all possible?","commit_id":"38be98eac5ef605d249bd6966de90db01ff72c29"},{"author":{"_account_id":12924,"name":"Patrick East","email":"east.patrick@gmail.com","username":"patrick.east"},"change_message_id":"203737eb82543f0cfe449894d28442fdc2ed3004","unresolved":false,"context_lines":[{"line_number":17,"context_line":"sync with what Cinder thinks (whether that\u0027s enabled, disabled, failed over,"},{"line_number":18,"context_line":"etc) an admin would have to go modify the database to get it back to the"},{"line_number":19,"context_line":"right state. This is not a very great user experience, and has been solved for"},{"line_number":20,"context_line":"the normal volume status via the os-reset_state admin action."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Use Cases"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da6ed579_321756ef","line":20,"in_reply_to":"da6ed579_2fee0ded","updated":"2016-01-11 23:23:58.000000000","message":"Done","commit_id":"38be98eac5ef605d249bd6966de90db01ff72c29"},{"author":{"_account_id":12924,"name":"Patrick East","email":"east.patrick@gmail.com","username":"patrick.east"},"change_message_id":"14c2bfb8b5df011facafb4f76d0a0b42d49726ec","unresolved":false,"context_lines":[{"line_number":17,"context_line":"sync with what Cinder thinks (whether that\u0027s enabled, disabled, failed over,"},{"line_number":18,"context_line":"etc) an admin would have to go modify the database to get it back to the"},{"line_number":19,"context_line":"right state. This is not a very great user experience, and has been solved for"},{"line_number":20,"context_line":"the normal volume status via the os-reset_state admin action."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Use Cases"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa69d971_4d6db4ca","line":20,"in_reply_to":"fa69d971_2f73d816","updated":"2016-01-06 16:10:40.000000000","message":"I think maybe we are talking about different problems then. I agree it isn\u0027t solved in the sense that there is a magic \u0027fix the volume\u0027 api, and the problem of volumes getting out of sync don\u0027t have a one touch solution. The problem of not being able to *ever* fix the volume without manually updating the db is solved. Thats small piece of the puzzle is what I\u0027m intending to tackle with this.","commit_id":"38be98eac5ef605d249bd6966de90db01ff72c29"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"c1dc4b83c66402702811adfc93539300f3963935","unresolved":false,"context_lines":[{"line_number":17,"context_line":"sync with what Cinder thinks (whether that\u0027s enabled, disabled, failed over,"},{"line_number":18,"context_line":"etc) an admin would have to go modify the database to get it back to the"},{"line_number":19,"context_line":"right state. This is not a very great user experience, and has been solved for"},{"line_number":20,"context_line":"the normal volume status via the os-reset_state admin action."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Use Cases"},{"line_number":23,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da6ed579_2fee0ded","line":20,"in_reply_to":"fa69d971_4d6db4ca","updated":"2016-01-11 22:55:35.000000000","message":"maybe reword this to be a bit more specific about what\u0027s it compares to.  It\u0027s not better or no worse than the normal volume update state change today.","commit_id":"38be98eac5ef605d249bd6966de90db01ff72c29"}]}