Bug 1172305

Summary: [RFE] Support Keystone read-only LDAP configuration with domain-specific identity backends
Product: Red Hat OpenStack Reporter: Nathan Kinder <nkinder>
Component: openstack-puppet-modulesAssignee: Ivan Chavero <ichavero>
Status: CLOSED ERRATA QA Contact: Mike Abrams <mabrams>
Severity: medium Docs Contact:
Priority: high    
Version: 7.0 (Kilo)CC: aberezin, ajeain, dnavale, ichavero, jpena, lbezdick, mburns, rharwood, rmeggins, sclewis, yeylon
Target Milestone: gaKeywords: FutureFeature, ZStream
Target Release: 7.0 (Kilo)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-puppet-modules-2014.2.12-1.el7ost Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-07 15:10:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1172308, 1194779, 1194780, 1195977, 1195978    
Bug Blocks: 1163445, 1194810    

Description Nathan Kinder 2014-12-09 19:50:13 UTC
Keystone has the ability to have domain specific identity backends in Juno.  This functionality can be used to satisfy a commonly requested use-case:

- Service users are kept in a R/W SQL backend (service domain)
- Normal users are kept in a R/O LDAP backend (user domain)

We need the ability to configure Keystone in this manner via Puppet.  The upstream puppet-keystone module does have some LDAP support already, but it has a few problems for this use case:

- R/W LDAP is assumed
- Domain-specific backend configuration is not supported.

Note that domain-specific backend support will also require adding Keystone v3 support to the puppet modules.

Some of this work is already under-way upstream:

  R/O LDAP - https://review.openstack.org/#/c/133601/

Comment 2 Rich Megginson 2014-12-09 20:11:41 UTC
Additional work will be required for using domain specific backends.  Keystone API v3 support will be required.  Work is underway upstream to add this support to the puppet-openstacklib component - https://review.openstack.org/116754 (using aviator REST - requires aviator support in opm https://bugzilla.redhat.com/show_bug.cgi?id=1171352) which will be followed by 
https://review.openstack.org/134843 (use openstackclient instead of aviator, which requires upgrading to python-openstackclient 1.0.0 https://bugzilla.redhat.com/show_bug.cgi?id=1171191).

This is just for the upstream common puppet-keystone module.  We also need the ability to use the keystone::ldap puppet class from the installer.  For example, we need the ability to set and configure LDAP parameters in packstack - https://review.openstack.org/129989

What installer should we target?  Note that StayPuft/ofi/astapor has no support for Keystone LDAP - is that required?

Comment 3 Ivan Chavero 2015-02-06 16:05:19 UTC
The functionality appears to be ready on the keystone side, after checking with Rich we agreed that adding this stuff to the OPM modules and the instsallers might be too risky for A1, Could this be targeted to A2?

Comment 6 Javier Peña 2015-03-09 15:52:19 UTC
This bug requires Keystone v3 support, due to the support for multiple domains. Since complete Keystone v3 support will not be feasible until Kilo, I think we should postpone this bug to a later release.

Comment 7 Nathan Kinder 2015-03-09 16:17:54 UTC
(In reply to Javier Peña from comment #6)
> This bug requires Keystone v3 support, due to the support for multiple
> domains. Since complete Keystone v3 support will not be feasible until Kilo,
> I think we should postpone this bug to a later release.

Agreed.  This will need to be pushed out.  Adjusting flags.

Comment 13 errata-xmlrpc 2015-04-07 15:10:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0789.html