[Openstack] [Swift][Keystone] Swift Quotas

Endre Karlson endre.karlson at gmail.com
Fri May 4 07:25:31 UTC 2012


Should you mix this into Keystone ? Seems kind of wrong to mix identity
manager with Quotas?

2012/5/4 Everett Toews <everett.toews at cybera.ca>

> Since storing the quota data in Keystone is a prereq for do the quotas in
> Swift, I'm starting there. After digging through the Keystone code a bit
> I've identified at least one issue with storing the quota data per tenant
> for the SQL backend.
>
> In the metadata table both tenant_id and user_id are primary keys. So the
> question is, *within the current design* how do you store some piece of
> metadata per tenant only?
>
> Storing the same quota data per user for a tenant doesn't work because of
> the many-to-many relationship between users and tenants.
>
> Another option is to use a static user_id for rows where you want to store
> metadata per tenant.
> e.g. user_id='per_tenant_metadata',
> tenant_id='55b6d515e00e48c38e2c92d27dc5c03e', data='{"quota": ...}' (I'll
> figure out what the JSON looks like later)
>
> If you retrieved the quotas via SQL it would look something like,
> select data from metadata where user_id='per_tenant_metadata' and
> tenant_id='55b6d515e00e48c38e2c92d27dc5c03e';
>
> This works but doesn't feel like the cleanest solution. Any thoughts on
> this approach?
>
> Of course, stepping outside the current design would yield more options
> but I wanted to look for a solution within the current design first.
>
> Everett
>
> On Tue, May 1, 2012 at 2:04 PM, Everett Toews <everett.toews at cybera.ca>wrote:
>
>> Hi All,
>>
>> I led the session [1] on Swift Quotas at the Summit and I'd appreciate
>> some feedback on the updated spec [2] and blueprint [3]. I also have a
>> couple of design level questions.
>>
>>  1. Should we store the Swift quota data in Keystone?
>>
>> One of the ideas that came out of the session was that we could store the
>> Swift quota data in Keystone. I took a look at Keystone and it appears the
>> best place for this would be in the metada table but it appears to me that
>> it's only accessible via the User Metadata Extension API in Keystone. Is it
>> feasible to store the Swift quota data in Keystone this way? Should we?
>>
>> On a related note, during the Pluggable Tenant Data session [4] led by
>> Phil Day something similar was being discussed for moving Nova quotas to
>> Keystone.
>>
>> 2. Where should the code for Swift quotas live?
>>
>> It was suggested during the session that this code could live in a
>> middleware for Swift. Seems like a reasonable approach to me. I've taken a
>> look at some of the code in /swift/common/middleware and it looks
>> relatively straight-forward. Any thoughts or suggestions on implementing
>> this as middleware?
>>
>> Regards,
>> Everett
>>
>> [1] http://etherpad.openstack.org/SwiftQuotas
>> [2] http://wiki.openstack.org/SwiftQuotas
>> [3] https://blueprints.launchpad.net/swift/+spec/storage-quotas
>> [4] http://etherpad.openstack.org/FolsomPluggableTenantData
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120504/0a58fffe/attachment.html>


More information about the Openstack mailing list