)]}'
{"cinder/backup/manager.py":[{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"79308d4eeb12ad01e7f07768d15d335343c11912","unresolved":false,"context_lines":[{"line_number":242,"context_line":"        for attachment in attachments:"},{"line_number":243,"context_line":"            if (attachment[\u0027attached_host\u0027] \u003d\u003d self.host and"},{"line_number":244,"context_line":"                    attachment[\u0027instance_uuid\u0027] is None):"},{"line_number":245,"context_line":"                        mgr.detach_volume(ctxt, volume[\u0027id\u0027],"},{"line_number":246,"context_line":"                                          attachment[\u0027id\u0027])"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"    def _cleanup_temp_volumes_snapshots(self, backups):"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a4dcd0f_4a4b1460","line":245,"updated":"2015-08-14 04:36:03.000000000","message":"Also, if you are intending to actually detach a volume from a host, you will need to do more than call detach_volume.   All detach_volume does is a DB updated basically.","commit_id":"99d6921277146ee5a6678512329d8b52fbbdb97c"},{"author":{"_account_id":170,"name":"Mike Perez","email":"thingee@gmail.com","username":"thingee"},"change_message_id":"900c220e74b19937d207e85f6e3ee3ae9b92540a","unresolved":false,"context_lines":[{"line_number":242,"context_line":"        for attachment in attachments:"},{"line_number":243,"context_line":"            if (attachment[\u0027attached_host\u0027] \u003d\u003d self.host and"},{"line_number":244,"context_line":"                    attachment[\u0027instance_uuid\u0027] is None):"},{"line_number":245,"context_line":"                        mgr.detach_volume(ctxt, volume[\u0027id\u0027],"},{"line_number":246,"context_line":"                                          attachment[\u0027id\u0027])"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"    def _cleanup_temp_volumes_snapshots(self, backups):"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a4dcd0f_f5e2819f","line":245,"updated":"2015-08-11 23:25:17.000000000","message":"This should be resilient to detach failures of a particular volume, skip db update, and move onto the next volume.","commit_id":"99d6921277146ee5a6678512329d8b52fbbdb97c"},{"author":{"_account_id":9003,"name":"Tom Barron","email":"tpb@dyncloud.net","username":"tbarron"},"change_message_id":"bf899c1edb7e8808ccd847139cc72c51e483bc87","unresolved":false,"context_lines":[{"line_number":242,"context_line":"        for attachment in attachments:"},{"line_number":243,"context_line":"            if (attachment[\u0027attached_host\u0027] \u003d\u003d self.host and"},{"line_number":244,"context_line":"                    attachment[\u0027instance_uuid\u0027] is None):"},{"line_number":245,"context_line":"                        mgr.detach_volume(ctxt, volume[\u0027id\u0027],"},{"line_number":246,"context_line":"                                          attachment[\u0027id\u0027])"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"    def _cleanup_temp_volumes_snapshots(self, backups):"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a4dcd0f_540deee6","line":245,"in_reply_to":"1a4dcd0f_4a4b1460","updated":"2015-08-14 09:48:52.000000000","message":"So all these issues were here (lines 229ff) before this proposed patch.  I would like to address them in a followup patch and in the mean time merge this change, which aims only to ensure that the volume cleanup is done even if there are no attachments.","commit_id":"99d6921277146ee5a6678512329d8b52fbbdb97c"},{"author":{"_account_id":9003,"name":"Tom Barron","email":"tpb@dyncloud.net","username":"tbarron"},"change_message_id":"bb355ef3b4fc816aeeb0f3a2b0bd867883b89b16","unresolved":false,"context_lines":[{"line_number":242,"context_line":"        for attachment in attachments:"},{"line_number":243,"context_line":"            if (attachment[\u0027attached_host\u0027] \u003d\u003d self.host and"},{"line_number":244,"context_line":"                    attachment[\u0027instance_uuid\u0027] is None):"},{"line_number":245,"context_line":"                        mgr.detach_volume(ctxt, volume[\u0027id\u0027],"},{"line_number":246,"context_line":"                                          attachment[\u0027id\u0027])"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"    def _cleanup_temp_volumes_snapshots(self, backups):"}],"source_content_type":"text/x-python","patch_set":2,"id":"1a4dcd0f_5053436b","line":245,"in_reply_to":"1a4dcd0f_f5e2819f","updated":"2015-08-12 00:20:52.000000000","message":"I wonder if I should just put a \u0027try:\u0027 between lines 200 and 201 and then follow line 217 with a bare except (with a LOG and continue).  Theory behind this broad try-except is that we should not prevent startup of the backup service because of a failure in initialization cleanup.\n\nThen we could do the same thing for the backup loops at 222 and 254.\n\nWonder if I should tackle these as a followup patch.  The lack of resilience in these cleanups is not new with this bug fix.","commit_id":"99d6921277146ee5a6678512329d8b52fbbdb97c"}]}