[openstack-dev] [nova] BUG? nova-compute should delete unused instance files on boot
Joshua Harlow
harlowja at yahoo-inc.com
Tue Oct 8 17:58:05 UTC 2013
Sure, basically a way around this is to do migration of the VM's on the
host u are doing maintenance on.
That¹s one way y! has its ops folks work around this.
Another solution is just don't do local_deletes :-P
It sounds like your 'zombie' state would be useful as a way to solve this
also.
To me though any solution that creates 2 sets of the same resources in
your cloud though isn't a good way (which afaik the current local_delete
aims for) as it causes maintenance and operator pain (and needless
problems that a person has to go in and figure out & resolve). I'd rather
have the delete fail, leave the quota of the user alone, and tell the user
the hypervisor where the VM is on is currently under maintenance (ideally
the `host-update` resolves this, as long as its supported on all
hypervisor types). At least that gives a sane operational experience and
doesn't cause support bugs that are hard to resolve.
But maybe this type of action should be more configurable. Allow or
disallow local deletes.
On 10/7/13 11:50 PM, "Chris Friesen" <chris.friesen at windriver.com> wrote:
>On 10/07/2013 05:30 PM, Joshua Harlow wrote:
>> A scenario that I've seen:
>>
>> Take 'nova-compute' down for software upgrade, API still accessible
>>since
>> you want to provide API uptime (aka not taking the whole cluster
>>offline).
>>
>> User Y deletes VM on that hypervisor where nova-compute is currently
>>down,
>> DB locally deletes, at this point VM 'A' is still active but nova thinks
>> its not.
>
>Isn't this sort of thing exactly what "nova host-update --maintenance
>enable <hostname>" was intended for? I.e., push all the VMs off that
>compute node so you can take down the services without causing problems.
>
>Its kind of a pain that the host-update stuff is implemented at the
>hypervisor level though (and isn't available for libvirt), it seems like
>it could be implemented at a more generic level. (And on that note, why
>isn't there a "host" table in the database since we can have multiple
>services running on one host and we might want to take them all down?)
>
>Alternately, maybe we need to have a 2-stage delete, where the VM gets
>put into a "zombie" state in the database and the resources can't be
>reused until the compute service confirms that the VM has been killed.
>
>Chris
>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list