18:00:54 #startmeeting keystone 18:00:55 Meeting started Tue Feb 17 18:00:54 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:59 The meeting name has been set to 'keystone' 18:01:02 https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:19 #topic kilo targeted specs 18:01:34 hi 18:01:41 morganfainberg brought this up, Specs Targeted for Kilo that have not been started / have significant progress by 2/24 are subject to being punted until Liberty 18:01:48 o/ 18:01:57 o/ 18:02:06 I tried to make a summary of the items here 18:02:07 https://etherpad.openstack.org/p/keystone-k3-blueprints 18:02:14 stevemar: Specs or implementation ? 18:02:23 marekd, impl. 18:02:24 marekd, implementation 18:02:41 there are some that are not started (tokenless auth, domain config in sql) 18:03:09 so who's working this weekend? 18:03:16 and we have a lot of bps that have not yet landed, so the amount of reviewing will be compounded 18:03:23 o/ 18:03:27 stevemar, tokenless review will be posted today 18:03:42 today = before midnight PST 18:03:45 why does no one ever want to punt stuff :) 18:03:54 (oops, sorry I’m late) 18:04:13 this is just a heads up 18:04:25 if you want it to land in K, get it started 18:04:38 morganfainberg, you just need something that complies right :) 18:04:42 we have very little time left 18:04:42 stevemar: i think you skipped one, I will update etherpad, ok? 18:04:51 ++ if it's a new feature that's going into K, have something up by 2/24 18:04:52 sure 18:05:09 real implementation (not just POC/strawman) by 2/24 18:05:26 we're running out of time in k3 18:05:32 and k3 is Feature Freeze 18:06:00 morganfainberg, did you want to talk about the next topic if we're done with this one? 18:06:04 no slipping things in past k3 (without extremely good reasons, and most of these specs can wait) 18:06:07 stevemar, sure 18:06:15 cut abfab. We've seen nothing from those folks 18:06:22 #topic liberty spec proposals 18:06:30 gyee, are you actively working on X509? 18:06:36 * ayoung too slow... 18:06:57 ayoung, we're not specify specs we're cutting today, just warning people to get moving 18:06:58 ayoung, yeah, it's just a matter of time time abfab is cut, and gyee said he'll have something up by tonight 18:07:10 cool 18:07:10 anyway, Liberty specs will open once K3 is cut 18:07:13 ayoung, I am mentoring a fellow to get it implemented 18:07:27 o/ 18:07:31 the idea is I want to avoid what is happening right now next cycle (PTL or not) 18:07:32 OK...Liberty specs: just submit all specs to backlog first 18:08:02 ayoung, the point i'm making is as of K3 you can start proposing them to be moved to the liberty target 18:08:04 we'll promote something to a "lizardbreath" er "liberty" spec after it is approved for backlog 18:08:31 the goal is to avoid this "cram everything into milestone 3" effect we have going on now 18:09:08 yeah, we'll make the necessary changes to specs, should be quick 18:09:09 I'm frankly worried about the quantity and i think the road to RC is going to be rocky this cycle 18:09:16 morganfainberg, I think you guys are starting to see the perspecive I developed about a year and a half ago: we really need to lead the summit come the close of M3 in order to be able to progress. 18:09:50 ayoung, yeah, we are slow out of the gate for some reason 18:10:09 ayoung, i think we're going to FF next cycle at milestone 2, spec freeze at milestone 1, so the summit really is almost ½ a cycle from when we start accepting specs being proposed against liberty target 18:10:21 but more on that once we hit milestone 3 this cycle. 18:10:31 stevemar, well, I think we are getting more deliberate. Its frustrating, but also the sign of a mature-ish project 18:10:42 this cycle may have been timing because of the holidays shortly after the summit 18:10:44 morganfainberg, exactly 18:10:56 dstanek, its been that way every year, though 18:11:01 ayoung, ++ 18:11:04 December comes and suddenly....whooosh 18:11:09 nothing here is set in stone, just some thoughts - the only thing i'm aiming for is specs can be targeted before we hit the end of this cycle. 18:11:13 we also bumped the spec dates up this release 18:11:15 ok thats it. 18:11:17 M2 is starting at us. 18:11:28 maybe it will take a release to two to get used to it 18:11:53 we will probably hash this out at the summit 18:12:04 #topic Reminder: Review Code 18:12:07 stevemar, we will probably hash this out before we end this cycle ;) 18:12:11 So...I think we are acually on a really good trajectory. We've had the specs out for a while...we can have spec approve push at the summit, with an eye to hitting the ground running afterwards 18:12:43 having a really dep backlog will help. Pre-approved specs that are ready for impl come the end of the bug fix cycle 18:12:50 #link https://gist.github.com/dolph/651c6a1748f69637abd0 18:12:57 It's scary looking ^^ 18:13:04 dolphm, and morganfainberg set up this gist, and it's getting to look scary 18:13:09 that is currently the reviews for "approved" specs. 18:13:36 this is without stuff that hasn't been started, or (potentially) the AE (whatever it's named now) token spec 18:13:37 and osme of those haven't even been started or are missing large swaths of patches (50%+) 18:13:42 so please please please rview 18:13:45 morganfainberg, I'm wondering if we can punt on domain-as-project as a requirement for reseller 18:13:49 how many of those should be marked WIP that aren't? 18:14:14 the more I think about it, the more I am convinced that, while it would have been right from the get go, it will be easier to just work around it 18:14:16 dolphm, any of those i marked were not abandoned, maybe 1 was WIP, and a couple were merge conflicted 18:14:25 dolphm, but doesn't diminish priority 18:14:43 dolphm, not as many as you would hope 18:15:04 stevemar: well i want them all to be polished, ready-to-merge code 18:15:25 ayoung, we have a sort of backlog to organize code implementation around reseller (using domais as project ofc) 18:15:30 ayoung, raildo can talk to ou later :) 18:15:33 dolphm, we all want that, but the only way there to get there is to review :) 18:15:48 ayoung: sure 18:16:06 dolphm, the point is i think we need to punt things so we can get that list more sane. i made the list look awful on purpose to show how far behind we are based upon what is approved 18:16:16 samueldmq, raildo happy to talk after meeting on that. Let's get that one moving, cuz it is otherwise close 18:16:37 dolphm, and not as many as you'd think were simple rebase away from being ready for review 18:16:46 ayoung, ++ 18:16:49 dolphm, most were/are reviewable :( 18:16:50 ayoung: yes, we have few days, but I think that we can do that. 18:17:18 and the more people we have working on new things this week, the less reviews we have 18:17:18 anyway 18:17:34 we're behind is the point 18:17:52 point taken 18:17:57 and we need to eliminate things from that list and from the approved spec list (most likely) 18:18:09 morganfainberg, ++ 18:18:36 and we're more than a little bit behind 18:18:42 anywho 18:18:53 #topic Reminder: Triage Bugs 18:19:02 #link http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html 18:19:13 shoul we set a mentor for each major feature to get the first +2 in? 18:19:41 ayoung: ++ I like that idea. 18:19:42 dangit I can't keep up 18:19:45 stevemar: ok, so I recommend punting on the extra-disable bp idea….that can wait till L 18:19:56 ayoung, ++ not bad idea 18:20:00 ayoung: I don't know, that can deter other people from looking at it 18:20:13 ayoung, ++ for review czar 18:20:16 lbragstad, easier to get people to look when it has a +2 18:20:31 but not when other people still find issues with the code 18:20:45 what looks fine to one person might not look fine to everyone, 18:20:55 lbragstad, also, it will help to ensure *someone* is looking at the code 18:20:59 but still better than having nobody looking at that code 18:21:00 I'll take reseller 18:21:05 ayoung, ++ 18:21:26 I'll also take websso portal 18:21:36 conflict of interest? 18:21:38 ayoung: guess means what exactly you mean by “mentor” 18:21:45 and mapping enhancements...all those are of interest to out group 18:21:48 I think we've established we're behind and need to review anyway 18:21:59 jacorob, someone that stays on the review until they are comforatble giving it a +2 18:22:08 lets not say mentoring is required here. simply review. 18:22:09 nova actually requires cores to sign up to review the changes for the bp. 18:22:12 jacorob, prioritizion 18:22:20 morganfainberg: ++ 18:22:26 morganfainberg, not required. 18:22:27 lbragstad: what can we do motivate people to -1 +2'ed CR's? 18:22:40 bknudson, something we should probably consider once we're a bit less under water, right now limited mentoring is likely going to hurt us more imo. 18:23:08 amakarov, it depends on the reason for the -1. 18:23:19 amakarov: not sure I understand the question 18:23:21 Anyway.. I'll commit to staying on those 3. If you are an author on those...feel free to bug me 18:23:35 ayoung, ++ you hit it there, let the author decide 18:23:37 morganfainberg: if it is a reason of course :) 18:23:49 if you are authoring a patch and feel the need for a review buddy speak now 18:23:57 amakarov, if its a real concern, -1. if it's a nit pick, please don't minus 1, at worst no-score with comments. 18:23:57 or ping later on -keystone 18:24:15 ayoung: I appreciate that! 18:24:21 morganfainberg: amakarov or propose a follow on patch fixing that you think needs to be fixed 18:24:41 OK...we ready to move on to bugs? 18:24:43 yep 18:24:44 yup! 18:24:45 morganfainberg: I'm about the idea that +2'ed CR's attract attention 18:24:50 looking... 18:24:50 bug list is looking better. 18:24:52 #link http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html 18:25:01 it was really ugly last week 18:25:02 just a handful of new bugs 18:25:11 a few more eyes will help keep it in check 18:25:20 we got behind around the holidays and didn't pick back up 18:25:35 looking at 4. [Undecided:New] Bug #1421966 in Keystone: "Getting role for trust is double-protected" 18:25:36 bug 1421966 in Keystone "Getting role for trust is double-protected" [Undecided,New] https://launchpad.net/bugs/1421966 - Assigned to Lin Hua Cheng (lin-hua-cheng) 18:25:51 so, keep eyes open, if there is a bug in "new state" [even if it's prioritized], please take a gander and get it triaged. 18:26:07 the goal is to have bugs not in "new" and with a priority 18:26:07 double-protected? that security or what 18:26:08 i'll need to look at the notification one 18:26:22 morganfainberg, can everyone triage bugs? 18:26:24 My kneejerk reaction, though, is that none of those would be stop ship-bugs, so lets focus on features until freeze 18:26:29 I went through the policy.json to add comments, and found a few problems so opened bugs... 18:26:33 samueldmq: yes 18:26:39 since I didn't have time to work on all of them. 18:26:44 ayoung, triage the bugs, don't need to fix them 18:26:51 deal 18:26:52 bknudson, double-protected is a special feature 18:26:58 lbragstad, ok thx 18:27:04 ayoung, but triaging them early means if we need things fixed because they are major we can make sure we land that ASAP 18:27:13 e.g. the unicode issue w/ the mapping of ids 18:27:18 that was a major bug 18:27:24 and needed a backport to juno 18:27:31 ayoung, yeah, i agree with you there, none appear to be stop ships, and we should focus on features, but as morganfainberg says, we should triage at least 18:27:57 it also gives people things to do when they get stuck on features and want to look at something else 18:28:16 bored of keystone? try more keystone! 18:28:20 (after they've code reviewed) 18:28:22 >.> 18:28:24 anyway 18:28:39 on to the really important topics for the meeting 18:28:50 yes, the one everyone is here for 18:28:55 #topic SPFE for Keystone Lightweight Tokens 18:29:02 #link https://review.openstack.org/#/c/130050/ 18:29:27 It's time to vote on Keystone lightweight tokens, and wether or not we allow an exception for the code to land in Kilo. 18:29:37 said code https://review.openstack.org/#/c/145317/ 18:29:38 AE got renamed to lightweight now? 18:29:44 gyee, yep 18:29:47 yes... 18:29:56 we are signing or encryption 18:29:58 gyee, yes, it is a framework for tokens, and does not require encryption. 18:29:59 encrypting* 18:30:07 so people didn't want to have a specific name 18:30:16 that's fine 18:30:17 Supermajority vote will decide the outcome, so 8 / 12 spec-cores must vote yes. 18:30:23 functionality doesn't change 18:30:35 even if you're not a spec-core please feel free to vote. 18:30:36 i think everyone is familiar with the spec - at least on a high level 18:30:38 no filibustering. 18:30:40 does keyczar scale? 18:30:45 yes, thanks morganfainberg 18:30:57 lbragstad: if we go with cryptography.fernet instead of python-keyczar, there's only a recipe for encryption afaik 18:30:57 bknudson, no, not for this item, maybe next time 18:31:00 gyee: dolphm has a commit based on mine that doesn't rely on keyczar 18:31:00 I vote for allowing an exception. 18:31:08 your votes will not be ignored, but if no one but cores votes it's a 8/12 spec core. 18:31:13 stevemar, please use #vote 18:31:14 so we'd have to implement our own signing if we go that way 18:31:15 topol, wait for the actual vote to start! 18:31:17 #startvote Allow Keystone lightweight tokens a SPFE? Yes or No. 18:31:18 Begin voting on: Allow Keystone lightweight tokens a SPFE? Valid vote options are Yes, or, No, . 18:31:19 Vote using '#vote OPTION'. Only your last vote counts. 18:31:20 so that means we'd have to roll our own signing 18:31:29 #vote Yes 18:31:29 #vote Yes 18:31:33 lbragstad, I wonder if it can scale horizontally or across regions 18:31:33 #vote yes 18:31:33 #vote Yes 18:31:35 are teh marked experimet nal? 18:31:36 #vote Yes 18:31:38 #vote yes 18:31:39 #vote yes 18:31:40 #vote Yes 18:31:41 someone please vote "or" 18:31:43 with a shared HMAC secet 18:31:49 #vote or 18:31:50 gyee: that depends on how you use it 18:31:51 #bote yes 18:31:56 #vote Yes 18:32:03 #vote or 18:32:04 yes 18:32:05 #vote yes 18:32:06 henrynash, that can be a stipulation, i'm ok with that. 18:32:11 #vote yes 18:32:14 #vote yes 18:32:14 anteaya, ++ *hi5* 18:32:15 #vote Yes 18:32:19 #vote yes 18:32:20 ha ha ha 18:32:25 #vote Yes 18:32:36 gyee: if you're feeling ambitious you could write an interface to something that stores your keys and replicates them 18:32:42 someone can vote . 18:32:46 #vote . 18:32:47 breton: . is not a valid option. Valid options are Yes, or, No, . 18:32:50 gyee: to sql or whatever. 18:32:53 (provided this fucntionality is marked as experimenatl): #vite yes 18:32:59 #vote yes 18:33:03 (provided this fucntionality is marked as experimenatl): #vote yes 18:33:06 breton, denied on the '.' vote 18:33:08 lbragstad, I was think barbican or some other KMS 18:33:11 henrynash, nice touch 18:33:15 henrynash, (you need to start the line with #vote) 18:33:26 it should be started as experimental 18:33:29 stevemar, what is this vote for? 18:33:32 #vote yes 18:33:35 sorry I missed it 18:33:36 gyee: I checked with the barbican folks and they don't have something in place yet, but they said that we should go talk to them once we have a solid use case, 18:33:43 lbragstad: like, secrets as a service? 18:33:48 dolphm: right 18:33:49 atiwari, allowinfg the exception for the AE token spec (renamed KLWT) 18:33:51 atiwari, allowing keystone light weight tokens an exception to land in Kilo 18:34:01 there's something a bit recursive about relying on barbican from keystone 18:34:02 atiwari, not the approval, just the allowed exception beyond the freeze 18:34:03 atiwari, SPFE for the AE tokens 18:34:10 lbragstad: import barbican as keystone_secrets 18:34:12 done 18:34:12 meaning i remove my -2. 18:34:32 and lbragstad works to quickly solve all outstanding issues with the spec. 18:34:41 and then code 18:34:51 might I also suggest that we expedite approving the spec, with a caveat that we will allow corrections of a minor sort afterwards... 18:35:05 ayoung, the goal is the spec should be approved within a couple days max 18:35:05 atiwari, vote with #vote Yes or #vote No 18:35:10 ayoung, morganfainberg IMO it is not ready for kilo 18:35:11 I don't want to spend time fixing little things with the spec 18:35:15 I'd rather work on the code 18:35:19 #vote NO 18:35:31 atiwari the whole concept or just some implementation details 18:35:35 lbragstad, ++, its conceptually sound 18:35:42 i think that's everyone 18:35:49 #endvote 18:35:50 Voted on "Allow Keystone lightweight tokens a SPFE?" Results are 18:35:52 Yes (15): gyee, lbragstad, ayoung, lhcheng, bknudson, topol, marekd, dstanek, dolphm, jamielennox, henrynash, amakarov, samueldmq, breton, stevemar 18:35:53 or (2): anteaya, morganfainberg 18:35:54 No (1): atiwari 18:35:56 atiwari, this is a vote on concept / general direction. 18:36:11 ok so that shows a clear majority that the exception should be granted 18:36:14 #agreed Keystone lightweight tokens will be granted an SPFE 18:36:24 it is leaning toward HMAC signature 18:36:26 lbragstad, i'll remove my -2, please work to address the issues in the spec. 18:36:27 correct 18:36:33 atiwari, it is focused around that. 18:36:34 morganfainberg: will do 18:36:39 atiwari, I think we can build toward your concept for HMAC tokens based on this spec. We can discuss later. 18:36:40 atiwari, but not exclusively 18:36:44 and IMO it is proposing the weak signature 18:36:50 atiwari: you can still HMAC sign 18:37:06 lbragstad, you *will* HMAC sign in it's current form ;) 18:37:21 yeah, we discussed that 18:37:23 anyway, so please do not -1 for nit-picky stuff 18:37:26 on that spec 18:37:32 please -1 for real concerns 18:37:42 and work with lbragstad to address them, the -2 will be lifted at the end of the meeting 18:37:49 lets do double-hmac for double-protection 18:37:55 morganfainberg, can we get more reviews on HMAC stuff? 18:38:03 atiwari, so one thing this will give us, beyond the ephemeral tokens, is that we will start deploying a very succint token format. That alone is necessary for the HMAC proposal 18:38:29 atiwari, your spec or lbragstad's. your spec is proposed to backlog meaning earliest liberty, lbragstad's is currently prioritised for kilo. 18:39:08 atiwari, i think we can discuss how to make it work on both sides as we progress towards the next cycle. lbragstad's is a starting place and i expect to see enhancements next cycle to it / things built on top of it 18:39:10 once we have this one deployed, we could then make use of the internal format for distributed token validation, ie. Your HMAC spec. We had discussed Id-only-tokens in the past, with a fetch-and-cache strategy for all the expanded data 18:39:14 lbragstad and dolphm have a PoC (probably past PoC at time point) so that helps too 18:39:36 so I see this as complementary, and even required, for the HMAC approach you wrote up. 18:40:03 ayoung,++ it compliments the HMAC spec, at worst is is the building blocks to get us there. 18:41:04 ok, ok 18:41:16 and now another SPFE... 18:41:21 #topic SPFE for Recursive Delete / Disable 18:41:32 #link https://review.openstack.org/#/c/148730/ 18:41:43 raildo, ^ 18:41:50 We are proposing this spec, In there we detail how will work recursive deletion and disabling for projects (and domains), these changes would ease a lot the way operators handle deployments using projects/domains hierarchies, the implementation changes are not big and we believe it could easily land in Kilo if the spec was approved. 18:41:53 i'll admit i didn't know this was up 18:42:05 this one depends on another spec 18:42:19 bknudson, yes, it seems to depend on the reseller one 18:42:37 raildo, does it depends on reseller? 18:42:37 raildo, does this one depend on the reseller code changes? 18:42:41 stevemar: yes 18:43:06 if we grant it a SPFE, it just means that it *can* go into this release, not that it *must* right? 18:43:07 stevemar: no, this spec just depend the the reseller spec 18:43:14 ayoung, correct 18:43:18 but not the code 18:43:21 I think this one is safe 18:43:34 it will fall into place fairly easilky once reseller is set 18:43:34 ayoung, right 18:43:39 ayoung, it could be moved to liberty just like any other approved spec (or it may not get approved because it has issues) 18:43:43 easily 18:44:06 and we have significant portions of the code implemented, right raildo ? 18:44:43 ayoung: yes, we are finishing the migration implementation and using the project API to create a is_domain project 18:45:01 any reasons to deny the extension? 18:45:04 I intend to send the patches tomorrow and update the other patch 18:45:13 #startvote Allow recursive deletion and disabling for projects? Yes No 18:45:14 Begin voting on: Allow recursive deletion and disabling for projects? Valid vote options are Yes, No. 18:45:15 Vote using '#vote OPTION'. Only your last vote counts. 18:45:41 #vote yes 18:45:46 #vote YES 18:45:54 #vote Yes 18:45:55 #vote yes 18:45:56 #vote yes 18:46:07 #vote or 18:46:07 ayoung: or is not a valid option. Valid options are Yes, No. 18:46:11 damn 18:46:13 #vote yes 18:46:14 #vote yes 18:46:18 #vote yes 18:46:19 ayoung, i learned this time! 18:46:22 ayoung, stevemar learned 18:46:24 #vote yes 18:46:26 #vote Yes 18:46:31 #vote yes 18:46:33 * ayoung should have tried last vot 18:46:34 #vote , 18:46:35 amakarov: , is not a valid option. Valid options are Yes, No. 18:46:36 e 18:46:38 #vote yes 18:46:43 amakarov, hehe 18:46:48 #vote yes 18:46:50 okay, this one looks like a done deal 18:46:54 #endvote 18:46:54 Voted on "Allow recursive deletion and disabling for projects?" Results are 18:46:55 Yes (13): gyee, dstanek, ayoung, morganfainberg, topol, marekd, samueldmq, jamielennox, amakarov, henrynash, raildo, breton, stevemar 18:47:06 spit and shake on it 18:47:10 #agreed recursive delete will be granted an SPFE 18:47:18 morganfainberg, please lift your -2 18:47:28 alright cool stuff coming up! 18:47:28 #topic Vancouver Summit Session Breakdown 18:47:33 #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html 18:47:38 There will once again be changes to the design summit, i think for the better. 18:47:42 :D 18:47:48 fishbowl sessions, which are similar to the usual design session, these have projectors and plenty of room 100-300 people 18:47:56 working sessions, which are more board room style, meant to replace project pods, (20-40ppl sized) for hacking on stuff 18:48:04 morganfainberg is aiming for 4 fishbowl and ~8 working sessions, leaving us time to wander over to talk to other projects 18:48:17 i really like the idea of the working sessions, seems like a mini-meetup 18:48:22 Hotels have been posted...reserve your rooms 18:48:30 we could easily go as high as 5 fishbowl, and 10 working 18:48:34 but i'd like to keep the numbers lower 18:48:42 mini-me--etup 18:48:50 unless people feel like there is a real reason to ask for more spaces 18:49:10 i felt like paris summit we were a little light on topics so some stuff filled in (it worked) but this is a bit more structure 18:49:25 i'm also asking for a full-day meetup on friday (vs. the ½ day we got in paris) 18:49:33 in lieu of the more working sessions/fishbowls 18:49:36 we usually have a few major topics that people want to talk about, thats what fishbowl is for 18:49:49 ++ for full day 18:49:55 Schedule your flights out saturday morning so we actually get the whole day, please 18:50:03 so if we get full day on friday, 4 fishbowl / 8 working would be good. 18:50:19 Unless you are on the West coast, or doing a red eye, but stay through the finish line 18:50:23 and we will have plenty of "bug other projects / go to other fishbowls" 18:50:25 morganfainberg, ayoung is it ok to implement a solution with "HMAC token" by kilo as an exception? 18:51:07 stevemar: what are fishbowls by summit definition? 18:51:08 atiwari, let's talk after this meeting...it depends on a few things 18:51:09 atiwari, i would be worried about any other SPFEs at this point. it's really late in the cycle 18:51:20 marekd, the same as our summit sessions we had in paris 18:51:28 morganfainberg: ok :=) 18:51:39 the short of it is that HMAC by itself won't heal the ills of PKI tokens. 18:51:40 ok so i'm going to ask for 4/8 + full friday. 18:51:54 they are going to pump more oxygen into the rooms this time right? 18:51:55 and move that to 5/10 if we can't get the full day on friday 18:52:22 gyee, that fresh Candian Air, pumped down from Bampf 18:52:24 where were hardly room to stand at Paris 18:52:44 gyee, we knew that Paris was going to be crowded. Suspect Vancouver will not have the shortcoming. 18:52:52 ok lets give time for the last topic 18:53:09 #topic Open Discussion 18:53:14 ha 18:53:16 #topic GSoC 2015 18:53:19 dims__, ^ 18:53:27 We are looking for Project ideas and mentors for Google Summer of Code - https://wiki.openstack.org/wiki/GSoC2015 18:53:27 #yay GSOC! 18:53:33 * topol I hope I don't get stuck smuggling ketchup chip back in at the border 18:53:45 Dynamic Policy has many subspecs. Would suggest starting there 18:54:01 ayoung, ++ 18:54:04 topol, you must bring back all the goodies i mentioned on twitter 18:54:09 kicking ass auth plugins in keystoneclient 18:54:11 thanks ayoung 18:54:15 also, there are parallel efforts for a GsoC project from http://adam.younglogic.com/2014/10/who-can-sign-for-what/ 18:54:21 marekd, ++ 18:54:22 dims__: i've mentored before and i'd do it again if there was a need 18:54:35 i mean, general framework for auth plugins. 18:54:36 dstanek: mind if i add your name on a wiki? 18:54:43 I am a candidate to mentor a project, I will look into those ayoung ideas and then submit a couple of ideas that fit the gsoc schedule 18:54:43 marekd, are you signing up for it? :) 18:54:52 thanks samueldmq 18:54:56 that second one assumes PKI tokens, which is less of a viable option with AE. Would probably recommend the dynamic policy one to start 18:55:07 marekd: what's missing? :) 18:55:08 stevemar: i would like to, but i am fearing i might not have time for that. Was just giving some ideas :( 18:55:20 marekd, fair enough! 18:55:27 dims__: not at all 18:55:30 marekd: we need ideas too, anything you can throw in the wiki link is appreciated 18:55:42 dims__, I'm willing to as well, but I might have an intern this summer which would probably eat up my mentoring budget 18:56:01 ayoung: ack, let's see how many people show up with security skills 18:56:13 thanks everyone! 18:56:20 dims__, thanks for reaching out 18:56:25 jamielennox: this very old idea where ou have complex auth plugin (say, SAML2 one), but would need to be able authN method between you and Identity PRovider (BasicAuth hardcoded today) 18:56:38 #topic open discussion 18:57:03 marekd: yea - we're getting there, missing some discovery on the server side yet 18:57:10 anyone else have something they want to chat about, or we can end things a bit early? 18:57:14 stevemar, I have a bp for for no-spec require status 18:57:24 jamielennox: i think there is nothing to do with the server. 18:57:30 #link https://blueprints.launchpad.net/keystone/+spec/assignment-manager-cleanup 18:57:32 samueldmq, liink? 18:57:32 you, the client must know what to use. 18:57:51 it's quite simple, to re-use list_role_assignemtns wherever possible inside the assingment manager 18:58:03 avoiding to replicate the code for inherited roles and grouping expansion 18:58:13 that leads to bugs sometimes 18:58:16 samueldmq, i don't think we need a spec for this 18:58:18 the main goal is to reuse code 18:58:27 marekd: right, you need to know what's available - anyways 18:58:33 I’ll make a quick pitch for some review of LDAP filtering (two patches, starting with https://review.openstack.org/#/c/147551/)…pretty easy, and we can get that in quickly 18:58:52 stevemar, great! that's my goal (no spec), do we need to vote? 18:58:52 henrynash, i'll be glad to review it 18:58:55 others? 18:58:56 I think I will also have the student this summer 18:58:59 henrynash, when you write those, add nkinder and richm to the reviews. They are the LDAP gurus 18:59:11 samueldmq, i think just post the code and see if you can get someone to review it 18:59:14 I'll look too, but I'd defer to them anyway 18:59:17 ayoung: ok, will do , thx 18:59:23 samueldmq, but priority will go to the ones associated with specs 18:59:45 why is priority given to bps with specs? 18:59:48 samueldmq, since this is a cleanup, we may allow it to go in post feature freeze, but i don't see why it can't wait til L 18:59:50 stevemar, ok ack, henrynash will probably review it, it's related to the work that's going on the assignment backend 19:00:00 can someone kick this off: https://review.openstack.org/#/c/150627/ - copy federation plugins over to the new repo 19:00:06 actually - marekd can do it now 19:00:17 marekd: this will make things quicker 19:00:23 stevemar, ok let's see how fast it goes (it's simple, nothing too complex) 19:00:24 jamielennox: looking 19:00:24 thnaks 19:00:38 #endmeeting