)]}'
{"nova/virt/libvirt/driver.py":[{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"ce9d75028075822b9a74e8eb65eb56708eba16e3","unresolved":false,"context_lines":[{"line_number":1610,"context_line":"            #             migration, so we should still disconnect even if"},{"line_number":1611,"context_line":"            #             the instance doesn\u0027t exist here anymore."},{"line_number":1612,"context_line":"            # NOTE(lyarwood): Additionally during LM rollback the destination"},{"line_number":1613,"context_line":"            # domain will be trainsient if the migration did not complete. As a"},{"line_number":1614,"context_line":"            # result we need to ignore failures to detach any devices from the"},{"line_number":1615,"context_line":"            # domain and ensure we disconnect the underlying volume from the"},{"line_number":1616,"context_line":"            # host."}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_5f7c8cb5","line":1613,"updated":"2018-06-29 15:43:47.000000000","message":"s/tranisient/transient/\n\nNit: Although it is clear to you and me, mind rephrasing it as (it a bit more wordy, but more contextful, IMHO):\n\n\"Additionally, during LM rollback, the destination domain will be transient *until* the migration completes successfully.  At which point, the domain will become persistent (because the Nova libvirt driver uses the VIR_MIGRATE_PERSIST_DEST flag):","commit_id":"0808f6e8463cfd36108bd7d9fc0557beac7e07b5"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4161a7975c6203a3da848128d46d88224fdf6b46","unresolved":false,"context_lines":[{"line_number":1627,"context_line":"            # \u003e\u003d 1.3.3 \u0027transient domains do not have any persistent config\u0027."},{"line_number":1628,"context_line":"            # https://libvirt.org/git/?p\u003dlibvirt.git;a\u003dcommit;h\u003d9dc19806f64"},{"line_number":1629,"context_line":"            elif (error_code \u003d\u003d libvirt.VIR_ERR_OPERATION_INVALID and"},{"line_number":1630,"context_line":"                    \"transient domain\" in six.text_type(ex)):"},{"line_number":1631,"context_line":"                LOG.warning(\"Ignoring failure to detach device from transient\""},{"line_number":1632,"context_line":"                            \"domain in order to disconnect the volume.\","},{"line_number":1633,"context_line":"                            instance\u003dinstance)"}],"source_content_type":"text/x-python","patch_set":2,"id":"5f7c97a3_57f3a2e7","line":1630,"range":{"start_line":1630,"start_character":20,"end_line":1630,"end_character":38},"updated":"2018-07-05 23:50:12.000000000","message":"At first glance, I\u0027m concerned this is too generic and could mask legit failures to detach a volume. Looking further, I see that in the case of the guest ignoring the ACPI request, we raise exception.DeviceDetachFailed, so that scenario is okay.\n\nBut what makes it safe to ignore all other errors related to a transient domain detach? The launchpad bug and the commit message are light on detail. We\u0027re not guaranteed to be in the context of a live migration in this method either -- this is just \"detach_volume\".\n\nDoes this string simply need to be more specific or are we so sure no legit error message can contain the words \"transient domain\"? I think we should be careful merging this before we answer these questions.","commit_id":"b3996670618717351b23fe9fee54bb61458b8f42"}]}