18:00:22 <dolphm> #startmeeting keystone 18:00:23 <openstack> Meeting started Tue Sep 24 18:00:22 2013 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:27 <openstack> The meeting name has been set to 'keystone' 18:00:31 <gyee> \0 18:00:34 <fabiog> hi 18:00:40 <dolphm> #topic havana-rc1 18:00:42 <ayoung> Oyez 18:00:44 <dolphm> #announcement SO CLOSE 18:00:53 <dolphm> YAY 18:01:08 <dolphm> fyi, you can see every project's progress on http://old-wiki.openstack.org/rc/ 18:01:09 <ayoung> #link https://launchpad.net/keystone/+milestone/havana-rc1 18:01:13 <henrynash> hi 18:01:14 <morganfainberg> woot. 18:01:14 <stevemar> just 3 bugs left? 18:01:17 <dolphm> just 3 18:01:20 <topol> hi 18:01:20 <stevemar> yay 18:01:27 <ayoung> 4 with the one that dolphm just triaged 18:01:33 <morganfainberg> and isn't one gating now? 18:01:35 <stevemar> nooo 18:01:37 <morganfainberg> or ready to 18:01:54 <dolphm> ayoung: well, that's already in progress, but we're waiting on upstream changes to openstack/requirements 18:02:03 <ayoung> nice 18:02:04 <dolphm> so, i guess let's run through every bug for status 18:02:10 <dolphm> bug 1182861 18:02:12 <uvirtbot> Launchpad bug 1182861 in trove "Switch to oslo.config 1.2.0 final" [High,Triaged] https://launchpad.net/bugs/1182861 18:02:15 <henrynash> morganfainberg: iep, mine is gatting 18:02:20 <henrynash> (yep) 18:02:22 <dolphm> in progress in keystone, requires an upstream changes to openstack/requirements 18:02:27 <dolphm> i think that'll be trivial 18:02:33 <dolphm> bug 1153645 18:02:36 <uvirtbot> Launchpad bug 1153645 in keystone "Deleting a role should revoke any tokens associated with it" [High,In progress] https://launchpad.net/bugs/1153645 18:02:50 <dolphm> gating now! 18:02:55 <morganfainberg> yay! 18:03:10 <dolphm> bug 1210515 18:03:12 <uvirtbot> Launchpad bug 1210515 in keystone "keystone chokes on empty "description" field in active directory" [Medium,In progress] https://launchpad.net/bugs/1210515 18:03:19 <ayoung> chmouel, can you hit the changes to ^^ 18:03:23 <ayoung> should be trivial 18:03:29 <dolphm> looks like brant had a couple nits, but as far as i can tell, this is really close 18:03:42 <ayoung> dolphm, the order of checks should be fixed 18:03:54 <bknudson> we shouldn't be allowing adding an immutable attribute 18:03:59 <dolphm> ayoung: ahh, i glossed over that comment 18:04:10 <bknudson> I had made the same comment on previous patch set 18:04:28 <chmouel> oh yeah i messed the ordering 18:04:33 <chmouel> tks 18:04:52 <bknudson> I wouldn't -1 for missing ' in didn't 18:04:58 <dolphm> chmouel: thank you! 18:05:00 <ayoung> chmouel, ping when done 18:05:04 <chmouel> yep will do 18:05:10 <dolphm> bknudson: yes you would ;) 18:05:20 <bknudson> I'd -2 18:05:21 <chmouel> i was writting some additional tests for that but i think someone did 18:05:23 <stevemar> haha 18:05:25 <chmouel> hehh 18:05:43 <dolphm> chmouel: dstanek wrote a few in a dependent patch, but i haven't reviewed yet 18:05:51 <dolphm> aaand... 18:05:52 <dolphm> bug 1221889 18:05:53 <uvirtbot> Launchpad bug 1221889 in keystone "Invalid X-Subject-Token results in HTTP 401 rather than 404" [High,In progress] https://launchpad.net/bugs/1221889 18:06:09 <dstanek> i have two patches with tests and a third that i'm trying to get to pass 18:06:13 <ayoung> morganfainberg, can you explain your comment https://bugs.launchpad.net/keystone/+bug/1221889/comments/7 18:06:14 <uvirtbot> Launchpad bug 1221889 in keystone "Invalid X-Subject-Token results in HTTP 401 rather than 404" [High,In progress] 18:06:57 <morganfainberg> ayoung, the tempest change to allow the test to continue has been merged. once we get this bug in, there is another tempest change needed to un-skip and change expected http status to 404 18:07:02 <dolphm> the fix for this one has been slow because it's dependent on changes to oslo and tempest first 18:07:10 <dolphm> now we need to sync up keystone policy with oslo policy 18:07:20 <dolphm> considering we extend oslo policy, i'm paranoid we'll see breakage there 18:07:28 <lbragstad> dolphm: yeah.. 18:07:32 <gyee> oslo changes is in 18:07:36 <dolphm> gyee: ++ 18:07:37 <lbragstad> I think they changed stuff to be oo 18:07:37 <ayoung> lets get lots of eyes on that review 18:07:41 <dolphm> but not synced over to keystone 18:07:43 <dolphm> ayoung: ++ 18:07:43 <morganfainberg> ayoung, i was responding to dolph's comment. 18:07:51 <gyee> dolphm, I'll take a look at that one 18:07:55 <atiwari> but the oslo's version of policy is way different than Keystone 18:08:06 <dolphm> gyee: thanks 18:08:21 <dolphm> for anyone that has free time, this is definitely the most complex patch of what we have left 18:08:22 <bknudson> we probably haven't merged oslo policy for a while... 18:08:26 <dolphm> bknudson: we haven't 18:08:29 <dolphm> bknudson: in a looong while 18:08:41 <gyee> time to roll the dice :) 18:08:44 <henrynash> dolphm: well, not since the end of Grizzly 18:08:49 <stevemar> eek 18:09:00 <gyee> stevemar, oh comon, live a little 18:09:04 <dolphm> henrynash: i was about to say, i think you were the last to do so 18:09:22 <morganfainberg> hehe 18:09:24 <lbragstad> I hit that on the sync for notifier on accident, a lot of the new stuff in oslo's policy is object oriented, its gonna take a bit a refactoring in Keystone 18:09:28 <jamielennox> why isn't it synced at the same time we do the rest of an oslo sync? 18:09:34 <henrynash> dolphm: guilty, as charged….although not sure it was actually in oslo at that point 18:10:04 <ayoung> is this going to conflict with henrynash 's changes for entity level policy rules? 18:10:50 <henrynash> ayoung: I don't see why it should…as long as they haven't reduced the capability of the engine 18:10:58 <ayoung> so...question is do we really want to sync now...or can we delay until Icehouse 1. What is in Oslo that we need? 18:11:15 <gyee> ayoung, have faith in our tests :) 18:11:33 <morganfainberg> ayoung, honestly, if we can avoid syncing till Icehouse1, i'd vote that. 18:11:33 <jamielennox> gyee, jk? 18:11:38 <henrynash> ayoung: I never changed the engine…. 18:11:41 * topol my scaredy cat anture says wait till Icehouse 1 18:11:42 <bknudson> the tests for oslo-incubator are in oslo... do we have our own tests for oslo stuff? 18:11:52 <atiwari> I think sooner is better otherwise two will deviate a bit 18:11:55 <ayoung> we don't have a review for the sync yet, do we? 18:12:02 <morganfainberg> ayoung, not that i see 18:12:03 <dolphm> so for reference, a full sync to oslo right now would look like this- http://pasteraw.com/h7q6rihq5hhtsz3q478ogtjxtveyeyj 18:12:21 <gyee> oh shit 18:12:22 <dolphm> and that causes new test failures 18:12:32 <ayoung> dolphm, can you WIP that review? 18:12:35 <dolphm> ayoung: sure 18:12:41 <topol> that looks harmless :-) 18:13:00 <morganfainberg> that actually doesn't look as bad as i'd expect 18:13:06 <ayoung> so.. lots of locale and language stuff... 18:13:11 <dolphm> full sync to oslo: https://review.openstack.org/#/c/48111/ 18:13:38 <jamielennox> most of that is fairly simple 18:13:52 <dolphm> policy is +274, -196 18:14:09 <dolphm> and imports fileutils, jsonutils and common logging 18:14:23 <topol> isnt policy tricky enough that there maybe uintended consequences??? 18:14:24 <dolphm> and oslo.config, of course 18:14:27 <gyee> those ain't that bad 18:14:43 <dolphm> topol: yep 18:15:09 <bknudson> policy has new config options, so would need to update sample config too 18:15:36 <ayoung> policy looks relativly minimal. We are one change ahead of their GenericCHeck, the rest looks like they have made an object that gets replaced for refreshing rules 18:16:27 <topol> whats the sense of urgency to do this now as opposed to when there is more runway to fix stuff? 18:16:32 <dolphm> on the upside, the entire test suite takes like 2 minutes now 18:16:35 <dolphm> mostly because they all fail 18:16:41 <morganfainberg> hehe 18:16:56 <jamielennox> it introduces a new exception that would need to be plumbed 18:17:05 <dolphm> DuplicateOptError: duplicate option: policy_file http://pasteraw.com/sqlxfrvg4mh7gf9wkzy797v8kgw4ypq 18:17:17 <ayoung> so..the argument for fixing this now is that if thereis a CVE in icehouse, we can replace the coder in all projects at once 18:17:26 <ayoung> a CVE in oslo code, that is 18:18:00 <ayoung> replace the code...the coder will likely have already been replaced.... 18:18:10 <dolphm> topol: this change is currently a release blocker (that could be changed, as i see this as a *very* compelling nice-to-have) https://review.openstack.org/#/c/46123/ 18:18:47 <dolphm> topol: which is currently dependent on a recent change to oslo policy due to the change made in etc/policy.v3cloudsample.json 18:18:55 <dolphm> and how that should be handled in keystone to support this use case 18:19:06 <gyee> dolphm, topol, we'll have to fix it one way or the other as API spec says 404 should be returned 18:19:13 <morganfainberg> gyee, ++ 18:19:16 <dolphm> so, we either need an alternative solution to the policy.json change, or we need to sync oslo to make the proposed change work 18:19:34 <gyee> so its really the cost of backporting we are considering here 18:20:03 <bknudson> or make whatever changes are required to fix to our policy.py and then get full policy in icehouse 18:20:36 <gyee> yes, we'll have to sync policy, eventually 18:20:49 <dolphm> bknudson: you mean carry some fork of common policy? :( 18:20:55 <topol> well if you have folks who feel they can contain it and its impact sounds cool to have... 18:21:01 <gyee> again, cost of backporting versus the cost of delaying the RC1 release 18:21:01 <bknudson> dolphm: yes :( 18:21:06 <jamielennox> i'd like to see a new & old client ran against that 18:21:12 <morganfainberg> dolphm, maybe sync policy icehouse 1, tag for backport? 18:21:24 <ayoung> morganfainberg, +1 18:21:33 <morganfainberg> doesn't delay RC, and gives us a longer runway to hit bugs. 18:21:54 <topol> morganfainberg +1. thats brilliant 18:22:04 <jamielennox> morganfainberg, +1 18:22:16 <stevemar> morganfainberg, thinking things through :P 18:22:18 <dolphm> morganfainberg: you don't see it as backporting features via oslo? 18:22:23 <bknudson> typically don't backport config changes. 18:22:41 <morganfainberg> bknudson, fair enough. but this might be worthwhile doing in this case. 18:23:09 <ayoung> dolphm, We would probably want to get our change to GenericCHeck merged into Oslo 1st anyway 18:23:16 <ayoung> otherwise we are not really in sync 18:23:24 <dolphm> ayoung: ? i thought that merged 18:23:34 <ayoung> dolphm, don't see it in your review 18:23:41 <bknudson> we've already got a fork of poicy? 18:23:55 <dolphm> ayoung: ? is that not the try catch on line 848 https://review.openstack.org/#/c/48111/1/keystone/openstack/common/policy.py 18:24:03 <dolphm> bknudson: in review, not in master 18:24:43 <ayoung> dolphm, duh, yes it is...I was reading it backwards. I was thinking we had applied that change to our repo. 18:25:37 <dolphm> ayoung: *whew* i thought i was crazy for a minute 18:25:41 * dolphm but thankfully it's just you 18:25:42 <dolphm> :) 18:26:13 <dolphm> ayoung: it's proposed here (and the reason for my -1) but not merged https://review.openstack.org/#/c/46123/11/keystone/openstack/common/policy.py 18:26:26 <atiwari> dolphm, if you are taking about https://review.openstack.org/#/c/46589/, I think it is in master now. 18:26:27 <ayoung> dolphm, just cuz we know I'm crazy doesn't mean that you aren't. You are just less crazy than me: you really need a higher bar than that. 18:26:50 <dolphm> ayoung: now you're being too logical 18:27:00 <gyee> heh 18:27:15 <topol> Im sure in Hong Kong we can find interesting food options and we can really see who is crazy... 18:27:21 <dolphm> atiwari: in oslo master, yes... but not keystone.common 18:27:27 <dolphm> topol: ++++ 18:27:28 <dolphm> i'm in 18:27:35 <morganfainberg> topol, should be fun. 18:27:37 <atiwari> ok 18:27:41 <dolphm> chicken feet was new for me not that long ago 18:28:00 <ayoung> topol, but gyee has a serious advantage in that he knows what the waiters will be saying. 18:28:02 <gyee> atiwari, we just need to leave that one out as oslo sync is in a separate review 18:28:24 <gyee> ayoung, I'll make sure I translate "properly" 18:28:30 <topol> yes. yes he does. 18:28:33 <ayoung> gyee, I'm sure you will 18:29:03 <morganfainberg> I'll be worries when gyee's translation is "there is no word for it in english, but… it's good, just eat it" 18:29:14 <gyee> ha! 18:29:21 <atiwari> :) 18:29:36 <gyee> atiwari, so just make your review a dependent of dolphm's 18:29:37 <fabiog> right, or when he will say, it is like chicken nuggets :-) 18:30:01 <morganfainberg> sounds like sync for RC it is then, gyee ? 18:30:08 <atiwari> gyee, OK 18:30:31 <ayoung> what is the official Keystone stance on etc/policy.v3cloudsample.json ? Is that going to be the default approach to policy moving forward? 18:30:41 <dolphm> gyee: except the full oslo sync is failing tests 18:30:55 <gyee> I think we should fix it as it impacts API spec 18:31:15 <ayoung> cuz I like it a lot better than the default policy.json. I would like to see the tests run against that. 18:31:30 <morganfainberg> ayoung, + 18:31:31 <morganfainberg> + 18:31:42 <ayoung> henrynash, nice work on that, BTW 18:31:48 <henrynash> ayoung: thx 18:31:54 <gyee> dolphm, lets fix the tests first 18:32:31 <ayoung> gyee, I'm going to try and splitting the sync, to see what happens if we sync only the policy.py file first 18:32:36 <henrynash> ayoung: fyi, there are a set of tests already that run against it….but only as a specific unit test 18:32:50 <gyee> ayoung, lets do this 18:33:00 <ayoung> henrynash, yeah...understood. And we can't just blindly swap over to it, as that will break all the current deployments out there 18:33:04 <dolphm> #topic open discussion 18:33:11 <ayoung> So.. policy 18:33:31 <ayoung> should we absorbe the policy code into Keystone again 18:33:37 <ayoung> and if so, does it go into keystone client 18:33:52 <ayoung> or should be make it a standalone library 18:33:53 <bknudson> there was a comment on the mailing list that they wanted middleware out of keystoneclient 18:34:12 <ayoung> bknudson, or should we make a keystonemiddleware project 18:34:21 <morganfainberg> ayoung, we probably should do that 18:34:32 <bknudson> how does the standalone library work? it would be treated more like keystoneclient? 18:34:33 <gyee> middleware should stay with keystone client 18:34:38 <bknudson> or is it released like keystone? 18:34:41 <gyee> too much of a dependency 18:34:42 <morganfainberg> standalone library that is. 18:34:50 <morganfainberg> (policy) 18:34:56 <bknudson> what's the dependency between keystoneclient and middleware? 18:34:56 <ayoung> I would not mind seeing something like python-openstackmiddleware python-openstackpolicy and python-libkeystone 18:35:15 <morganfainberg> ayoung, ++ (not oslo.policy?) 18:35:16 <gyee> auth_token will be using keystoneclient's requests part 18:35:46 <gyee> bind token check 18:35:49 <gyee> cms 18:36:01 <gyee> pluggable auth for admin token request, etc, etc 18:36:04 <bknudson> we'd have to duplicate cms again. 18:36:14 <bknudson> that would be bad 18:36:23 <gyee> what's the convincing argument for split it out? 18:36:38 <morganfainberg> short of moving cms into a (similarly) common library, it would be silly to duplicate it again 18:36:40 <jamielennox> gyee actually there is no dependency on client from auth_token 18:36:55 <ayoung> morganfainberg, the policy rules are tightly coupled with the token implementation. The generic policy engine is more general purpose. I don't care about the naming, but I would like to have the policy available as a reusable component 18:36:58 <jamielennox> there should be... 18:37:11 <gyee> jamielennox, thought you are going to make to fix for using requests lib for everything? 18:37:14 <ayoung> libkeystone should be for code common to server and client 18:37:20 <ayoung> gyee, he is... 18:37:21 <dolphm> what's the argument in favor of splitting middleware out of keystoneclient? 18:37:35 <jamielennox> yea, requests has happened, but it doesn't use the client's requests path it's got its own 18:38:20 <morganfainberg> ayoung, I think policy probably does not belong in keystoneclient. but i think it should absolutely be moved into it's own library (and i don't think it would be improper to be handled by keystone to maintain it, but that is a separate argument) 18:38:20 <gyee> jamielennox, thought you are going to do that next as we are currently duplicating code 18:38:22 <dolphm> bknudson: there should be a stronger dependency there, i know it's on jamielennox's wishlist as well as mine to rewrite auth_token to use the regular old keystoneclient ... http client 18:38:36 <jamielennox> dolphm: the best one i've heard is being able to release auth_token without having to do a full release of the client code 18:38:57 <gyee> jamielennox, that's not a convincing argument :) 18:39:04 <jamielennox> there are reasons that auth_token should not be pegged to the current minimum required version of keystoneclient which i think is still 0.2.1 18:39:05 <dolphm> jamielennox: that a weak argument, without an example of a specific reason why you'd want to do one without the other 18:39:25 <dolphm> jamielennox: 0.2.1 according to who? 18:39:30 <jamielennox> whoa, this isn't my push... 18:39:37 <ayoung> dolphm, I suspect it is just whinging from people that have pegged their client dependencies to a low version... 18:39:56 <ayoung> we had some tempest/gate breakage due to that and incompatbile client versions 18:39:58 <gyee> ayoung, one line chef change :) 18:39:59 <morganfainberg> ayoung, and that isn't solved with spliting it. they'd just pin the middleware too :P 18:40:06 <ayoung> heh 18:40:17 <jamielennox> apologies it's been updated to 0.3.2 - i ddidn't know that 18:40:20 <dolphm> ayoung: that's why we mandate minimum client versions, but not to pin them to a max 18:41:01 <jamielennox> gyee, and it is definitely on my todo list 18:41:20 <ayoung> morganfainberg, so...I don't really havea burning reason to split them, rather it is more from a cleanliness perspective. If I am doing CLI operations, I don't need middleware, and if I am runnign a service, I don't need CLI. There is no real reson to split them, other than they pull in other package dependencies that may not be appropriate in all situations 18:41:36 <morganfainberg> ayoung, agreed. 18:41:43 <ayoung> auth_token middleware is differnt from the client in that it is priamrily a token consumer 18:41:53 <ayoung> CLI is p[rimarily a token requestor 18:41:53 <gyee> speaking of which, can somebody take a look at https://review.openstack.org/#/c/47661/ 18:42:03 <bknudson> CLI in keystoneclient is deprecated. 18:42:07 <gyee> I sorta leave the door open for pluggable auth for admin token request 18:42:11 <ayoung> now, auth_token does request tokens for some usages, but that almost seems gratuitous 18:42:17 <bknudson> or, to be deprecated 18:42:20 <morganfainberg> ayoung, if we had say, libkeystone i could see auth_token being split logically. 18:42:29 <ayoung> you should not have to ask Keystone for a token in order to to a keystone based operation 18:42:35 <morganfainberg> but right now, we're still cli+libkeystone 18:42:58 <morganfainberg> this might be worth reconsidering when openstackclient is ready to go? 18:43:00 <bknudson> use the admin token 18:43:13 <jamielennox> gyee, any chance that we can just do that base on admin_password == None for now rather than a new config option? 18:43:14 <ayoung> I don't see any real problem with splitting a growing project into more granular packages. 18:43:50 <gyee> jamielennox, but that's a hack, I rather do this properly 18:43:53 <morganfainberg> ayoung, don't get me wrong, i'm infavor of more granular development. 18:44:22 <jamielennox> i'm thinking the issue will go away if we can get the APIClient stuff in and then move that into auth_token 18:44:25 <morganfainberg> ayoung, but we might have bigger fish to fry until a bit later on. 18:44:28 <ayoung> morganfainberg, so the question is: what should the layout be? 18:44:36 <morganfainberg> ayoung, that is a valid question 18:44:53 <dolphm> p.s. i thought of an interesting use case the other day for not deprecating keystoneclient's CLI that no one here probably cares about 18:45:13 <jamielennox> gyee, also the admin_token is required for fetching a revocation list - which is required for PKI operations as well, so we do kind of still need it around 18:45:17 <ayoung> If we assume that the typical usage is client on one machine, server on a second, and auth_token on a third...and we only want to put code essential to those operations on each machine, I think the layout becomes clear 18:45:35 <topol> dolphm, do tell 18:45:36 <morganfainberg> dolphm, ok i'll bite, share :) 18:45:54 <dolphm> "I want to deploy keystone for use with not-openstack, so I don't want to use python-openstackclient to interact with keystone on the CLI." 18:46:02 <gyee> jamielennox, I basically make it optional 18:46:15 <ayoung> libkeystone gets common functionality, but is only usable when called from python. auth_token gets a reduced role to call into the library for its operations. CLI can be replaced with the common CLI without disrupting or dual deploying 18:46:29 <topol> hmmm. sounds like heresy 18:46:40 <bknudson> I hope openstackclient would be pluggable, so you could only plug-in keystone function 18:46:58 <bknudson> we'll need to update keystone CLI for V3 18:47:09 <morganfainberg> dolphm, actually, good point. my friend is looking ot use keystone for a non-openstack project. 18:47:13 <gyee> bknudson, ++ 18:47:15 <dolphm> every now and then someone will be interested with deploying keystone as a standalone authn/z service for something totally unrelated to openstack 18:47:21 <dolphm> i've never heard of anyone actually doing it 18:47:23 <ayoung> dolphm, actually, I've had a request for that. And then I pointed out that they were a Java based project and Keystone was python. I politely suggested they look into Jython and never heard back from them 18:47:24 <topol> oh no its spreading 18:47:43 <morganfainberg> dolphm, it's likely going to happen in a month or two for sure (was talking about this last night) 18:47:53 <dolphm> ayoung: lol 18:48:02 <dolphm> morganfainberg: let me know when it happens :) 18:48:07 <morganfainberg> dolphm, for sure. 18:48:54 <dolphm> this is just a theoretical, and it's not a strong argument for NOT using openstackclient, but i've heard similar "but i don't want to use completely-useful-thing X just because it's called X" 18:49:04 <bknudson> Looks like change for bug 1201251 is ready. 18:49:05 <uvirtbot> Launchpad bug 1201251 in keystone "issues of updating user via keystone rest api" [Medium,In progress] https://launchpad.net/bugs/1201251 18:49:12 <ayoung> dolphm, so...keystone is really two things now. One is a very limited IdP. The other is that it is an authorization mapping service. I think it is this second role that people want to tie in with. As such, all of the discussion around Federation becomes much more interesting 18:49:42 <ayoung> I've started a Q&A around Federation on the old federation etherpad, and dchadwick has answered some questions on it today 18:49:52 <bknudson> https://review.openstack.org/#/c/42826/ Add user to project if project ID is changed 18:49:52 <gyee> ayoung, link? 18:49:52 <dolphm> ayoung: i'd argue that we've always been that, and both sides of our authn + authz abilities have expanded quite a bit 18:50:03 <stevemar> https://etherpad.openstack.org/keystone-federation 18:50:06 <stevemar> gyee ^ 18:50:09 <topol> we have stuff for the new federation etherpad when it becomes avail 18:50:13 <bknudson> still can't require a password to change every 6 months with sql 18:50:21 <gyee> #link https://etherpad.openstack.org/keystone-federation 18:50:22 <morganfainberg> bknudson, i'll look at that review as soon as we're done here. (1201251) 18:50:27 <stevemar> topol, i'm going to add to it now 18:50:38 <bknudson> still can't require certain chars in password, can't lock out users after bad attempts 18:50:43 <topol> Thanks stevemar 18:50:50 <gyee> meetbot working? 18:51:00 <ayoung> lets try to keep that page somewhat oragnized, so we can use it as the basis for making decisions around Federation based features 18:51:02 <gyee> #link https://etherpad.openstack.org/keystone-federation 18:51:02 <stevemar> hmm #link https://etherpad.openstack.org/keystone-federation 18:51:09 <gyee> wtf? 18:51:11 <morganfainberg> gyee, meetbot has been odd lately 18:51:23 <ayoung> gyee, probably og picked up, 18:51:31 <ayoung> it doesn't tell you on all successful operations 18:51:35 <gyee> k 18:52:07 <stevemar> oh, is this going in: #link https://review.openstack.org/#/c/46363/ 18:52:44 <morganfainberg> did we want to get the optional dep stuff in for Havana? 18:52:56 <stevemar> i thouht we did? 18:53:01 <stevemar> thought 18:53:09 <ayoung> so, it sounds like the three main approaches to Identity are going to be LDAP for corporate, SQL for a self contained deployment, and SAML for communicating with a remote IdP. OAuth is very SAML like. The old mapping blueprint/backend is proably best thought of as an extension to the identity bakcend: I got it in form X, here it is as a userid or as a group. 18:53:09 <stevemar> dolphm ? ^ 18:53:26 <bknudson> the oauth dependency was a problem for some packagers. 18:53:42 <morganfainberg> bknudson, ok, i'll look at that one as well when we are done here 18:53:50 <dolphm> sorry, was looking back to check on meetbot 18:54:04 <ayoung> stevemar, thanks for brining that up. I'd like it to go in. Even if it is a short lived feature, 18:54:29 <topol> why shortlived? 18:54:29 <stevemar> yeah, i think it went by the way side for a little 18:54:32 <ayoung> I'd like to Keep keystone from pulling in the Oauth dependency at the package level 18:54:44 <dolphm> ayoung: stevemar: that's a good breakdown 18:54:45 <ayoung> topol, because, as the comment suggests, it is backwards 18:54:58 <topol> didnt see that. thanks 18:55:32 <ayoung> topol, I've been thinking that the token provider should be a pipeline for some time now...suggested it back when gyee did the origianl -plugability stuff. 18:55:48 <ayoung> We want to be able to inject or extract something like OAuth in to the larger workflow 18:55:54 <morganfainberg> ayoung ++ 18:55:58 <ayoung> something built out of tree, say 18:56:03 <topol> that sounds cool 18:56:09 <ayoung> without having to change core Keystone to support it 18:57:10 <dolphm> ayoung: thankfully we have the WSGI pipeline to do exactly that :) 18:57:11 <ayoung> topol, and the paste code supports that kind of pipeline, but we don't have time to do it completely for Havana. So I would say, do option dependencies for Havana, and use that to insule the oauth changes. Then, we can pipeline up token creation later. 18:57:18 <dolphm> ayoung: we just have to take better advantage of it 18:57:19 <stevemar> dolphm, ayoung, if that stuff is going in, we should give the bug an rc1 tag 18:57:28 <morganfainberg> dolphm, ayoung , henrynash: last question while we have people here. the domain_scope cleanup. should I even try to get that ready for RC timeline? or did we just want to mothball it until I-1? i think it's got a lot of pitfalls we can't address even in cleanup until Icehouse 1 18:57:32 <ayoung> dolphm, yes, exactly 18:57:41 <ayoung> dolphm, I want to make better use of that across the board. 18:57:43 <topol> ayoung ++ 18:57:49 * dolphm hugs ayoung 18:57:57 <gyee> lets do this 18:58:02 <dstanek> i'm not fond of the optional dependencies as implemented. it feels like a bandaid 18:58:10 <ayoung> dolphm, for instance, we should not be explicitly starting each of the managers in service.py. They should be activated by their inclusing in the pipeline, like the extensions are. 18:58:14 <dolphm> dstanek: it very much is a bandaid 18:58:24 <dolphm> dstanek: post comments on the review! 18:58:25 <dolphm> #endmeeting