openstack team mailing list archive

[John Dickinson <me@xxxxxx>]

I should also mention the summit session talking about this very topic led by Everett Toews. It's (currently) scheduled for 9am on wednesday.

http://summit.openstack.org/sessions/view/81

--John



On Apr 12, 2012, at 8:51 PM, John Dickinson wrote:

> Swift keeps total bytes, container, and object count (eventually) up-to-date in the account metadata. There are also log processing tools (like slogging - http://github.com/notmyname/slogging) that can provide usage information (including bandwidth) based on swift logs.
> 
> While I think that it's appropriate for swift to generate the usage information (via internal processes or log processing), the appropriate place for quotas is in whatever system handles the concept of a user (normally the auth system). This way quotas are enforced by revoking or limiting access of the auth token.
> 
> --John
> 
> 
> On Apr 12, 2012, at 11:53 AM, Frederik Van Hecke wrote:
> 
>> Hi Kuo,
>> 
>> One option would be to keep the usage information (num files, num bytes, etc) per container / account in an sqlite DB, just like it is done for account and container info.
>> 
>> To avoid having to loop through all data at regular intervals (to update the info), additional logic could be added to the api methods to update the sqlite DB's when new files are added, files are deleted, etc. Such approach will require more lines of code, but will be far less stressful on performance.
>> 
>> (the brute-force approach to loop through it at regular intervals will be hell on performance on large deployments..)
>> 
>> 
>> For data transfer billing based on download / upload amounts, a similar approach could be used.
>> 
>> If no one else is looking into this, I would certainly be willing to help to help get this started.
>> 
>> 
>> Kind regards,
>> Frederik Van Hecke
>> 
>> T:  +32487733713
>> E:  frederik@xxxxxxxxx
>> W: www.cluttr.be
>> 
>> 
>> 
>> 
>> 
>> This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s)named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation.
>> 
>> 
>> 
>> On Thu, Apr 12, 2012 at 17:45, Kuo Hugo <tonytkdk@xxxxxxxxx> wrote:
>> Hi folks , 
>> 
>> I'm thinking about the better approach to manage "an user" or "an account" space usage quota in swift.
>> Is  there any related blueprint or sub-project even an idea around ?
>> Any suggestion of benefits to be an external service or to be a middle-ware in swift-proxy ?
>> 
>> I'm concerning about such feature will reduce the performance of entire Swift environment. 
>> 
>> Appreciate :>
>> 
>> 
>> 
>> -- 
>> +Hugo Kuo+
>> tonytkdk@xxxxxxxxx
>> +886 935004793
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature