18:00:49 <heckj> #startmeeting keystone 18:00:50 <openstack> Meeting started Tue Oct 30 18:00:49 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:52 <openstack> The meeting name has been set to 'keystone' 18:01:38 <heckj> Agenda for today at http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:47 <heckj> ayoung? 18:01:50 <heckj> dolphm? 18:02:13 <heckj> #topic High priority bugs or immediate issues? 18:02:20 <heckj> Anything new popping up? 18:02:45 <heckj> There's been some ongoing conversation on PKI tokens with some of the the Horizon crew 18:02:58 <dolphm_> (Running back to my desk) 18:03:10 <heckj> dolphm: np - we'll give you a few 18:03:17 <ayoung> \)/ 18:03:36 <ayoung> that is me running in the room realizing I was late 18:03:46 <heckj> tl;dr of horizon discussion - PKI as a default is causing havoc with current Horizon implementaiton in devstack - looking for potential solutions 18:03:52 <heckj> heh 18:04:08 <gyee> what problems? 18:04:10 <ayoung> heckj, simple fix is to A) key the PKI tokens by hash and B) store the hash in the cookie 18:04:16 <ayoung> but they don't want the simple fix 18:04:26 <ayoung> they want to push all state over to keystone so: 18:04:33 <ayoung> we still do ^^ 18:04:44 <heckj> ayoung: I didn't read that actaully - I think they're fine with that concept, we just don't have a public API lookup by hash at this point 18:04:52 <ayoung> and then, if they don't want to run memcached, it will fall back to online checking 18:04:58 <ayoung> heckj, yes we do 18:05:05 <ayoung> it is the token validate call 18:05:17 <ayoung> it should respond to the HASH of to token 18:05:31 <ayoung> as that is the ID stored in the database 18:05:57 <ayoung> caveat 18:06:07 <heckj> ayoung: wasn't clear to me - we ought to get that into email to gabriel so we can vet it out. If we have a lookup via hash, that should suffice for his immediate needs 18:06:08 <ayoung> I haven't tried it out. 18:06:21 <ayoung> also, I think that is only implemented for SQL 18:06:27 <ayoung> need to confirm 18:06:36 <heckj> cool 18:06:47 <heckj> ayoung: dolphm_: aware of any other hot topics hitting recently? 18:07:08 <heckj> there's also a security bug oustanding related to validating SSL chains I think 18:07:15 <ayoung> heckj, well, I realized I dealt out all of the work last week, and made myself dependent on everyone else getting their stuff in 18:07:38 <ayoung> for example the above change would need to be duplicated with henrynash 's work on moving auth_token to client 18:07:49 <dolphm> (catching up) 18:08:01 <ayoung> heckj, yeah, SSL. I was just discussing with gyee. 18:08:25 <ayoung> We also need to clean up how we generate certificates for SSL in the dev case. 18:08:58 <ayoung> right now, the script he provided last week is good for CA and SSL certs. We need to extend it to generate signing certs for the PKI tokens, too 18:09:01 <heckj> ayoung: sounds like you've got generally positive notes on all of that (pki setup) - no real responses from operators beyond self-signing that I've seen 18:09:41 <ayoung> also, we probably need it to use an existing CA cert if provided in order to just update a working deployment 18:10:07 <dolphm> heckj: user/project name uniqueness (global vs domain-scoped) 18:10:11 <ayoung> heckj, other than that...REMOTE_USER has some feedback that I wil be incorporating. 18:10:40 <ayoung> dolphm, I thought we had agreed: global to start, but scoped back to per domain. 18:10:59 <boden> ayoung -- what is the status of that REMOTE_USER review? is there something I need to follow up on? 18:11:05 <ayoung> boden, yea, feedback 18:11:08 <heckj> ayoung: in general, we had - henrynash has been pushing for making that change more aggressively 18:11:11 <gyee> +1 on global, for backward compatibility 18:11:12 <dolphm> ayoung: heckj wasn't aware of that conversation, i don't think 18:11:18 <ayoung> boden, https://review.openstack.org/#/c/14823/ 18:11:33 <ayoung> comment is in the wsgy.py file 18:11:40 <ayoung> I was going to address it 18:11:49 <heckj> dolphm: it was primarily Gabriel writing to Ayoung directly - just happened to CC me in the path 18:11:50 <boden> ayoung -- ok that was the question... you or me :) 18:12:24 <heckj> #topic Pluggable authN: Apache proxy vs pluggable python handlers -- which to support (or both) 18:12:31 <ayoung> boden, I'll post an updated change. The fix breaks the unit tests, so I need to tweak those first. Once I post, +1 if you like 18:12:35 <heckj> I'll come back to the uniqueness and remote-user things in a sec 18:12:40 <dolphm> i don't see any gotchas if we make room for domain-scoped names in the spec, but stick with global-uniqueness in our implementation for now 18:12:49 <ayoung> boden, actually, why don't you make the fix, and that way I can approve. Heh 18:13:12 <boden> ayoung -- ok I can, although I didn't agree with the latest comments I saw from Paul 18:13:31 <ayoung> boden, that is fine. respond in the review then 18:13:53 <boden> ayoung -- I did directly respond to his comments 18:13:53 <gyee> are we sure REMOTE_USER cannot be set by the client? 18:13:55 <ayoung> ah, see that you did 18:14:14 <gyee> s/client/untrusted client/ 18:14:51 <heckj> gyee: hold a sec on that thread 18:15:03 <ayoung> boden, yeah, I was more concerted with the comment in wsgi.py. The others indicate the need to refactor authenticate, but we do that after this patch 18:15:16 <heckj> ayoung: dolphm: what's the current state of Pluggable authN: Apache proxy vs pluggable python handlers 18:15:23 <heckj> Is that specific to the REMOTE_USER thing, or more generic? 18:15:32 <dolphm> ayoung: refactoring should generally happen before you make things worse, not "someday" 18:15:33 <ayoung> heckj, nothing has been done except REMOTE_USER 18:15:48 <ayoung> pluggable should follow a refactor of authenticate 18:16:03 <boden> ayoung -- ok can do... I have no problems with the wsgi comment 18:16:08 <ayoung> gyee, I know you had some work on authenticate you were going to do, but do you mind if I refactor authenticate first 18:16:38 <gyee> ayoung, go ahead 18:16:51 <ayoung> gyee, actually, that would free you up to tackle the SSL client stuff, if you want it. 18:17:01 <gyee> sounds good 18:17:39 <ayoung> heckj, Ok, so pluggable will follow on a refactor of authenticate, where we can just alyout what is supposed to happen in clean, readable Python first 18:18:07 <ayoung> then pluggable will be done by putting values into the authenticate chain based on values in the config file 18:18:30 <heckj> ayoung: sounds like a good plan 18:18:53 <ayoung> gyee was going to tackle that, but it will likely take a little time to clean up authenticate first. 18:19:09 <ayoung> heckj, how come I can't assign bugs to gyee? 18:19:26 <heckj> you can't? 18:20:01 <ayoung> heckj, nope 18:20:06 <ayoung> can you? 18:20:08 <mnewby> i don't mean to interrupt, but i think i have a high priority issue. please let me know when i can voice my concern. 18:20:09 <heckj> ayoung: hmm - you're not a member of "keystone-bugs" group - ading you now 18:20:20 <gyee> ayoung, you will use paste.deploy pipeline for the authn stuff right? 18:20:32 <heckj> thought that was an explicit superset of keystone-core, guess not 18:20:57 <heckj> ayoung: try now, you should be good to go 18:21:49 <heckj> Okay - sounds like we're clear on pluggable AuthN, remote_user, and assorted plans - any further questions/issues there before I hit our last topic? 18:22:20 <mnewby> heckj: is devstack on the agenda? 18:22:40 <heckj> mnewby: nope 18:22:48 <ayoung> mnewby, what about devstack? 18:23:08 <mnewby> by default keystone uses pki, which doesn't appear to be configured by default. 18:23:19 <heckj> mnewby: feel free to add to agenda at http://wiki.openstack.org/Meetings/KeystoneMeeting prior to the meeting and it will be 18:23:28 <ayoung> mnewby, yes it is 18:23:45 <ayoung> mnewby, the change is in keystone/config.py 18:23:58 <dolphm> (referring to pki_setup?) 18:24:00 <ayoung> So long as no one modifies the default config file, they get pki tokens 18:24:21 <mnewby> ayoung: all i know is, i merged with upstream, ran devstack, and got a broken auth config. 18:24:53 <mnewby> ayoung: the concern is this breaks devstack for everyone by default. unless i'm doing something really wrong 18:25:41 <mnewby> ayoung: might be pebkac - just wanted to make sure it was brought to your attention. happy to work offline at resolving. 18:25:57 <ayoung> mnewby, there was a patch for running pki_setup as part of devstack. It is possible that it got removed due to poor patch management. 18:26:22 <ayoung> mnewby, 5119f6b8b75307e4f1fa764c0c56d3953a18e2ed 18:26:25 <mnewby> ayoung: if you could try running devstack as it exists in trunk and see if you can replicate the problem, i would appreciate it. 18:26:51 <heckj> #topic feature-branch merging 18:27:15 <heckj> dolphm: there's a few requests for small changes to one or two of the reviews, otherwise they're mostly all applied 18:27:41 <ayoung> mnewby, I tested a while ago, but willing to test again. 18:27:43 <heckj> Once we have that in place, jeblair and mordred indicated this morning that we could do the feature-branch merge with ... 18:27:50 <heckj> a merge commit 18:27:52 <heckj> #link http://wiki.openstack.org/GerritJenkinsGithub#Merge_Commits 18:27:59 <dolphm> heckj: a single merge commit? 18:28:01 <mnewby> ayoung: yeah, it looks like i'm missing that, i'm guessing i pulled at just the wrong time. i'll let you know. 18:28:12 <heckj> Apparently they gave me permissions (or maybe keystone-core folks) to set up and do a merge commit 18:28:31 <heckj> dolphm: I believe so 18:28:34 <ayoung> mnewby, well, the change has since migrated into the devstack/lib/keystone file, but it is there for me 18:28:45 <dolphm> heckj: hmm alright -- there will be some conflicts to resolve 18:28:59 <heckj> dolphm: yeah, expecting that 18:29:37 <dolphm> heckj: i'll work on fixing outstanding requests 18:29:45 <heckj> dolphm: how's your week looking for this? Do you have time to do any final tweaks and then work with me on getting the relevant merge commits into place and ready to roll? 18:29:52 <dolphm> heckj: absolutely 18:30:15 <heckj> dolphm: cool 18:30:46 <dolphm> heckj: it looks like the client's branch is totally merged -- is that correct? 18:30:55 <heckj> my week is going to be a bit insane, but I'm planning on pushing on this to try and get it nailed down end of this week or early next week 18:31:16 <heckj> dolphm: I think so at this point - I review/approved them all in this morning - haven't looked to see if any had failures 18:31:51 <heckj> #topic open discussion 18:31:53 <dolphm> heckj: if they're all in, we can try a merge commit there 18:31:55 <heckj> Free for all 18:32:25 <henrynash> ok, so how about the infamous "user/project" name uniqueness issue 18:32:28 <heckj> dolphm: I'll start there, and see how it works. I've not used the merge commit thing before, so this is all experiment. Will be pestering james and monty if things go awry 18:33:12 <ayoung> henrynash, so I wanted them unique from the get go. But starting off with globally unique as a more restrictive rule to start simplifies things 18:33:51 <ayoung> but agree that uniqe per domain is the right solution 18:33:52 <heckj> henrynash: I want the simpler for where we are - we're making a lot of delta, and keeping things as simple as possible to start is a high priority for me 18:34:18 <dolphm> i don't want a pesky api constraint to hinder a decent domain-scoped implementation if we come up with one, but we do need to be clear that we're more restrictive than the api for immediate compatibility 18:34:21 <gyee> we need to consider backward compatibility too 18:34:29 <heckj> henrynash: I also *really* want feedback from Ryan Lane and/or Tim Bell related to the end user experience impact. For the browser based setup, it can really be hidden - but from a CLI point of view, it can't. 18:34:32 <ayoung> we need a way to pass the domain from the webUI 18:35:09 <heckj> ayoung: CLI is a first class citizen here - it can't be ignored in this solution either 18:35:19 <henrynash> gyee: so backward compatibility with v2 is OK if you only use a single domain in v3 18:35:23 <ayoung> So lets start there. 2 options: keystone domain maps to hostname of the webserver or webserver has some way to multiplex domains. People are going to want both. Maybe at the same time. 18:35:43 <ayoung> heckj, CLI is trivial. We add another, optional, parameter 18:35:46 <dolphm> domains aren't hostnames 18:36:00 <ayoung> dolphm, didn't say they were 18:36:04 <ayoung> example: 18:36:11 <heckj> ayoung: the change is trivial, but we're aksing for more information as a default basis to operate on the cloud - that's NOT trivial 18:36:14 <ayoung> say redhat gets hosting at keystone 18:36:23 <ayoung> er, rackspace 18:36:28 <ayoung> they hostname then would be 18:36:37 <ayoung> http://redhat.rackspace.com 18:36:38 <dolphm> ayoung: anytime anyone uses "hostname" or "email address" in the same sentence as "keystone domains" i'm going to jump on them 18:36:45 <ayoung> and that would map to the redhat domain 18:37:02 <ayoung> dolphm, yes, but I happen to know what I am talking about 18:37:06 <heckj> what I want is to get some explicit feedback from the operator community or end-user basis with the gist of "yeah, I get it - let's do this!", then I'll be happy shepherding that change forward 18:37:06 <gyee> dolphm, me too, and carry a pile of stones :) 18:37:18 <dolphm> ayoung: lurkers may not (/waves to posterity) 18:37:25 <ayoung> understood. 18:37:48 <ayoung> but what I was saying is that the webUI can be customized such that when a user logs in, they are already constrained to a domain 18:38:12 <gyee> uh, using email as username? 18:38:17 <henrynash> heckj: that's fair….and actually this is my big concern that with domain-uniquness, a class of enterprise can't but hosted in an OS backed public cloud 18:38:42 <heckj> henrynash: yeah - understood. 18:39:12 <heckj> maybe we can reach out explicitly to Ryan and Tim (since there's a kind of lack of "user" committee to bounce this kind of thing off of so far) 18:39:21 <henrynash> gyee: so username is one item, but so is project name….having that be unique would be hard to explain to an enterprise 18:39:52 <dolphm> for the context of https://review.openstack.org/#/c/13400/ i'm going to back off on domain-scoped uniqueness, and revert to global-uniqueness (i.e. no change) ... it's a hot enough topic to deserve it's own review in gerrit 18:40:04 <gyee> henrynash, project name can user the same technique right? 18:40:09 <gyee> project@domain? 18:40:12 <dolphm> i'll also need to propose a revert for tenant name uniqueness 18:40:23 <heckj> dolphm: +1 18:40:40 <henrynash> "what do you mean I can't create a project called "Test" 'cause some some other customer of my cloud provider already had one called that?" 18:40:44 <heckj> gyee: that shorthand has somewhat already sailed in that we never set a convention 18:40:49 <henrynash> (i can hear the support call now) 18:41:14 <gyee> well, are we going to change the public APIs? 18:41:41 <gyee> right now, none of the other OS services are domain-aware 18:42:08 <heckj> gyee: I think it's incumbent on us to encourage them all to become domain aware to allow us to change this. 18:42:21 <henrynash> dolphm: It just seems to me that the time to get this right is the point we introduce domains…i.e. now! 18:42:31 <heckj> meaning we likely need to reach into the other projects, submit change requests, doc updates, etc. to support 18:43:12 <henrynash> heckj: agreed, my oft quote example is images….and wanting those domain wider as well as project wide 18:43:15 <dolphm> henrynash: we are, we're being as restrictive as we can to give ourselves room to get it right :) 18:43:19 * gyee sees a frankenstorm coming :) 18:43:43 <dolphm> revised https://review.openstack.org/#/c/13400/ to be globally-scoped user names 18:44:33 <heckj> Okay - so getting there. 18:44:44 <gyee> so, we've decided neither username and project name need to be globally unique? 18:45:07 <heckj> gyee: right now, we're asserting they need to be globally unique 18:45:13 <dolphm> heckj: +1 18:45:20 <dolphm> (for the moment) 18:45:28 <heckj> gyee: the question is how can we step forward to get us to the place (hopefully quickly) where they don't need to be for compatibility 18:45:44 <gyee> so its still up in the air then 18:46:21 <gyee> I think we really need to measure the impact of such change 18:46:28 <heckj> gyee: what's up in the air? It's globally unique now - (I think) we'd all like to get to a place where it doesn't need to be. Do you disagree there? 18:46:45 <heckj> gyee: not opposed - how would you propose to do so? 18:46:57 <gyee> in a perfect world yes 18:47:19 <gyee> all I am saying is we need to be careful, given the impact of such change 18:47:37 <dolphm> gyee: continuing with global uniqueness is the careful approach, no? 18:47:40 <heckj> gyee: sorry, does that mean you do or don't want to get to an endgame of not requireing global uniqueness? 18:47:44 <gyee> I think the current model is good enough to satisfy the use case 18:47:55 <dolphm> gyee: and we're sticking with it 18:48:01 <gyee> good 18:48:04 <henrynash> so we should first decide if in order to make this change we need a) more evidence that it is needed, or b) a comprehensive bp that describes who we would do this and describes all the impacts 18:48:07 <gyee> +2 for global uniqueness 18:48:19 <henrynash> -1 for global uniquness 18:48:36 <heckj> gyee: Okay - so starting with global uniqueness, do you want to be able to transition to a place where it's NOT required? 18:48:38 <gyee> henrynash, that's still a +1 sum :) 18:48:46 <henrynash> s 18:48:57 <dolphm> revert project names to be globally unique: https://review.openstack.org/#/c/15051/ 18:49:07 <gyee> heckj, as long as we have a smooth transition 18:49:07 <dolphm> +1 party ^ don't be left out 18:50:07 <gyee> dolphm +1 18:51:14 <henrynash> so would it help to build a full bp of the impact of the change to domian-uniquness? 18:51:35 <dolphm> henrynash: absolutely 18:51:43 <gyee> henrynash, +1 18:51:43 <heckj> henrynash: I don't want to set up makework, but I think that would be valuable 18:52:08 <heckj> I think the key question behind this all is how to "migrate to" a world where it's not globally unique and do so smoothly 18:52:28 <henrynash> i feel very strongly that we need this for OS to be successful, so am OK with putting the time in 18:52:47 <heckj> henrynash: combine that with some explicit feedback from Tim and Ryan (any anyone else who wants to step up from the user community) and we should have the makings of a reasonable plan 18:53:15 <henrynash> ok, sounds good 18:53:57 <ayoung> gyee, since you are going to be tackling some other client issues, can I fob keyring support off on you? https://bugs.launchpad.net/keystone/+bug/1040361 18:53:58 <uvirtbot> Launchpad bug 1040361 in keystone "Use Keyring to store Tokens" [Medium,Triaged] 18:54:16 <gyee> ayoung, now you are pushing it 18:54:45 <ayoung> gyee, It looks like support for it is in some of the clients already, just not the keystone client 18:55:04 <gyee> sure 18:55:05 <ayoung> I have been suggesting it for a while, as it limits the amount of calls that go to keystone 18:55:46 <heckj> would be nice - 18:55:51 <heckj> I think nova has some of that support too 18:55:54 <henrynash> on the subject of https://bugs.launchpad.net/keystone/+bug/1039567 (which we assigned to me)…I'm still up for this, but slight delay in IBM getting my fu*%&! CLA signed, should happen this week or early next... 18:55:55 <uvirtbot> Launchpad bug 1039567 in keystone "auth_token middleware should be stand alone" [High,Triaged] 18:56:00 <heckj> (i.e. you can steal idaes/code setup from that client I think) 18:56:12 <gyee> heckj, yeah 18:56:16 <henrynash> …..I know others are dependant on the, so wanted to make sure this is still OK 18:56:24 <heckj> ayoung: ^^? 18:56:54 <heckj> with merging in the feature branches, I think we can work with the delay, but checking on you since some bugs are on your plate and impacted by this 18:57:08 <gyee> henrynash, I understand your pain, I've been there :) 18:57:14 <ayoung> heckj, yeah, I'm ok with it. The only issue is that we might need to make a fix to the keystone auth_token for Horizon. That will need to get synced up, too. I'll ping henrynash on it 18:57:23 <henrynash> ok 18:57:52 <heckj> sounds good 18:57:54 <ayoung> henrynash, should be a clear change to port. Just keying memcached off the hash as opposed to the whole token. 18:58:01 <ayoung> Means I need hash in the client as well, 18:58:07 <ayoung> I->we 18:58:22 <henrynash> more the merrier 18:58:24 * heckj nods 18:58:36 <henrynash> (not really) 18:59:10 <heckj> Okay - going to wrap this up for now 18:59:16 <heckj> #endmeeting