)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Compute RPC methods for live migration v2"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"FIXME: Move object change to patch before this"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"This adds the new live migration RPC calls that condutor will use to"},{"line_number":12,"context_line":"drive this process without any RPC communication between the two"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"cc5497e5_ad9648e6","line":9,"updated":"2026-10-05 18:01:17.000000000","message":"Note the objects changed here are just squashed for convenience, but obviously need to be moved out ahead of this.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"}],"nova/compute/manager.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":9103,"context_line":"                                                           block_device_info)"},{"line_number":9104,"context_line":"        result \u003d self._source_can_numa_live_migrate(ctxt, dest_check_data,"},{"line_number":9105,"context_line":"                                                    result)"},{"line_number":9106,"context_line":"        if (\u0027block_migration\u0027 in result and result.block_migration):"},{"line_number":9107,"context_line":"            result.src_disk_info_json \u003d self.driver.get_instance_disk_info("},{"line_number":9108,"context_line":"                instance, block_device_info\u003dblock_device_info)"},{"line_number":9109,"context_line":"        LOG.debug(\u0027source check data is %s\u0027, result)"}],"source_content_type":"text/x-python","patch_set":1,"id":"c3577a63_d553ad57","line":9106,"updated":"2026-10-05 18:01:17.000000000","message":"Agents love to add this sort of thing because they don\u0027t understand o.vos very well and this makes things not break. I\u0027ve removed a bunch of this ambiguity when I see it but I\u0027ll have to make another pass. This is of course related to v2 not supporting this flag at all and the potential for it to be either in this shared check routine.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":10886,"context_line":"        # call, here we wrap _setup_destination_for_live_migration"},{"line_number":10887,"context_line":"        # (which calls driver.pre_live_migration to plug VIFs) in"},{"line_number":10888,"context_line":"        # wait_for_instance_event so we deterministically receive the"},{"line_number":10889,"context_line":"        # events before returning to the conductor."},{"line_number":10890,"context_line":"        events \u003d self._get_neutron_events_for_live_migration(instance)"},{"line_number":10891,"context_line":"        try:"},{"line_number":10892,"context_line":"            timeout \u003d CONF.vif_plugging_timeout"}],"source_content_type":"text/x-python","patch_set":1,"id":"10b5350b_ac2ce426","line":10889,"updated":"2026-10-05 18:01:17.000000000","message":"Major v2 refactor here worth noting. Nothing to do wth cross-cell migration at all. Previously the events for the destination setup were generated by destination-side actions, but events are sent to the source. So the source sets up to wait, calls the destination to do the work, which generates the events, which the source validates. This doesn\u0027t really make any sense and is quite complicated, but just exists that way because neutron events were designed after live migration (v1) was established in the code and so the hokey source-\u003edestination-\u003eneutron-\u003esource-\u003edestination linkage was born.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":10941,"context_line":"        # Start the destination monitor thread. It watches Placement"},{"line_number":10942,"context_line":"        # for migration completion/failure and triggers post/rollback"},{"line_number":10943,"context_line":"        # on this host independently of the source."},{"line_number":10944,"context_line":"        self._start_recorded_task("},{"line_number":10945,"context_line":"            thread_pool_factory.ExecutorType.LIVE_MIGRATION,"},{"line_number":10946,"context_line":"            \u0027live_migration_v2_monitor\u0027, instance, ctxt,"},{"line_number":10947,"context_line":"            self._live_migration_v2_monitor,"}],"source_content_type":"text/x-python","patch_set":1,"id":"a03109f4_3728007e","line":10944,"updated":"2026-10-05 18:01:17.000000000","message":"Today, this records a task to block our live migration and then exits. That task never gets cleaned up until/unless the source calls to us to tell us it is finished (success or failure). Tha leads to this bug:\n\nhttps://bugs.launchpad.net/nova/+bug/2166009\n\nNote the change here that we\u0027re doing the same thing (of blocking graceful shutdown), but starting an actual destination-side monitoring thread which will end eventually based on the outcome of the migration as determined by how the source ultimately reconfigures the allocations in placement.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":10965,"context_line":"        while True:"},{"line_number":10966,"context_line":"            migration_allocs \u003d ("},{"line_number":10967,"context_line":"                self.reportclient.get_allocations_for_consumer("},{"line_number":10968,"context_line":"                    ctxt, migration.uuid))"},{"line_number":10969,"context_line":"            if not migration_allocs:"},{"line_number":10970,"context_line":"                # Migration consumer allocations are gone — the source"},{"line_number":10971,"context_line":"                # has either completed or reverted."}],"source_content_type":"text/x-python","patch_set":1,"id":"6a91c9ad_de43d528","line":10968,"updated":"2026-10-05 18:01:17.000000000","message":"Note that we have more opportunity here than before to make a good decision and/or warn about potential situations that are bad. In v1 we have certain failure paths where the source and destination don\u0027t agree on where the instance ended up, which mostly stems from a loose definition of the cleanup responsibility I think.\n\nFor example, if the destination finds the instance in local libvirt, but the allocations never get convered by the source, we could log and do something. If the source claims the instance was reverted but a local VM remains here, we could do something smart like potentially pause it and log the error so that it\u0027s recoverable instead of leaving the state completely corrupted, etc.\n\nRight now, this only looks at allocations, but I think we have the opportunity to do more, at least forensically. It also gives us a place for the destination to do things after a migration (failed or not) where in v1 we can only do that *if* we\u0027re called by the source.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":10976,"context_line":"                    LOG.info(\u0027Destination monitor detected successful \u0027"},{"line_number":10977,"context_line":"                             \u0027live migration for instance %s\u0027,"},{"line_number":10978,"context_line":"                             instance.uuid)"},{"line_number":10979,"context_line":"                    if migration.cross_cell_move:"},{"line_number":10980,"context_line":"                        # For cross-cell, the dest monitor owns the"},{"line_number":10981,"context_line":"                        # migration record in the target cell."},{"line_number":10982,"context_line":"                        migration.status \u003d \u0027completed\u0027"},{"line_number":10983,"context_line":"                        migration.save()"},{"line_number":10984,"context_line":"                        # The instance was cloned hidden\u003dTrue by"},{"line_number":10985,"context_line":"                        # conductor. Unhide it now that migration"},{"line_number":10986,"context_line":"                        # succeeded so it appears in listings."},{"line_number":10987,"context_line":"                        instance.hidden \u003d False"},{"line_number":10988,"context_line":"                    self._do_post_live_migration_at_destination("},{"line_number":10989,"context_line":"                        ctxt, instance, False)"},{"line_number":10990,"context_line":"                else:"}],"source_content_type":"text/x-python","patch_set":1,"id":"620b83e7_135c3531","line":10987,"range":{"start_line":10979,"start_character":0,"end_line":10987,"end_character":47},"updated":"2026-10-05 18:01:17.000000000","message":"For the success case, this is basically the delta between \"intra-cell\" and \"cross-cell\" migrations.\n\nI point this out because if we were to retain all of the v1 plumbing and just make it work for cross-cell, we have to sprinkle stuff like this all over the varied cleanup paths. By changing how all that process happens, it becomes far cleaner.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b03c65c6604b234c8a7e5be24f144b0830a5fea2","unresolved":true,"context_lines":[{"line_number":11047,"context_line":""},{"line_number":11048,"context_line":"        if not migration.cross_cell_move:"},{"line_number":11049,"context_line":"            return"},{"line_number":11050,"context_line":"        try:"},{"line_number":11051,"context_line":"            instance.destroy(hard_delete\u003dTrue)"},{"line_number":11052,"context_line":"        except Exception:"},{"line_number":11053,"context_line":"            LOG.exception(\u0027Failed to delete destination instance during live \u0027"},{"line_number":11054,"context_line":"                          \u0027migration rollback.\u0027, instance\u003dinstance)"},{"line_number":11055,"context_line":""},{"line_number":11056,"context_line":"    def _require_nw_info_update(self, context, instance):"},{"line_number":11057,"context_line":"        \"\"\"Detect whether there is a mismatch in binding:host_id, or"}],"source_content_type":"text/x-python","patch_set":1,"id":"8e52bfa4_83c15522","line":11054,"range":{"start_line":11050,"start_character":0,"end_line":11054,"end_character":67},"updated":"2026-10-05 18:01:17.000000000","message":"For failed migrations, this is basically the cross/intra cell delta.","commit_id":"fcbc7fc4954a71ad257a2730daabb2467ea42ed8"}]}