openstack team mailing list archive

[Tim Bell <Tim.Bell@xxxxxxx>]

+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

Attachment: smime.p7s
Description: S/MIME cryptographic signature