Open Stack

+1 to what Chris suggested. Zombie state that doesn't affect quota, but
doesn't create more problems by trying to reuse resources that aren't
available. That way we can tell the customer that things are deleted, but
we don't need to break our cloud by screwing up future schedule requests.

-Mike


On Tue, Oct 8, 2013 at 11:58 AM, Joshua Harlow <harlowja at yahoo-inc.com>wrote:

> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131008/a3cdde9d/attachment.html>