18:02:18 #startmeeting Keystone 18:02:19 Meeting started Tue Jan 6 18:02:18 2015 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:20 link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:23 The meeting name has been set to 'keystone' 18:02:26 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:02:30 gyee, LOL. enjoy rubbing it in! 18:02:55 we'll come back to henrynash's stuff at the end (since henry is on vacation) 18:03:00 welcome to 2015. 18:03:17 o/ 18:03:30 lets keep things moving in the right direction, and we'll be up on the milestone 2 in no-time 18:03:50 #topic Migration path for R/W LDAP spec 18:04:00 jorge_munoz, o/ 18:04:08 #link https://review.openstack.org/#/c/140175/ 18:04:08 Who needs R/W LDAP? Can we kill it? 18:04:23 ayoung, not likely 18:04:24 :) 18:04:24 just get rid of it 18:04:45 joesavak, is jorge_munoz here? 18:04:45 +1 18:05:01 lbragstad: ^ 18:05:02 I think so - let me ping him 18:05:03 yes 18:05:04 * topol Im worried ayoung has dimensia setting in 18:05:06 he is 18:05:13 he is typing 18:05:18 furiously 18:05:21 hehe ok 18:05:23 topol, multiple dimensions 18:05:27 Yes, I wanted to ask how much implementation detail needs to be in the spec for the new schema. Also, wanted to get some feed back on the downgrade path. 18:05:48 "new schema" meaning what? We should not be specifying a schema 18:05:49 we generally suck at downgrade 18:06:02 LDAP is written to work with existing schemas. I would say more like: 18:06:14 "base level assumptions of schema..." 18:06:51 the current r/w ldap is bad and probably should be removed. however there is a desire to keep r/w ldap from a few sources. 18:06:57 jorge_munoz: avoid implementation detail in the spec, in general, otherwise +1 for ayoung 18:07:09 * ayoung reads spec 18:08:05 jorge_munoz, jorge_munoz So...why LDAP? Is it the replication story that you need? 18:08:54 morganfainberg: are all those sources represented here right now? 18:09:05 dolphm, should be. 18:09:12 dolphm, i have been chasing down who else uses it. 18:09:17 Note that I am not categorically against LDAP as a backend, just that the number of Orgs requesting support for it has dropped to 1. 18:09:39 uno? 18:09:42 @ayoung We have an identity system that uses an LDAP backend for both read and writes. 18:09:43 I kindof like LDAP for assignments, but can't personally justify the time it takes to support it. 18:09:44 dolphm, there were more at one point, but i can't get anyone to respond now. so 18:09:54 dolphm, it'd be what rackspace is asking for. 18:10:07 use your ldap tools to update your ldap directory 18:10:16 we shouldn't have to provide a new tool for doing ldap updates 18:10:23 morganfainberg: i'm not sure it's what rackspace needs at all, but i could be too far out of the loop 18:10:39 dolphm, at this point, that spec is what i have to go on. 18:10:41 bknudson, replace LDAP with SQL in that statement and see how much it makes you shudder 18:11:02 dolphm, so, i'm willing to let jorge_munoz and joesavak make the case 18:11:08 ayoung - LDAP due to service level agreement with vendor, replication rules that we have, and the current integrations we have with it. 18:11:09 it's common to have applications define their own sql schema. 18:11:13 it's also not very smart 18:11:15 jorge_munoz, in light of the proposed project reform (http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html), its a good time to test the new water with this thing :) 18:11:35 gyee, negative 18:11:52 hey, if we are going to separate out IdP from Keystone, why now? 18:11:55 gyee, that would be the equivalent of writing their own keystone afaik 18:12:05 gyee, which is not what is being proposed here 18:12:05 hell yeah 18:12:16 so Identity is for users, but I understood Rack to need Assignment support as well, right? 18:12:27 right 18:12:32 correct 18:12:48 gyee, that is a different bit of work, first off we need the split - not "go write your own keystone to get a split" 18:12:56 joesavak: jorge_munoz: is there anyone else interested in using the same architecture as rackspace? 18:13:16 joesavak: jorge_munoz: i'm wondering if rackspace's solution should be open source, but perhaps not upstream / maintained by keystone core 18:13:20 gyee, slightly different. don't force a complete re-write of keystone to get the split, the split should happen independently 18:13:38 but this is a lot of rewrite as is 18:14:06 just saying 18:14:06 gyee, the split should occur *anyway*. please take that off the table as part of this dicussion 18:14:25 anyway, I don't have a problem either way 18:14:27 keep this focused on r/w ldap, support of it going forward. 18:14:28 etc 18:14:53 @dolphm It could be but having a cleaner implementation give better option of deployers 18:14:56 dolphm - heard from a few large customers that they are interested in it for their private cloud deploys. Sit on top of exisitng LDAP and not use federation as they don't have ADFS or consider it too c omplex. 18:15:02 jorge_munoz, and joesavak can you guys get some feedback from the operators and other users who else is interested in LDAP support for Assignments 18:15:03 ? 18:15:24 if they have existing ldap then that's not r/w ldap 18:15:53 bknudson, the Rack rational is replication, which is what CERN was using it for as well 18:16:10 LDAP has a better multi-site story than MySQL 18:16:32 then they should pick a database that supports it better 18:16:35 ayoung, to a very limited scale without insane topology that rivals sql in complexity and risk 18:17:06 morganfainberg, LDAP as a domain controller (jhosts, hierarchical) is very well trodden territory 18:17:10 ldap and sql have different scale concerns, but both are largely solved. 18:17:13 jhost-> just hosts 18:17:50 @ayoung Sure, we can do some in inquiries on who would be a consumer of the LDAP drivers. 18:17:53 ayoung, it's bad when you get to 10-20 sites, your topoligy for replication is as complex/more risky per-addtion/change to the layout [not data] as SQL 18:18:22 it's all bad for unified replication. 18:18:29 so we're talking about replacing the current LDAP implementation with a new one? (that's going to be awesome) 18:18:30 jorge_munoz, it sounds like the biggest thing you are looking for is upgrade/downgrade support, which is likely to be Directory Server specific. 18:18:40 what are you guys using? 18:18:45 if you care to share... 18:18:54 We want to target 389 18:18:58 :) 18:19:35 morganfainberg, I think perhaps out-of-tree makes sense for this effort 18:19:53 would a keystoneldap project make sense? 18:19:56 if this is out-of-tree do we keep the old ldap? 18:20:16 bknudson, I think maybe we pare it down to RO Identity 18:20:21 bknudson, i'm willing to do ML/survey etc work to find out if we can deprecate r/w ldap 18:20:37 well, deprecate ldap assignment, and separately r/w ldap identity 18:20:38 There might still be users who want to user their own schmea 18:20:39 that sounds great 18:20:42 two different concerns 18:20:45 jorge_munoz, joesavak you guys need multiple domains with R/W LDAP Assignement? 18:21:42 so it sounds like the best option here would be to build this out of the keystone tree 18:21:46 so possibly stackforge? 18:21:47 agree with Jorge - the backend schema for LDAP should be implementor choice. 18:21:59 ayoung, bknudson, if we ask this to go out of tree, short of saying "go write your own keystone" we would need to agree to solidifying the manager-api for assignment and/or identity 18:22:20 if the backend schema is up to the implementor you'll have all sorts of options... so what's different with the existing ldap implementation? 18:22:39 ok, we'll all on the same page then :) 18:22:44 ayoung, bknudson, i would like to avoid saying "go write your own keystone" [that feels like the wrong stance to take right now to keep the community close] 18:22:44 morganfainberg: ++ 18:22:49 joesavak, jorge_munoz if you are already targetting 389, lets get a discussion going between your team and the FreeIPA team. Perhaps we can handle this as stackforge effort 18:23:24 morganfainberg: and resources! 18:23:29 bknudson, yes. 18:23:45 (noting that we can't solidify the api since we change it all the time) 18:23:55 but we should work to make that interface very stable/non-changing anyway 18:24:09 but that is something we've not committed to yet. 18:24:20 this comes to that whole "better pluggable architecture" conversation 18:24:28 so are we saying any schema different than the one in place right now that needs driver development - that driver dev needs to be in stackforge? (lost) 18:24:41 where things plugin shouldn't change massively - just like the REST api shouldn't. 18:25:23 joesavak, that would sum up the general view - unless i'm miss reading things ( ayoung ?) 18:25:27 is that the problem that the LDAP rewrite is trying to solve? the schema is wrong? 18:25:33 joesavak, right now LDAP is very light on schema requirments, which works for Identity, but does not really work for Assignments. I think that targetting something more rigid like a FreeIPA Hostgroup/project design would work better 18:25:52 bknudson, plus no way to do migrations 18:26:29 bknudson, it's trying to solve the "we've tried to wedge keystone into current ldap schemas when keystone controls everything" - it's a poor representation of what we support because the LDAP schema (default) isn't designed to handle the assignment backend 18:26:41 the identity backend is much closer to what a normal LDAP schema would support. 18:26:50 i like the other approach of surveying user of ldap schema in place, or perhaps versioning them to get to a schema that handles assignments too 18:26:52 if assignment is meant ot be r/w it probably should have it's own schema 18:27:17 An IPA backend for Keystone would probably be easier, as it would let you do things like creating users and hosts at the Python level as opposed to direct LDAP calls 18:27:17 whether that is in-tree or out. 18:27:40 ayoung, ok we need to isolate the conversation, identity OR assignment? 18:27:44 which are you talking about now. 18:28:00 because we're crossing them all over this conversation and they are different concerns 18:28:09 morganfainberg, I'm actually talking about the Write side of LDAP for both 18:28:13 o/ sorry i am late 18:28:15 Identity LDAP is primariy R/O 18:28:26 the R/W discussions is for both Id and assignement 18:28:31 ayoung, and assignment in LDAP is a poor representation of what keystone supports 18:28:34 but is, I think, a niche case 18:28:37 I don't see that they're different concerns... we should either support LDAP or not support it... right now it's kind-of supported. 18:28:40 regardless of r/w or r/o 18:28:52 having 2 non-conflicting schemas for LDAP (assignment & ID) may work - needs more research 18:29:13 great topic for the upcoming meetup 18:29:14 joesavak, and you need multi-domain, too, right? 18:29:14 bknudson ++ 18:29:23 ayoung: yes 18:29:25 bknudson, we can't remove ldap identity in the near term (read/only) that is for sure. but that isn't a hard sell or missing anything really from what we support 18:29:39 morganfainberg: but we could deprecate it 18:29:45 jorge_munoz, jorge_munoz nkinder OK, lets table the rest of the discussion,and the 4 of us should set up a meeting instead 18:29:47 i assume that's all we're discussing here 18:30:11 dolphm, this is the issue we are discussing 3 things: identity r/o, identity r/w, assignment ldap 18:30:19 er..the second jorge_munoz should have been joesavak 18:30:37 morganfainberg, I think I would suggest the following: 18:30:41 dolphm, some of that could be deprecated, some could be sooner vs later 18:31:01 1. Remove R/W from Keystone as is. 2. Work with Rackspace to come up with a solution specuific to their needs 18:31:29 i think the answer is ML/survey on LDAP assignment (both) - ML/Survey on R/w identity (seprate), leave r/o identity for now as is 18:31:41 ayoung: we don’t want to modify the current implemetation just yet 18:31:48 +1 morgan 18:31:52 jorge_munoz, I understand. We can help on that 18:32:00 if we're clear (less people/no one using) on the r/w front we can deprecate them, slate for removal in M 18:32:15 i am near positive assignment will be able to go 18:32:17 jorge_munoz, the R/W code as it exists is crap. I should know, I wrote it. 18:32:37 It makes a lot of assumptions, but FreeIPA was in my mind when I made those assumptions 18:32:47 r/w identity *may* go, may need to wait till we split the identity part out and fully support something better (e.g. FreeIPA interface/separate API to manage things, etc) 18:32:53 So if you need W/R LDAP, it should be do-able 18:33:22 and r/o ldap identity can be evaluated once the r/w stories are dealt with 18:33:35 yes 18:33:37 ayoung - sounds like a good collab opportunity. We'll discuss offline 18:33:52 morganfainberg: jorge_munoz ++ 18:34:00 #action joesavak and jorge_munoz to poll deployers on LDAP use-cases 18:34:24 #action morganfainberg to sent ML topics and surveys to determine use of ldap assignment (possible deprecation) 18:34:47 #action morganfainberg to send ML topics and surveys to determine use of read/write identity with LDAP (possible deprecation) 18:35:32 #action ayoung nkinder jorge_munoz joesavak to work offline to look at out-of-tree implementation to cover specific use-cases. 18:35:41 does that cover everything? 18:36:04 yup 18:36:21 anything anynoe else wants to add before we move on? 18:36:49 #topic AEToken Specification 18:36:53 #link https://review.openstack.org/#/c/130050/ 18:36:55 lbragstad o/ 18:36:57 there has been some discussion on the spec https://review.openstack.org/#/c/130050/23/specs/kilo/ae-tokens.rst 18:37:08 specifically between nonameentername and gyee 18:37:18 around the token_version 18:37:21 vs. token_format 18:37:36 bikeshedding 18:37:41 and what all needs to be known in order to determine how to unpack the token 18:38:07 lbragstad, what's the problem? I don't have any issue with the spec 18:38:17 lgtm 18:38:21 OK, so I'm lukewarm about AE 18:38:24 nonameentername: could you elaborate on the point you were making? 18:38:52 ayoung, as long as we have a non-persistent provider in kilo and an easy way to get new providers in, i'm happy 18:39:05 the non-persistent provider could be AE, it could be PKI based, etc 18:39:09 ayoung, having 1 is important. 18:39:12 morganfainberg, AE as writtend doesn't meet that requirement 18:39:20 during deployments of keystone there is a period of time when there are two releases. There should be a way to tell what version the token is. 18:39:20 ayoung, it does. 18:39:22 AE does not record role assignements 18:39:26 they are recreated 18:39:29 lbragstad: this seems like something that can be easily added later if we need it 18:39:48 ayoung, it doesn't need to be, just the scope is enough 18:39:56 nonameentername: and that assumes there is something different, data-wise, between the two tokens 18:39:57 ayoung, that doesn't mean it doesn't meet the non-persistent qualifier 18:40:14 morganfainberg, it means we've redefined what is meant by a token 18:40:15 lbragstad: yes 18:40:15 ayoung, like i said, as long as we have a non-persistent provider this cycle i'm happy. 18:40:26 we have that now with PKIZ 18:40:29 nonameentername: so, with that 18:40:44 ayoung, no we don't PKIZ is not-non-persistent as is there is work that is needed to get there on either front 18:40:46 nonameentername: we can add two extra bits and leave those for the driver to determine what they need it for 18:40:48 we just need to make PKIZ small enough 18:41:04 OK...so 18:41:15 ayoung, PKIZ could be the basis, i'm not concerned with which one we end up with or if we have multiples - as long as we hit a non-persistent provider. 18:41:17 1. We need a registry of token formats. Please review that spec 18:41:28 2. We need revocation events regardless 18:41:34 lbragstad: that would work. 18:41:36 ayoung, invert those two in priority. 18:41:37 3. Revocation events was written in March 18:41:46 but yes 18:41:46 nonameentername: so, something like AE0001? 18:41:49 morganfainberg, they are orthogonal 18:41:51 we need both 18:42:46 AE spec needs special work for Trusts and OAuth as I recall 18:42:48 lbragstad: yes 18:42:51 has that been addressed? 18:42:52 ayoung: I reviewed token registry 18:42:58 lbragstad, thank you 18:43:11 lbragstad, nonameentername, i think this is a topic that is into implem,entation details now 18:43:35 lbragstad, nonameentername, and it does sound a lot like bikeshedding 18:44:13 I think we can work through the rest of my reservactions on AE, but you need to be dilligent 18:44:14 let's just realize that specs aren't written in stone and it's not a justification in a review to say that this was agreed on in the spec. 18:44:14 can we continue this in -keystone channel, and work to resolve the issues before looking at AEToken as a viable in-tree provider? 18:44:27 there are a lot of assumptions we need to make explicit 18:44:27 bknudson: ++ 18:44:29 bknudson, ++ that works. 18:44:45 morganfainberg: I agree, this can be done when impelmenting the code. 18:45:07 I'd like to see what the code looks like and also get the other required changes in... e.g., revocation events 18:45:12 ok lets move on. 18:45:35 #action *EVERYONE* review revocation events - help to get it in place as the default to replace the revocation list 18:46:09 moving on 18:46:18 #topic Assignment split 18:46:26 Henry isn't here, but he's split the review up 18:46:33 mr nash is not present :( 18:46:35 please start reviewing it 18:46:42 starts here: 18:46:45 #link https://review.openstack.org/#/c/144239/ 18:46:45 rumor is he is in Hawaii? 18:47:03 let's spread that rumor 18:47:04 business or pleasure 18:47:10 #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/pluggable-assignments,n,z 18:47:35 moving on 18:47:39 #topic Spec Review 18:47:41 gyee, why not both 18:47:56 Please review specs. Lets get the easy ones in prior to the meetup. 18:48:17 #topic BPs / reviews that do not need specs 18:48:21 marekd's got a nice spec for redefining the way we get a scoped token for federation 18:48:22 bknudson, o/ 18:48:25 it's probably the smallest spec that's up there 18:48:54 refactor keystone-all and http/keystone 18:48:54 bknudson, you have these please lead us on it. but in short if we agree - we'll note it and those can be merged w/o a spec 18:49:15 looking at these i think they can safely be done w/o a spec. (personally) 18:49:16 https://review.openstack.org/#/c/145204/ 18:49:27 and the spec is indeed tiny 18:49:33 so this is about moving code out of keystone-all / http/keystone into keystone.* and then reuse code 18:49:38 bknudson, ++ 18:49:47 I don't know if we need a vote or what? 18:49:48 required for https://review.openstack.org/#/c/130593 18:50:15 stevemar: thanks for bringing it here :-) 18:50:37 bknudson, can do a vote 18:51:33 or, if someone doesn't like the explanation on the meeting, can complain about a specific one and then I'll write a spec 18:51:35 #startvote Does the refactor of keystone-all and http/keystone need a spec? Yes, No, Abstain 18:51:36 Begin voting on: Does the refactor of keystone-all and http/keystone need a spec? Valid vote options are Yes, No, Abstain. 18:51:37 Vote using '#vote OPTION'. Only your last vote counts. 18:51:49 #vote No 18:51:55 #vote no 18:52:16 #vote No 18:52:51 #vote No 18:53:00 #vote NO 18:53:13 #vote Abstain 18:53:29 * joesavak feels like a true politician now 18:53:31 I'm not sure why refactors would even need a spec 18:53:42 joesavak, I cannot confirm nor deny 18:53:57 joesavak or "I am not a crook"? 18:54:00 * topol joesavak show some backbone spineless jello 18:54:12 one of my aides typed that in. I was on the golf course. 18:54:14 breton, some refactors are large - and have a lot of moving parts 18:54:17 #vote No 18:54:42 breton, this is the whole reason we added the "some bps don't need specs" concept. 18:54:49 i don't think refactors ever need a spec, unless somehow that refactor impacts end users 18:54:54 in which case, it's not a refactor 18:54:54 dolphm, want to proxy for dstanek ? ;) 18:54:59 I did not have relations with that code module keystone-all 18:55:11 topol, LOL 18:55:17 #showvote 18:55:18 Abstain (1): joesavak 18:55:20 No (6): morganfainberg, bknudson, dolphm, jamielennox, breton, topol 18:55:31 topol: just wait for the stained dress. 18:55:44 my vote was bought. 18:55:48 anyone else? lbragstad, ayoung, stevemar nkinder 18:55:57 morganfainberg: why a bug isn't enought? How do we differentiate no-spec-refactoring and bug-is-enough refactoring? 18:55:57 marekd 18:56:09 #vote nO 18:56:23 gyee, tester heh 18:56:23 *enough 18:56:27 morganfainberg: safe to say it's No i think 18:56:31 #endvote 18:56:32 Voted on "Does the refactor of keystone-all and http/keystone need a spec?" Results are 18:56:33 Abstain (1): joesavak 18:56:34 No (7): gyee, morganfainberg, bknudson, dolphm, jamielennox, breton, topol 18:56:40 yeah bknudson , i'd say it's all good 18:56:48 ok, I'll put a blueprint on it. 18:56:50 #vote no 18:56:50 breton, it's because some refactors have a lot of moving parts. 18:56:52 nooo i missed it 18:56:57 stevemar, late to the game! 18:57:04 next is "refactoring keystonemiddleware to extract classes" 18:57:07 #vote no 18:57:09 does it even need a blueprint? 18:57:09 #note no 18:57:14 #vote no 18:57:15 stevemar: if it all goes to hell you can at least say it wasnt your fault 18:57:16 #note vo 18:57:16 #note vo 18:57:22 breton, and *could* impact deployers and/or users 18:57:27 stevemar: my dyslexia has set in 18:57:34 #tone loc 18:57:35 if we're using voting, you need to end the previous vote first 18:57:40 i did! 18:57:44 dolphm, ^^ 18:57:44 #vote no 18:57:57 i just haven't started the next vote 18:57:59 :P 18:58:10 #phone home 18:58:25 #startvote refactor keystonemiddleware to extract classes need a spec? yes, no, idontlikepolls 18:58:26 Begin voting on: refactor keystonemiddleware to extract classes need a spec? Valid vote options are yes, no, idontlikepolls. 18:58:27 Vote using '#vote OPTION'. Only your last vote counts. 18:58:32 #vote no 18:58:36 #vote no 18:58:42 #vote no 18:58:45 #vote no 18:58:45 can we start up an etherpad for the hackathon? 18:58:47 well, ok. IMO it wasn't even worth voting. 18:58:53 get some goals outlined there 18:58:53 #vote no 18:58:58 bknudson, and please do still use a BP (tag it to k2 and set a priority) 18:59:18 (this time i didnt miss) 18:59:20 morganfainberg: I'll file bps for all these that we agree on. 18:59:21 have we ever done a full spec for middleware? 18:59:21 #vote no 18:59:22 #vote no 18:59:25 just do it 18:59:29 #vote no 18:59:37 breton, the point of voting is to make sure we're clear on not needing a spec. 18:59:48 #showvote 18:59:49 no (8): gyee, morganfainberg, bknudson, marekd, dolphm, jamielennox, stevemar, topol 18:59:59 going in 5 19:00:05 #vote no 19:00:16 annnnnnnnddddd 19:00:19 #endvote 19:00:22 Voted on "refactor keystonemiddleware to extract classes need a spec?" Results are 19:00:23 no (9): gyee, morganfainberg, bknudson, marekd, dolphm, jamielennox, stevemar, breton, topol 19:00:23 #vote bandwagon 19:00:39 out of time... can work on the rest next week 19:00:44 bknudson, ++ 19:00:46 \o/ 19:00:48 #endmeeting