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: frede...@cluttr.be >> 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 <tonyt...@gmail.com> 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+ >> tonyt...@gmail.com >> +886 935004793 >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
