18:00:08 <dolphm> #startmeeting keystone 18:00:09 <openstack> Meeting started Tue Mar 19 18:00:08 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:12 <openstack> The meeting name has been set to 'keystone' 18:00:28 <dwaite> don't know whether its better to be 55 minutes early or 5 minutes late 18:00:40 <ayoung> \O/ 18:00:47 <dolphm> i totally missed last weeks meeting 18:00:58 <dolphm> partly due to time change and partly due to being pulled away from my desk 18:01:11 <dolphm> anyway, hola everyone 18:01:20 <topol> Hi 18:01:23 <spzala> Hi all! 18:01:23 <henrynash> hi 18:01:25 <gyee> \o 18:01:26 <stevemar> Howdy 18:01:26 <[1]fabio> hi 18:01:27 <dolphm> heckj: thanks for sticking around :) 18:01:27 <bknudson> hi 18:01:32 <dolphm> henrynash: /salute 18:01:43 <henrynash> likwwise :-) 18:01:44 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:17 <dolphm> ayoung: thanks :P 18:02:31 <henrynash> maybe round cyber-applause is appropriate for Dolph…..and a thank you to Joe 18:02:31 <dolphm> #topic RC1 bugs 18:02:37 <dolphm> #link https://launchpad.net/keystone/+milestone/grizzly-rc1 18:02:50 <topol> Agreed!!! 18:03:05 <dolphm> lol thanks everyone 18:03:13 <ayoung> thanks to everyone involved. dolphm I especailly thnk you for taking on the additional work that I have no desire to do, and henrynash for being willing to do so 18:03:33 <dolphm> ayoung: appreciated 18:03:45 <ayoung> dolphm, before we do that list, can we take a quick scan through the open bugs to see if there is anything that should be on there that isn't? 18:04:35 <dolphm> ayoung: so, i ran through the remaining bugs this morning, i didn't see anything that should block RC 18:05:03 <gyee> dolphm, I think we still have a bug on the v2 v3 intermix for non default domains 18:05:03 <ayoung> dolphm, wasthat before or after I noticed the timeout isssue? 18:05:06 <gyee> but I need to confirm first 18:05:08 <dolphm> if anyone is aware of a bug that is not targetted toward RC1 that should be, please mention it / tag it / target it / etc 18:05:24 <dolphm> ayoung: i assume before 18:05:34 <dolphm> gyee: another bug? 18:05:34 <gyee> we shouldn't be able to validate token using v2 for non default domains 18:05:45 <dolphm> gyee: +1 18:05:45 <gyee> dolphm, I need to confirm it first 18:06:11 <dolphm> the response to such a request wouldn't make sense on v2 / would cause issues with clients depending on tenant name, etc 18:06:25 <gyee> right 18:06:27 <bknudson> I'd like to see this one fixed: https://bugs.launchpad.net/keystone/+bug/1092187 18:06:28 <uvirtbot> Launchpad bug 1092187 in keystone "LDAP implementation incomplete for User Groups" [Undecided,In progress] 18:06:43 <gyee> dolphm, I am also concerned with Swift ACLs and nova client migration 18:06:51 <gyee> novarc is using tenant name instead of tenant ID 18:06:57 <bknudson> because without it, LDAP identity backend returns 501 Not Implemented for authentication 18:07:10 <dolphm> gyee: that's also consuming v2 specifically, correct? 18:07:20 <topol> bknudson, thats sahdev's I think it got red x'd 18:07:21 <dolphm> gyee: so it tenant name would assume default domain 18:07:29 <gyee> dolphm, correct, we need figure out a migration path 18:07:46 <dolphm> gyee: is there an issue on the keystone side though? 18:07:52 <topol> sahdev, how close are you on 1092187 18:07:53 <gyee> dolphm, no 18:07:58 <spzala> btopol: yes, that's true! 18:08:07 <gyee> just nova and swift migration to consume v3 18:08:08 <dolphm> gyee: my goal for keystoneclient is to assume v3 if a domain is specified, for example... could the same apply there? 18:08:25 <spzala> btopol: I believe it's done. 18:08:27 <topol> sahdev, are you done with 1092187? 18:08:34 <dolphm> bug 1092187 18:08:35 <uvirtbot> Launchpad bug 1092187 in keystone "LDAP implementation incomplete for User Groups" [Undecided,In progress] https://launchpad.net/bugs/1092187 18:08:39 <topol> sahdev, OK 18:09:36 <topol> so code is there for review. dolphm, I believe it was feeling like a feature as opposed to a bug so you red x'd it 18:09:41 <dolphm> topol: does this need to block RC1? 18:09:51 <dolphm> there's a merge there 18:10:07 <topol> ll let bknudson answer 18:10:15 <topol> he's asking for it 18:10:26 <bknudson> I don't think it needs to block rc1 18:10:36 <bknudson> as long as there's another rc or something it can block. 18:10:43 <dolphm> bknudson: spzala: should a new bug be filed? the current one at least needs to be revised to indicate what's lacking 18:11:14 <dolphm> bknudson: RC is a potential grizzly release, so that's not really feasible 18:11:22 <dolphm> bknudson: at least, not a guarantee 18:11:23 <spzala> dolphm: sure, can do that. 18:11:59 <bknudson> dolphm: I think the bug says what the problem is... the LDAP implementation isn't complete... since it's not complete something isn't implemented so it returns 501. 18:12:22 <dolphm> bknudson: that's super vague though -- what's broken / missing? 18:12:31 <bknudson> groups support 18:12:44 <spzala> dolphm: the bug provides supprt for group crud, add/delete users in group, list groups etc. and also domain crud 18:12:45 <bknudson> I don't have a problem with a new bug 18:12:54 <ayoung> Ah..yeah. Groups. 18:13:04 <ayoung> I thought we had acked that a long time ago. 18:13:16 <gyee> LDAP is natural for groups :) 18:13:17 <dolphm> the current ldap solution is sufficient for v2 controllers, correct? 18:13:52 <topol> dolphm, yes I believe so. At least all the live regressions ldap tests run thanks to crazed 18:13:54 <spzala> ayoung: this is one is for LDAP. The group support was done for sql and kvs. 18:14:47 <topol> dolphm, and all the v2 controller stuff already worked 18:14:52 <dolphm> i'd vote for shipping grizzly without ldap support for v3, it's a bit late to "fix" that 18:15:12 <bknudson> When I configure the LDAP backend using devstack, I get 501 Not Implemented from keystone token-get. 18:15:39 <dolphm> bknudson: know which driver call is triggering that, specifically? 18:15:47 <gyee> bknudson, LDAP is meant for highly static data 18:15:51 <gyee> token is not static data 18:15:51 <dolphm> i don't think a backtrace would be logged specifically 18:16:10 <dolphm> gyee: there is no token driver for ldap, but auth consumes identity_api which is implemented by ldap 18:16:18 <dolphm> any driver call there could cause a 501 18:16:23 <gyee> dolphm, there shouldn't be 18:16:42 <gyee> token is not static data and shouldn't be stored in LDAP 18:16:43 <ayoung> spzala, I was referringto LDAP specifically 18:16:45 <bknudson> dolphm: I'll look for the function, I was just trying this yesterday. 18:16:49 <dolphm> gyee: agree 18:16:58 <ayoung> spzala, the issue was how users are assigned, and what objectclass to use 18:17:01 <spzala> ayoung: :) Ah... 18:17:16 <spzala> ayoung: yes 18:17:39 <ayoung> spzala, so if we use groupOfName, users go in member, but some of the LDAP servers won't allow the roles to be assigned under it 18:17:48 <ayoung> alternative was to use OU 18:18:22 <spzala> ayoung: hmmm... the fix I have submitted for review is using groupOfName 18:18:23 <ayoung> I think the review for that closed long enough ago due to a -1 that it is off the report...let me see if I can find it 18:18:43 <dolphm> i'd like to have a patch *ready* to be merged to grizzly, and then ask ttx for permission -- this blurring the lines between bug and feature freeze extension 18:18:50 <spzala> ayoung: OK #link https://review.openstack.org/#/c/22624/ 18:19:11 <dolphm> spzala: apparently i'm already blocking it :P 18:19:20 <ayoung> how am I not on that one? 18:19:31 <spzala> dolphm: :) yes 18:19:32 <dolphm> spzala: is this ready to merge & satisfy ldap support for v3, in your opinion? 18:19:36 <gyee> dolphm, what's the deadline for rc1? 18:19:41 <dolphm> gyee: asap 18:19:45 <spzala> ayoung: ah, sorry about that. 18:19:45 <gyee> ha 18:19:50 <dolphm> #link http://old-wiki.openstack.org/release/rc/ 18:19:59 <dolphm> the race to rc1 ^ :) 18:20:07 <spzala> dolphm: yes, I think so. I have tested it with fake and real ldap 18:20:13 <dolphm> spzala: appreciated 18:20:14 <gyee> lets do this! 18:20:31 <spzala> dolphm: no problem! 18:20:34 <dolphm> ttx: do i need to ping you on list for ultra late FFE or can i drag you into our meeting? 18:20:36 <ayoung> spzala, that might work for OpenLDAP. Won't work for AD 18:20:44 <spzala> ayoung: I didn't realize about it 18:20:58 <spzala> ayoung: but adding you as reviewer now 18:20:59 <ayoung> spzala, I think that is near to identical to an Nack review...looking 18:21:05 <ayoung> spzala, already did 18:21:17 <gyee> whoever uses AD will have to pay the consultants :) 18:21:18 <spzala> ayoung: :) that was quick. Thanks! 18:21:35 <dolphm> #action dolphm to ask for FFE for https://review.openstack.org/#/c/22624/ 18:22:04 <topol> ayoung, does he just need to change an objectclass choice for AD? 18:22:10 <ayoung> THis should be brought back to life, BTW. spzala want to take it? https://review.openstack.org/#/c/22558/ 18:22:16 <dolphm> #action gyee to test for non-default domain token validation on v2 18:22:18 <ayoung> topol, define the word "just" 18:22:36 <spzala> ayoung: sure 18:23:07 <gyee> dolphm, I should have that done today 18:23:25 <dolphm> gyee: awesome 18:23:42 <topol> ayoung, Im missing something. What would need to change? 18:24:00 <dolphm> #topic RC blocker: domain validation 18:24:02 <dolphm> #link https://review.openstack.org/#/c/24753/ 18:24:08 <dolphm> henrynash: just want to check in on status 18:24:17 <ayoung> topol, looking. THis might have been resolved...I remember the problem, but not if we came to a solution... 18:24:30 <bknudson> Running in the debugger, the exception is thrown from /opt/stack/keystone/keystone/identity/core.py(581)list_groups_for_user() 18:24:35 <dolphm> henrynash: any issues, need help, etc? 18:24:36 <bknudson> keystone.token.controllers _get_group_metadata_ref() calls self.identity_api.list_groups_for_user, 18:24:36 <bknudson> and the LDAP backend doesn't implement list_groups_for_user 18:24:49 <henrynash> dolphm: so main one I am working on is Big 1130236 18:24:55 <henrynash> bug 1130236 18:24:56 <dolphm> bug 1130236 18:24:57 <bknudson> dolphm: ^ that's what's missing, list_groups_for_user. 18:24:57 <uvirtbot> Launchpad bug 1130236 in keystone "Domains are not validated on authentication" [High,In progress] https://launchpad.net/bugs/1130236 18:24:58 <topol> ayoung, I thought you and Jose agreed on the schema and put it in a blueprint 18:25:19 <ayoung> topol, sounds right...I haven't thought about this in a while, and wasn't tracking it actively 18:25:31 <henrynash> dophm: just struggling to get various tests to function, although found a few interesting issues along the way 18:26:03 <dolphm> henrynash: can you post a revised WIP? i should have time to poke at it later today as well 18:26:10 <henrynash> (e.g. we don't to a copy when we do a get from our kvs backend…so you can change the values without doing a set!_ 18:26:21 <henrynash> dolphm: yes, will do tonight 18:26:47 <henrynash> dolphm: in fact, I;ll do it in the next 30 mins 18:26:51 <topol> ayoung, https://blueprints.launchpad.net/keystone/+spec/ldap-groups 18:26:54 <dolphm> henrynash: awesome 18:27:05 <ayoung> topol, thank you, launchpad was mocking me 18:27:13 <henrynash> dolphm: two other bugs on my list I am suggesting we don't fix. 18:27:23 <henrynash> bug 1153645 18:27:24 <uvirtbot> Launchpad bug 1153645 in keystone "Deleting a role should revoke any tokens associated with it" [High,New] https://launchpad.net/bugs/1153645 18:27:56 <henrynash> working around is that if you remove a rol form someone explicitly, then we DO revoke tokens 18:28:12 <henrynash> its just deleting the role itself, that doesn't revoke 18:28:43 <henrynash> bug 1125046 18:28:44 <uvirtbot> Launchpad bug 1125046 in keystone "Downward migration from separate domain name spaces can cause name clashes" [Medium,Triaged] https://launchpad.net/bugs/1125046 18:28:46 <dolphm> henrynash: i'm thinking that should be marked as a public security issue 18:29:22 <henrynash> dolphm: probably tru…we definitely fix it as soon as possible, just don;t think its an rc1 blocker 18:29:45 <dolphm> the downward migration one probably shouldn't block rc either 18:30:00 <henrynash> dolphn: agreed 18:30:21 <ayoung> spzala, OK I am back tracking. If the powers that be are OK with pushing in groups for LDAP, I can ACK the review...I need to look a little closer at it before formally doing so, but the approach looks OK 18:30:29 <henrynash> gyee: here's one we could clear up: bug 1154072 18:30:30 <uvirtbot> Launchpad bug 1154072 in keystone "Auth_token middleware should cope with no response from "Get versions"" [Medium,New] https://launchpad.net/bugs/1154072 18:30:31 <dolphm> ayoung: does bug 1153645 overlap with one you filed? 18:30:32 <uvirtbot> Launchpad bug 1153645 in keystone "Deleting a role should revoke any tokens associated with it" [High,New] https://launchpad.net/bugs/1153645 18:30:55 <ayoung> dolphm, no, mine was token to token 18:30:56 <spzala> ayoung: OK, sounds great. Thanks! 18:31:19 <dolphm> ayoung: cast your review vote for ldap groups -- i'd like to have two +2's on it with my -2 before i bug ttx 18:31:23 <henrynash> gyee: I made a comment on it for you….as to whether we really need this….if not, let's abandon 18:31:25 <ayoung> dolphm, I thought we already delete all tokens upon removing a role 18:31:32 <gyee> henrynash, sure 18:31:35 <dolphm> ayoung: so we can switch to approve with permission asap 18:31:43 <henrynash> ayoung: we should, that;s the bug :-) 18:31:45 <ayoung> dolphm, will do... 18:31:59 <gyee> henrynash, we probably don't need it as long as we have away to override 18:32:12 <ayoung> henrynash, so we bypass the controller when removing the roles from the user, don't we? 18:32:17 <dolphm> henrynash: can you mark that as a public security issue -- i don't see an option for that on launchpad, but i know you can 18:32:17 <henrynash> gyee: we have the override 18:32:26 <dolphm> ayoung: thanks 18:32:37 <gyee> henrynash, I am OK with closing it as by design 18:32:41 <henrynash> ayoung: so remove a role from a user is fine…I have covered that 18:33:01 <henrynash> ayoung: the problem is if you just do a "role delete" 18:33:14 <henrynash> gyee: ok, will do 18:33:15 <ayoung> henrynash, I know. 18:33:38 <henrynash> dolphm: ok ,will do 18:34:09 <ayoung> spzala, have you tested your changes with liveldap? You should be 18:34:34 <spzala> ayoung: I tested with openldap installation 18:34:51 <dolphm> henrynash: thanks 18:35:15 <dolphm> #topic keystone.middlware.auth_token support 18:35:30 <spzala> ayoung: the way I tested was with openldap with real config data in the backend_ldap.conf 18:35:45 <dolphm> #link http://lists.openstack.org/pipermail/openstack-dev/2013-March/006706.html 18:35:48 <ayoung> spzala, did you run the _ldap_livetest suite? 18:36:22 <dolphm> i pinged the list about this -- i have two fixes in review... one cheap & easy but requiring configuration changes, and the other providing a hacky solution to maintain support (patch WIP and broken at the moment) 18:36:53 <spzala> ayoung: no :( I did it with openldap data via backend_ldap.conf. Thought that's the best way but will run _livetest suite just in few. 18:36:58 <dolphm> just wanted to mention it here -- it's a RC blocker and i'm certainly open to creative solutions 18:37:14 <topol> ayoung, would spzala need to pull down crazed liveldap patch to be successful 18:37:15 <ayoung> spzala, rebase on master and you should get the fixed tests 18:37:24 <ayoung> topol, thought that merged? 18:37:34 <spzala> topol: thanks, good point. 18:37:37 <dolphm> gyee: chmouel: markmc: thanks for reviews 18:37:39 <gyee> dolphm, I think we can just throw an exception when attempting to import keystone.middleware.auth_token 18:37:40 <topol> ayoung did it? 18:37:46 <spzala> ayoung: OK, that sounds good. 18:37:50 <gyee> or make it a warning 18:37:50 <dolphm> gyee: we actually can't 18:38:21 <dolphm> gyee: i replied to your comment with a bit of an explanation, but the backtrace in the bug would be hit before you ever had a chance to log anything 18:38:26 <gyee> they'll need to make the change anyway 18:38:36 <ayoung> spzala, running now...I'll post a rebased patch after the tests run 18:38:43 <topol> dolphm, it sounded like you had two options, one was a bandaid that would hide the issue and the other was a needed change to the paste config. Is that correct? 18:38:51 <dolphm> yep, but as a community we've also agreed to maintain backwards compatibility for config options for a couple releases before removing them 18:39:00 <spzala> ayoung: great, thanks. 18:39:01 <dolphm> topol: yes, exactly 18:39:09 <dolphm> needs config change: https://review.openstack.org/#/c/24251/ 18:39:24 <dolphm> bandaid to suppress the issue: https://review.openstack.org/#/c/24701/ 18:39:47 <dolphm> the second review is broken -- i wrote it without being able to test it in devstack, i'm working through those issues today, but you can see the intention in the review 18:39:56 <gyee> if we need to maintain backward compat for 2 releases then the choice is obvious 18:40:00 <gyee> B) 18:40:10 <dolphm> gyee: if i can get (B) to work lol 18:40:15 <topol> dolphm, I agree. From a serviceability perspective changing the config file was bad. doing problem determination will take time (hard to figure out the problem from the trace) so even if its just a config change the serviceability cost will be high 18:40:25 <dolphm> it's going to be an elaborate hack 18:41:12 <topol> dolphm, it seemed like the bandaid would not have any serviceability costs and the config file change could add up a lot 18:41:33 <dolphm> gyee: if we manage to keep keystone.middleware.auth_token though, i agree, it should totally raise a warning if imported successfully -- i'll do that in the second patch 18:41:44 <ayoung> topol, it was approved, but didn't merge...grrr 18:41:56 <topol> questions to the email list, questions to OS distributers, and other folks who have to provide serviceability 18:42:33 <dolphm> topol: i think the op preference is clear, we just need to make it happen if possible 18:42:54 <topol> dolphm, I thought it was easy. I missed something then 18:43:26 <topol> dolphm, I thought you just swallowed the exception 18:43:26 <dolphm> topol: my bandaid breaks in other spectacular ways -- i'm trying to fix 18:43:31 <spzala> ayoung: OK, I will pull crazed's liveldap patch 18:43:33 <dolphm> topol: there are subsequent exceptions 18:43:43 <ayoung> spzala, wait one and you can get it from gerrit 18:44:01 <spzala> ayoung: OK, that's cool. 18:44:02 <topol> dolphm, oh scary. that changes the whole equation 18:44:04 <ayoung> spzala, I am going to resubmit yours rebased on it 18:44:08 <dolphm> #action dolphm to try really hard to fix https://review.openstack.org/#/c/24701/ 18:44:14 <ayoung> spzala, the tests fail... 18:44:23 <spzala> ayoung: ah :( 18:44:28 <dolphm> topol: i'll try to clean up the final result as best i can 18:44:28 <spzala> ayoung: hmmm 18:44:30 <gyee> really hard? :) 18:44:31 <dolphm> make it presentable :P 18:45:01 <dolphm> i assume we don't have any other high priority issues that aren't RC blockers, so.... 18:45:06 <dolphm> #topic open discussion 18:45:12 <dolphm> 15 minutes :) 18:45:20 <topol> ayoung, does spzala have time to debug 18:45:33 <topol> its usually soemthing small. 18:45:39 <ayoung> topol, looking myself...possible test issues and not backend 18:46:00 <ayoung> topol, and possible schema issues as we know/ 18:46:06 <dolphm> for anyone interested -- i'm going to try and review summit topics this week, so if you have one you're thinking about presenting, i'd welcome at least a draft or something on http://summit.openstack.org/ 18:46:18 <dwaite> looking forward to the havana summit. actually a fair number of people from my company going now 18:46:54 <topol> dolphm, we will be sending in stuff soon. 18:46:58 <ayoung> spzala, pull down the latest, and you will get the live test. I mistrust my implementation enough that I think you should try running them yourself 18:47:04 <dwaite> dolphm: one question, my proposal includes a lot of groundwork technology to cover, I think that might limit discussion time 18:47:21 <dwaite> is there a way to get a slot larger than 40m, or break it into two parts? 18:47:25 <gyee> dwaite, you can schedule some unconference sessions as well 18:47:30 <dwaite> ok 18:47:35 <spzala> ayoung: OK, sounds good and thanks for the quick test! 18:48:04 <henrynash> dolphm: the authentication for disabled domains just got a bit worse….as well as v2 not checking, v3 allows you to authenticated by user_id to a disabled domain(although catches it if you authenticate by user-name) 18:48:10 <dolphm> dwaite: i'll make a note, but unless that's the point of the discussion (discussing tech options), perhaps request that attending brief themselves on the list of pre-req's and jump straight in? 18:48:16 <henrynash> bug 1130236 18:48:17 <uvirtbot> Launchpad bug 1130236 in keystone "Domains are not validated on authentication" [High,In progress] https://launchpad.net/bugs/1130236 18:48:19 <dolphm> dwaite: ideally provide some links or something 18:48:29 <ayoung> NO_SUCH_OBJECT: {'matched': 'dc=openstack,dc=org', 'desc': 'No such object'} 18:48:31 <dolphm> s/attending/attendees/ 18:48:36 <ayoung> looks legit 18:49:18 <ayoung> dwaite, its ok, I think there will be enough of us with enough background that we can consume your session. I really want that one to be in the summit talks 18:49:40 <dwaite> dolphm, I can do that. link 'executive overview'-type documents, and provide just enough at the start to level-set and perhaps propose ideas on where the technologies can be leveraged 18:49:43 <ayoung> dolphm, as PTL I think you can pre-approve. heckj can you pass the magic incantations on for that? 18:50:00 <dolphm> henrynash: hmm v2 isn't a huge deal because it's only default domain, although it should be checked.. 18:50:17 <dolphm> henrynash: does using user_id utilize a whole different code apth? 18:50:18 <crazed> ayoung: any reason that live ldap test after approval failed? i noticed a no such file or directory error from jenkins, but have no insight to what went wrong there 18:50:20 <dolphm> path 18:50:44 <ayoung> crazed, pep8? Yeah, looks like a merge thing. I'm trying to push it through now 18:50:50 <heckj> ayoung: dolphm: set log into the side - ttx has already updated it, so I can't pre-approve any longer. You'll see a button hiding off on the side that says something like "review keystone" for the sessions 18:51:02 <heckj> er /side/site/ 18:51:02 <henrynash> dophm: no it just only looks up the domain if it has to i.e. user-name…fix is quite easy, although, of course, I think it breaks some other tests 18:51:07 <heckj> summit.openstack.org 18:51:14 <crazed> ayoung: cool thanks 18:51:17 <dolphm> henrynash: yeah i saw that and it scared me 18:51:18 <ayoung> crazed, tell you what. I'll tkae care of that, van you help spzala with https://review.openstack.org/#/c/22624/14 18:51:23 <dolphm> heckj: ^ lol 18:51:41 <dolphm> heckj: there's a hundred more buttons that appeared 18:51:47 <henrynash> dolphm: I've fixed it my patch, but trying to make sure the other tests work... 18:52:08 <dolphm> henrynash: cool 18:52:54 <heckj> heh 18:55:24 <crazed> spzala: what do you need help with? 18:56:29 <spzala> crazed: thanks..I am going to pull your code and going to test my stuff with it.. and if I run into something then I may need help :) 18:56:39 <dolphm> henrynash: thanks for revising description on bug 1130236 18:56:41 <uvirtbot> Launchpad bug 1130236 in keystone "Domains are not validated on authentication" [High,In progress] https://launchpad.net/bugs/1130236 18:56:53 <henrynash> dolphm: np 18:57:54 <topol> dolphm, if we have time can you see if I did somehting evil in my latest fix ldap on fedora for devstack patch by including the openldap schema files in the patch? 18:58:21 <topol> its a license thing im worried about 18:58:33 <dolphm> topol: link? 18:58:53 <topol> https://review.openstack.org/#/c/24764/ 18:59:49 <dolphm> topol: oh wow, i have no idea 18:59:49 <topol> after pushing up the patch I noticed the following preamble: 18:59:51 <topol> # $OpenLDAP$ 18:59:52 <topol> 3 ## This work is part of OpenLDAP Software <http://www.openldap.org/>. 18:59:54 <topol> 4 ## 18:59:55 <topol> 5 ## Copyright 1998-2011 The OpenLDAP Foundation. 18:59:57 <topol> 6 ## All rights reserved. 18:59:58 <topol> 7 ## 19:00:00 <topol> 8 ## Redistribution and use in source and binary forms, with or without 19:00:01 <topol> 9 ## modification, are permitted only as authorized by the OpenLDAP 19:00:03 <topol> 10 ## Public License. 19:00:04 <topol> 11 ## 19:00:06 <topol> 12 ## A copy of this license is available in the file LICENSE in the 19:00:07 <topol> 13 ## top-level directory of the distribution or, alternatively, at 19:00:09 <topol> 14 ## <http://www.OpenLDAP.org/license.html>. 19:00:12 <dolphm> topol: less pasting into irc ;) 19:00:32 <dolphm> switching to -dev 19:00:33 <dolphm> #endmeeting