18:02:08 #startmeeting keystone 18:02:09 Meeting started Tue Jun 4 18:02:08 2013 UTC. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:12 The meeting name has been set to 'keystone' 18:02:15 https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:24 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:43 #topic High priority bugs or immediate issues? 18:02:43 #link https://bugs.launchpad.net/keystone/+bug/1179955 18:02:45 Launchpad bug 1179955 in keystone "Disabling a tenant would not disable a user token" [Critical,In progress] 18:03:09 dolphm, so...just to point out 18:03:12 ayoung: that doesn't need to be in the meeting notes every week :P 18:03:16 this is a slippery slope 18:03:29 there's a few high priority bugs on our plate that we need to get backported to grizzly 18:03:37 I mean, we are not yet disabling projects 18:03:53 ayoung: sure we are 18:04:01 we meaning Keystone 18:04:10 we are not disabling the hyopervisors 18:04:16 or, the VMS rather 18:04:28 correct, that's a whole different issue tracked in bp notifications 18:04:49 https://blueprints.launchpad.net/keystone/+spec/notifications 18:04:51 #link https://blueprints.launchpad.net/keystone/+spec/notifications 18:05:06 but...we will need to be able to list tokens by project, which will be expensive, and not make termie happy 18:05:26 termie's been quiet lately 18:05:38 bknudson, day job has demanded his attention 18:06:26 should the project be in the token table/ 18:06:52 regarding disabling tenants, we've had several related issues over the past 6 months regarding authz against disabled entities... we really need a framework to consistently handle the consequences of disabling/deleting any given entity 18:07:39 dolphm: agreed, I think was a bit over zealous in the changes i made to grants/disabling/deletions etc. 18:07:42 performance has to come second to security related functionality... i think it's alright if disabling/deleting an entity is understood to be an expensive operation... we can fix performance later 18:08:04 dolphm, my suggestion is that we focus on short term tokens, and then the whole disable/revoke mechanism is not required. 18:08:40 we still have existing code out there that has to work. 18:08:42 ayoung: I guess you need to define short-term 18:08:58 simo, 5 minutes 18:09:21 ayoung: does that mean users need to renew credentials every 5 minutes ? 18:09:26 simo, within clock skew, the same amount of time for a change to propate through the system 18:09:45 simo, they will need a new token, yes 18:09:57 from a master token ? 18:10:03 or full re-authentication ? 18:10:14 what happens for requests that needs longer time ? 18:10:27 bknudson: project / domain, depending on scope 18:10:27 henrynash_: i think you made great progress in the right direction, but there's still some gaps to fill 18:10:27 i'd just like to make sure they're all filled so this is the last such defect we get 18:10:38 simo, later discussion 18:11:34 dolphm: agreed..feel free to assign some of these to me to sfix if we think we need to 18:13:54 hmm…is the chat room misbehaving for others….I seem to get only bursts of messages every few minutes... 18:14:04 henrynash: working for me. 18:14:09 ok 18:14:27 henrynash, I am having the same problem 18:14:33 henrynash: sure 18:14:57 two other reviews that simply need some love, as they're relatively high priority for backporting https://review.openstack.org/#/c/31552/ https://review.openstack.org/#/c/31559/ 18:15:50 dolphm, I will review today. Will help me get back into the swing of things 18:15:53 approaved and ... 18:15:58 henrynash: that's happened to me w/ irc on poor wifi in the past 18:15:58 #topic Inherited roles from domain 18:15:58 #link https://review.openstack.org/#/c/29781/ 18:15:58 henrynash: was this just on the agenda from last week? 18:16:08 topol: thanks 18:16:34 dolphm: yes, but I left it on since we've not managed to close it yet... 18:16:47 I have two issues on that one 18:16:55 I went ahead and updated it as we discussed last week... 18:17:02 1) we need to extend the capability to all domains 18:17:05 but gyee and others have some legit concerns 18:17:16 2) one, instead of multiple, APIs to get the effective role grants 18:17:18 henrynash: anything worth discussing here, or just want more attention on the review? 18:17:43 so I think I'd like some guidance on the one vs multiple apis 18:17:50 (Gyee's 2nd point) 18:17:56 two choices: 18:18:42 a) extending, as is shown in the current proposal, various apis to support inherited roels 18:19:21 b) change the format of the grant call, to provide more or less terms to achieve this: 18:20:12 e.g. Role applicable to all projects within a domain 18:20:12 PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/projects 18:20:12 Roles inherited by all projects in all domains 18:20:12 PUT /usrs/{user_id}/roles/{role_id}/projects 18:20:12 Roles inherited by all domains, at the domain level 18:20:12 PUT /usrs/{user_id}/roles/{role_id}/domains 18:20:28 I would like to see GET /user/{id}/roles return the effective grants, plus extra information on where the roles are granted 18:20:50 gyee, would "extrat info" be an additional call? 18:20:59 (which was Gyee's suggestion) 18:21:00 ayoung, no 18:21:02 (so this is actually Gyee's 1st point, sort) 18:21:10 gyee, how would it look? 18:21:19 it would be in the same collection 18:21:26 just add an extra "scope" field or something 18:21:34 gyee: that's already in the spec…we just need to change the name slightly and implemt it as speced 18:21:42 (i.e. it's in the v3 spec!!!) 18:21:49 on point 1) i'd argue that global roles are completely out of scope for this change, HOWEVER, this change should be made with thought put towards what global roles would look like. global roles have been repeatedly poo-poo'd by the community since diablo 18:22:21 dolphm, inherited is semi or not full global :) 18:22:27 if not 18:22:38 gyee: henrynash: i think point 2 can be discussed better in review, with the context of the calls themselves? 18:22:39 same use case 18:23:13 role assignment is really about the scope it covers 18:23:25 global, domain-global, domain-local, or project 18:23:27 dolphm: agreed 18:23:47 that's essentially what "inherited" means 18:23:53 really about role scoping 18:24:27 so "inherited" as I defined it is "domain-local" in your terminology? 18:24:32 if we are going down the inherited path, we need something generic 18:24:48 henrynash, it would be domain-global 18:24:55 since it covers the entire domain 18:25:11 domain-local is just domain grant without inheritance 18:25:13 gyee: ahh, so domain-local is what we have today for a domain role 18:25:20 correct 18:26:21 can a role scope be both domain-local and domain-global? 18:26:23 do my argument agains global is simply that .given that domain creation is either a rare occurrence (which case adding a role to each domain is not a chore) or frequent and automated (in which case automation could do the role assignment) - is the lack of global role really that bad? 18:26:35 would help to somewhere clearly define domain-local, domain-global, etc. 18:26:46 bknudson, if we want, my point is we need something generic so we can extend later if we want 18:27:16 what is the distinction between domain-global and domain-local? 18:27:31 domain-global = inherited by all projects 18:27:38 domain-local = domain only 18:27:48 better nming perhaps: global-scope, domain-scope, project-scope 18:27:55 ok, can we not call it domain-global 18:28:00 simo +1 18:28:03 simo, +1 18:28:07 simo, that's fine, we can make the names more intuitive 18:28:16 but we need something extensible 18:28:19 gyee: it' half the work, really :) 18:28:20 and generic 18:28:43 dolphm: may I raise a concern ? 18:28:58 maybe it's my lack of knowledge though 18:29:02 so...isn't this really a mapping issue 18:29:18 users in Group X get a role on all projects in domain Y 18:29:26 gyee: so your argument is that the api changes should allow a progression to more globalness in the future if we chose that path? 18:29:45 henrynash, correct 18:30:25 gyee: Ok, understand that 18:31:26 So...dchadwick would, if he were here, point out that this is just the sort of problem the mapping code is supposed to solve 18:31:41 ayoung: it is possible 18:31:42 maybe we should punt on this until we have a plan to get that integrated instead 18:31:46 ayoung, mapping is a different issue I think 18:31:53 gyee, mapping is a mechanism 18:31:58 ayoung: is there a concept of groups in keystone currently ? 18:32:01 ayoung: it's rally how we express that various mappings we want (or might want) 18:32:01 gyee: so you would be ok if we didn't go all the way to "global", but the api changes we make would allow us a natural progression to that in the future if we chose it? 18:32:03 simo, yes 18:32:07 mapping is name manipulation 18:32:13 ayoung: what for ? I can't think of why you would want it 18:32:42 gyee, mapping is "attribute in" becomes "Attribute out" 18:32:50 henrynash, as long as we make it generic and extensible, I am fine 18:33:00 gyee, "attribute out" in this case would be "role in project" 18:33:00 aren't projects sufficient ? 18:33:08 simo, nope 18:33:19 projects are the groupsing for external resources 18:33:24 gyee: ok, let me work on that and update the bp 18:33:26 groups are like LDAP groups for users 18:33:27 ayoung, role is just a name today 18:33:31 nothing more 18:33:42 gyee, it is the inheritance thing that mapping solves 18:33:50 the mechanism for assigning implicit roles 18:34:00 you know the concern I have is that it seem we have nowhere a document that describes the security model and all the security/identity elements in the system and what they are intended to be used for 18:34:11 this means everyone will have their own ideas about things 18:34:21 and there will be friction implementing any change 18:34:27 ayoung, role manipulation can be done in the pluggable token provider if you want :) 18:34:30 dolphm: ok, maybe time for another topic…I still 20 mins 18:34:38 (I stole 20 mins) 18:34:46 that's where we pull all the roles and stuff them into token 18:34:47 gyee, mapping is the mechanism for implementing 18:34:55 so, yes 18:35:12 simo, you had an issue with the service catalog 18:35:21 well sort of 18:35:21 you need to get an endpoint out, but don't jhave a token 18:35:32 and right now we say that is "admin only" 18:35:32 I think that's a big dicussion and I gave up on it for now 18:35:44 dolphm, is there any reason to "protect" the service catalog? 18:35:51 but the quesiton I have is why read access to the catalog is restricted ? 18:35:59 yeah, we need an interface for service catalogs, similar to AccessInfo 18:36:06 perhaps it can lives in oslo 18:36:12 oslo ? 18:36:13 simo, I do know that it is supposed to be scoped to give the user the "right" service catalog 18:36:23 gyee: you mean as a client ? 18:36:24 simo, oslo is openstack common 18:36:29 ayoung: I know 18:36:36 all data from Keystone should be protected by ssl 18:36:36 (found out :) 18:36:41 right, we need a consistent way for clients to access the service catalog 18:36:50 bknudson: ? 18:36:52 parse and access 18:37:07 gyee, so the question is do we need to protect the query for endpoints? 18:37:20 bknudson: unless you are talking ssl client certs, ssl does not 'protect' much, on its own 18:37:35 ayoung, sure, that's what endpoint-filter bp's about 18:37:38 I would think that, at a minimum, we should drop the "admin is required" on querying the service catalog 18:37:59 gyee: is there any place that explains why the catalog must be secret? 18:38:12 https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering 18:38:15 gyee, yeah, but I was think that was what we put in the token. But maybe direct query of all endpoints for a service would be exposing too much info? 18:38:19 (i'll take that as a yes) 18:38:19 #topic DB2 enablement 18:38:19 #link https://wiki.openstack.org/wiki/DB2Enablement 18:38:19 bknudson: all yours 18:38:21 what is the point in withholding information about endpoints ? 18:38:30 this should be a quick one... 18:38:45 others here have been working with the community to set up DB2 test env 18:39:01 we have some docs up on the wiki now: https://wiki.openstack.org/wiki/DB2Enablement 18:39:19 that I've asked the guy who wrote it here to update with more detailed instructions for those not familiar with db2 18:39:21 simo, what's the point of returning an endpoint you don't have access to? 18:39:30 we had a blueprint https://blueprints.launchpad.net/keystone/+spec/db2-database that was closed 18:39:37 gyee: (define you) 18:39:46 and it seemed like the correct way to proceed was to file a bug and submit the code 18:39:48 bknudson, so, my position is the same as before: we should make sure thatthe generic DB code executes the same on all platforms. THat requires getting the DB code into gate first and foremost 18:39:49 you = token holder 18:39:50 so that's what I plan to do 18:40:07 gyee: in my case I do not even have a token (and don't need one for now) 18:40:44 bknudson, so the issue is provisiong the DB for testing, and it sounds like tempest is the right place to do that. Ideally, the Postgresql and DB2 code paths would be identical 18:40:46 ayoung: I agree it would be great to have it in the gate. 18:41:30 ayoung: I thought even the postgres testing was out of the gate since nobody was supporting it? 18:41:35 (i got booted by freenode) 18:41:42 bknudson: I use it every day :) 18:42:03 dolphm: seem there are issues on freenode today 18:42:04 bknudson, for now, you can add a config file in test so that we can run the migrations against DB2, and we'll work on getting the rest of the backend tests running against the real RDBMSs afterwards 18:42:07 simo: are you supporting it? 18:42:09 sure, lets include DB2 18:42:12 dolphm, yes we are 18:42:16 ayoung: easy to do. 18:42:17 dolphm: you got booted for 'excess flood' 18:42:19 more tests more merrier 18:42:23 DB2 won't go into gate, though 18:42:44 That can be your companies Special sauce, bknudson 18:42:49 simo: postgres gate is failing 18:42:57 http://logs.openstack.org/31559/2/check/gate-tempest-devstack-vm-postgres-full/20047 : FAILURE in 53m 03s (non-voting) 18:43:08 ayoung: or ibm can donate CI resources to make it a gate 18:43:10 tbh I find it a bit ridiculous we need to have more and more and more DBs ... 18:43:16 bknudson, does DB2 need to be open sauce first? 18:43:28 dolphm: I and ayoung will make sure someone takes a look 18:43:29 simo: agree, but there's not one db that fits all 18:43:42 dolphm: it needs to fit US! right ? 18:43:52 simo: everyone's deployment is different 18:43:58 sigh 18:44:03 agree 18:44:27 gyee: I guess it's up to the community if they will accept code changes to support a non-open-source db. 18:44:30 dolphm: it's just a slow down, crappy inducing factor, but I do understand, for once I can;t stand mysql :) 18:44:44 simo: agree 18:45:01 gyee: depends on the extent of the changes :( 18:45:04 bknudson: * 18:45:05 knudson, should this be a legal discussion first? 18:45:20 bknudson: if you need proprietary support, then it's tough odds 18:45:23 do we have db specific code actually ? 18:45:33 isn't everythign wrapped into sqlalchemy ? 18:45:40 bknudson: if you're simply discovering issues using db2 that benefit other backends, then great 18:45:49 simo: migrations, typically 18:45:54 simo: there are several places where we've got db-specific code in migrations. 18:45:58 simo, problem is sqlalchemy behave differently for different dbs 18:46:09 that's why more tests is good 18:46:12 the changes I've got to support db2 are similar to the ones for mysql/postgres/sqlite. 18:46:14 gyee: well of course, given different DBs have different features ... 18:47:09 simo, no, I mean basic stuff like renaming a table 18:47:14 bknudson, yeah...on that point 18:47:14 some support it some don't 18:47:21 bknudson: feel free to put them up for review 18:47:23 dolphm: wouldn't it be beneficial at least to try to confine all 'special' code into a pluggable module ? 18:47:29 https://review.openstack.org/#/c/31249/ is not longer DB specific 18:47:33 dolphm: ok, I'll try it. 18:47:39 simo: migrations can be broken down that way already 18:47:44 gyee: in fact renaming tables is a 'feature' :-/ 18:47:56 ayoung: I think https://review.openstack.org/#/c/31249/ is a good example where db2 support might be helpful. 18:48:32 bknudson, try running the Postgresl live tests against DB2 and post your results 18:48:35 the mysql fix was specific to mysql whereas this one should work with db2. 18:48:56 I'll give it a try 18:49:10 bknudson, you should be able to modify the test config for DB2 and run 18:49:38 So...one issue on splitting identity if we have time? 18:50:24 I wrote it up as Mapping Usernames from Multiple IdP's to Keystone 18:50:29 and sent it in email 18:50:45 #link https://etherpad.openstack.org/mapping-user-ids 18:51:13 (fyi, i'm going to #endmeeting a bit early) 18:51:13 jamielennox, dchadwick/ksiu and I have be debating this one, and I wanted to get a larger perspective 18:51:46 ayoung, I'll take a look 18:51:48 I think I want to drop the "expires" time thing from the user bp 18:51:49 on my todo list 18:52:01 +1 on dropping expires 18:52:03 it seems to me that it should be role assignments which are time limited 18:52:15 nope 18:52:27 role assignments shouldn't have a time limit either 18:52:36 #topic open discussion 18:52:36 fwiw - I don't think there are any problems adding db2 support patches - but it's unlikely that the CI systems will be able to test them for you 18:52:38 that's strictly a backend/provider issue 18:52:39 gyee, true, it can be enforced by token expiriy 18:53:03 gyee, this is for autoprovisioning 18:53:31 bknudson: mordred: nor does the community necessarily have the expertise to properly review them 18:53:45 dolphm: ++ 18:53:54 So, what we need is a policy that enforces the token creation, but we don't need expl;icit APIs for them. 18:54:02 ayoung, not sure what you mean 18:54:09 gyee, I am agreeing with you 18:54:23 how does token expiry related to role expiry? 18:54:42 dolphm: I think we'll have ci infra internally here, so I'll probably post a fix if it breaks. 18:54:43 gyee, think of it as "on demand you get a limited amount of resources for a limited time" 18:55:03 btw, my colleague is ready to work on the generic signature auth bp 18:55:10 #link https://blueprints.launchpad.net/keystone/+spec/generic-signature-validation 18:55:15 my colleague Nachi 18:55:27 if you guys have some time, please review the proposal 18:55:31 gyee, that is kindof what simo is working on, isn't it? 18:55:36 bp temporary-user-provisioning can certainly be done as an extension - it doesn't need to be done as core 18:55:47 dolphm, +1 18:55:55 #link https://blueprints.launchpad.net/keystone/+spec/temporary-user-provisioning 18:55:59 ayoung, no, that's different 18:56:16 I think simo is working on the kerberos stuff 18:56:22 dolphm, agreed, and I think we don't need to expand the API to support it, the more I think about it, the more I am convinced it can be handled with current public APIs 18:56:36 gyee, no, he is doing the messaging crypto stuff 18:56:44 which includes HMAC 18:56:47 gyee: no I am doing message signing 18:57:05 ok, we're good then 18:57:25 gyee: and I have a patch in oslo-incubator that will give you access to generic HMAc as part of my bp 18:57:33 gyee: so let's try not to duplicate work 18:57:33 simo, I thought you were doing HMAC as part of that? 18:57:45 what I said precisely 18:57:48 simo, beautiful 18:57:52 yes, you type faster than I do 18:57:59 we can definitely leverage your stuff 18:58:21 gyee: please tell your colleague to review https://review.openstack.org/#/c/28471/ 18:58:29 gyee: and let me know if he needs anything else 18:58:58 just a couple minutes left, but i'd suggest switching to -dev :) 18:58:59 #endmeeting