[openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

2015-02-27 Thread Matthew Booth
Gary Kotton originally posted this bug against the VMware driver: https://bugs.launchpad.net/nova/+bug/1419785 I posted a proposed patch to fix this here: https://review.openstack.org/#/c/158269/1 However, Dan Smith pointed out that the bug can actually be triggered against any driver in a mann

Re: [openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

2015-02-27 Thread Dan Smith
Did we really need another top-level thread for this? > 1. _destroy_evacuated_instances() should do a better job of sanity > checking before performing such a drastic action. I agree, and no amount of hostname checking will actually address this problem. If we don't have a record of an evacuate

Re: [openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

2015-02-27 Thread Daniel P. Berrange
On Fri, Feb 27, 2015 at 04:24:36PM +, Matthew Booth wrote: > Gary Kotton originally posted this bug against the VMware driver: > > https://bugs.launchpad.net/nova/+bug/1419785 > > I posted a proposed patch to fix this here: > > https://review.openstack.org/#/c/158269/1 > > However, Dan Smit

Re: [openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

2015-02-27 Thread Daniel P. Berrange
On Fri, Feb 27, 2015 at 08:57:53AM -0800, Dan Smith wrote: > > Note that in the above case the libvirt driver changed the hypervisor > > identifier despite the fact that the hypervisor had not changed, only > > its communication endpoint. > > I'd argue they're one and the same, and that's just fin

Re: [openstack-dev] [nova] Nova compute will delete all your instances if you change its hostname

2015-02-27 Thread Dan Smith
> The hostname is a unique identifier, however, it isn't a /stable/ > unique identifier because it is determined at the whim of the > administrator. Honestly, I think it's as stable as the administrator wants it to be. At the level of automation that any reasonable deployment will be running, I