[openstack-dev] [ironic] New contributor
Hi all I'm looking to start contributing to Ironic, and in fact I did a couple of small patches already which are still waiting to be landed/reviewed. [1] I'm finding it a little hard to find some more reasonable bugs to get started with fixing, so if any of you guys can point me at a few I would appreciate it, or indeed if someone is willing to do more involved mentoring. (I am in the +10 time zone so this may be awkward, sadly) Cheers J PS Some of you may remember me as the original Ubuntu MAAS lead, so I am pretty familiar with bare metal stuff generally. [1] https://review.openstack.org/#/c/449454/ and https://review.openstack.org/#/c/450492/ __ 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
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On 25 July 2015 at 04:02, Adam Young ayo...@redhat.com wrote: This has come up numerous times, as I am sure you are now aware by reading the rest of the thread. Yes indeed :) I was thinking as I wrote it that I can't be the first person with this question. However I think Daviey has shown me that I was misunderstanding how assignment worked, and I suspect that I can do what I need to do already (Thanks Dave!). Having said that, I still think there's value in doing more with groups, more below. A couple points; I've been aware of the hybrid driver for several years. I feel it is a security mistake to copy the users from the system of record (LDAP) into a cache (Keystone) and then tro only trust the values in the cache; if I delete or disable a user in LDAP, that should be the state used, not the cached value. Groups are tricky things. While I've often toyed with what you suggest here, I always come back to the `group` being an identity attribute that exists outside of Keystone, and everything that we do inside of Keystone can be done with existing mechanisms in Keystone itself, especially now that we have Hierarchical Multitenantcy. I've honestly never thought of group being an identity attribute; for me it relates to authorization management — being part of a group grants access to something. Anyway, that's slightly tangential to this discussion. The most common reason for a group is to be able to share access to multiple tenants. This is broken up into a handful of use cases: Right, this is part of the problem, although you could consider it an optimization. A very useful one though. 1. All in one organization, multiple projects 2. Users from a remote organization get mapped in to a local set of projects (but not all...) 3. A virtual organization I'd like to see the problems you are dealing with to evaluate if splitting groups from users makes sense. My situation has several *completely independent* Openstack deployments that wish to share a common identity service (also preferably without having to log in to each, but that will be solved later with federation). Each user may or may not have the same access rights across each deployment, hence the need to fine-tune roles/assignments. In the case where multiple projects exist, are we going to have to specify an assignment for each user to each project? It would be nicer to do this through groups. I'm not sure which of the 3 cases of yours above this maps to, but possibly all of them. We could of course do this through a federated identity service, but this then requires each user to be separately configured in the federation group mapping which is very quickly going to get completely untenable for large numbers of groups and users. The mapping could also map to local users, and that brings me back to the original problem I raised at the start of the thread. TL;DR 1. User assignments to projects will probably work for me. 2. Doing it with groups will be a lot nicer and easier to administer Cheers J __ 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
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On 24 July 2015 at 14:50, Steve Martinelli steve...@ca.ibm.com wrote: The LDAP driver for identity shouldn't require write access to look up groups. It'll only require write access if you want to allow Keystone to create/delete/update new groups. Not sure what you mean by requires an LDAP admin to set up groups separately either. Have any more details you can share? Hi Steve Assuming LDAP access is read-only, group info would need to be set up in the LDAP server itself prior to keystone accessing it. This is not something that many large corporations would be willing to accommodate, which means you'd need to get group data from elsewhere. Hence, my suggestion! __ 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
Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB
On 24 July 2015 at 14:51, Matt Fischer m...@mattfischer.com wrote: Julian, You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql: https://github.com/SUSE-Cloud/keystone-hybrid-backend We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does so keep that in mind. Oh cool, I'll check that out, thanks for the pointer. Ideally I'd like to get something in-tree, but this might be a good start. I know some of the Keystone team has pretty strong opinions about this but it works for us. There's clearly a problem that needs solving, but I'd like to hear the opinions. And nice to run into you again... Likewise! Cheers. __ 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
[openstack-dev] [keystone] LDAP identity driver with groups from local DB
Hello, I am relatively new to Openstack and Keystone so please forgive me any crazy misunderstandings here. One of the problems with the existing LDAP Identity driver that I see is that for group management it needs write access to the LDAP server, or requires an LDAP admin to set up groups separately. Neither of these are palatable to some larger users with corporate LDAP directories, so I'm interested in discussing a solution that would get acceptance from core devs. My initial thoughts are to create a new driver that would store groups and their user memberships in the local keystone database, while continuing to rely on LDAP for user authentication. The advantages of this would be that the standard UI tools could continue to work for group manipulation. This is somewhat parallel with ephemeral federated user group mappings, but that's all done in the json blob which is a bit horrible. (I'd like to see that working with a decent UI some time, perhaps it is solved in the same way) However, one of the other reasons I'm sending this is to gather more ideas to solve this. I'd like to hear from anyone in a similar position, and anyone with input on how to help. Cheers, Julian. __ 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
