openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #14771
Re: [Keystone] Quotas: LDAP Help
That's the general area I was going to head with the Active Directory backend I'm hacking on. Chris Hoge of UOregon presented today (@ OSCON) on a local keystone hack that they did to enable LDAP AuthN + a fail back to SQL based system for their scientific computing cluster - follows a very similar model.
-joe
On Jul 17, 2012, at 2:16 PM, Tim Bell <Tim.Bell@xxxxxxx> wrote:
> +1 The corporate LDAP should be read-only for a source of user, roles and
> attributes. Updating the corporate LDAP is not an option in many
> environments which can significantly benefit from the structured directory
> information available.
>
> Thus, at minimum, allow a r/o LDAP and local DB store for any openstack
> specific information that needs updating.
>
> Tim
>
>> -----Original Message-----
>> From: openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx
>> [mailto:openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx] On Behalf
>> Of Ryan Lane
>> Sent: 17 July 2012 20:43
>> To: Adam Young
>> Cc: Joseph Heck; openstack
>> Subject: Re: [Openstack] [Keystone] Quotas: LDAP Help
>>
>>> 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
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
Follow ups
References