19:00:36 #startmeeting keystone-office-hours 19:00:37 Meeting started Tue Dec 19 19:00:36 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:41 The meeting name has been set to 'keystone_office_hours' 19:00:42 o/ 19:00:46 davidalles, let's keep talking here 19:00:53 ruan? 19:00:58 yep 19:01:00 OKi, so the conclusion it: BP is --2 19:01:07 davidalles, can you ask for ruan join this channel? 19:01:17 davidalles: i walked back to a -1, the fernet bits were removed. 19:01:18 and Orange must work on the 'resources ID' driver 19:01:35 yep, I did 19:01:36 i'm a strong -1 on the new API, i would be a -2 on "optional" features. 19:01:45 i recommend this being a driver. 19:02:25 davidalles, the spec can be rewrite to instead of pointing to an API change, to reference that as an new resource driver change 19:02:33 understood; thanks all of you: we found one solution so that Orange will comply to the hard IAM&ACM requirement :) 19:02:34 you could actually inherit the upstream driver and just override the project specific methods 19:02:53 you can write this driver out of tree, then you wouldn't need a new spec or any buy-in from us 19:02:57 davidalles: did k2k comply to that hard requirement? 19:03:00 and you can make it out of tree, so no need to wait for our go 19:03:18 right - you just need to make sure you read the release notes for interface changes 19:03:21 yep: then I will synchro with Ruan and we will comment the BP 19:03:25 :) 19:03:34 :) :) 19:03:40 because sometimes we do change those interfaces, which will impact your implementation 19:03:42 thanks for your comments, we will try to work on that 19:03:42 lbragstad: kmalloc out-of-tree like we don't need to worry about upstream timelines? 19:03:58 hrybacki: right 19:04:05 hrybacki: yeah, as long as the interface hasn't changed 19:04:07 hrybacki, yep 19:04:09 ruan__he: davidalles i'm still really interested in the k2k case 19:04:11 have a nice day (or night) 19:04:18 ack ack 19:04:18 i'd like to work on fixing the performance issues there 19:04:21 davidalles: please let us know where k2k didn't work. 19:04:26 esp. if it's related to performance 19:04:28 ruan__he: ^ 19:04:29 fwiw not that anyone should ever use this but i wrote https://github.com/cmurphy/keystone-json-assignment which could be used as an example, specifically setting up the entry points 19:04:37 Ruan will: he was the guy testing it 19:04:55 cool 19:04:55 ruan__he: is it possible for you to forward the information about that setup and the results? 19:04:59 cmurphy: everyone reads TC blogs :) 19:05:19 i want to fix the k2k bit if it's slow/notworking 19:05:36 right - because we've been pushing people to use it for years 19:05:52 and that is going to be critical in making federation a first-class citizen 19:06:19 lbragstad: you'll get a lot of feedback from me in terms of performance in the coming months 19:06:27 we're very close to production deployment for mixmatch 19:06:31 knikolla: ++ 19:06:58 ok i need to go eat 19:22:14 someone please look at https://review.openstack.org/#/c/523524/ :) 19:22:44 and https://review.openstack.org/#/c/522356 19:27:14 cmurphy: +3 on both 19:27:28 thanks kmalloc 19:27:43 i give you permission to go enjoy your vacation :P 19:28:40 woo! 19:28:49 patches are moving! 19:29:36 cmurphy: ruan__he jdennis hrybacki running this by the mailing list http://lists.openstack.org/pipermail/openstack-dev/2017-December/125744.html 19:31:21 https://review.openstack.org/#/c/528960/ merged - so we should be good to start rechecking? 19:31:45 ya i think so 19:33:26 cool - i have like 20 patches failing :) 19:34:34 lbragstad: might be good to send that email to the -ops list? 19:36:14 yup - i did 19:36:22 ah cool 19:36:46 http://lists.openstack.org/pipermail/openstack-operators/2017-December/014697.html