Open Stack

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