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