openstack team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

On 07/25/2012 10:19 AM, Ionuț Arțăriși wrote:
> On 07/17/2012 11:33 PM, Joseph Heck wrote:
> > 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
> > > >
> > > > _______________________________________________
>
> Hi,
>
> I just wanted to add a bit to this thread. We're currently working on 
> a hybrid backend between LDAP and SQL. I have a working version for a 
> specific setup in which the user accounts are stored in LDAP, but 
> tenants and roles are all stored in SQL together with other openstack 
> user accounts such as the nova admin account.
>
> I basically just Frankensteined the two backends together for user 
> processing and left everything else to be handled by the SQL backend. 
> I'd like to hear other people's opinion on this or alternative 
> implementations.

Are tenants completely in the SQL DB?  If so, how to you list tenants 
for a given user?

Do you copy users from LDAP to SQL for anything?


> https://gist.github.com/3176390
>
> -Ionuț
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp