But there is a difference here that I think needs to be clear. Releasing the resources from nova (in the current way its done) means another individual can take those resources and that causes inconsistencies (bad for deployer).
I think we talked about how we can make this better by putting the resources into a 'not-yet-deleted' state, where they can no be taken. But this has side-effects in itself that need to be thought out carefully, as those resources are potentially still 'active' so a malicious user will now have access to more resources than there quota allows (+1 for malicious user). And if the malicious user is especially malicious they can take advantage of the fact that all the deletes are going into the 'not-yet-deleted' state and they can the DOS your resources (in a way). That¹s why I prefer consistency and just denying the delete, as I believe it is more simple, although as u said, the end-user won't be as 'happy'. On 10/28/13 9:56 AM, "Chris Friesen" <chris.frie...@windriver.com> wrote: >On 10/28/2013 10:30 AM, Joshua Harlow wrote: >> I wish everything was so simple in distributed systems (like >> openstack) but there are real boundaries and limits to doing >> something like a "kill -9" correctly while retaining the consistency >> of the resources in your cloud (any inconsistency costs someone >> $$$). > >Arguably that cost needs to be factored in by the cloud provider as a >cost of doing business. > >As Clint said, once an end-user says "I want to stop using these >resources", they shouldn't be charged for them anymore. If the >provider's system is currently broken and can't properly process the >request right away, that's their problem and not the end user's. > >So if there are technological limitations as to what can be done, you >register that the user wants to clean everything up, you stop charging >them, and then you clean things up as fast as you can behind the scenes. > >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
