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