openstack team mailing list archive
Mailing list archive
Re: [Keystone] Quotas: LDAP Help
Ryan Lane <rlane@xxxxxxxxxxxxx>, Adam Young <ayoung@xxxxxxxxxx>
Tim Bell <Tim.Bell@xxxxxxx>
Tue, 17 Jul 2012 21:16:06 +0000
Joseph Heck <heckj@xxxxxx>, openstack <openstack@xxxxxxxxxxxxxxxxxxx>
CERN SpamKiller Note: -50
[Openstack] [Keystone] Quotas: LDAP Help
+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
Thus, at minimum, allow a r/o LDAP and local DB store for any openstack
specific information that needs updating.
> -----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
> > 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
> We should only consider storing something in LDAP if it's going to be
> by other applications. LDAP has a strict schema for exactly this purpose.
> 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
> 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
Description: S/MIME cryptographic signature