)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3b59ff24ac22925c7abaa661ccffe888b4c07ab8","unresolved":false,"context_lines":[{"line_number":34,"context_line":"persisted PCI change as now such change is only persisted at the end"},{"line_number":35,"context_line":"of the migration but still we need to refresh the instance object"},{"line_number":36,"context_line":"during the rollback as the instance object is stale, containing dest"},{"line_number":37,"context_line":"host related PCI information."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Also in case of rescheduling during live migrate if the rescheduling"},{"line_number":40,"context_line":"failed the PCI change needed to be rolled back to the source host by a"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_107cb06f","line":37,"updated":"2020-01-17 17:28:58.000000000","message":"What happens if you\u0027re migrating to/from a compute that is running the old code?","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a4d986acae7d2f1f19e9ce1b7636eb356cd99ece","unresolved":false,"context_lines":[{"line_number":34,"context_line":"persisted PCI change as now such change is only persisted at the end"},{"line_number":35,"context_line":"of the migration but still we need to refresh the instance object"},{"line_number":36,"context_line":"during the rollback as the instance object is stale, containing dest"},{"line_number":37,"context_line":"host related PCI information."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Also in case of rescheduling during live migrate if the rescheduling"},{"line_number":40,"context_line":"failed the PCI change needed to be rolled back to the source host by a"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_4bdfcbd6","line":37,"in_reply_to":"3fa7e38b_107cb06f","updated":"2020-01-20 13:46:18.000000000","message":"If the dest host is running the old code then during the rollback it will persist the stale instance object. \n\nThis data inconsistency does not cause any end user visible side effect as such InstancePCIRequest will be updated again during the next move operation of the instance. But it is ugly that we have invalid data in the db and in the future some operation might want to depend on the fact that the data is in sync.","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3b59ff24ac22925c7abaa661ccffe888b4c07ab8","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Also in case of rescheduling during live migrate if the rescheduling"},{"line_number":40,"context_line":"failed the PCI change needed to be rolled back to the source host by a"},{"line_number":41,"context_line":"specific code. But now those change are never persisted until the"},{"line_number":42,"context_line":"migration finishes so this rollback code can be removed too."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Change-Id: Ied8f96b4e67f79498519931cb6b35dad5288bbb8"},{"line_number":45,"context_line":"blueprint: support-move-ops-with-qos-ports-ussuri"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_30e44c42","line":42,"updated":"2020-01-17 17:28:58.000000000","message":"Same.","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a4d986acae7d2f1f19e9ce1b7636eb356cd99ece","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Also in case of rescheduling during live migrate if the rescheduling"},{"line_number":40,"context_line":"failed the PCI change needed to be rolled back to the source host by a"},{"line_number":41,"context_line":"specific code. But now those change are never persisted until the"},{"line_number":42,"context_line":"migration finishes so this rollback code can be removed too."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Change-Id: Ied8f96b4e67f79498519931cb6b35dad5288bbb8"},{"line_number":45,"context_line":"blueprint: support-move-ops-with-qos-ports-ussuri"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3fa7e38b_0b90f3f2","line":42,"in_reply_to":"3fa7e38b_30e44c42","updated":"2020-01-20 13:46:18.000000000","message":"This part of the change only affect the conductor code the explicit save and the explicit rollback was both done in the LiveMigrationTask so this change does not affect the upgrade.","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"}],"nova/compute/manager.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3b59ff24ac22925c7abaa661ccffe888b4c07ab8","unresolved":false,"context_lines":[{"line_number":8215,"context_line":"                    migration_id\u003dmigration_id, instance_uuid\u003dinstance.uuid,"},{"line_number":8216,"context_line":"                    state\u003dmigration.status, method\u003d\u0027abort live migration\u0027)"},{"line_number":8217,"context_line":"            self.driver.live_migration_abort(instance)"},{"line_number":8218,"context_line":""},{"line_number":8219,"context_line":"        self._notify_live_migrate_abort_end(context, instance)"},{"line_number":8220,"context_line":""},{"line_number":8221,"context_line":"    def _live_migration_cleanup_flags(self, migrate_data):"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_106ef0c7","line":8218,"updated":"2020-01-17 17:28:58.000000000","message":"Random whitespace damage :(","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a4d986acae7d2f1f19e9ce1b7636eb356cd99ece","unresolved":false,"context_lines":[{"line_number":8215,"context_line":"                    migration_id\u003dmigration_id, instance_uuid\u003dinstance.uuid,"},{"line_number":8216,"context_line":"                    state\u003dmigration.status, method\u003d\u0027abort live migration\u0027)"},{"line_number":8217,"context_line":"            self.driver.live_migration_abort(instance)"},{"line_number":8218,"context_line":""},{"line_number":8219,"context_line":"        self._notify_live_migrate_abort_end(context, instance)"},{"line_number":8220,"context_line":""},{"line_number":8221,"context_line":"    def _live_migration_cleanup_flags(self, migrate_data):"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_8be14300","line":8218,"in_reply_to":"3fa7e38b_106ef0c7","updated":"2020-01-20 13:46:18.000000000","message":"Done","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3b59ff24ac22925c7abaa661ccffe888b4c07ab8","unresolved":false,"context_lines":[{"line_number":8656,"context_line":"        # NOTE(gibi): We need to refresh the instance as it might be changed by"},{"line_number":8657,"context_line":"        # the conductor during scheduling based on the selected destination"},{"line_number":8658,"context_line":"        # host. As the migration is rolling back to the source host we don\u0027t"},{"line_number":8659,"context_line":"        # want to persist such change in the DB."},{"line_number":8660,"context_line":"        instance.refresh()"},{"line_number":8661,"context_line":""},{"line_number":8662,"context_line":"        if (isinstance(migrate_data, migrate_data_obj.LiveMigrateData) and"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_5099c8cc","line":8659,"updated":"2020-01-17 17:28:58.000000000","message":"I\u0027m confused. This patch removes the persisting of the pci_device change in conductor, right? What changes are you expecting to refresh here?\n\nThe last sentence here makes it sound like calling save() on our instance might overwrite something in the database if we don\u0027t do this, but that will only happen if our instance object has recorded that field as dirty. Is there some situation where our field will be dirty and outdated? Can you specifically call out what field you\u0027re worried about here in the comment?","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"a4d986acae7d2f1f19e9ce1b7636eb356cd99ece","unresolved":false,"context_lines":[{"line_number":8656,"context_line":"        # NOTE(gibi): We need to refresh the instance as it might be changed by"},{"line_number":8657,"context_line":"        # the conductor during scheduling based on the selected destination"},{"line_number":8658,"context_line":"        # host. As the migration is rolling back to the source host we don\u0027t"},{"line_number":8659,"context_line":"        # want to persist such change in the DB."},{"line_number":8660,"context_line":"        instance.refresh()"},{"line_number":8661,"context_line":""},{"line_number":8662,"context_line":"        if (isinstance(migrate_data, migrate_data_obj.LiveMigrateData) and"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_28185581","line":8659,"in_reply_to":"3fa7e38b_5099c8cc","updated":"2020-01-20 13:46:18.000000000","message":"The instance object is coming from the conductor via RPC. The conductor changed the content of the InstancePCIRequest according to the dest host of the migration but did not persist it. Now if we do not refresh the instance object before we save it below then the InstancePCIRequest change will be persisted to the DB. We don\u0027t want to do that as this is a rollback scenario so the instance is not on the dest host.\n\nWe do want to dirty the pci_requests field of the instance object in the conductor so that if the migration finishes then that change will be automatically persisted to the DB.\n\n\nI\u0027ve added more details to the comment.","commit_id":"4c1b5d133cd22b912f6e39d2691c813bd167d523"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f6d1e7aa947698c8334106d0c833549c836c471f","unresolved":false,"context_lines":[{"line_number":8554,"context_line":"        \"\"\""},{"line_number":8555,"context_line":"        # NOTE(gibi): We need to refresh the instance as it might be changed by"},{"line_number":8556,"context_line":"        # the conductor during scheduling based on the selected destination"},{"line_number":8557,"context_line":"        # host.If the instance has SRIOV ports with resource request then the"},{"line_number":8558,"context_line":"        # LiveMigrationTask._find_destination call updated the"},{"line_number":8559,"context_line":"        # instance.pci_requests.requests[].spec with the SRIOV PF device name"},{"line_number":8560,"context_line":"        # to be used on the destination host. As the migration is rolling back"}],"source_content_type":"text/x-python","patch_set":4,"id":"3fa7e38b_da23eaba","line":8557,"range":{"start_line":8557,"start_character":15,"end_line":8557,"end_character":17},"updated":"2020-01-30 17:24:56.000000000","message":"Missing a space here.","commit_id":"20747a7303ae691ee902c696fb3a76b0f355b5d4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ced6f78584554d11d528571e53cae09e39b2fc84","unresolved":false,"context_lines":[{"line_number":8554,"context_line":"        \"\"\""},{"line_number":8555,"context_line":"        # NOTE(gibi): We need to refresh the instance as it might be changed by"},{"line_number":8556,"context_line":"        # the conductor during scheduling based on the selected destination"},{"line_number":8557,"context_line":"        # host.If the instance has SRIOV ports with resource request then the"},{"line_number":8558,"context_line":"        # LiveMigrationTask._find_destination call updated the"},{"line_number":8559,"context_line":"        # instance.pci_requests.requests[].spec with the SRIOV PF device name"},{"line_number":8560,"context_line":"        # to be used on the destination host. As the migration is rolling back"}],"source_content_type":"text/x-python","patch_set":4,"id":"3fa7e38b_23419da8","line":8557,"range":{"start_line":8557,"start_character":15,"end_line":8557,"end_character":17},"in_reply_to":"3fa7e38b_da23eaba","updated":"2020-02-03 11:46:21.000000000","message":"Done","commit_id":"20747a7303ae691ee902c696fb3a76b0f355b5d4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cf22c7dc7140d468699842de6eadeb110bda8e75","unresolved":false,"context_lines":[{"line_number":8560,"context_line":"        # to be used on the destination host. As the migration is rolling back"},{"line_number":8561,"context_line":"        # to the source host now we don\u0027t want to persist the destination host"},{"line_number":8562,"context_line":"        # related changes in the DB."},{"line_number":8563,"context_line":"        instance.refresh()"},{"line_number":8564,"context_line":""},{"line_number":8565,"context_line":"        if (isinstance(migrate_data, migrate_data_obj.LiveMigrateData) and"},{"line_number":8566,"context_line":"              migrate_data.obj_attr_is_set(\u0027migration\u0027)):"}],"source_content_type":"text/x-python","patch_set":4,"id":"3fa7e38b_f5d4b74e","line":8563,"updated":"2020-01-30 17:26:46.000000000","message":"18:22 \u003c dansmith\u003e gibi: what about checking obj_what_changed() right before the refresh \n                  and asserting that it\u0027s either empty or just contains the pci request \n                  info and logging a warning if not?\n18:23 \u003c dansmith\u003e gibi: in fact if you did that you could avoid the expensive refresh for \n                  everyone else if it\u0027s not SRIOV\n18:23 \u003c gibi\u003e dansmith: I can do that. But I can also extend the refresh() call with an \n              optiona; field list\n18:23 \u003c dansmith\u003e gibi: I\u0027m less excited about the latter just because of the potential \n                  effort in validating it, but it seems like that might be useful\n18:24 \u003c dansmith\u003e gibi: I think the reason we didn\u0027t initially do that is because you may \n                  be creating a franken-instance where you\u0027ve pulled some updates from the \n                  db and not others, which are co-dependent and then would save it back in \n                  an inconsistent state\n18:24 \u003c gibi\u003e dansmith: OK. I will follow your suggestion and check obj_what_changed and \n              log a warning if we would drop other fields than pci\n18:24 \u003c dansmith\u003e gibi: and avoid the refresh if nothing is changed yeah?\n18:24 \u003c gibi\u003e yepp\n18:24 \u003c dansmith\u003e cool","commit_id":"20747a7303ae691ee902c696fb3a76b0f355b5d4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ced6f78584554d11d528571e53cae09e39b2fc84","unresolved":false,"context_lines":[{"line_number":8560,"context_line":"        # to be used on the destination host. As the migration is rolling back"},{"line_number":8561,"context_line":"        # to the source host now we don\u0027t want to persist the destination host"},{"line_number":8562,"context_line":"        # related changes in the DB."},{"line_number":8563,"context_line":"        instance.refresh()"},{"line_number":8564,"context_line":""},{"line_number":8565,"context_line":"        if (isinstance(migrate_data, migrate_data_obj.LiveMigrateData) and"},{"line_number":8566,"context_line":"              migrate_data.obj_attr_is_set(\u0027migration\u0027)):"}],"source_content_type":"text/x-python","patch_set":4,"id":"3fa7e38b_83c5f15f","line":8563,"in_reply_to":"3fa7e38b_518d917b","updated":"2020-02-03 11:46:21.000000000","message":"If I have to prepare for a future instance.save() then I can only re-generate the old pci spec by calling update_pci_request_spec_with_allocated_interface_name() (that will call placement) as the db already contains the value based on the destination host.\n\nHowever I\u0027m not sure I want to prepare my solution against a future change that might or might not happen (i.e. YAGNI). I added test coverage that will fail if a future dev adds an instance.save() to the code path. So it cannot be silently broken. The test_live_migrate_with_qos_port_abort_migration fails if I add an instance.save() before the instance.refresh().\n\nI can do a selective refresh for the pci_requests to avoid big hammer refresh(). (But I still think that refreshing AZ is a good thing here)\n\nDone a selective refresh() of the pci spec only","commit_id":"20747a7303ae691ee902c696fb3a76b0f355b5d4"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5b4c1a8166b3a06c581959d06bae82919649beb9","unresolved":false,"context_lines":[{"line_number":8560,"context_line":"        # to be used on the destination host. As the migration is rolling back"},{"line_number":8561,"context_line":"        # to the source host now we don\u0027t want to persist the destination host"},{"line_number":8562,"context_line":"        # related changes in the DB."},{"line_number":8563,"context_line":"        instance.refresh()"},{"line_number":8564,"context_line":""},{"line_number":8565,"context_line":"        if (isinstance(migrate_data, migrate_data_obj.LiveMigrateData) and"},{"line_number":8566,"context_line":"              migrate_data.obj_attr_is_set(\u0027migration\u0027)):"}],"source_content_type":"text/x-python","patch_set":4,"id":"3fa7e38b_518d917b","line":8563,"in_reply_to":"3fa7e38b_8b82ff01","updated":"2020-01-31 15:04:58.000000000","message":"\u003e So I tested the obj_what_changed() way but there is no record of\n \u003e our InstancePCIRequest.requests[].spec change in any level in the\n \u003e ovo.\n \u003e \n \u003e Runing the func test test_live_migrate_with_qos_port_abort_migration\n \u003e I observer the followings before the instance.refresh() call. Note\n \u003e that in this test there is one InstancePCIRequest (one SRIOV port)\n \u003e with a single pci spec.\n \u003e \n \u003e * instance.obj_what_changed() -\u003e {\u0027flavor\u0027, \u0027availability_zone\u0027}\n \u003e * instance.pci_requests.obj_what_changed() -\u003e set()\n \u003e * instance.pci_requests.requests[0].obj_what_changed() -\u003e set()\n \u003e * instance.pci_requests.requests[0].spec[\u0027parent_ifname\u0027] -\u003e\n \u003e \u0027host2-ens2\u0027\n \u003e \n \u003e Note that in this test host2-ens2 is a PF on the migration\n \u003e destination host, host1-ens2 is the PF on the source host.\n \u003e \n \u003e So while the spec contains changed data we want to revert, the\n \u003e obj_what_changes() facilities cannot be used to detect if such\n \u003e changes was made.\n\nOkay and it looks like we always serialize/save that field on instance.save() whether it has changed or not :(\n\nEither way, synchronization of the dirty flag(s) in the pci_request(s) object(s) definitely look to be broken.\n\n \u003e The availability_zone was modified by the conductor live migration\n \u003e task [1] as well to set the AZ of the target host of the migration.\n \u003e So reverting that during the rollback is the logical thing to do.\n \u003e \n \u003e The flavor being dirty is a more interesting thing. The flavor is\n \u003e marked dirty because it is lazy loaded at rejecet_sev_instance\n \u003e decorator [3] top of the compute.api.live_migrate call [2]. While\n \u003e instance._obj_load_attr has a obj_reset_changes() call at the end\n \u003e it has no effect on the dirtiness of the flavor field. Also right\n \u003e after an instance.save() in the compute.api.live_migrate call [4]\n \u003e the flavor is still marked dirty.\n\nPotentially because nothing else is calling obj_reset_changes() on the flavor itself. ObjectField items are considered dirty if the inner object is dirty, and resetting is only recursive if you ask for it. That recurse-ability was a change in recent years which likely didn\u0027t permeate everywhere.\n\n \u003e Logically the flavor should not change during a live migration and\n \u003e looking at the flavor in the test it does not.  So I think we can\n \u003e ignore that the flavor is dirty. That is a separate bug.\n \u003e \n \u003e In summary I think calling a instance.reset() is necessary as\n\nDo you mean refresh() here?\n\n \u003e i) we don\u0027t know if the pci spec is changed or not\n \u003e ii) there is no way to know what else is really changed due to\n \u003e false positives in obj_what_changed()\n\nI don\u0027t think this statement is true, because if instance.host or something like that was changed, it would be clearly visible. I agree that the flavor being marked as dirty is an issue, but that is clearly a recent regression due to the SEV work, even if the bug is in the lazy load code.\n\n \u003e iii) if something is changed since the last instance.save() in the\n \u003e compute.api.live_migrate call then those changes are due to the\n \u003e anticipation of the new host of the instance and therefore these\n \u003e changes needs to be reverted as the migration is rolling back\n \u003e causing that the anticipated host change does not happen.\n\nPart of what seems wrong to me here is assuming that the instance never gets save()d between starting and failing the live migration. Meaning, I get that may be the case today, but in the future, someone may add something in the destination path that, unrelated to pci_requests, needs to get save()d. So they call instance.save(), which stabs the new pci_requests in there and then makes this refresh do nothing. How can we protect against that?","commit_id":"20747a7303ae691ee902c696fb3a76b0f355b5d4"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"34a7a36eba116d20ad9540457d4ff64ce8aedbbf","unresolved":false,"context_lines":[{"line_number":8560,"context_line":"        # to be used on the destination host. As the migration is rolling back"},{"line_number":8561,"context_line":"        # to the source host now we don\u0027t want to persist the destination host"},{"line_number":8562,"context_line":"        # related changes in the DB."},{"line_number":8563,"context_line":"        instance.refresh()"},{"line_number":8564,"context_line":""},{"line_number":8565,"context_line":"        if (isinstance(migrate_data, migrate_data_obj.LiveMigrateData) and"},{"line_number":8566,"context_line":"              migrate_data.obj_attr_is_set(\u0027migration\u0027)):"}],"source_content_type":"text/x-python","patch_set":4,"id":"3fa7e38b_8b82ff01","line":8563,"in_reply_to":"3fa7e38b_f5d4b74e","updated":"2020-01-31 09:45:42.000000000","message":"So I tested the obj_what_changed() way but there is no record of our InstancePCIRequest.requests[].spec change in any level in the ovo.\n\nRuning the func test test_live_migrate_with_qos_port_abort_migration I observer the followings before the instance.refresh() call. Note that in this test there is one InstancePCIRequest (one SRIOV port) with a single pci spec.\n\n* instance.obj_what_changed() -\u003e {\u0027flavor\u0027, \u0027availability_zone\u0027}\n* instance.pci_requests.obj_what_changed() -\u003e set()\n* instance.pci_requests.requests[0].obj_what_changed() -\u003e set()\n* instance.pci_requests.requests[0].spec[\u0027parent_ifname\u0027] -\u003e \n\u0027host2-ens2\u0027\n\nNote that in this test host2-ens2 is a PF on the migration destination host, host1-ens2 is the PF on the source host. \n\nSo while the spec contains changed data we want to revert, the obj_what_changes() facilities cannot be used to detect if such changes was made.\n\nThe availability_zone was modified by the conductor live migration task [1] as well to set the AZ of the target host of the migration. So reverting that during the rollback is the logical thing to do.\n\nThe flavor being dirty is a more interesting thing. The flavor is marked dirty because it is lazy loaded at rejecet_sev_instance decorator [3] top of the compute.api.live_migrate call [2]. While instance._obj_load_attr has a obj_reset_changes() call at the end it has no effect on the dirtiness of the flavor field. Also right after an instance.save() in the compute.api.live_migrate call [4] the flavor is still marked dirty.\n\nLogically the flavor should not change during a live migration and looking at the flavor in the test it does not.  So I think we can ignore that the flavor is dirty. That is a separate bug.\n\nIn summary I think calling a instance.reset() is necessary as \ni) we don\u0027t know if the pci spec is changed or not\nii) there is no way to know what else is really changed due to false positives in obj_what_changed()\niii) if something is changed since the last instance.save() in the compute.api.live_migrate call then those changes are due to the anticipation of the new host of the instance and therefore these changes needs to be reverted as the migration is rolling back causing that the anticipated host change does not happen.\n\n[1] https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/conductor/tasks/live_migrate.py#L131\n[2] https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/compute/api.py#L4830\n[3] https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/compute/api.py#L236\n[4] https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/compute/api.py#L4848","commit_id":"20747a7303ae691ee902c696fb3a76b0f355b5d4"}]}