[openstack-dev] [nova] Thoughs please on how to address a problem with mutliple deletes leading to a nova-compute thread pool problem

Dan Genin daniel.genin at jhuapl.edu
Wed Oct 30 14:26:59 UTC 2013


Punishing benign users as a defense against (potentially) malicious 
users sounds like a bad strategy. This should not be a zero-sum game.

On 10/28/2013 02:49 PM, Joshua Harlow wrote:
> 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" <clint at 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 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/eadff8e8/attachment.bin>


More information about the OpenStack-dev mailing list