18:00:52 #startmeeting keystone 18:00:53 Meeting started Tue May 7 18:00:52 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:56 The meeting name has been set to 'keystone' 18:01:01 Hello 18:01:45 #topic High priority bugs or immediate issues? 18:01:58 (other than stable/grizzly stuff, which is on the agenda for last) 18:02:02 dolphm, Well, the gate is now fixed 18:02:14 ayoung: bknudson: thanks! ^ 18:02:20 IPv6 and the memcached fixes are in 18:02:31 ayoung: what was the memcache fix? 18:02:40 dolphm, dolphm blackout one version of it 18:02:45 oh the 1.51 thing 18:02:52 dolphm, the fix was done by putting a later version onto the mirrors 18:02:54 hi 18:04:16 dolphm, the only high bug I was aware of was the LDAP domain issue 18:04:32 Anvil4Me~! 18:04:52 fabio: nice pw :) 18:04:55 ha 18:05:04 sorry wrong window :-) 18:05:08 ayoung: cool 18:05:18 dolphm, this one is the one we are going with, right? https://review.openstack.org/#/c/28197/ 18:05:36 i'd like the ldappers to decide that 18:05:48 but that's on the agenda in a minute 18:05:54 cool 18:05:55 or we can just skip to it.. 18:06:08 #topic stable/grizzly 2013.1.1 release and the default domain in LDAP 18:06:15 #link http://lists.openstack.org/pipermail/openstack-stable-maint/2013-May/000611.html 18:06:21 stable/grizzly is happening this week 18:06:36 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting 18:06:38 i asked that keystone 2013.1.1 be held until we get a default domain fix together for ldap 18:06:59 #link https://bugs.launchpad.net/keystone/+bug/1168726 18:07:01 Launchpad bug 1168726 in keystone/grizzly "default_domain_id breaks the ability to map keystone to ldap" [Critical,In progress] 18:07:07 dolphm, I actually mentioned that to apevec as well 18:07:23 so, *a* fix needs to merge ASAP if we're going to do a backport of anything at all 18:07:46 dolphm, whats the review number 18:07:55 topol, gyee please look at https://review.openstack.org/#/c/28197/ 18:07:55 I'll review it this afternoon. 18:07:58 and to re-iterate, my proposed solution is backporting a feature-cut (multi-domain support for ldap) https://review.openstack.org/#/c/28197/ 18:08:05 #link https://review.openstack.org/#/c/28197/ 18:08:09 dolphm, I endorce this approach 18:08:12 endorse 18:08:21 dolphm, I endorse as well 18:08:31 topol: sooner the better 18:08:31 I was able to work around it earlier, just added a domain entry 18:08:50 I will review right after this meeting 18:08:51 bknudson, yes, but it breaks other things that way 18:08:59 bknudson: yeah, jcannava confirmed you could work around it post-config as well 18:09:07 bknudson, if LDAP is read only, there is no field available for domain 18:09:22 I thought it was businessCategory 18:09:28 :) 18:09:32 yes, but breaks our read only 18:09:58 bknudson, mixing two different things 18:10:29 its not the businessCategory mapping; its the need for a default domain or even horizon pukes 18:10:31 dolphm, yeah, I don't think your fix is going to be sufficient 18:10:49 we need to remove businessCategory and the domain field or we still have a broken LDAP 18:10:56 was it spzala 's fix that did that? 18:11:16 ayoung: explain? 18:11:27 ayoung: from config? 18:11:42 dolphm, no, the user and projects objects 18:11:46 Can't you put the domain mapping to businessCategory on the ignore list? 18:11:55 user_domain_id_attribute? 18:12:00 for groups, etc 18:12:03 dolphm, right 18:12:14 so every user in LDAP should be in the default domain 18:12:17 I thought I saw a patch that removed it 18:12:24 bknudson, for now, yes 18:12:36 ayoung, why cant that just be fixed via config? 18:12:42 looks like dolphm's patch does that. 18:13:06 e.g., get_user() calls self._set_default_domain() on it. 18:14:58 so if you were using businessCategory for your domain id, it'd get wiped out. 18:15:07 bknudson, yes 18:15:18 wiped out or ignored? 18:15:58 _set_default_domain is going to overwrite whatever domain_id is in the ref and replace it with the default domain_id. 18:16:42 bknudosn, but what happens with user_domain_id_attribute? 18:17:01 I don't see user_domain_id being wiped out 18:17:08 bknudson: that's how the function behaves, but i don't think it will be overriding anything in the real world? 18:17:10 exactly 18:17:13 topol, OK, I think you are right. We cannot safely remove it. We need to set attribute_ignore on it 18:17:34 ayoung. yes, exactly 18:17:58 and that can be done via config 18:18:14 if domain_id attribute is ignored, does Keystone set user_domain_id to the default domain_id? 18:18:42 topol, so dolphm's patch should probably check for that value instead of blanket removing the domain. 18:18:47 in ldap in wont set it at all 18:19:08 * ayoung not happy with domain_attribute, but oh well 18:19:10 how is a client going to know what the default domain id is? 18:19:11 hmm, i need to update docstrings 18:20:05 erm, so create_user, for example, should be validating that the default domain was specified, and then remove the domain_id attribute before handing off to ldap 18:20:11 i'm not doing that second part atm 18:20:36 dolphm, it can be done another way 18:20:47 there is a field called attrbute_ignore. 18:20:49 I'll link 18:20:54 ayoung: why not fix it now? 18:21:01 thats in the config 18:21:21 I'd think you want to send the domain_id, and let ldap ignore it or not. 18:21:25 and thats how we handle attributes that may or may not map to ldap depending on the schema 18:21:33 https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L251 18:21:38 if you've already deployed against ldap/ad with a real domain object, you shouldn't have to change config to use 2013.1.1 18:21:39 bknudson, AGREED! 18:21:58 if that's the case, then this is unbackportable 18:22:06 dolphm, what if some grizzly early adopter started using LDAP with domains 18:22:23 dolphm, two cases, one they let the domain map two busiensscategory or their equivalent or they use ignore 18:22:26 ayoung: that's the case i'm referring to which i'd like to handle gracefully 18:23:03 if you keep the ability to map to businesscatgory or equivalent you shouldnt break anyone 18:23:25 and then others can use the attribute ignore if they have readonly and it doesnt map 18:23:35 and don't wipe out the domain_id if LDAP returns it. 18:23:38 topol: two users: one has already deployed keystone 2013.1 against ldap/ad and created a domain object, and the other is on folsom, both are migrating to 2013.1.1 18:24:10 and read-only users are currently stuck on folsom 18:24:16 dolphm, so if default_domain is set, and 'user_attribute_ignore' is set... 18:24:29 dosaboy: default_domain what? 18:24:50 so you create a default domain, correct? 18:24:58 it's not created, it's virtual 18:25:06 that has an id attribute, correct? 18:25:30 the virtual domain has it's id set to the default_domain_id 18:26:00 K, so worst case that value gets shoved into businessCategory or equivalent (if they mapped it) 18:26:27 or they can choose to add to the ignore list for a read only ldap with no domain equivalent 18:26:34 I think that's what you'd want. If they ignored it then it doesn't go anywhere. 18:26:42 make sense? 18:26:53 so this patch seems to be doing "too much" 18:27:13 and we dont end up taking away the businessCategory mapping if someone is already using it 18:28:41 topol, it needs to be added to the ignore list for all objects 18:28:55 user, group, project at least... 18:29:02 ayoung: you mean by default? 18:29:32 i'm still lost on why we shouldn't just be stripping the domain_id attribute from all refs on create() 18:29:57 dolphm, you were scared someone was using it. you will break them 18:30:13 every single one of the assignments, too 18:30:30 or you can take it away and see if anyone screams... 18:30:53 bknudson, yes, by default 18:31:22 bknudson, one of the probles is that we don't have an upgrade script for LDAP, so we have no way of knowing. 18:31:35 ayoung: that sounds like a better solution to me. 18:31:37 So it needs to be well documented 18:31:53 bknudson, we need a read only default domain as well, I think 18:32:05 and I don;'t know what will happen if we just attribute ignore it 18:32:15 I like the read-only default domain. 18:32:20 can the daomin field be blank? 18:32:23 I suspect not 18:32:28 ayoung: where? 18:32:29 should we just pull it now and hope no one became dependent on it? 18:32:30 topol, have you tested this? 18:32:59 I have not tested dolphms patch and not tested making it ignore 18:33:03 topol, if you are going to suggest that we "just" do the attribute ignore, you need to, at a minimum, confirm it works. I don;t think it will 18:33:06 topol: not if we can't handle it gracefully, but i don't understand why we would be breaking them by ignoring it (unless they've already deployed multi-domain, you mean?) 18:33:28 dolphm, that was the fear. Im not sure its realistic 18:34:09 dolphm, of the two cases, I think breaking LDAP for 99% of the users is a worse sin than breaking the early adopter that is using LDA domains 18:34:09 we need to ping the operators list on this 18:34:19 but we a damned either way 18:34:21 I rather do death or glory, pull it completely out and feel comfortable we know the code is solid. 18:34:37 ayoung, I agree 18:34:44 ayoung: unfortunately i agree 18:35:01 ayoung: that's a good way to word it, i might steal that 18:35:25 cause frankly its the direction we are heading one domain per ldap so we break them now or break them later when they really are dependent on it 18:35:31 The bug was reported by spzala... but I don't think that's because a customer complained. 18:35:41 no 18:35:50 we found it doing a poc 18:35:56 i found it via helping internal team 18:36:01 actually, I also reported it, as I found it broken when doing a basic LDAP install for the FreeIPA presentation 18:36:28 ok, just making sure that we had a good reason to backport to grizzly. 18:36:29 If we leave the domain attribute there, it needs to be completely ignorable 18:37:04 ayoung, what scary is the combinations we will have to debug if we leave it as an ignorable option or not... 18:37:17 ayoung: can you be more specific? "there" and "ignorable" 18:37:18 topol, agreed. I am in favor of yanking it whole hog 18:37:20 isn't it already ignorable? 18:37:25 bknudson, I doubt it 18:37:36 we end up having to support two yucky options for a long time 18:37:36 bknudson, ignored just means not persisted to the DB 18:37:49 ie. not put into ldap 18:38:15 but if the code depends on that value, we have to do something nasty like populate it from config if the LDAP server is not providing it. HOrrible option 18:38:32 it needs to go 18:38:37 if we get shot either way I rather be shot by the .00001% that already depend on multiple domains for an ldap 18:38:42 we already do that for domain_id in identity v2. 18:38:45 I don;t think we have a choice 18:38:57 bknudson, will that work for V3? 18:38:59 This seems pretty similar 18:39:06 * ayoung doubts it, but would like someone to test 18:39:15 I agree with ayoung. If we pull it now we have maybe one person yell at us 18:39:24 JOe Savak 18:39:32 We wait a year we could really get stuck 18:40:24 you should not hardcode LDAP queries, and just have defaults that can be changed and replacement variables 18:40:46 then a good default configuration taht defines the stuff the way you want it for default 18:40:56 look at postfix support for LDAP if you need inspiration 18:41:09 ayoung, problem with Joe is he hates us now a little or hates us later (when fully dependent on it) a ton 18:41:33 simo, agreed, but there are only limits to what we can do right now 18:41:52 ayoung: right now you need a sane if simpler code 18:42:04 the domain support was not well thought out in the context of LDAP, and needs to be rolled back. 18:42:14 big picture is we dont want to support multiple domains in a single ldap. We either break the bad news to Joe now or later. But either way he will be upset 18:42:48 topol: I think you should not make that decision but for the short term it certainly is better to have less options than have broken ones 18:43:01 I'm sure Joe isn't impressed by how multiple domains is implemented today. 18:43:02 topol, eventually, we can do it via multiple subtrees, just not today 18:43:24 OK, dolphm what do we need to do to make this happen, besides rewrite the patch? 18:43:33 simo, problem is right now it really is broken. Need some time to do it right 18:43:47 ayoung, agreed 18:44:14 topol, are you going to complete the rewrite? 18:44:28 ayoung: i'm not sure i understand the changes i'd need to make, so i'd prefer someone else to volunteer to pick it up? 18:44:32 and by you, I mean spzala, of course 18:44:40 ayoung, rewrite of dolphs patch? 18:44:44 or i need a mean code review to get me going 18:44:52 my opinion - it would be better to have the default LDAP integration be as simple and maintainable as possible, even if that means additional functionality plugged in via contributed code 18:45:11 topol, either that or continue on with spzala 's but removing the domains attribute as well as making sure the domain API is not broken for LDAP 18:45:27 sahdev will help dolphm in any way he wants 18:45:45 i'm not sure why jsavak would care ahead of havana 18:45:47 spzala: topol, yes 18:46:00 want to #action that? 18:46:16 sahdev likes dolphs approach 18:46:30 then there's no #action 18:46:32 I like dolph's approach. as far as I know, domain support for ldap, wasn't complete....so for example, when you create user with domain_id attribute, there was no domain created and user was added to that domain. So how would it break anything? 18:47:04 No 18:47:16 that is not sufficient 18:47:19 necessary yes 18:47:20 like that, if it never works, then its not a bug :) 18:47:33 but we need to make sure that if the domain attribute remains, it can be ignored 18:47:33 ayoung: be careful about backportability 18:47:51 i'd like to just ignore it 100% 18:48:04 who decides backportability? 18:48:09 dolphm, someone needs to confirm it works. 18:48:11 stable maintenance team 18:48:14 dolphm, was your code on a path to ignore it? 18:48:15 I doubt that is the case 18:48:16 I've seen reviews in stable where they just say the change is too bit. 18:48:22 too big. 18:48:43 bknudson: +1 18:49:20 I think they would reject dolphm's patch, but I'm just guessing. 18:49:41 I think we have a broken impl, even with dolph's patch 18:49:48 suspect 18:49:57 bknudson: i wouldn't be surprised, but stakeholders need to beg either way 18:50:05 probably broken even without dolphm's patch, too. 18:50:13 I'll confirm 18:50:18 ayoung: can you propose a follow up fix? 18:50:23 sahdev's original pathc was much smaller 18:50:37 what was the original patch? 18:50:47 wasnt pretty but small and got the job done 18:50:53 is this the one to add domain with keystone-manage? 18:50:58 topol: my patch was to return a default domain (virtual one) if one is not created 18:51:11 #link https://review.openstack.org/#/c/27364/ 18:51:28 ayoung: thanks 18:51:34 it failed jenkins so no one looked at it. 18:51:36 spzala, what does that do if there is no attribute available to map to the domain id? 18:52:51 bknudson, that was a jenkins bug I believe 18:52:58 ayoung: the patch was on providing our conceptual domain 18:53:14 bknudson: yes, that was due to 'token' bug 18:53:27 that failed jenkins for many patches 18:53:38 what if sahdev ran his patch and did a fullr egression with domain_id_atrribute being ignored? 18:54:04 so, 8 minutes left... we need a strong consensus to backport anything here... if we don't have a consensus, i'd recommend that we leave stable/grizzly broken and think about how to move stable/folsom deployments to havana, or even publish a "fixed" driver outside of the openstack release cycle that those users can pick up 18:54:43 dolphm, I say to let spzala take it and run with it 18:55:00 and I will be involved on the approach 18:55:17 ayoung: go with my patch? with ignore attribute? 18:55:51 spzala, yes plus you need to set the attribute to something that doesn exist. busineesssCatagory might not even be there on the back end 18:56:22 ayoung doesnt exist is guarenteed to break. I dont understand 18:56:25 dolphm, we'll let you know shortly if this is going to work 18:56:41 topol, then we need to go further...lets just agree to work on it for now. 18:56:43 ayoung: thanks. hmmm... I didn't get it either 18:56:56 I think we're at least headed to not backporting this for the stable/grizzly 2013.1.1 18:57:00 i'd also suggest considering splitting the ldap driver into drivers that serve more specific use cases, so serving one specific use case is much less likely to break others moving forward 18:57:06 ayoung, I just dont understand what you mean 18:57:35 dolphm: as part of https://wiki.openstack.org/wiki/MessageSecurity I need a key server and I am starting with building one in keystone, I have a couple of q.s about that, you think there is time ? 18:57:42 topol, that is fine, I can explain later...we have 3 minutes left in the meeting 18:57:43 a read-only LDAP driver would be nice. 18:57:45 dolphm: pluggable LDAP drivers? 18:58:16 simo: yes, i have an opinion... contribute to https://github.com/cloudkeep/barbican 18:58:19 morganfainberg: the LDAP driver is a plugin. 18:58:27 dolphm: unrelated 18:58:39 bknudson: oh right. ugh. i came into this a bit late, brain is not 100%, sorry. 18:58:46 100% firing yet* 18:58:49 morganfainberg: multiple ldap drivers 18:58:59 dolphm: right, makes sense. 18:59:04 like ldap.ReadOnlyDriver, etc 18:59:07 simo, dolphm lets move this discussion to #openstack-dev. We are not going to finish it here and now 18:59:09 sahdev will investigate and will try fulll regression with domain_id_atrtribute ignored and will report back. patch will be small. and then others folks call whether it meets backporting guidleines 18:59:09 dolphm: but if you feel strongly I can see 18:59:13 #endmeeting