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