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 <[email protected]> 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: [email protected] >> [mailto:[email protected]] 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 : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
