18:06:43 #startmeeting 18:06:44 Meeting started Tue Jun 5 18:06:43 2012 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:06:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:06:59 might as well get started 18:07:11 fyi- joe heck is traveling today, so i'll be proxying for him 18:07:40 #topic Status and Progress 18:07:53 Not sure if I can even do that... 18:07:56 #topic status and progress 18:08:10 guess not 18:08:12 might be tied to whoever did startmeeting (?) 18:08:32 gyee: did you want to give us an update on bp keystone-domains? 18:08:37 yep 18:08:41 I know it took some extra effort/time to get the draft review going 18:08:57 I uploaded the initial version to gerrit for draft review 18:09:04 anyone else want to be included? 18:09:07 #link http://etherpad.openstack.org/keystone-domains 18:09:25 gyee, yes, please 18:09:36 gyee, me too please 18:09:43 got it 18:09:58 #link https://blueprints.launchpad.net/keystone/+spec/keystone-domains 18:10:10 I'll be finishing up the architectural doc some time this week 18:10:26 gyee, post link? 18:11:07 gyee, you want to summarize the core concepts for domain here? (for those who are not familiar with it yet) 18:11:12 https://review.openstack.org/#/c/8114/ 18:11:20 its a draft review so I'll have to add you guys in 18:11:24 not yet public 18:12:16 conceptually, domains are administrative boundaries/containers for users, tenants, and optionally roles 18:12:32 gyee, alternatively, you could do what I've been doing for "signed tokens" which is posting it to github. Might make more sense 18:12:56 ayoung, yet, that'll work too 18:12:59 so domain will have roles associated? 18:13:23 role definitions can be either domain-agnostic or domain-specific 18:13:24 which limit or grant certain action rights? 18:13:42 gyee: i'm not a fan of that extra complexity at all 18:13:49 right, but it will be associated with domain, correct? 18:13:58 dolphm, its flexibility 18:14:02 tongli|2: correct, there's a domain-role association table in the implementation 18:14:25 gyee: flexibility to achieve what specific use cases? 18:14:52 in that case, how will it be different from user groups? 18:15:02 the goal is to provide the ability for somebody to be a domain admin 18:15:12 termie, correct 18:15:22 separation of duties, delegate administration, etc 18:15:32 the simplest implementation would be to add an additional category of roles that is a user-domain role, rather than a user-tenant role 18:15:41 gyee: i don't buy the rest of that 18:16:04 my goal is to allow a domain administrator with the same policy semantics as already exist 18:16:09 what's user-domain role? 18:16:20 I thought that during the design summit, the decision was made clear that delegation should not be in keystone. 18:16:29 gyee: a role that applies to a user-domain pair, rather than a user-tenant pair 18:16:44 tongli|2: that's correct 18:16:45 so all tenants in that domain will have that role? 18:16:51 gyee: any tenant that user is using within a given a domain will provide in additon to "roles" a set of "domain-roles" 18:16:56 gyee: no 18:16:59 gyee: it is user-domain 18:17:04 not tenant-domain 18:17:29 whenever that user is operating within that domain they have some domain-roles associated 18:17:30 so if I authenticate and scope to a tenant in that domain, will I get that role? 18:17:34 domain is a collection of users, tenants, roles, and groups... not just users or just roles 18:17:51 jsut as whenever the user is operating within a tenant they will have the normal roles they have associated with that tenant 18:17:56 jr__: wrong 18:18:01 jr__: a domain is a collection of tenants 18:18:05 wrong 18:18:09 jr__: i'd argue that it's not users or roles at all, it's just a collection of tenants, everything else is implicit 18:18:15 if at all 18:18:17 I wrote the domain spec, i think i would know 18:18:27 jr__: i rejected the spec 18:18:33 * ayoung grabs some popcorn 18:18:56 just a collection of tenants provides little value 18:19:20 jr__: we went over this all at the design conf, the needs you were trying to address were all addressed 18:19:31 as were the needs of the others interested in such a concept 18:19:56 i am not sure which person you were in the meeting 18:20:06 but i do recall one person with a grumpy face after it 18:21:19 morale of the story: we are not trying to incorporate HP's system into keystone, we are trying to solve the same problems in a way that works for other people as well 18:21:36 s/morale/moral/ (i'm not really that into morale) 18:22:09 grouping of tenants is just 'grouping' of tenants. it does nothing for separation of duties and all the other goodness provided 18:22:31 isn't that where rbac comes in? 18:22:32 it does totally fine 18:22:38 that is not what domains is about... if you want tenant grouping, then call it that and create another blueprint 18:22:46 domain-roles with the same policy semantics get you all you needed 18:23:05 termie, can you elaborate how domain-roles work? 18:23:10 i just did man 18:23:27 role grants are currently performed on a user-role-tenant combination 18:23:41 a domain-level grant would simply be a user-role-domain combination, i presume 18:23:49 dolphm: correct 18:23:56 k? and? 18:24:16 11:16 gyee: any tenant that user is using within a given a domain will provide in additon to "roles" a set of "domain-roles" 18:24:18 11:16 gyee: no 18:24:21 11:16 gyee: it is user-domain 18:24:24 11:17 not tenant-domain 18:24:46 11:17 whenever that user is operating within that domain they have some domain-roles associated 18:24:52 11:17 jsut as whenever the user is operating within a tenant they will have the normal roles they have associated with that tenant 18:25:17 use cases are documented in: 18:25:20 #link http://etherpad.openstack.org/keystone-domains 18:25:21 I feel this is an introduction of nested tenant. 18:25:28 the domain they are operating under are defined by the tenant they are operating under 18:25:34 that really hurts. 18:25:36 tongli|2: it is a collection of tenants 18:25:45 tongli|2: not nested, nested implies recursion 18:26:07 The intention of domain is to separate users, roles and tenants in one domain from another. The only way to link them is via trust relationship. 18:26:09 tongli|2: in practice large organizations tend to need three levels 18:26:10 i'd actually prefer arbitrary tenant hierarchies rather than introducing new concepts 18:26:10 right, two levels inclusion, basically like a tenant can have other tenants inside. 18:26:37 dolphm: that is a bad idea and forces your datastructures into graph traverals 18:26:57 tongli|2: not exactly, they have different properties 18:26:57 termie: only as deep as your real-world use case 18:27:14 termie, but conceptually they are all containers. 18:27:29 tongli|2: one is a container, one is a resource owner 18:27:37 termie: with domains, you're forcing two levels, when one could satisfy a majority, while a minority will eventually want additional complexity 18:27:53 dolphm: additional complexity means additionally complex code 18:28:02 dolphm: and additionally complex testing, edge cases 18:28:27 dolphm: design the right system, not something you aren't going to need 18:28:35 termie: i haven't thought it all the way through, but it seems much simpler in terms of API-impact and implementation changes 18:29:19 dolphm: feel free to take it offline and propose such a concept 18:29:44 dolphm: if you think we should wait on domains until you write it up 18:29:51 dolphm: i'm not against that 18:30:09 as existing advocates for the domains still seem to not be on the same page 18:30:13 termie: i'll spend some time on it and see where my opinion lands :) 18:30:35 dolphm: keep what happened to "zones" in mind when you do ;) 18:31:30 probably it will really help to make a case to describe how domain can solve that tenant and user group combination can not. 18:32:03 tongli|2: it provides an abstraction for managing multiple tenants as a group 18:32:04 so we move on to open discussions now? 18:32:18 tongli|2, not yet, we are still on "Progress" 18:32:27 is anyone else not included in the domains draft review that would like to be? 18:32:30 ok. not a problem. 18:32:41 can you please add me? 18:32:45 we done on domains? 18:32:54 gyee: can you add tongli|2 ? 18:33:01 launchpad id is litong01@us.ibm.com 18:33:25 sure 18:33:29 me too please 18:33:30 thanks a lot. 18:33:44 ayoung: yes 18:34:05 I've gotten some good feedback on the signed tokens work 18:34:23 termie: I would like to know about your opinon on the queryng by name V3 API 18:34:41 this week tow duplicates for #link https://bugs.launchpad.net/keystone/+bug/972800 18:34:41 rafaduran: i wrote down comments on the doc 18:34:42 Launchpad bug 972800 in keystone "Identity backends provide get_by_name methods but they aren't available via API" [Wishlist,Incomplete] 18:35:06 maybe this link works? https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit?disco=AAAAAEYr61Q# 18:35:11 termie: sorry, I didn't see, I'm going to check 18:35:12 it looks dubious 18:35:26 termie, what looks dubious? 18:36:27 i think querying by name is pretty well discussed in the v3 draft, which is a more appropriate venue for that type of discussion 18:36:35 ayoung: want to give us an update on pki? 18:36:40 sure. 18:36:50 proceed! 18:36:54 added anotehr comment on the doc, didn't see dolph's question 18:36:59 ayoung: the link does 18:37:05 I've gotten some good feedback, with a couple *big* questions 18:37:06 ayoung: i don't know if it will work for others 18:37:22 termie, link worked for me 18:37:27 anyway 18:37:47 gyee, asked if signed tokens should replace the existing, or if we should keep the existing around 18:37:59 my gut says that if we give people the option to not change, they won't change 18:38:18 ayoung: a fair assumption 18:38:21 I'd rather have the signed tokens out there soon and find out if it breaks things 18:38:21 ayoung: i would love for that to be the case (signed required) 18:38:32 termie, glad to hear it 18:38:44 I have been going through and fixing all of the unit tests I broke 18:38:51 and in doing so learning a little bit 18:39:09 I think it is fair to say that we would want to run those tests over both token mechanisms if we kept both 18:39:15 and I think that is prohibiative 18:39:31 ayoung: i don't thnkk so 18:39:40 ayoung: we have existing patterns for running tests against multiple drivers 18:40:14 termie, it isn't just a different driver here, though. 18:40:29 The logic for processing the tokens is slightly different 18:40:40 ayoung: i haven't looked at your proposed implementation, but it largely is in my mind 18:40:41 as the signed tokens don't need the network call, etc 18:41:11 ayoung: that just means bumping a strategy abstraction up a level somewhere 18:41:15 termie, take a look. Thjere are still details to work out, but the approach in general is pretty close. 18:41:28 termie, yeah, it is starting to feel that way 18:41:50 there are a bunch of #termie comments and #dolph comments in there that indicate that as well 18:41:58 "move this to common:" type stuff 18:42:41 I'll post an updated patch later on today with the next set of unit tests fixed 18:43:15 there was also the question about whether we still want to have memcache support for ticket validation 18:43:35 ayoung: github link? 18:44:01 https://github.com/admiyo/keystone/tree/signed-tokens 18:44:14 ayoung: / intending to open a draft/public review? 18:44:15 ayoung: i don't think it will be the most common use case, but memcache is more robust than most people tend to think 18:44:16 dolphm, I've been rebasing that 18:44:34 ayoung: it has the main benefit of having built-in cleanup 18:44:35 #link https://github.com/admiyo/keystone/tree/signed-tokens 18:45:01 termie: about the querying by name, it makes sense to me your comments, moving it under /search path makes it easier to include it as an extension rather than core, keeping core clean 18:45:21 rafaduran: (we're still discussing pki) 18:45:21 termie, it is not a question of robust, but whether we need to shortcut the token validation. Right now, we cache so we don't need to go back to Keystone. With signed-tokens, the cost of validating is less 18:46:07 termie, the cost of validating is spinning up an additional process and waiting for it to finish. THis is non-zero, but still not too bad compared to a network call 18:46:19 ayoung: for most kinds of signed tokens, but things in multifactor auth will still probably need a temporary store 18:46:47 termie, sounds good. It is easier for me to leave it in. Just don't want that to be decision made out of lazyness 18:47:01 termie, are you cool with the Popen approach to running openssl? 18:47:13 ayoung: mostly i just don't think we need to ditch all the code yet, that may change shortly but i think there are probably still some uses for having it in tehre, even if it just means not re-typing half of it 18:47:44 ayoung: aye, can add an abstraction to make another machine do it for us later on 18:48:55 ayoung: anything else on pki for today? 18:49:04 termie, I would probably suggest that we use AMQP or some other local RPC to talk to a process that just cranks through validation requests saying "yes" or "no" to each if we find we need to minimize the cost of the proces start up 18:49:15 ayoung, so token revocation will be meaningless with the PKI stuff then? 18:49:22 gyee, correct 18:49:33 gyee: besides pki cert revocation 18:49:41 gyee, I have a write up of how to do it, but it makes things more complicated 18:49:46 oh 18:49:49 gyee: and things of that nature 18:50:03 i doubt it will be supported right away 18:50:05 when starting Keystone, I was wondering if it should self generate the certs it needs if they do not exist 18:50:31 ayoung: i agree on wanting to farm out the work, i think that is something that is second priority to getting it working 18:50:44 ayoung: hmm.. and write them to disk? 18:50:51 I was thinking more along the lines of devstack than for live deployments 18:50:53 dolphm, yes 18:51:13 ayoung, dolphm: i'd probably put that in the whatever setup command (like db_sync) 18:51:32 termie, +1 18:51:40 termie: agree 18:51:52 we don't want to add many additional setup steps, but it still seems like something people should be knowingly doing 18:52:07 but i do like the idea of auto-generating them if necessary, but perhaps just keep them in memory and throw lots of warnings about how all your tokens will be invalid if you shut down keystone 18:52:19 could probably add a flag to auto-generate for testing or whatnot 18:52:24 termie, so the services *are* downloading the ca certs and the signing certs in order to validate. 18:52:35 ayoung: statement or question? 18:52:38 I think that is OK 18:52:43 do you? 18:52:44 #allow_autogenerated_keys = False 18:53:29 ayoung, just to clarify, so PKI token is not configurable correct? 18:53:49 i think it should be 18:53:50 gyee, ayoung: signed token, i don't think pki is the only version of that 18:53:52 gyee, correct. It will replace the token code 18:54:15 why not an option? 18:54:16 ayoung: without api impact, though 18:54:20 ayoung: correct? 18:54:23 dolphm, no API impact 18:54:29 ayoung: just sort of renders a few calls useless 18:54:58 dolphm, and, the remote services can, in theory, run with the PKI tokens and the existing auth_token middleware, but I wouldn't want to support it 18:55:35 ayoung, no API impact? 18:55:46 what about the 3rd party clients don't use middleware? 18:55:47 gyee, no. from an API perspective, nothing changes 18:56:02 well, there won't be validate token call right? 18:56:11 gyee: it's just not necessary 18:56:11 they can request a token, can use it as a blob, send it back to keystone to validate if they want 18:56:14 ayoung: Even though there is no API impact, for clients that do not want to deal with certs, they are now out of option 18:56:29 gyee: keystone could still implement one, for clients that don't understand that they can validate signed tokens themselves 18:56:56 ok, so it's backward compatible then 18:57:01 gyee: yes 18:57:12 I am more concern with reference implementations 18:57:19 alright, for the sake of completeness... 18:57:20 #topic high priority bugs or immediate issues? 18:57:30 we had a pair of bugs opened against admin API operations that weren't requiring *any* sort of auth 18:57:34 #link https://bugs.launchpad.net/keystone/+bug/1006815 18:57:36 Launchpad bug 1006815 in keystone "Admin API /v2.0/tenants/{tenant_id}/users/{user_id}/roles doesn't validate token" [Critical,In progress] 18:57:38 #link https://bugs.launchpad.net/keystone/+bug/1006822 18:57:40 Launchpad bug 1006822 in keystone "API(v2.0/OS-KSADM/services,v2.0/OS-KSADM/services/{service_id})doesn't validate token" [Critical,Fix committed] 18:57:44 services one is in 18:57:45 liemmn, is that a show stopper for you? DO you need to deploy in "no certs allowed" environments? 18:58:18 ayoung: i wouldn't explicitly remove the old functionality just yet, for the record, but i think we probably want to deprecate it 18:58:20 that is not right. I just looked at /tenants/{tenant_id} 18:58:27 it confirms that an admin token was sent it 18:58:43 termie, how would it get configured? 18:58:48 ayoung: I think Dolph answered my question... It is not a show stopper, but as a reference implementation, I would try to keep it as simple as possible. 18:59:05 and for more completeness, i'm going to assume there aren't any other high priority issues (i'm not aware of any, at least), and... 18:59:05 #topic open discussion 18:59:07 right not it is specified as a middle_ware 18:59:22 right now 18:59:27 and now we wait for mtaylor to dance us out of here 19:00:06 NOONTIME 19:00:19 well, in the real timezone 19:00:30 our meeting is now over, i think 19:00:34 true 19:00:35 guys, 19:00:38 let's all run for the hills 19:00:41 I have an item. 19:00:42 heh 19:00:47 can we talk about it? 19:00:48 spit it out son 19:00:50 tongli|2: open discussion until mtaylor kicks us 19:00:54 tongli|2, fire away...we might get chased out soon 19:01:06 Keystone log in with invalid tenant name return 200, should there be a difference between good and bad tenant name? 19:01:14 I added into the agenda. 19:01:16 tongli|2: imo, yes, it should return a 401 19:01:21 agreed 19:01:28 sounds like it was already a bug? 19:01:31 that bothers me a lot. 19:01:33 dolphm: take your time, I doubt we have a full hour of stuff anyway 19:01:34 tongli|2: i'm pretty sure https://review.openstack.org/#/c/6875/ takes care of that (please test!) 19:01:48 mtaylor: i always think the same thing about keystone 19:02:00 i am in the middle of approving that patch 19:02:02 dolphm: ++ 19:02:03 FTR 19:02:08 unless i forget over lunch 19:02:16 great. I will take a look at , thanks folks. 19:02:20 termie: i wouldn't blame you, lunch is awesome 19:02:22 in general 19:02:25 cool 19:02:28 #endmeeting