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.frie...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
