Public bug reported: Currently when using neutron we don't update the binding:host_id during the evacuate code path.
This can cause the evacuation to fail if we go to sleep waiting for events in virt.libvirt.driver.LibvirtDriver._create_domain_and_network(). Since the binding:host_id in neutron is still pointing to the old host, neutron will never send us any events and we will eventually time out. I was able to get the evacuation to update the binding by modifying compute.manager.ComputeManager.rebuild_instance() to add a call to self.network_api.setup_instance_network_on_host() right below the existing call to self.network_api.setup_networks_on_host(). I'm not sure this solution would work for nova network though. It's a bit confusing, currently the networking API has three routines that seem to overlap: setup_networks_on_host() -- this actually does setup or teardown, and is empty for neutron setup_instance_network_on_host() -- this maps to self._update_port_binding_for_instance() for neutron. For nova network it maps to self.migrate_instance_finish() but that doesn't actually seem to do anything. cleanup_instance_network_on_host() -- this is empty for neutron. It maps to self.migrate_instance_start for nova network, but that doesn't actually seem to do anything. It seems like for neutron we use setup_instance_network_on_host() and for nova-network we use setup_networks_on_host() and the rest are not actually used. ** Affects: nova Importance: Undecided Status: New ** Tags: compute network -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1444171 Title: evacuate code path is not updating binding:host_id in neutron Status in OpenStack Compute (Nova): New Bug description: Currently when using neutron we don't update the binding:host_id during the evacuate code path. This can cause the evacuation to fail if we go to sleep waiting for events in virt.libvirt.driver.LibvirtDriver._create_domain_and_network(). Since the binding:host_id in neutron is still pointing to the old host, neutron will never send us any events and we will eventually time out. I was able to get the evacuation to update the binding by modifying compute.manager.ComputeManager.rebuild_instance() to add a call to self.network_api.setup_instance_network_on_host() right below the existing call to self.network_api.setup_networks_on_host(). I'm not sure this solution would work for nova network though. It's a bit confusing, currently the networking API has three routines that seem to overlap: setup_networks_on_host() -- this actually does setup or teardown, and is empty for neutron setup_instance_network_on_host() -- this maps to self._update_port_binding_for_instance() for neutron. For nova network it maps to self.migrate_instance_finish() but that doesn't actually seem to do anything. cleanup_instance_network_on_host() -- this is empty for neutron. It maps to self.migrate_instance_start for nova network, but that doesn't actually seem to do anything. It seems like for neutron we use setup_instance_network_on_host() and for nova-network we use setup_networks_on_host() and the rest are not actually used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1444171/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp