16:00:03 #startmeeting keystone 16:00:04 Meeting started Tue May 1 16:00:03 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:06 ping ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy, sonuk 16:00:08 The meeting name has been set to 'keystone' 16:00:15 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:00:17 agenda ^ 16:00:18 o/ 16:00:34 o/ 16:01:12 o/ 16:01:48 since we have a pretty light agenda - we'll give people a few minute to join 16:01:51 FYI: Moving forward, Tuesday's I will be dedicating my working day to Keystone. 16:01:57 Tuesdays* 16:02:03 knikolla: awesome - i'm happy to hear that 16:02:28 knikolla: we should sync up on the community goal stuff later if you have time 16:03:13 Sounds good. Except lunch time right after the meeting I'll be here. 16:03:50 o/ 16:05:39 #topic exposing limit model information 16:05:47 #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1765193 16:06:06 so - i have a couple patches up for the limit stuff, and curious about feedback 16:06:11 o/ 16:06:26 i know a few folks have taken a look already, which i appreciate 16:06:48 curious what people think about the overall approach 16:06:54 o/ 16:06:59 and the API in general 16:07:56 other than that, johnthetubaguy and i just wrapped up a discussion on limits 16:08:54 wxy|: i doubt you've had a chance process it all yet 16:08:57 do we envision other configuration attributes besides "model"? 16:09:35 so - model is a dictionary that contains the configured enforcement model (so, flat by default) 16:10:08 i don't really envision much more on our end besides the model. 16:10:29 is/will model be a global setting or per-domain? 16:10:36 if we ever implement a 'strict' model for example, that would be relayed in the "model" bit 16:10:46 knikolla: no, it's a global def. 16:10:47 global initially 16:11:12 too hard to reliably make it per-domain, too many fiddly bits and issues on that front (changing between models will basically invalidate the limit data) 16:11:20 this should not be something toggled per-domain. 16:11:28 i'm pretty sure my brain would fall out of my ears thinking about this on a per domain basis 16:12:10 the quota model is something that the system administrator, or operator, should be setting 16:12:23 because it's how they want resources to adhere in their deployment 16:12:44 or how strict they want to be with those resources and their enforcement 16:13:19 then they can use limits to make resource allocations for their customers 16:13:31 agree, makes sense 16:14:24 i think the two big things that came out of the discussion with johnthetubaguy is: 16:14:37 1.) we need to restrict the current proposal to only support two hierarchies 16:15:01 2.) we need to be clear about how usage is calculated and what that interaction looks like 16:15:53 i was going to try and write all this up as a subsequent patch to what wxy| has proposed, since he's already got 90% of this written up 16:16:01 just clarifying those two points 16:17:40 does anyone have questions on the unified limit stuff? 16:17:42 lbragstad: thanks. Really helpful discussion with johnthetubaguy. I'll read the whole log later. 16:18:13 wxy|: ++ it's a lot to parse, but i think it's helpful (at least for me anyway) 16:18:19 hopefully others find it useful 16:19:48 lot of moving parts, but that's about all i had for limit stuff 16:19:53 #topic open discussion 16:20:57 floor is open if anyone has anything they'd like to bring up 16:21:19 do we have an etherpad where we note down keystoners that will be at the summit? 16:21:29 and arrival departure dates 16:21:41 knikolla: yep 16:21:45 #link https://etherpad.openstack.org/p/YVR-keystone-forum-sessions 16:22:35 lbragstad: thanks 16:22:40 yep 16:24:50 anything else? 16:24:52 about enable sqlite FK for unit test, https://bugs.launchpad.net/keystone/+bug/1744195 My plan is to enable it step by step by files. Then remove the "enable_sqlite_foreign_key" to enable FK by default at last. An example is https://review.openstack.org/#/c/558029/ 16:24:54 Launchpad bug 1744195 in OpenStack Identity (keystone) "unit tests don't enable Foreign Key for Sqlite" [Medium,In progress] - Assigned to wangxiyuan (wangxiyuan) 16:25:02 any thought? 16:25:27 i like the approach 16:26:01 as opposed to doing it all in a single patch 16:26:58 I'll try. It may be a large patch since it will effect lots of tests I guess 16:27:20 http://logs.openstack.org/85/558185/2/check/openstack-tox-py27/87b4ea9/testr_results.html.gz 16:27:36 The tests which will fail once the FK is enabled. 16:28:13 the implementation has a toggle for TestCase that enables or disables it, right? 16:28:34 yeah 16:29:09 it's "enable_sqlite_foreign_key", which is False by default now. 16:29:30 so then each patch enables it for a specific test class then fixes the tests? 16:30:02 may for a file, or some files in each patch 16:30:11 sure 16:31:11 i think that seems reasonable 16:33:32 i know everyone is pretty busy, so if there is nothing else, we can call it early and get some time back before office hours 16:35:15 alright - thanks for coming everyone 16:35:19 make sure to update the summit attendance etherpad 16:35:20 ;) 16:35:41 ++ 16:35:49 #endmeeting