Open Stack

Hi All,

I recently experienced failures getting images from Glance while spawning instances. This step comes after building the networks in the guild sequence. When the Glance failure occurred the instance was cleaned up and rescheduled as expected, but the networks were not cleaned up. On investigation I found that the cleanup code for the networks is in the compute manager's _do_build_run_instance() method as follows:


            # NOTE(comstud): Deallocate networks if the driver wants
            # us to do so.
            if self.driver.deallocate_networks_on_reschedule(instance):
                self._cleanup_allocated_networks(context, instance,
                        requested_networks)

The default behavior in for the deallocate_networks_on_schedule() method defined in ComputeDriver is:

    def deallocate_networks_on_reschedule(self, instance):
        """Does the driver want networks deallocated on reschedule?"""
        return False

Only the Ironic driver over rides this method to return True, so I think this means the networks will not be cleaned up for any other virt driver.



Is this really the desired behavior?



I have filed a bug for this and plan to fix it: https://bugs.launchpad.net/nova/+bug/1410739



My initial thought is to fix this either by making the method in the base class return True or by adding the method to virt drivers returning True (I would expect the former). But I wanted to check if there is a reason for the base class behavior (and so the default behavior) to be *NOT* to clean up the networks?



Paul


Paul Murray
Nova Technical Lead, HP Cloud
+44 117 316 2527

Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150114/5f352e25/attachment.html>