)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"37b99ecc1b247a2cdb2338f8e4a4b8bb582e8e33","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     huanhongda \u003chongda.xun@easystack.cn\u003e"},{"line_number":5,"context_line":"CommitDate: 2019-07-11 15:30:26 +0800"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"[Stable Only] libvirt: Handle volume API failure in post_live_migration"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In commit 5513f48dea529fe4e690f50a462300129594210c, we wrap the Cinder"},{"line_number":10,"context_line":"API calls of manager\u0027s _post_live_migration in a try/except, and logs"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"3fa7e38b_96bc5f6a","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":13},"updated":"2019-09-17 19:46:13.000000000","message":"The commit message should explain somewhere why this is a stable/pike only change. It looks like you\u0027re doing this because I0390c9ff51f49b063f736ca6ef868a4fa782ede5 wasn\u0027t backported to stable/pike and I\u0027m not sure how possible that is, nor how much we\u0027d want to risk doing that since pike is now in extended maintenance mode and will no longer be released.","commit_id":"0b41bca6500e9a3216333256fad2d4f020debef0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"dae8922a112e81b39c1f5cbcd2020eded80e97fd","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     huanhongda \u003chongda.xun@easystack.cn\u003e"},{"line_number":5,"context_line":"CommitDate: 2019-07-11 15:30:26 +0800"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"[Stable Only] libvirt: Handle volume API failure in post_live_migration"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"In commit 5513f48dea529fe4e690f50a462300129594210c, we wrap the Cinder"},{"line_number":10,"context_line":"API calls of manager\u0027s _post_live_migration in a try/except, and logs"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"3fa7e38b_8e77633c","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":13},"in_reply_to":"3fa7e38b_96bc5f6a","updated":"2019-11-07 18:11:36.000000000","message":"\u003e The commit message should explain somewhere why this is a\n \u003e stable/pike only change. It looks like you\u0027re doing this because\n \u003e I0390c9ff51f49b063f736ca6ef868a4fa782ede5 wasn\u0027t backported to\n \u003e stable/pike and I\u0027m not sure how possible that is, nor how much\n \u003e we\u0027d want to risk doing that since pike is now in extended\n \u003e maintenance mode and will no longer be released.\n\nhttps://review.opendev.org/#/c/683008/ has been backported to stable/pike so I think we can drop this now.","commit_id":"0b41bca6500e9a3216333256fad2d4f020debef0"}],"nova/virt/libvirt/driver.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"37b99ecc1b247a2cdb2338f8e4a4b8bb582e8e33","unresolved":false,"context_lines":[{"line_number":7262,"context_line":"                LOG.error(\u0027Initialize the volume connection during \u0027"},{"line_number":7263,"context_line":"                          \u0027post_live_migration on source host failed: %s\u0027,"},{"line_number":7264,"context_line":"                          six.text_type(e), instance\u003dinstance)"},{"line_number":7265,"context_line":"                # From commit b626c0dc7b113365002e743e6de2aeb40121fc81:"},{"line_number":7266,"context_line":"                # NOTE(mdbooth): The block_device_info we were passed was"},{"line_number":7267,"context_line":"                # initialized with BDMs from the source host before they were"},{"line_number":7268,"context_line":"                # updated to point to the destination. We can safely use this"},{"line_number":7269,"context_line":"                # to disconnect the source without re-fetching."},{"line_number":7270,"context_line":"                connection_info \u003d vol[\u0027connection_info\u0027]"},{"line_number":7271,"context_line":"                # Refresh the connector to source host."},{"line_number":7272,"context_line":"                connection_info[\u0027connector\u0027] \u003d connector"}],"source_content_type":"text/x-python","patch_set":5,"id":"3fa7e38b_16a86f1d","line":7269,"range":{"start_line":7265,"start_character":16,"end_line":7269,"end_character":63},"updated":"2019-09-17 19:46:13.000000000","message":"This is not correct at all since that code is not in stable/pike.","commit_id":"0b41bca6500e9a3216333256fad2d4f020debef0"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"37b99ecc1b247a2cdb2338f8e4a4b8bb582e8e33","unresolved":false,"context_lines":[{"line_number":7267,"context_line":"                # initialized with BDMs from the source host before they were"},{"line_number":7268,"context_line":"                # updated to point to the destination. We can safely use this"},{"line_number":7269,"context_line":"                # to disconnect the source without re-fetching."},{"line_number":7270,"context_line":"                connection_info \u003d vol[\u0027connection_info\u0027]"},{"line_number":7271,"context_line":"                # Refresh the connector to source host."},{"line_number":7272,"context_line":"                connection_info[\u0027connector\u0027] \u003d connector"},{"line_number":7273,"context_line":""}],"source_content_type":"text/x-python","patch_set":5,"id":"3fa7e38b_f67fd3a8","line":7270,"updated":"2019-09-17 19:46:13.000000000","message":"In Pike vol[\u0027connection_info\u0027] is actually coming from the connection on the dest host so I\u0027m not sure how safe this is to try on the source host - that\u0027s why we are calling initialize_connection above with the source host connector to get the connection info for the source host volume connection. So _disconnect_volume might work depending on the storage backend, but it might not and we don\u0027t seem to be handling that here, e.g. let\u0027s say we get an error calling initialize_connection and use the dest host connection_info and source host connector but _disconnect_volume fails, would we catch and log an error but not re-raise that back up?","commit_id":"0b41bca6500e9a3216333256fad2d4f020debef0"}]}