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" <cl...@fewbar.com> 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 >risk. > >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@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
