[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