Re: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP)
On January 29, 2015 at 3:19:34 AM, Yuriy Taraday (yorik@gmail.com) wrote: Hello. On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg morgan.fainb...@gmail.com wrote: 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 interest. 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
Re: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP)
-Original Message- From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] Sent: 28 January 2015 21:29 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP) To make it perfectly clear: We are NOT removing nor plan to remove the ability to use LDAP for users and groups in Keystone. NOTE: Please be sure to read the whole email AND FAQ before worrying about the impact of this deprecation. 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. To confirm, CERN are fine with the plans and will move the project data out of LDAP while keeping users and groups in LDAP. We're aiming for this as part of our Juno migration. Now before anyone starts worrying about this please read the whole email and FAQ at the end. Let me be perfectly clear. LDAP assignment is *not* referring to using LDAP for user and groups. That highly popular feature remains in Keystone.This change should have no impact for other users of LDAP in Keystone. 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). 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. FAQ —— Q: Will Keystone still support Users and Groups in LDAP? A: Absolutely! There are no plans to deprecate utilizing LDAP (or Active Directory) to store users and groups. The Keystone team is committed to maintaining and improving the LDAP Identity driver. Q: Will there be a migration from LDAP Assignment to SQL Assignment for the deployers that are still using LDAP Assignment backend? A: Each deployment is highly specific to the LDAP data store used and schema defined by the organization. The Keystone team has spoken with the deployers that have stated they are using LDAP Assignment (and plan to move to SQL assignment). Most deployers using LDAP Assignment already have plans on how to Migrate. The Keystone team will be happy to provide advice (come chat with us in #openstack-keystone on Freenode) but we do not expect to provide a canned script to make the migration happen. We can share our scripts if there are others interested but they would be CERN specific. However, if there is someone else using this, they could act as a base for their migration. Q: Why not just keep Assignment in LDAP as an option, but freeze it like the V2 API? A: We explored this option, but with all of the new functionality (including identity federation), code fixes, and maintenance issues, it just doesn’t make sense from a cloud-interoperability standpoint to maintain a second-class [at best barely implementing feature
Re: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP)
Hello. On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg morgan.fainb...@gmail.com wrote: 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. 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. 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. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
