18:06:48 <ayoung> #startmeeting Keystone 18:06:49 <openstack> Meeting started Tue Jun 25 18:06:48 2013 UTC. The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:06:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:06:52 <openstack> The meeting name has been set to 'keystone' 18:06:54 <gyee> yah ayoung! 18:07:17 <topol> gyee was sweating a potential battlefield promotion if you didnt show 18:07:43 <ayoung> Attending I see gyee topol lbragstad [1]fabio bknudson stevebaker 18:07:48 <ayoung> argh 18:07:50 <ayoung> stevemar, 18:07:55 <stevemar> ;) 18:08:00 <ayoung> dolphm is PTO 18:08:11 <bknudson> he earned it. 18:08:19 <topol> yep 18:08:24 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting 18:08:35 <bknudson> the rest of us have to step up and do code reviews. 18:08:37 <ayoung> #topic Havana milestone 2 18:08:48 <ayoung> What is burning for H2? 18:08:59 <ayoung> We have 3 weeks, and I am PTO next week. 18:09:00 <gyee> pluggable token provider? 18:09:03 <bknudson> probably henrynash 18:09:06 <bknudson> 's blueprints 18:09:10 <bknudson> and pluggable token provider 18:09:18 <bknudson> does pluggable token provider affect the api? 18:09:24 <gyee> bknudson, no 18:09:35 <ayoung> #link https://launchpad.net/keystone/+milestone/havana-2 18:09:58 <bknudson> service catalog affects the api 18:10:05 <gyee> ayoung, opt-out service catalog is high priority 18:10:08 <ayoung> Split Identity should be targetted there as well 18:10:11 <gyee> as it is impacting PKI token size 18:10:14 <ayoung> gyee, who is working on that? 18:10:20 <gyee> ayoung, fabio 18:10:26 <bknudson> There's a review up for it already. 18:10:32 <ayoung> [1]fabio, can you et that for H2? 18:10:36 <[1]fabio> yes 18:10:41 <ayoung> Ah,. OK. lets target H2 that 18:10:41 <bknudson> but it looked like the code was changing before the api spec. 18:10:44 <ayoung> link? 18:11:00 <gyee> #link https://review.openstack.org/#/c/33188/ 18:11:14 <[1]fabio> I will make the API changes by EOW 18:11:21 <ayoung> [1]fabio, Get a blueprint link in there, and we cabn link the BP to the H2 release. 18:11:42 <gyee> [1]fabio, what up with the [1]? 18:11:53 <bknudson> to distinguish him from the other fabio 18:11:57 <[1]fabio> Don't know, stupid IRC client, I guess 18:12:00 <topol> the one and only fabio 18:12:05 <gyee> my keyboard is kindda [1] unfriendly 18:12:06 <bknudson> I can't believe it's not fabio 18:12:27 <topol> we did that joke last time 18:12:32 <gyee> [1] looks like a big f u sign 18:12:34 <gyee> sight 18:13:08 <gyee> just kidding 18:13:15 <topol> fabio I just edited my name. you should be able to as well 18:13:27 <bknudson> [1]fabio: looking forward to the api spec change. 18:13:29 <[1]fabio> how you do that, please? 18:13:37 <gyee> use /nick command 18:14:04 <topol> my chatzilla has a name pulldown next to the typing window 18:14:46 <ayoung> , so the only BPs tagged unstarted for H2 are 18:14:55 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles 18:15:05 <ayoung> #action henrynash to update 18:15:19 <ayoung> and v3 Region API 18:16:00 <ayoung> which was jaypipes , blocked by termie but due to the fact he wanted to make sure the approach was general enough. 18:16:06 <ayoung> That review has lapsed 18:16:20 <atiwari> can we look https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition for H2? 18:16:27 <atiwari> has some API change 18:16:45 <gyee> #link https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition 18:17:31 <atiwari> mostly for roles API 18:17:42 <gyee> I like the service attribute approach 18:17:50 <ayoung> atiwari, are you wroking on it? 18:17:51 <gyee> service role attribute 18:18:17 <atiwari> yes, started the BP I can start soon 18:18:38 <atiwari> based on +1/+2 18:18:39 <gyee> ayoung, can we at least bless the BP first? 18:19:20 <gyee> we can hash out the design details 18:19:35 <ayoung> gyee, so role names should be global, so I can't say as I agree with that. I think it shows a fundamental misunderstanding of how our RBAC is iplemented 18:19:52 <ayoung> it is groups that can come from different organizations, not roles 18:20:07 <atiwari> it will not impact RBAC 18:20:10 <ayoung> roles are to determine what perms a user has in a service, so that should be global 18:20:24 <ayoung> atiwari, I am specifically addressing the verbage in the BP 18:20:32 <gyee> ayoung, you are confusing role names with role IDs 18:20:57 <gyee> having role names global is inflexible 18:21:11 <gyee> just like we do away with having user names global 18:21:13 <ayoung> Ah, OK...He is saying specifically only per service. I can get behind that 18:21:29 <gyee> correct, roles are service-specific anyway 18:21:34 <atiwari> sorry, if it is confusing 18:21:49 <ayoung> atiwari, nah, I;m just in too much of a rush and jumping to conclusions 18:22:31 <ayoung> OK, action Item, lets get some feedback on that BP 18:22:40 <gyee> sounds good 18:23:01 <ayoung> I can take a look after this meeting, atiwari feel free to noodge me 18:23:08 <gyee> #action need feedback on https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition 18:23:10 <atiwari> ok 18:23:12 <ayoung> #action ayoung to review https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition 18:23:20 <atiwari> great 18:24:37 <gyee> ayoung, more more BP https://blueprints.launchpad.net/keystone/+spec/generic-signature-validation 18:24:51 <ayoung> OK...want to address a point on two patches I have out that are H2 https://review.openstack.org/#/c/33745/ and https://review.openstack.org/#/c/34254/ are prep for split id. Both are alrage number of lines, but both should be failry trivial patches, as they are moving code around, not rewriting 18:25:26 <gyee> ayoung, will do that today 18:26:06 <topol> ayoung, will review them today as well 18:26:08 <ayoung> assignment backend in particular is nasty in gerrit, as tracking relocations is tough, as jamielennox points out. Feel free to ping me with questions 18:26:11 <gyee> both changes seem pretty trivial 18:26:14 <lbragstad> ayoung: forgot to put my +1 on https://review.openstack.org/#/c/33745/ my questions were answered 18:26:20 <ayoung> gyee, that was the goal 18:27:04 <ayoung> the final stage will be allowing assignments and ID to be separately configurable, which should be easier to understand than trying to mix it in with these patches. 18:27:05 <ayoung> OK... 18:27:14 <ayoung> Anything else for H2? 18:27:27 <gyee> #action code review https://review.openstack.org/#/c/34254/ and https://review.openstack.org/#/c/33745/ 18:27:42 <topol> stevemar, is oauth for H2? 18:27:59 <ayoung> topol, yes 18:28:06 <stevemar> topol, ayoung, yeah - oauth is for h2 18:28:21 <ayoung> stevemar, I'd love it if oauth and trusts could use common code for the revocation issues I brought up 18:28:46 <ayoung> Ideally ,a "trust" would be the same table as "consumer" I think 18:29:00 <stevemar> ayoung: i need more info on that before i agree to anything 18:29:03 <stevemar> :) 18:29:09 <fabioG> I am working on this BP as well: https://etherpad.openstack.org/havana-endpoint-filtering 18:29:16 <gyee> ayoung, but for oauth, consumer trust is established out-of-band right? 18:29:30 <ayoung> gyee, not really. It is a separate web call 18:29:34 <ayoung> but it is inband 18:29:51 <ayoung> fabioG, good stuff, think you can haveboth ready for H2? 18:30:08 <fabioG> I think so 18:30:29 <fabioG> planning to get a review out end of the week 18:30:44 <fabioG> do I need to already merge the two or I can leave them separate for now? 18:30:49 <ayoung> fabioG, https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering is an auth_token middleware change, not a keystone change right? 18:31:02 <ayoung> middleware does not have to be in for H2 18:31:09 <fabioG> no is keystone 18:31:13 <gyee> ayoung, that's API level change 18:31:29 <fabioG> there are new APIs to link projects and endpoints 18:31:42 <fabioG> creating associations used to filter the catalog back 18:32:58 <ayoung> fabioG, I would think that the first step is : create a token that lists a single endpoint in its service catalog. Then, on the middleware side, enforce that an token that comes in lists the current service in its catalog 18:33:15 <ayoung> simpler, and more likely to actually get finished 18:33:41 <ayoung> On the token creation side, allow adding an endpoint into the request 18:33:53 <fabioG> ayoung, code is 90% done 18:34:07 <ayoung> fabioG, that is no reason to accept a aptch, you realize 18:34:23 <bknudson> isn't all code always 90% done? 18:34:28 <fabioG> I know, is that I implemented following the current BP 18:34:31 <fabioG> specs 18:34:31 <ayoung> we have to make sure we are not over designing, and I thought this one was pretty clear when we discussed it 18:35:22 <ayoung> Now, allong a project/enpoint relationship is a valuable abstraction, but notnecessary for binding a token to an endpoint when enforcing it 18:35:27 <gyee> ayoung, we discussed it at the summit 18:35:29 <ayoung> those can be split 18:35:40 <gyee> pretty much everyone was nodding their head 18:36:09 <gyee> ayoung, enforcement comes from the client 18:36:15 <ayoung> gyee, there was also the jaypipes regions thing which was the other way of scoping endpoints 18:36:36 <ayoung> gyee, yes, enforcement comes from the client, which is not tied to H1 18:36:38 <ayoung> H2 18:36:40 <gyee> ayoung, no, jaypipes patch deals with endpoint lookup in the reverse order 18:37:02 <jaypipes> reverse order? 18:37:03 <gyee> like region->service->endpoint 18:37:11 <jaypipes> ah, yes... correct. 18:37:22 <ayoung> gyee, and this is project->service->endpoint 18:37:23 <fabioG> that is a catalog search 18:37:24 <jaypipes> with region == some amorphous container. 18:37:29 <gyee> I am totally fine with that 18:38:09 <gyee> endpoint-filtering deals with assigning endpoints to tenants and only return those assigned to the scoped tenant 18:38:40 <gyee> rather than returning the whole shebang, we only return the ones assigned to the tenant 18:38:44 <ayoung> #action review https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering 18:39:03 <ayoung> gyee, OK, so is anyone working enforcement? 18:39:19 <gyee> ayoung, no need 18:39:42 <gyee> novaclient will reject the request if I can't get the endpoint from the service catalog 18:39:44 <ayoung> gyee, auth_token middleware will need to enforce that a token is scoped the the current service 18:39:47 <gyee> for example 18:39:57 <ayoung> gyee, we can't count on the clients being run 18:40:18 <ayoung> OK, that can happen on separate cycle 18:40:27 <gyee> ayoung, yeah, you are right, we need to pass in the service ID for token validation 18:40:36 <gyee> ayoung, yeah, I agree 18:40:52 <ayoung> #action follow up on auth_token middleware enforcing endpoint scoping of tokens 18:41:06 <ayoung> #topic high priority bugs 18:41:54 <ayoung> #link https://bugs.launchpad.net/keystone/+bugs?search=Search&field.importance=High&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In%20Progress&field.status=Fix%20Committed&orderby=status&start=0 18:42:51 <ayoung> Downgrading the one marked incomplete, as there has been no feedback privded by the reporter, and it has not been seen elsewhere 18:43:11 <bknudson> ayoung: isn't there a priority above High? Critical 18:43:49 <ayoung> bknudson, yes, and there is nothing there that has not been tagged Fix released 18:44:10 <ayoung> bknudson, so the High bugs neeed to be triaged, and post H2, focus will shift to clearing out that list 18:45:00 <ayoung> #topic Unified Client authentication 18:45:07 <ayoung> OK, so this comes from my camp 18:45:25 <bknudson> this would help everyone 18:45:55 <ayoung> bknudson, yes. In addition, we should standardize all clients to using the request library, and getting the SSL configuration solid 18:46:05 <gyee> +1 18:46:27 <bknudson> only question is... what's the status of the openstack client ? 18:46:43 <topol> stevemar???? 18:46:47 <ayoung> bknudson, different question 18:46:48 <bknudson> we're saying we're not going to take new function in keystone. 18:46:59 <bknudson> are other projects the same? 18:47:00 <ayoung> this is making all of the current clients use keystoneclient as their auth library 18:47:04 <bknudson> so maybe we just do openstack client. 18:47:26 <bknudson> the python libs? 18:47:32 <bknudson> ayoung ^ 18:47:38 <topol> wait I thought openstack client was the unified command client 18:48:07 <stevemar> topol: they're talking about unified client auth... i think it's different from what i'm working on 18:48:08 <topol> didnt we separate the goals 18:49:10 <topol> maybe I misunderstood bknudson when he said openstack client.... its what he said.. 18:49:44 <ayoung> There was a ticket for making all of the clients use the requests library. That was a first step 18:49:53 <bknudson> topol: one thing the CLIs don't do today is handle --domain for the usernames. 18:50:06 <ayoung> BTW, that is what https://review.openstack.org/#/c/34161/ is about 18:50:12 <ayoung> But hat tis middleware 18:50:39 <stevemar> bknudson: agreed... 18:52:00 <bknudson> httplib is part of python standard libs and requests is external? 18:52:01 <ayoung> The reason that review failed is, I think, requrest and PrettyHTML as a mocking library, OPrttyHTML would need to be added to test-requires 18:53:27 <ayoung> bknudson, I think so, 18:53:42 <ayoung> but requests is identified as the Openstack client of choice 18:53:54 <bknudson> so somebody's using it already? 18:54:02 <ayoung> bknudson, keystoneclient is 18:54:39 <ayoung> bknudson, https://github.com/openstack/python-keystoneclient/blob/master/requirements.txt 18:55:01 <bknudson> so some tests were using requests and others httplib... 18:55:05 <ayoung> One last item for review: https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token 18:55:07 <bknudson> ok, makes sense 18:55:32 <ayoung> Since ^^ is an API change, would like to get it blessed 18:56:08 <gyee> ayoung, that for m2? 18:56:09 <bknudson> ayoung: is this going to be required or optional? 18:56:18 <ayoung> bknudson, optional to start 18:56:28 <ayoung> bknudson, we are doing a graduated enforcement 18:56:31 <ayoung> 1. is ignored 18:56:33 <ayoung> 2 is optional 18:56:45 <ayoung> 3. is enforce if present 18:56:50 <ayoung> 4. is required 18:57:08 <bknudson> at some point, why not just use Kerberos? 18:57:55 <ayoung> bknudson, because Kerberos doesn't do authorization, just authentication 18:58:09 <ayoung> and yes I am aware of the extensions to Kerberos to do authZ 18:58:14 <ayoung> and service tickets 18:58:22 <gyee> and KDC has to stay up all the time right 18:58:35 <ayoung> bknudson, this is specifically tying authorization documents to authentication 18:58:39 <gyee> more dependency 18:59:04 <bknudson> so client provides a public key and that can get embedded in the token? 18:59:06 <ayoung> gyee, it can also be done with X509 18:59:20 <ayoung> So that decision is left to the deployment 18:59:33 <gyee> bknudson, yep, that's a possibility 18:59:36 <ayoung> bknudson, probably the cert finglerprint makes more sense for PKI 18:59:51 <ayoung> OK...1 minute left 18:59:57 <ayoung> #topic opendiscussion 19:00:00 <bknudson> ok, this makes sense. 19:00:01 <lcheng> ayoung, do you have permission to release a new version of keystoneclient? This is blocking the BP for v3 auth login in horizon. 19:00:16 <ayoung> lcheng, link? 19:00:37 <ayoung> lcheng, I don't think I do, think that has to be PTL 19:00:53 <ayoung> lcheng, ask at the release meeting tonight at 5 19:00:56 <ayoung> Easter 19:00:57 <ayoung> n 19:01:04 <ayoung> OK, we are over time 19:01:06 <lcheng> horizon bo: https://blueprints.launchpad.net/horizon/+spec/login-domain-support 19:01:12 <lcheng> ayoung, okay. 19:01:14 <ayoung> #endmeeting