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