[openstack-dev] [nova] Networks are not cleaned up in build failure

Andrew Laski andrew.laski at rackspace.com
Wed Jan 14 19:15:42 UTC 2015

On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote:
> 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?

Yes.  Other than when using Ironic there is nothing specific to a 
particular host in the networking setup.  This means it is not necessary 
to deallocate and reallocate networks when an instance is rescheduled, 
so we can avoid the unnecessary work of doing it.

If the instance goes to ERROR then the network will get cleaned up when 
the instance is deleted.
> 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".
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

More information about the OpenStack-dev mailing list