[openstack-dev] strange behaviour (possible bug) with "nova evacuate"

Pavel Kravchenco KPAVEL at il.ibm.com
Thu Oct 3 11:45:53 UTC 2013


Hi Chris,

You probably encountered this bug: 
https://bugs.launchpad.net/nova/+bug/1156269
It been fixed here: https://review.openstack.org/#/c/24600/
Btw, what code are you using?

Thanks,
Pavel

> Date: Wed, 2 Oct 2013 15:30:11 -0600
> From: Chris Friesen <chris.friesen at windriver.com>
> 
> Hi all,
> 
> I posted this on the IRC channel but got no response, so I'll try here.
> 
> Suppose I do the following:
> 
> 1) create an instance (instance files not on shared storage)
> 2) kill its compute node and evacuate the instance to another node
> 3) boot up the original compute node
> 4) kill the second compute node and evacuate back to the first compute 
node
> 
> In step 4 it seems to be failing a check in rebuild_instance() because 
> it finds the old instance file on the disk at/var/lib/nova/instances/. 
>   Is this a bug?  If not, what's the intended behaviour in this case? 
> Surely the admin isn't supposed to manually wipe a compute node before 
> reconnecting it to the network...
> 
> It seems to me that when the original compute node boots up it should 
> recognize that the instance has been evacuated and delete the instance 
> file on the disk.
> 
> Or is the problem that it doesn't know whether the instances are on 
> shared storage (in which case we wouldn't want to delete the instance 
> file) or local storage (in which case we would)?  If this is the case, 
> then maybe we should embed the storage type in the instance itself--this 

> would also let us avoid having to manually specify --on-shared-storage 
> in the "evacuate" call.



> 
> Thanks,
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131003/b37d5953/attachment.html>


More information about the OpenStack-dev mailing list