18:00:50 #startmeeting keystone 18:00:51 Meeting started Tue Dec 4 18:00:50 2012 UTC. The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:51 FYI we have just updated the attribute mapping blueprint 18:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:54 The meeting name has been set to 'keystone' 18:01:16 #link http://wiki.openstack.org/Meetings/KeystoneMeeting 18:02:24 agenda is fine for me 18:02:26 Robot Rollcall 18:02:35 heckj, you in today? 18:02:38 here!~ 18:02:41 Sorry, was reading bugs 18:02:43 :-) 18:02:51 heckj: Error: Can't start another meeting, one is in progress. 18:02:54 That is one thing you never need apologise for 18:03:04 heckj, already started 18:03:05 Oh - you already did it, sweet! 18:03:07 lol 18:03:12 You should apologise for creating bugs :-) 18:03:17 heh 18:03:18 dwchadwick, that would be me 18:03:19 never 18:03:28 * dolphm apologizes 18:03:29 and I don't mean logging them 18:03:48 #topic High priority bugs or immediate issues? 18:03:50 felt bad after henrynash asked me about a triaged bug and realized I hadn't done anything to triage in weeks 18:04:02 8 bugs outstanding to be triaged - working on that today 18:04:25 heckj: aren't you supposed to be on holiday? 18:04:26 Haven't made any progress on the memcache thing and repro work - not hard, just haven't been able to dedicate the time as yet 18:04:31 Starting tomorrow 18:04:49 * heckj shuts up now and let's Adam run this 18:05:12 heckj, actually, since we were talking Bugs, anything on the new list that is burning? 18:05:22 Or recently triaged? 18:05:34 just now going through them 18:05:42 auth_token failure if signing_dir not specified running under upstart.....not a bug 18:05:53 Length of user_name in database too short for X.509 DNs that is mine 18:06:00 The only burning one is the periodic memcache failure due to eventlet race conditions and memcache clients at high concurrency 18:06:08 (that I know of) 18:06:31 heckj, OK, so the long term solution for that one is the swift memcache ring, right? 18:06:33 swift memcache ring impl seem pretty solid 18:06:56 ayoung: yep - Alex Yang was getting that into openstack common - may need a "boost" to do so, then using it from there 18:07:01 heckj: who's working to get the solution into oslo? (i believe that's the blocker on a fix, no?) 18:07:10 heckj: (spoke too soon!) 18:07:21 dolphm: fellow (that I don't really know) who commented on the bug 18:07:37 dolphm: he opened a blueprint against oslo - looks like he made traction for a while, then disappeared or lost interest 18:08:02 heckj that is https://bugs.launchpad.net/keystone/+bug/1052674 right? 18:08:03 Launchpad bug 1052674 in keystone "Keystone auth_token middleware should support Swift global memcache" [High,Triaged] 18:08:09 auth_token used to take env['swift.cache'] 18:08:19 did I file that one? 18:08:39 actaully, I think there's a separate bug there - this might be a dupe 18:09:03 trivial fix 18:09:05 I can do it 18:09:50 #link https://bugs.launchpad.net/keystone/+bug/1052674 18:09:52 Launchpad bug 1052674 in keystone "Keystone auth_token middleware should support Swift global memcache" [High,Triaged] 18:09:56 #link https://bugs.launchpad.net/keystone/+bug/1020127 18:09:58 Launchpad bug 1020127 in keystone "proxy-server Error: Second simultaneous read or write detected" [High,In progress] 18:10:20 same intent, different bugs 18:10:41 gyee, can you own this from the Keystone side? 18:10:49 sure 18:11:11 OK, other big issues? 18:11:36 https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New 18:12:20 btw, I upgrade pep8 to 1.3.3 and it started to flag a bunch of new pep8 errors 18:12:24 upgraded 18:12:40 in both keystone and keystoneclient 18:12:53 gyee, open ticket. We'll either fix or we'll ignore 18:13:13 question is which version is correct? :) 18:13:28 no errors from older versions of pep8 18:13:35 trying to figure out how to link https://bugs.launchpad.net/keystone/+bug/1082050 to the Ubuntu packagers crew 18:13:36 Launchpad bug 1082050 in keystone "Spelling errors reported on IRC" [Undecided,New] 18:13:50 mostly choking on line continuation 18:14:40 OK, lets move on 18:14:55 lets keep open discussion for the end 18:15:03 #topic Groups vs. attribute mappings 18:15:31 ok, so last week we approved the groups bp….and so I am starting implmentation 18:15:45 dwchadwick, I'm guessing which side of this discussion you are going to take... 18:15:52 david & I have had some conversations and Kirsty and I need to have some more 18:15:54 Henry raised an issue that the attribute mapping blueprint did not mention tenants so that has been fixed now. A new version was published just before the meeting 18:16:33 Kristy is not starting the implementation. We plan to have the first version available by the end of the year 18:16:51 "not" should be "now" right? 18:17:00 If Henry makes the changes he needs to use this for groups it should make both our works easier 18:17:03 dwchadwick: so have been looking at that…perhaps the thing that is missing is what actually going to use the attributes to enforce permissions 18:17:34 soyeah, that is going to require buy in outside of Keystone 18:17:37 i.e. what changes are needed elsewhere in keystone 18:17:57 We want to use the policy engine to support ABAC 18:18:10 and policy engine is going to live in Oslo 18:18:14 I would think so 18:18:28 We also have an open source policy engine that we can use 18:18:29 So I think the right approach is like what we did for PKI 18:18:58 make it work, but disabled by default. Make is a "seamless change" and switch the default in the H timeframe 18:19:10 ayoung: +1 18:19:27 dwchadwick, is that engine in Python? It will be a non-starter if it isn't 18:19:38 no, its in java 18:19:42 haha 18:19:52 dwchadwick, so was Keystone originally 18:19:57 but we have a python interface 18:20:01 ayoung: excellent idea 18:20:04 and it uses xml too? :) 18:20:08 heh 18:20:15 yea 18:20:23 * heckj hangs his head 18:20:26 dwchadwick, well, we can use it as the reference implementation, 18:20:40 exactly. but back to attribute mapping 18:20:41 same kind of thing was an issue when talking about using Dogtag for certificates 18:21:04 Henry, I did not follow your comment 18:21:30 ayoung: I do like the idea of getting the attribute implementation in there, finding where we need to do the hooks, but disabled by defualt 18:21:37 dwchadwick, you mean "what actually going to use the attributes to enforce permissions" 18:21:48 dwchadwick: sorry :-) which one? 18:22:02 henry. Ok, now I follow. You are talking about the PDP 18:22:21 dwchadwick, please expand your acronyms 18:22:30 But the attribute mapping design was specified so that it can work with the existing RBAC interface 18:22:54 I see the use of ABAC by services as independent of attribute mapping 18:23:47 PDP - policy decision point. The policy engine that is fed an RBAC or ABAC policy and returns a grant/deny decison 18:24:05 dwchadwick: yes 18:24:23 PDP is the term used by Internet RFCs and most published papers on authorisation 18:24:28 dwchadwick, yes, so Keystone doesn't own that. 18:25:07 Exactly. Thus attribute mapping is independent of how services make their authz decisions. It only effects how user attributes are converted into roles and tenants 18:26:08 Whilst groups do not help with the longer term strategy, attribute mappings do, and can provide most of the functionality that groups need 18:26:41 dwchadwick, so are you saying for V1, we make no changes to the current policy enforcement, and instead only focus on mapping an attribute to a role in a tenant? 18:26:50 but adds more complexity? 18:26:56 The only thing missing is for the administrator to give the users some group memberships, and then for keystone middleware to pick these up and call the attribute mapping service 18:27:10 ayoung - exactly 18:27:48 Plus mapping is an optional feature that can switched on or off 18:27:56 what I had in mind was a having a reference groups implementation that is wholly contained withng "current keystone mechanisms", with a prototype that would talk to the attribute mapping component 18:27:59 dwchadwick, OK, so I think we still need groups. They are a n additional attribute for a user that will then map to multiple roles. 18:28:22 (sorry I menat prototype interface) 18:28:23 I don't think we have anything yet that can do that for us 18:29:11 ayoung. Yes you need something like groups to solve the use cases Henry specified in a non-federated world 18:29:30 dwchadwick, but not in a federated world? 18:29:41 ayoung yes, what is missing from our service is the capability for administrators to assign organisational attributes internally 18:29:53 But what I am suggesting is a simpler implementation of groups for Henry because the service that deals with assigning tenants and roles to groups is done by the attribute mapping service 18:29:57 that way we can flesh out how the attribute mapping side works, what the admin interfaces for it are etc. etc. and know we can switch over groups to use it when we have those production ready 18:30:34 then when we migrate to federated access, the same attribute mapping service is used and the group assignment feature is no longer carried out in Keystone, but in the organisation that acts as the IDP 18:31:11 dchadwick: I'm less worried about typing that Henry has to do, but rather how we incrementally get to where we need to be and still ship production ready code at G and H 18:31:20 henrynash, do you understand what dwchadwick is proposing? 18:31:44 So to summarise. Users need to be assigned to groups or organisational attributes. This is done either in Keystone (centralised authn) or in the IDPs (federated login) 18:31:56 right 18:32:07 ayoung: only in part… 18:32:13 then these group attributes are mapped into keystone roles and tenants by the attribute mapping service 18:32:15 so groups is a must, attribution is option, that right? 18:32:23 attribute mapping I mean 18:32:53 gyee - groups on their own are useless. This is because services dont understand them 18:33:14 they are useful in assigning roles 18:33:18 ayoung: I understand the parts do far proposed, but seems to me that there are still significant pieces to fill in 18:33:28 groups have to be mapped into tenants and roles. So we need the attribute mapping service for this (or something similar) 18:33:41 OK, lets say we have a groups table 18:33:51 then we add an attribute_mapping table 18:33:58 gyee - no groups are only useful in assigning roles if you have a service that can do this 18:34:09 and a group assignment table 18:34:40 just a small comment - groups are also useful for some access control models like ACLs - if someone will wish to plug this in at the storage level 18:34:44 one a user is assigned to a group via an entry in the group assignment table, we add an entry in the attribute_mapping table that would give them the role? 18:34:45 dwchadwick, groups is only visible to Keystone 18:35:07 yes tables will do this, but if you look at the entity relationship diagram in our blueprint you will see that a simple table is not good enough in general to do many to many mapping 18:35:46 To do many to many mapping you need several tables (as per our diagram) 18:36:52 you need a group table, an OS set table (which links together tenants and roles) and and a mapping table 18:36:52 dwchadwick: agreed in general - but so far in keystone we have chased static assignments and hence the groups proposal is to extend that staid model….I agree a longer term goal of more flexibility is good 18:37:38 hmm, some words didn't come out right in that sentence :-) 18:37:54 henry - but you still have to deal with tenants and roles dont you? 18:38:03 (chosen status assignments……extend static model) 18:38:18 dwchadwick: sure 18:39:06 Our model has five new tables I think 18:39:36 dwchadwick, OK, I think we need to go back and review to that design. Let me see if I can get it up on line 18:39:38 we don't use the sets model of course in leystone today 18:39:40 So this is what we are talking about. Providing a set of APIs for setting, getting and deleting the table entries 18:40:03 https://docs.google.com/a/kent.ac.uk/document/d/1cObK3P_ic9XSTwJRFsmimG94LDnFbsPbvx_H1aM1FPI/edit# 18:41:56 Should we move to the next topic now and continue detailed discussions about attribute mapping via email, as time is running out 18:42:45 Well, I think we covered everything but trusts 18:42:50 #topic Trusts 18:43:06 http://wiki.openstack.org/Keystone/Trusts 18:43:24 this seems to be progressing nicely 18:43:43 I think some more work is still needed for recursive delegation 18:43:44 I feel pretty good about this spec. There was one outstanding issue about whether we should allow administrative acces to the trusts. 18:44:02 dwchadwick, agreed, but I think I want to punt on recursive for phase 1 18:44:19 You will need either backdoor or front door API access for administrators 18:44:23 Since that is encapsulated inside of Keystone, we can phase it in 18:44:37 dwchadwick, yeah, and I guess there is no harm there, either 18:44:45 it will be either GET or DELETE 18:45:02 Yes, you can default delegation depth to zero in the first implementation. Also default validity time to infinity 18:45:54 I don't think I want to allow admins to create Trusts, and no one should be able to modify them 18:46:04 ayoung: I like where it's going - want to get vishy input on it too, as it'll impact a number of pieces in core nova as well 18:46:10 You can also omit most other policy fields in the first implementation so that delegation is based primarily on the tenant and roles 18:46:12 (any notmyname and bcwaldon) 18:46:35 ? 18:46:39 ayoung agreed. Admin should only read and delete 18:47:01 heckj, yes, but i suspect that, like most things, they won't pay attention until it is implemented and they try to use it. 18:47:12 * ayoung is slightly jaded from PKI 18:47:29 I have to go in five mins. sorry 18:47:31 ayoung: fair enough, I'm pushing them to look, read and think about it here 18:47:55 heckj, as well we should. 18:48:07 #topic open discussion 18:48:16 once they start to use it, then they will be hooked and you will have plenty of demand for new features :-) 18:48:28 Can you all chime in with who is working on what, if it has not come up in the meeting yet? 18:48:35 What about adding IDPs to service catalog 18:48:50 aah, right 18:48:51 Kristy has nearly finished this implementation now 18:49:31 It wont be needed until federation, but it would be nice to include the code to make sure it is bug free 18:49:33 I don;t see anything contraversial there. 18:49:45 yes, i should have a rough implementation finished by the end of tomorrow. 18:49:53 excellent 18:50:13 (separate topic): I think we need more clarity on what we mean when we talk about a "tenant" in v3 and beyond 18:50:15 but make sure it is smooth before it is sent for QA :-) 18:50:32 kwss, great. don't be daunted by the thoroughness of dolph's code reviews. 18:50:39 tenant is an entity in the ISO standard for clouds 18:51:12 It is equivalent to account holder so I am led to believe 18:51:13 henrynash, yes. The thing is, we misused tenant in Keystone in the past 18:51:30 ayoung: agreed 18:51:31 * heckj is tired of tilting at that windmill 18:51:41 which is why we want to get everyone saying project for a while before we reintroduce the term in its correct meaning 18:51:50 * vishy has something to add to the meeting when there is a moment 18:51:55 we (the project) blew that earlier I'm afraid, makes it difficult to reset to what is reasonable 18:51:58 ayoung: lol 18:52:06 vishy, you have the conch 18:53:11 seeing as vishy seems to have dissappeared, what about the release shedule for federation 18:53:49 If we can get attribute mapping and idp service in first, then it makes the rest that much less work 18:54:14 dwchadwick, so it really is a question of having it ready for review 18:54:24 IDPs will be G2 18:54:26 BTW, there is an OpenStack meeting in London tomorrow, where I am giving a talk about federated Keystone 18:54:51 dwchadwick, where is attribute mapping? Almost done? Month or two away? 18:55:12 vishy: jump in whenever 18:55:15 Ok, so once Kristy has finished IDP service it will go for review, then next will be attribute mapping, and then finally the revised federation making use of the new service APIs. 18:55:41 Sorry but I must go now. Take care everyone 18:55:58 dwchadwick, agreed. So I would guess that G3 is likely, but like PKI, a tech preivew for Grizzly? 18:56:11 ayoung, we hope to have an attribute mapping implementation ready by the end of the year 18:56:46 kwss, I would warn you that things slow down in December, but I promise to keep on top of any code reviews 18:57:08 ayoung, understood 18:57:16 But that should stil be a go for G2 18:57:54 But even if it isn't It really matters how far between that and the full Federated impl 18:58:23 heckj: sorry, missed the notification 18:58:46 and that is likely to be completed shortly before the end of the Grizzly cycle. We'll have to decide based on how close and how hard it is to test whether it goes in, and if so, if we caveat it with "something new and shiny, please test." 18:58:49 heckj: so we were discussing having a way to map tenant_ids to tenant_names 18:59:10 is there an easy way to do it a) for one tenant and b) in bulk for a group of tenants? 18:59:32 vishy, tenant ID generation defaults to uuid, but it doesn't need to be 18:59:50 tenant ID just needs to be unique, so the two could potentially be the same 19:00:17 let me peek at the create_tenant API, 19:00:58 vishy: today, no - but we could make an extension API to single or bulk lookup 19:00:59 also tenants are created by name, but deleted by tenant_id - this is very inconvenient. Can this be changed? 19:01:09 tenant_ref['id'] = tenant_ref.get('id', uuid.uuid4().hex) 19:01:28 so you should be able to create a tenant with a specified ID that you pass it in 19:01:41 TenantController.create_tenant 19:02:01 can we allow delete by tenant name as well (and implement the look up inside)? 19:02:02 You can't modify the id once it is created 19:02:26 working with names is easier ... 19:02:34 i get push back about making them the same 19:02:49 becuase then project names can't change 19:03:02 i just need a way to map one to the other for user display 19:03:05 Alex-Shulman, I think we can make that extension. It is not changing previous behaviour. It would also entail a CLI change 19:03:07 horizon needs it too 19:03:30 this will be great, thanks 19:04:02 Alex-Shulman, file it as a ticket in track 19:04:11 ok 19:04:23 er, launchpad 19:04:30 ayoung: heh 19:04:49 vishy, by mapping, do you mean just an API to enumerate all the tenants, names and ids? 19:04:49 vishy: I'll create a quick BP to make an extension or something for the lookup - will that work to get it started? 19:05:07 ayoung: lit "give me a name for this UUID" 19:05:15 ayoung: for projects and users I think 19:05:26 * heckj bets cielometer would love that too 19:05:35 * mordred would love it 19:05:43 * mordred loves UUIDs 19:05:48 heckj GET works for userid 19:06:15 mordred: i think the whole infra team loves uuids. ;) 19:07:20 I have to leave. Take care :) 19:07:21 * mordred hands jeblair a UUID, asks what its name is 19:07:35 cheers, everyone 19:09:57 mordred: it's name is "#endmeeting" 19:10:42 ayoung: care toe #endmeeting for us? 19:10:45 #endmeeting