Re: [openstack-dev] strange behaviour (possible bug) with nova evacuate
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.frie...@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] strange behaviour (possible bug) with nova evacuate
On 10/03/2013 05:45 AM, Pavel Kravchenco wrote: Hi Chris, You probably encountered this bug: *https://bugs.launchpad.net/nova/+bug/1156269* It been fixed here: https://review.openstack.org/#/c/24600/ Yes, that looks like what I'm seeing. Thanks for the pointer. Btw, what code are you using? I'm currently using Grizzly. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] strange behaviour (possible bug) with nova evacuate
On 10/02/2013 11:42 PM, Lingxian Kong wrote: Hi Chris: Aftering exploring the code, I think there is already clean up on the original compute node, it will check that the instances reported by the driver are still associated with this host. If they are not, they will be destroyed. Please refer to: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L784 Looks like the problem is that I'm using Grizzly. This was fixed in Havana back in April but the fix was never backported. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] strange behaviour (possible bug) with nova evacuate
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] strange behaviour (possible bug) with nova evacuate
Hi Chris: Aftering exploring the code, I think there is already clean up on the original compute node, it will check that the instances reported by the driver are still associated with this host. If they are not, they will be destroyed. Please refer to: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L784 2013/10/3 Chris Friesen chris.frie...@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 __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ** *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: konglingx...@huawei.com; anlin.k...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
