[Openstack] [Keystone] Quotas: LDAP Help

Adam Young ayoung at redhat.com
Tue Jul 17 18:56:11 UTC 2012


On 07/17/2012 02:42 PM, Ryan Lane wrote:
>> I haven't been thinking about quotas, so bear with me here. A few thoughts:
>>
>> Certain deployments might not be able to touch the LDAP backend.  I am
>> thinking specifically where there is a corporate AD/LDAP server.  I tried to
>> keep the scheme dependency simple enough that it could be layered onto a
>> read-only scenario.  If we put quotas into LDAP,  it might break on those
>> deployments.
>>
> Many, many deployments won't be able to. Applications should generally
> assume they are read-only in regards to LDAP.
>
>> I can see that we don't want to define them in the Nova database, as Swift
>> might not have access to that, and swift is going to be one of the primary
>> consumers of Quotas.  I am Assuming Quantum will have them as well.
>>
>> As you are aware, there is no metadata storage in the LDAP driver, instead
>> it is generated from the tenant and role information on the fly.  There is
>> no place to store metadata in "groupOfNames" which is the lowest( common
>> denominator) grouping used for Tenants.  Probably the most correct thing to
>> do would be to use a "seeAlso"  that points to where the quota data is
>> stored.
>>
> Let's try not to force things into attributes if possible.
>
> When LDAP is used, is the SQL backend not used at all? Why not store
> quota info in Keystone's SQL backend, but pull user info from LDAP,
> when enabled?
>
> We should only consider storing something in LDAP if it's going to be
> reused by other applications. LDAP has a strict schema for exactly
> this purpose. If the quota information isn't directly usable by other
> applications we shouldn't store it in LDAP.
>
> Many applications with an LDAP backend also have an SQL backend, and
> use the SQL as primary storage for most things, and as a cache for
> LDAP, if it's used. I think this is likely a sane approach here, as
> well.
>
> - Ryan

Yes, it is possible to use LDAP for Identity and SQL for the other 
things, like Tokens and Policy.  Quotas could be done the same way. You 
just have to extract the Quotas calls out of the Identity Provider.  It 
might make sense to go in Policy, or into its own driver.







More information about the Openstack mailing list