On January 29, 2015 at 3:19:34 AM, Yuriy Taraday (yorik....@gmail.com) wrote:

On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg <morgan.fainb...@gmail.com> 
LDAP is used in Keystone as a backend for both the Identity (Users and groups) 
and assignments (assigning roles to users) backend.

Where did the LDAP Assignment backend come from? We originally had a single 
backend for Identity (users, groups, etc) and Assignment (Projects/Tenants, 
Domains, Roles, and everything else not-users-and-groups). When we did the 
split of Identity and Assignment we needed to support the organizations that 
deployed everything in the LDAP backend. This required both a driver for 
Identity and Assignment.

 We are planning on keeping support for identity while deprecating support for 
assignment.  There is only one known organization that this will impact (CERN) 
and they have a transition plan in place already.

I can (or actually can't do it here) name quite a few of our customers who do 
use LDAP assignment backend. The issue that is solved by this is data 
replication across data centers. What would be the proposed solution for them? 
MySQL multi-master replication (Galera) is feared to perform badly across DC.

A couple of thoughts on this front: If the remote systems are not updating the 
assignment data, it would be possible to use read-only replication to the 
remote datacenter. Galera performance is actually quite good with local reading 
even with replication across a WAN. 

But more importantly, what are you trying to solve with replicating the data 
across datacenters? More than very limited cases (where Galera would work) 
becomes a very, very difficult system to maintain with a highly complex 
topology that is as likely to be fragile as a mysql replication. 
Multi-master-cross-datacenter replication of LDAP is probably even scarier in 
my opinion. I’d really encourage a move towards using federated Identity 
instead as it helps to encapsulate the data by DC and limit failure domains 
(overall a better design). However, I do get that moving to Federated Identity 
is a complete re-design.

The Problem
The SQL Assignment backend has become significantly more feature rich and due 
to the limitations of the basic LDAP schemas available (most LDAP admins wont 
let someone load custom schemas), the LDAP assignment backend has languished 
and fallen further and further behind. It turns out almost no deployments use 
LDAP to house projects/tenants, domains, roles, etc. A lot of deployments use 
LDAP for users and groups.

We explored many options on this front and it boiled down to three:

1. Try and figure out how to wedge all the new features into a sub-optimal data 
store (basic/standard LDAP schemas)
2. Create a custom schema for LDAP Assignment. This would require convincing 
LDAP admins (or Active Directory admins) to load a custom schema. This also was 
a very large amount of work for a very small deployment base.
3. Deprecate the LDAP Assignment backend and work with the community to support 
(if desired) an out-of-tree LDAP driver (supported by those who need it).

I'd like to note that it is in fact possible to make LDAP backend work even 
with native AD schema without modifications. The only issue that has been 
hanging with LDAP schema from the very beginning of LDAP driver is usage of 
groupOfNames for projects and nesting other objects under it. With some fixes 
we managed to make it work with stock AD schema with no modifications for 
Havana and port that to Icehouse.
I hate to be blunt here, but where has the contribution of these “fixes” been? 

I am disappointed on two fronts:

1) When the surveys for LDAP assignment went out (sent to -dev, -operators, and 
main mailing lists) I received no indication you were using it (in fact I 
received specific information to the contrary). 

2) That these fixes you are speaking of are unknown to me. LDAP Assignment has 
been barely maintained. So far it has been the core team maintaining it with 
input/some help from a single large deployer who has already committed to 
moving away from LDAP-based assignments in Keystone. The maintenance from the 
core team really has been to make sure it didn’t just stop working, no feature 
parity with the other (SQL) backend has even been attempted due to the lack of 

Based upon interest, workload, and general maintainability issues, we have 
opted to deprecate the LDAP Assignment backend. What does this mean?

1. This means effective as of Kilo, the LDAP assignment backend is deprecated 
and Frozen.
1.a. No new code/features will be added to the LDAP Assignment backend.
1.b. Only exception to 1.a is security-related fixes.

2.The LDAP Assignment backend ("[assignment]/driver” config option set to 
“keystone.assignment.backends.ldap.Assignment” or a subclass) will remain 
in-tree with plans to be removed in the “M”-release.
2.a. This is subject to support beyond the “M”-release based upon what the 
keystone development team and community require.

Is there a possibility that this decision will be amended if someone steps up 
to properly maintain LDAP backend? Developing such driver out of main tree 
would be really hard mostly "catch up with mainline" work.
Based upon the information I have I don’t support this staying in-tree unless 
we have a few things (including but not limited to):

* A clear set of stakeholders and maintainers. It is unfair to ask the core 
team to maintain this feature and code base with no support, no clear 
stakeholders, and no feedback that it is a feature that is in use.

* Documented/confirmed use of the driver. I don’t expect you to tell me all 
your customers, I expect that you participate as a stakeholder and resources 
are committed to making it a 1st class assignment backend. This backend has a 
high maintenance cost and (until your response) an extemely small/shrinking 
install base.

As it stands I think stackforge is likely a better place for the driver. I 
don’t want you to need to develop it 100% from scratch. I would *never* 
advocate that. In fact, we should be able to help make sure it is easy to load 
the driver from a package via stackforge (we can improve loading drivers by 
using stevedore etc). You could easily fork-lift the driver to stackforge, and 
I’d even be willing to bet that some help could be provided to help split 
testing apart and make it happen as part of the deprecation.

The big win for it moving to stackforge is that the developers who have a real 
stake in it can really own the code. This allows you to even provide things 
that may be incompatible with the Identity shared-code since it could be 
isolated. Stackforge/out-of-tree is the best way forward based upon information 
we have today.

I am willing to change the direction we’re taking here, but I am setting a high 
bar to keep it in tree.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to