Sure, convergence model is great and likely how it has to be done.

Its just a question of what is that convergence model :)

I agree that its bad customer service to say 'yes u tried to delete it but
I am charging u anyway' but I think the difference is that the user
actually still has access to those resources when they are not completed
deletion (due to say a network partition). So this makes it a nice feature
for malicious users to take advantage of, freeing there quota while still
have access to the resources that previously existed under that quota. I'd
sure like that if I was a malicious user (free stuff!). Quotas are as u
said 'records of intentions' but they also permit/deny access to further
resources, and its the further resources that are the problem, not the
record of intention (which at its simplest is just a write-ahead-log).

What is stopping that write-ahead-log from being used at/in the billing
'system' and removing 'charges' for deletes that have not completed (if
this is how a deployer wants to operate)?

IMHO, I think this all goes back to having a well defined state-machine in
nova (and elsewhere), where that state-machine can be altered to have
states that may say prefer consistency vs user happiness.

On 10/28/13 9:29 AM, "Clint Byrum" <> wrote:

>Excerpts from Joshua Harlow's message of 2013-10-28 09:01:44 -0700:
>> Except I think the CAP theorem would say that u can't accurately give
>>back there quota under thing like network partitions.
>> If nova-compute and the message queue have a network partition then u
>>can release there quota but can't actually delete there vms. I would
>>actually prefer to not release there quota, but then this should be a
>>deployer decision and not a one size fits all decision (IMHO).
>CAP encourages convergence models to satisfy problems with consistency.
>Quotas and records of allocated resources are records of intention and
>we can converge the physical resources with the expressed intentions
>later. The speed with which you do that is part of the cost of network
>partition failures and should be considered when assessing and mitigating
>It is really bad customer service to tell somebody "Yes I know you've
>asked me to stop charging you, but my equipment has failed so I MUST
>keep charging you." Reminds me of that gym membership I tried to
>cancel... _TRIED_.
>OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to