18:01:48 <dolphm> #startmeeting keystone 18:01:48 <openstack> Meeting started Tue Sep 17 18:01:48 2013 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:52 <openstack> The meeting name has been set to 'keystone' 18:01:57 <topol> Hi 18:02:22 <dolphm> i assume we'll spend most of the meeting time talking about havana RC blockers in review -- so let me cover the one unique thing on the agenda first... 18:02:34 <dolphm> #topic python-keystoneclient v0.3.3 18:03:22 <dolphm> packagers tend to ship whatever client version is available at the time of the release of services... so i want to do a last minute release of keystoenclient before havana ships 18:03:36 <dolphm> it looks like it'll mostly be a bugfix release with some refactoring under the hood 18:03:49 <ayoung> jamielennox, you awake yet? it is your favorite topic 18:03:51 <jamielennox> sounds good to me 18:04:00 <dolphm> but if there are any significant reviews that should make v0.3.3, ping me or target them to that milestone 18:04:01 <bknudson> anything that needs to get in before havana? 18:04:26 <dolphm> there's lots of nice-to-haves in review, but i don't want to hold up v0.3.3 for any of them 18:04:46 <henrynash> for reference, what is the state of v3 support in it? Just auth, I assume? 18:04:50 <ayoung> #link https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient,n,z 18:04:51 <dolphm> (that i'm aware of) 18:05:01 <jamielennox> everything i've got left is fairly major and not a reason to wait for a release 18:05:14 <ayoung> how about https://review.openstack.org/#/c/46999/ 18:05:28 <dolphm> happy to do a v0.3.4 in a few weeks, but i wanted to get one more out the door asap 18:05:35 <ayoung> seems like that will effect the packaging 18:05:54 <morganfainberg> I would argue that https://review.openstack.org/#/c/35403/ would be great if we could get that one resolved today. 18:06:01 <dolphm> ayoung: that will definitely be new for ksc 18:06:09 <morganfainberg> but i don't see any that are absolutely needed. 18:06:25 <ayoung> https://review.openstack.org/#/c/46889/ looks like a good one, too 18:06:47 <bknudson> why send a blank email? 18:07:04 <bknudson> --email "" ? 18:07:04 <stevemar> i think they mean attribute 18:07:10 <dolphm> morganfainberg: that's dependent on this change, though https://review.openstack.org/#/c/40703/6/keystoneclient/middleware/auth_token.py 18:07:17 <ayoung> ok, we can punt on that one.... 18:07:18 <morganfainberg> dolphm, right. 18:07:33 <morganfainberg> so then lets not worry 18:08:04 <dolphm> #topic Code reviews for havana bugs 18:08:06 <ayoung> agreed 18:08:12 <jamielennox> dolphm, i haven't seen that babel issue, but if he's correct that should go in prior to release 18:08:25 <dolphm> this is gating https://review.openstack.org/#/c/45584/ 18:08:32 <jamielennox> https://review.openstack.org/#/c/46999/ 18:08:38 <dolphm> morganfainberg: which means this should be rebased https://review.openstack.org/#/c/46207/ 18:08:49 <morganfainberg> dolphm, yep, i'll have that rebased after this meeting 18:08:58 <dolphm> morganfainberg: cool 18:09:10 <morganfainberg> i'll want some carefule eyes on it, henrynash and I touched some of the same code 18:09:11 <dolphm> morganfainberg: i'll keep an eye out for it -- i'd love to have both gating today 18:09:15 <ayoung> bugs are listed here https://launchpad.net/keystone/+milestone/havana-rc1 18:09:21 <morganfainberg> i don't think there are any regressions, but.. worth extra eyes on it 18:09:34 <henrynash> morganfainberg: happy to help out 18:09:48 <ayoung> morganfainberg, did your domain patch go through? 18:10:03 <morganfainberg> ayoung, no, got yanked into more meetings. 18:10:25 <morganfainberg> today i can work on the pre-req, but we have open-topic stuff to cover for it (as per our conversation last night() 18:10:56 <ayoung> morganfainberg, yeah...I think that I might have a work around on the DN composition...see this 18:11:20 <dolphm> it looks like this is on track to land in havana? (cc: morganfainberg, henrynash) https://review.openstack.org/#/c/45649/ 18:11:35 <morganfainberg> dolphm, that was what ayoung and i were just talking about. 18:11:46 <morganfainberg> but yes, i want that in Havana. 18:11:50 <ayoung> https://bugs.launchpad.net/keystone/+bug/1210141/comments/4 18:11:52 <uvirtbot> Launchpad bug 1210141 in keystone "LDAP identity provider fails when using samAccountName" [Medium,In progress] 18:12:34 <ayoung> dolphm, BTW, I think the bug ^^ can be addressed by config file changes. 18:12:47 <ayoung> which is also addressed in that comment. 18:13:05 <dolphm> ayoung: is the bug invalid, or do we need to make supporting documentation / test changes? 18:14:08 <bknudson> yes, we just need to document how to set up LDAP. 18:14:48 <bknudson> http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-identity.html 18:15:34 <gyee> \o 18:15:37 <gyee> sorry I am late 18:16:25 <dolphm> shouldn't user_id_attribute = dn, and user_name_attribute = samAccountName ? 18:16:57 <ayoung> dolphm, I think documentation change might be called for. It would not be obvious from the existing docs that this would work 18:17:37 <dolphm> ayoung: sounds fair 18:17:45 <dolphm> i'm going to lower priority and unblock from rc1 18:18:06 <ayoung> dolphm, you would think so, but the the id is the full dn...which might break HTTP spec. I haven't tested that yet. But if they are using samAccountName as the ID, then user_id_attribute is samAccountName 18:18:18 <ayoung> agreed 18:18:48 <dolphm> ayoung: i guess i meant havana, or post-havana (not today) 18:18:58 <dolphm> ayoung: in *theory* 18:20:02 <dolphm> is this a dupe? bug 1226475 18:20:03 <uvirtbot> Launchpad bug 1226475 in keystone "Update user v2.0 does not automatically assign user on new tenantId" [Medium,New] https://launchpad.net/bugs/1226475 18:20:19 <dolphm> i know we just talked about this, but i couldn't find an existing bug 18:21:16 <bknudson> dolphm: https://bugs.launchpad.net/keystone/+bug/1201251 18:21:17 <uvirtbot> Launchpad bug 1201251 in keystone "issues of updating user via keystone rest api" [Medium,In progress] 18:21:27 <bknudson> https://review.openstack.org/#/c/42826/ 18:22:19 <morganfainberg> This is partially related to the bug I'm working on. 1219739 18:22:33 <morganfainberg> bug 1219739 18:22:37 <uvirtbot> Launchpad bug 1219739 in keystone "Inconsistent use of tenant_id, tenantId, default_project_id across identity drivers for the User object/ref" [High,In progress] https://launchpad.net/bugs/1219739 18:23:33 <henrynash> morganfainberg: so I think it's create that we are attacking that….do we need to do that now (e.g. for the domain fix) or is it just cleanup? 18:23:43 <henrynash> (so I think it is great….) 18:23:54 <morganfainberg> ah. 18:24:05 <bknudson> henrynash: the bug is that you create tenant_id with v2 but v3 expects default_project_id 18:24:18 <morganfainberg> bknudson, that should be fixed with my changeset. 18:24:34 <morganfainberg> since i normalize tenantId and default_project_id everywhere 18:24:37 <bknudson> there's another bug where you change tenant_id and you don't get added to the new tenant 18:24:48 <morganfainberg> in v3, right? 18:25:03 <morganfainberg> v2 seems to have that code already 18:25:33 <dolphm> bknudson: that's what this patch is doing https://review.openstack.org/#/c/42826/22/keystone/identity/controllers.py 18:25:35 <bknudson> morganfainberg: https://review.openstack.org/#/c/42826/22/keystone/identity/controllers.py 18:25:44 <bknudson> dolphm: quit reading my mind 18:26:00 <dolphm> bknudson: these bugs are nearly dupes, but i'm hesitant to mark them as such 18:26:31 <dolphm> mostly because the older one has a bunch of issues (and should really be filed as multiple bugs...) 18:26:33 <bknudson> morganfainberg: what code did you think v2 has already? 18:26:33 <morganfainberg> bknudson, right. 18:26:51 <morganfainberg> bknudson, looking. because i was just working in there. 18:26:56 <bknudson> dolphm: could have them add the new bug to the message. 18:27:45 <morganfainberg> bknudson, it has logic, just making it more role friendly 18:28:15 <henrynash> morganfainberg: I may have removed one of the few places where we checked for both tenantID vs PRojectID with my (merged) patch of: https://review.openstack.org/#/c/45584/7 18:28:33 <morganfainberg> https://review.openstack.org/#/c/46207/10/keystone/identity/controllers.py i was lifting logic up to the controller 18:28:41 <morganfainberg> so some of the same fix is in my patchset in tenantId cleanup 18:29:02 <henrynash> morganfainberg: no question that your change makes things cleaner... 18:29:03 <morganfainberg> henrynash, ah, i'll keep my eyes open for it 18:29:04 <dolphm> so, https://review.openstack.org/#/c/42826/ removes an authz check on an API method ... -2'd until that's fixed 18:29:43 <bknudson> dolphm: I'd complained about that earlier, but this function calls add_user_to_project which does the same assert. 18:29:52 <bknudson> sorry, calls update_user() 18:30:29 <dolphm> bknudson: oh wow, i didn't realize it was calling another controller method 18:30:30 <bknudson> dolphm: although I agree that shouldn't have made that change... I probably wouldn't have. 18:31:38 <bknudson> morganfainberg: it does look like your change in https://review.openstack.org/#/c/46207/10/keystone/identity/controllers.py does the same as https://review.openstack.org/#/c/42826/22/keystone/identity/controllers.py 18:31:42 <dolphm> bknudson: a comment or something would have been nice 18:32:16 <morganfainberg> bknudson, right becasue i needed to lift the logic into the controller. i don't address v3, because the functionality wasn't there to begin with 18:32:41 <dolphm> morganfainberg: that's by design -- v3 is spec'd to not have that behavior 18:32:47 <morganfainberg> dolphm, right. 18:36:38 <dolphm> chmouel: any chance you have a revision in the works for this? https://review.openstack.org/#/c/45447/ 18:37:02 <chmouel> dolphm: woops i have forgotten about this, let me update it by tomo 18:37:08 <dolphm> chmouel: thank you :) 18:37:16 <chmouel> dolphm: thanks reminding me ;) 18:39:33 <atiwari> any thoughts on https://review.openstack.org/#/c/46123/5 and https://review.openstack.org/#/c/46589/6 18:39:36 <atiwari> ? 18:39:51 <dolphm> atiwari: i was just looking at 46589 18:40:20 <dolphm> atiwari: it's not obvious that a KeyError would be raised by calling rule(), and unless that's part of it's documented API ... i suspect oslo will reject this change 18:40:26 <atiwari> ok, it is change proposed for 46123 in OSLO 18:40:45 <ayoung> atiwari, why are we getting key errors? 18:41:12 <dolphm> ayoung: the comment in the except block explains how they could be produced 18:41:15 <ayoung> I guess since our rules are written as "ors" this might be OK 18:41:15 <bknudson> changes in openstack/common need to be pulled in from oslo 18:41:18 <atiwari> ok, if there are two rules and while evaluation first there is not enough data in target 18:41:20 <bknudson> we can't have keystone different here. 18:41:27 <atiwari> we should move to next 18:41:46 <morganfainberg> bknudson, ++ 18:41:51 <dolphm> bknudson: ++, this is the same change proposed against oslo https://review.openstack.org/#/c/46589/6/openstack/common/policy.py 18:41:55 <atiwari> ayoung, yes 18:42:01 <lbragstad> bknudson: +1 18:42:10 <ayoung> atiwari, so we are saying these rules are Ored together, and only one of them needs to pass in order for the rule to allow access? 18:42:23 <atiwari> that is correct 18:42:36 <bknudson> oh, this is oslo already. 18:42:41 <atiwari> if 1sr got failed we should moved to next 18:42:51 <dolphm> anyone know who's core on oslo that would be most likely to review this change? 18:42:51 <ayoung> atiwari, but the logic is written such that first failure short-circuits, no? 18:43:18 <topol> I always bug dims for oslo stuff 18:43:19 <atiwari> no, first failure move one 18:43:26 <lbragstad> dolphm: bnemec_ is core, so is dims 18:43:29 <ayoung> dolphm, markmc is usually pretty on-top of opolicy changes 18:43:58 <atiwari> look at the test https://review.openstack.org/#/c/46589/6/tests/unit/test_policy.py 18:44:00 <dolphm> ayoung: i want to say either markmc or dprince wrote the original policy impl in oslo 18:44:28 <ayoung> atiwari, that is what I meant, first success short circuits... 18:44:39 * ayoung can't type 18:45:06 <ayoung> ok...so the logic as is is safe, but the catching of the exception should be handled by the "or" logic, I think 18:45:28 <ayoung> I thought there was a specific OR rule. 18:45:56 <atiwari> yes, this while evaluating OR 18:46:11 <atiwari> class OrCheck(BaseCheck): 18:46:20 <bknudson> ayoung: https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py#L423 18:47:31 <ayoung> bknudson, I was thinking of this https://github.com/openstack/keystone/blob/master/keystone/openstack/common/policy.py#L338 18:48:09 <bknudson> ayoung: that's the keystone version... which seems a little different? 18:48:32 <atiwari> yes, that is what I am trying to mention in my comments 18:48:33 <ayoung> bknudson, yeah, but just cuz we haven't synced in a few...I think it is time for policy to become its own libarary 18:48:53 <henrynash> ayoung: we sync at the end of Grizzly... 18:49:04 <bknudson> atiwari: why is it just OrCheck, doesn't this apply to every rule? 18:49:20 <dolphm> bknudson: i think we're way behind on syncing policy 18:49:24 <atiwari> I dont think it should for AND 18:49:36 <dolphm> bknudson: afaik, we've only ever sync'd it once, after it was originally added 18:49:42 <bknudson> atiwari: AND should raise KeyError but OR shouldn't? 18:49:50 <atiwari> correct 18:50:02 <henrynash> dolphm: the policy engine? No, I synced it at the end of Grizzly 18:50:14 <ayoung> so...key_error should just trigger a false, right? 18:50:15 * topol hard to argue with atiwari's argument. QED 18:50:16 <atiwari> A policy check that requires that at least one of a list of other 18:50:17 <atiwari> checks returns True. 18:50:25 <ayoung> atiwari, what rule was generating the key error? 18:50:42 <atiwari> ok, in https://review.openstack.org/#/c/46123/5 18:51:05 <atiwari> I am trying to make the target as the x-subject-token 18:51:28 <atiwari> in case token is gone or revoked your target will have nothing 18:51:29 <ayoung> atiwari, um...doesn't it need to be parsed first? 18:51:32 <henrynash> atiwari: you can't have two substations in the same rule 18:51:37 <bknudson> atiwari: seems like the check should be in https://github.com/openstack/oslo-incubator/blob/master/openstack/common/policy.py#L838 -- would return False if KeyError 18:51:58 <ayoung> GenericCheck? 18:52:14 <henrynash> atiwari: split it up like I did for the demain and project checks 18:52:19 <atiwari> it did not get there 18:52:39 <ayoung> cred[self.kind] should be a get 18:52:57 <atiwari> you do not have enough info for GenericCheck 18:53:07 <atiwari> you failed before GenericCheck 18:53:25 <henrynash> dolphm: 7 mins to go….other Havana bugs we need to discss? 18:53:29 <ayoung> atiwari, OK, lets continue this after meeting 18:53:34 <atiwari> ok 18:53:42 <dolphm> henrynash: i'm looking! i don't see any standouts 18:54:03 <dolphm> actually i was trying to figure out where babel is supposed to come from 1226736 18:54:07 <dolphm> bug 1226736 18:54:08 <uvirtbot> Launchpad bug 1226736 in python-keystoneclient "Missing dependency on babel" [Undecided,In progress] https://launchpad.net/bugs/1226736 18:54:16 <lbragstad> dolphm: do you consider this a bug https://bugs.launchpad.net/keystone/+bug/1226132 or under the new feature category for notifications? 18:54:19 <uvirtbot> Launchpad bug 1226132 in keystone "Keystone doesn't emit event notifications for domains" [Wishlist,Triaged] 18:54:41 <lbragstad> I can push something up with notifications implemented for domains if so 18:54:58 <dolphm> lbragstad: i think it's a bit more complicated than it sounds -- because if you send a notification for a domain, you should also be sending notifications for all consmuming users & tenants 18:55:00 <ayoung> lbragstad, nothing will be able to consume it this go round...icehouse IMO 18:55:05 <henrynash> dolphm: we definitely should get https://review.openstack.org/#/c/46972/ in 18:55:09 <dolphm> s/consuming/owned/ 18:55:26 <lbragstad> dolphm: ayoung ok that sounds good 18:55:27 <henrynash> bug 469722 18:55:32 <uvirtbot> Launchpad bug 469722 in nautilus "Karmic Koala does not automount usb devices (dup-of: 463347)" [Low,Incomplete] https://launchpad.net/bugs/469722 18:55:33 <uvirtbot> Launchpad bug 463347 in udev "devices not detected -- too many open files" [High,Fix released] https://launchpad.net/bugs/463347 18:55:41 <henrynash> oops 18:55:44 <ayoung> heh 18:55:52 <henrynash> bug 46972 18:55:54 <uvirtbot> Launchpad bug 46972 in kubuntu-docs "index of links remained not translated for guides already translated" [Medium,Fix released] https://launchpad.net/bugs/46972 18:56:05 <henrynash> hmm 18:56:06 <dolphm> henrynash: then fix your pep8's :) 18:56:22 <henrynash> bug 1226225 18:56:22 <uvirtbot> Launchpad bug 1226225 in keystone "v2 token cache not correctly invalidated when using "Belongs To"" [High,In progress] https://launchpad.net/bugs/1226225 18:56:23 * topol is henrynash moonlighting on other projects??? :-) 18:56:37 <henrynash> git it, duh... 18:57:03 <henrynash> and that will enable bug 1153645 18:57:04 <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:57:28 <dolphm> speaking of random bug numbers, i hope everyone is familiar with bug 1 18:57:37 <uvirtbot> dolphm: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable 18:57:43 <dolphm> ha 18:57:49 <dolphm> bug #1 18:57:54 <bknudson> uvirtbot doesn't even know bug 1. 18:57:57 <uvirtbot> dolphm: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable 18:57:58 <uvirtbot> bknudson: Error: "doesn't" is not a valid command. 18:57:59 <uvirtbot> bknudson: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable 18:58:05 <dolphm> https://bugs.launchpad.net/ubuntu/+bug/1 18:58:06 <uvirtbot> dolphm: Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable 18:58:48 <bknudson> wanted to mention I got a doc change in: https://review.openstack.org/#/c/46686/ 18:59:03 <bknudson> bug 1090655 18:59:04 <uvirtbot> Launchpad bug 1090655 in openstack-manuals "grizzly: keystone user groups" [Medium,Fix released] https://launchpad.net/bugs/1090655 18:59:09 <dolphm> bknudson: awesome! 18:59:18 <bknudson> a small pebble in the grand canyon of missing docs. 18:59:30 <dolphm> one small step... 18:59:39 <dolphm> switching to -dev 18:59:40 <dolphm> #endmeeting