Open Stack

On 1/23/14 1:46 AM, Matthieu Huin wrote:
> Hello Christian,
>
> ----- Original Message -----
>> From: "Christian Schwede" <christian.schwede at enovance.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, "Matthieu
>> Huin" <matthieu.huin at enovance.com>
>> Sent: Wednesday, January 22, 2014 10:47:24 PM
>> Subject: Re: [openstack-dev] [Swift] domain-level quotas
>>
>> Hi Matthieu,
>>
>> Am 22.01.14 20:02, schrieb Matthieu Huin:
>>> The idea is to have a middleware checking a domain's current usage
>>> against a limit set in the configuration before allowing an upload.
>>> The domain id can be extracted from the token, then used to query
>>> keystone for a list of projects belonging to the domain. Swift would
>>> then compute the domain usage in a similar fashion as the way it is
>>> currently done for accounts, and proceed from there.
>>
>> the problem might be to compute the current usage of all accounts within
>> a domain. It won't be a problem if you have only a few accounts in a
>> domain, but with tens, hundreds or even thousands accounts in a domain
>> there will be a performance impact because you need to iterate over all
>> accounts (doing a HEAD on every account) and sum up the total usage.
>
> One might object that this is already a concern when applying quotas
> to potentially huge accounts with lots of containers, although I agree
> that domains add an order of magnitude to this problem.

Swift accounts and containers keep track* of the total object count and 
size, so account/container quotas need only perform a single HEAD 
request to get the current usage. The number of containers per account 
or objects per container doesn't affect the speed with which the quota 
check runs.

Since domains don't map directly to a single entity in Swift, getting 
the usage for a domain requires making O(N) requests to fetch the 
individual usage data. Domain quotas wouldn't just make usage checks "an 
order of magnitude" more costly; they'd take it from roughly constant to 
potentially unbounded.

* subject to eventual consistency, of course