Open Stack

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.friesen at 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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev