18:00:38 #startmeeting keystone 18:00:38 Meeting started Tue May 28 18:00:38 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:41 The meeting name has been set to 'keystone' 18:00:46 hey 18:00:53 * ayoung here too 18:01:04 hi 18:01:04 ayoung: gyee: termie: o/ 18:01:11 bknudson: o/ 18:01:29 #topic High priority bugs or immediate issues 18:01:51 so, i'd like to keep this meeting as short as possible, because we do have a high priority issue... 18:02:20 we opened bug 1179615 today as public security 18:02:22 Launchpad bug 1179615 in keystone/folsom "[OSSA 2013-014] auth_token middleware neglects to check expiry of signed token" [Critical,In progress] https://launchpad.net/bugs/1179615 18:02:41 and the patch is failing at gate due to integration failures https://review.openstack.org/#/c/30743/ 18:03:14 ongoing conversation in the review + #openstack-dev if anyone wants to jump in and help 18:03:39 (i'm going to assume that's the only high priority issue because that's all i'm aware of) 18:03:47 #topic havana milestone 1 18:04:02 milestone 1 is being cut later today for may 30 18:04:17 we have one outstanding blueprint 18:04:28 Unified Logging 18:04:31 #link Unified Logging 18:04:38 whoops 18:04:39 #link https://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone 18:04:53 lbragstad: o/ 18:05:06 the implementation is currently blocked by a build failure, -2 by ayoung, and broken default config values 18:05:21 yep, I have a review up but I had a couple of questions on the default config values 18:05:33 I wonder how the other projects got around the default config values problem? 18:05:35 lbragstad: i assume you have a patch that would fix build failures? 18:05:36 I wanted to get some input from you guys before respinning the patch 18:05:54 ayoung: i think your -2 is a valid concern but shouldn't be blocking, as it's not creating a hard dep on eventlet 18:06:06 so the only issue that remains is how we handle broken default values 18:06:16 https://review.openstack.org/#/c/29803/ 18:06:24 there is the review, if anyone needs it 18:06:25 what's the error? 18:06:28 lbragstad: can we simply override oslo's defaults with more sensible defaults? or do we need to patch oslo first and then consume the fix? 18:06:57 bknudson: the default values that oslo provides for logging don't work for keystone 18:06:59 dolphm: if we make any changes to oslo it needs to land in oslo before we can pull it into keystone 18:07:06 lbragstad: right 18:07:12 lbragstad: which means this is pushed to m2 18:07:31 lbragstad: which is fine, but if there's a workaround, we still have a bit of time today to get it in 18:08:00 Looks like it expects an "asctime" argument in the dict passed in 18:08:08 (from looking at http://paste.openstack.org/raw/37611/) 18:08:12 right, so the only thing is determining what the default values should be for these config options so if we need to makes changes to oslo we know what to change, 18:08:47 lbragstad: i would think the default values in oslo should be very generic and work for any project 18:09:00 lbragstad: kwargs like "instance" are *way* to specific for oslo 18:09:04 dolphm: I agree, and %(instance)s kind of breaks that 18:09:10 dolphm: +1 18:09:19 maybe this needs discussion on the -dev mailing list 18:09:20 lbragstad: do we have a way to override the defaults from the keystone side, though? 18:10:05 dolphm: we could try and get around it somehwere in keystone/common/config.py 18:10:21 I am treating that as an interface to the new logging from oslo 18:10:21 lbragstad: do you have time to try? 18:10:34 dolphm: yeah, I can give it a shot 18:10:36 cool 18:11:03 (skipping around the agenda a tiny bit) 18:11:05 #topic keystoneclient vs openstackclient 18:11:14 question is- What enhancements we should still allow into keystoneclient? 18:11:15 so i put that on 18:11:40 just thought we should clarify when we should still update keystonecleint 18:11:43 I assume this is just the keystone command-line utility 18:11:44 i think my answer to that is that anything can go into keystoneclient except new CLI features -- CLI bug fixes and polish is fair game 18:11:50 dolphm, I was worried that the change was pulling in Eventlet indirectly, via the "Weak" attribute, if I read the code right. 18:12:08 ayoung: weakref correct? 18:12:17 ayoung: it is, but only if the deployment's configuration opts in 18:12:22 (i think) 18:12:43 henrynash: is that a satisfactory answer, or did you have a specific case? 18:13:16 lbragstad, if you can confirm that, I'll remove the -2 18:13:24 dolphm: Ok, so defecto rule: cli commands/parameters are fixed…. 18:13:26 ayoung: thanks 18:13:37 maybe we should document the decision of what enhancements go into keystoneclient somewhere. so someone doesn't go about implementing something 18:13:43 ayoung: confirm that weakref isn't pulling in eventlet as a hard dep? 18:13:49 only to get -2d 18:13:54 henrynash: unless it's a bug fix or trivial user experience polish 18:14:17 bknudson: that'd be nice -- perhaps in the docstr of keystoneclient.cli? 18:14:19 dolphm: bug fix sure…..user experience polish might be a bit of a slippery slope 18:14:34 ayoung: from what I have researched so far, it uses weakref to switch between contexts 18:14:36 lbragstad, yes, that we are not pulling in more deps on eventlet as we move forward. We are actively working to corral the eventlet code, and interpsersing it throughout oslo code makes it harder to do that 18:14:46 I've got to admit I'm a little worried about openstack client... just from the lack of progress. Wish I had time to help out 18:14:59 (i guess the trivial part is subjective, but fine) 18:15:11 dolphm: is there a README or HACKING in python-keystoneclient? or, add it to the readme. 18:15:13 bknudson: i worry about keystoneclient the same way :P 18:15:21 #action dolphm to document in keystoneclient that CLI evolution is deprecated in favor of openstackclient 18:15:28 bknudson: yes, i'll probably do both 18:15:36 dolpM; excellent 18:15:46 #topic Inherited roles from domain 18:15:51 #link https://review.openstack.org/#/c/29781/ 18:15:54 henrynash: all yours 18:15:59 gyee: you here? 18:16:25 he had the only booking comment right now.... 18:16:35 (blocking...) 18:17:02 since he's not here, anyone else have issues? If not, I'll close it offline with him 18:18:04 I had a comment about using PUT vs PATCH 18:18:13 ahh, right thanks yes... 18:18:23 seemed like PUT handled everything so PATCH wasn't necessary 18:19:04 It's more of a question of stateless/idempotent vs stateful 18:19:14 was a bit uncomfortable using PUT to overwrite an attribute in an existing "object" 18:19:28 this is how PUT normally works in HTTP 18:19:39 it replaces whatever's there with the new object 18:19:45 a whole new object* 18:19:48 e.g., if you PUT a file to a web server 18:20:01 yes, a whole new object, not replacing parts of it 18:20:16 I thought we were trying to use PATCH for partial updates? 18:20:28 nice thing is you always know what you get in the end. 18:20:33 (of course PUT will have the desired affect) 18:20:37 henrynash: bknudson: we can side step the entire issue by creating a whole new resource like PUT /domains/{domain_id}/users/{user_id}/inherited-roles/{role_id} 18:21:53 that way you crud them completely separately, and we can put the burden of transparently handling both sets correctly on the client side 18:22:16 What does "PUT /domains/{domain_id}/groups/{group_id}/roles/{role_id}" do now if the role is already granted to the group on domain? 18:22:18 we could do that….have to think through the implications of creating a new "class" of role across the apis 18:22:34 respond with 204 No Content again or something else already exists? 18:22:42 so if you tried to add a role as inherited, and it was already non-inherited, the client could delete the non-inherited role and create an inherited role 18:23:06 bknudson: should raise a 409 conflict 18:23:40 s/add/assign/ 18:24:02 dolphm: there is one thing I like about your idea…in that in my proposal an inherited role ends up on the domain AND the projects within it…. 18:24:14 …and actually you really want one or the other 18:24:57 you erither have a role on a domain (to admin stuff at that level) or you want the role to (just) appear at each project... 18:25:10 I think that first slightly better with what you siggest 18:25:51 henrynash: interesting, i hadn't actually considered that 18:26:34 dolphm: let me try re-working along that idea and if it pans put I'll update the proposa; 18:26:38 proposal 18:26:44 henrynash: alternatively, PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inheritance <-- slightly different semantics 18:27:09 #topic open discussion 18:27:37 about 30 minutes left, but i'm going to go fuss over https://review.openstack.org/#/c/30743/ 18:30:15 so what's happening is that new tokens are considered invalid? 18:31:32 UUID tokens that *should* be valid are being denied 18:31:56 bknudson: and getting the expected logs out of the vm has been an issue 18:32:01 by keystone server or auth_token middleware? 18:32:04 bknudson: they appear to be truncated early 18:32:18 bknudson: keystone server returns 200, auth_token denies, inexplicably 18:33:27 UUID tokens weren't a problem before, only PKI tokens... 18:34:32 bknudson: correct 18:39:50 henrynash: Got a question regarding keystone client test test_auth_token_middleware.py 18:40:03 Question: Do we expect to populate http headers with none values? 18:40:18 nachi: headers can't really be null 18:40:36 I see that the tests in keystone client code which expects headers with none values when authenticating against v3 for unscoped token. 18:40:43 you don't know if it's "invalid token format:" or "Token expired a " ? 18:41:14 https://github.com/openstack/python-keystoneclient/blob/master/tests/test_auth_token_middleware.py#L1391 18:42:42 nachi: so you mean the headers of just env variables being set by auth_middleware? 18:42:56 yes 18:43:27 nachi: sorry, I meant that as a question….is it headers OR env variables? 18:45:43 http headers 18:46:53 nachi: I think you are referring to wsgi environment variables actually….I believe that's how we pass the info from auth_token to whatever is following in the pipeline 18:47:12 henrynash: Sorry I am late but added some concern about inherited roles design in https://review.openstack.org/#/c/29781/ . Can we revisit that topic? If time permits. 18:47:56 sorry, was in a meeting and am late, wanted to toss this: https://review.openstack.org/#/c/27597/ on the "to be discussed" if therte is time. 18:48:01 atiwari: thx, just saw your comments - good to receive them…I'll look at them later and respond - we are still working through the api changes anyway... 18:49:06 or. uhm. did i misread the meeting :P 18:49:28 np, basically I am proposing scoping of inherited roles to one domain but not to all customer domains 18:50:15 atiwari: without thinking it through….my gut feel is negative to that….but want to study your issues more closely before I respond! 18:50:31 sure 18:51:05 atiwari: we want to really get this right and not get ouselves into more problems than we are trying to solve :-) 18:51:26 nachi: does that make sense? 18:51:28 henrynash: thanks 18:51:33 yes, that is what my comment all about :) 18:51:37 henrynash: yes 18:52:00 atiwari: agreed 18:52:23 morganfainberg: sorry, meeting kind of dissolved early due to an urgent issue 18:52:36 henrynash: ah no worries. 18:52:57 like i said, i was in a meeting and missed a lot because… well… meeting :P 18:53:22 morganfainberg: :-) 18:59:10 #endmeeting