16:00:33 #startmeeting keystone 16:00:34 Meeting started Tue Aug 13 16:00:33 2019 UTC and is due to finish in 60 minutes. The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:37 The meeting name has been set to 'keystone' 16:00:44 #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda 16:00:48 o/ 16:00:49 o/ 16:01:15 o/ 16:01:43 o/ 16:01:59 o/ 16:02:58 hi everyone 16:03:02 #topic Shanghai Forum/PTG 16:03:28 I went ahead and responded to the foundation survey saying we don't need ptg space 16:03:46 basically no one showing up? 16:03:49 =/ 16:03:51 basically 16:03:54 :( 16:03:57 i am still moreorless planning on being there barring the usual uncertainty so can be around for ad hoc discussions 16:04:06 So no onboarding then? 16:04:32 no i was still planning on doing the onboarding 16:04:38 i guess i should clarify with them 16:04:45 I think those moved to the PTG this time. 16:05:04 I guess I don't know if they were going to be scheduled separately though. 16:05:05 maybe i can just request an hour for the onboarding 16:05:16 they didn't really mention the onboarding part in the survey email 16:06:16 regardless, i will still propose a session or two for the forum 16:06:22 and would like help coming up with topics 16:06:36 #link https://etherpad.openstack.org/p/keystone-shanghai-ptg ptg/forum etherpad 16:07:44 will also start planning the pre- and post- virtual ptgs soon 16:08:40 any questions or concerns? 16:08:46 or ideas? :) 16:10:22 #topic Feature proposal freeze this week 16:10:34 #link https://releases.openstack.org/train/schedule.html cycle schedule 16:10:58 we're still missing a few implementation proposals that are due this week 16:11:08 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/expiring-group-memberships.html refreshable group membership 16:11:14 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/resource-options-for-all.html resource options for all 16:11:22 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/support-federated-attr.html federated attributes 16:12:18 expiring group membership is not intend for LDAP groups right? 16:12:33 gyee: correct, just federated users 16:12:38 k 16:12:51 unfortunately knikolla isn't here to discuss two of those 16:13:01 kmalloc: any update on resource options? 16:14:53 it's slow going 16:15:00 because i've had a lot of other things on my plate. 16:15:16 i am carving some time out to land the migrations here soon 16:15:28 and the rest of the code shuffle is getting easier. 16:15:59 i think the approach i'm going to do is implement the new table and setup the scaffolding and *then* migrate user options 16:16:11 so we have the support for everything independant of the user options 16:16:20 which ahs been the hard(est) part to put together 16:16:28 that sounds reasonable 16:17:15 would a 1-week extension give enough breathing room to help you with that? 16:17:23 possibly. 16:21:02 if we went forward with resource options just for roles as in https://review.opendev.org/666739 would that get seriously in the way of the migration work? 16:24:50 kmalloc: ^ 16:27:30 okay, well wrt expiring group membership and federated attributes, i will sync up with knikolla but my initial proposal is 1) drop federated attributes till next cycle 2) propose an extension for refreshable group membership 16:27:38 if needed 16:27:43 yeah it probably would 16:28:01 kmalloc: yeah i figured :/ 16:28:17 i can take on the resource options for roles if i get the other support done it should really be minimal code. 16:28:30 then adding immutable should be a very small patch. 16:28:44 ;i'll do waht i can to get something up this week. 16:29:12 alright, thanks kmalloc 16:30:48 I will sync up with people by the end of the week and send an email if we need to propose to drop or extend things 16:31:27 #topic Noisy policy deprecation warnings 16:31:52 so we landed the fix to get these out of the unit tests which is nice 16:31:57 #link https://review.opendev.org/673933 16:32:06 it didn't really help with the ci like i had hoped 16:32:29 :-( 16:32:52 i suspect we need to revisit https://review.opendev.org/663065 and actually get the efficiency of our protection tests under control 16:33:43 but with regard to the operator-facing issues I proposed kind of a cop-out https://review.opendev.org/674940 16:33:59 wondering if there are any concerns about that approach? 16:35:27 we tend to cargocult that warning message to every other policy so want to be sure we agree on it 16:36:24 cmurphy: maybe we make the warning the generic one 16:36:32 and debug run through each rule? 16:36:46 and make sure the policy checker CLI emits verbose warnings 16:37:09 doesn't address CI things but addresses operator impact 16:37:09 how did it impact ci? we can't handle large log files? 16:37:31 hard to read logs, stupid large logs, and slow because emitting tons of lines 16:37:35 kmalloc: not sure what you mean by debug run 16:37:42 gyee: the logs were around 150MB 16:37:55 the ci was sometimes choking on uploading them to the log server 16:38:08 maybe we can setup a filter to optionally filter them out? 16:38:09 cmurphy: emit the warning for each policy when in debug 16:38:14 and trying to load them in a browser caused the browser to crash 16:38:30 gyee: we tried that, there are so many it's even more inefficinet 16:38:32 cmurphy: emit only a generic "hey, we noticed some things, use X command to see more details" when in not-debug mode 16:38:59 kmalloc: would we need to add a new thing to oslo.policy? 16:39:00 cmurphy: and make sure the policy checker tool can emit full output of each rule 16:39:14 cmurphy: we would need to adjust olso.policy 16:39:41 cmurphy: for logging purposes, and for CI we would need to keep the "don't emit deprecation warnings" flag. 16:40:14 this feels like a debug level message vs a warning message to follow up on 16:40:18 okay, i can play around with that 16:40:26 and the oslo policy checker tool can be very verbose., 16:40:39 and likely should be 16:40:39 The only thing is that debugging is probably when the log spam is most annoying. 16:40:58 Maybe we should expose a verbose_deprecations option or something to make it explicit. 16:41:08 or we crater this to trace level logging 16:41:15 but hard -2 on "verbose_deprecations" 16:41:24 I thought we were trying to kill off trace? 16:41:30 are we? 16:41:42 yeah i don't think we use trace any more 16:41:46 or just make it a policy checker tool 16:41:55 but really -2 on verbose_deprecations. 16:42:32 warn that some policys are wonky (1 line) and make the checker tool emit verbose information 16:42:47 and indicate the checker tool shgould be used to know what policys are in this state. 16:42:53 policy-rules* 16:42:55 Yeah, I like that. 16:42:55 I am kinda surprised that a log filter didn't work. I thought that's what its for. 16:43:04 gyee: too many lines to parse 16:43:19 gyee: it works, it makes CI runs 2-3x longer 16:43:49 oh wow 16:43:54 gyee: and that is a bigger issue than filtering is. 16:44:17 so one WARN that indicates something is wrong, a one-line DEBUG for each policy, and a detailed message in the policy checker? 16:44:28 one warn that says use the policy checker tool 16:44:36 and policy checker tool more verbose 16:44:41 no debug for each policy 16:44:56 +1 16:45:02 okay 16:45:08 we can escalate that one warn up to error/critical as we move closer to finalizing the move 16:45:13 sounds good to me 16:46:13 #topic review requests 16:46:19 any other reviews to highlight? 16:47:41 guessing this one is a hard no? https://review.opendev.org/675303 16:48:01 System scope for endpoint group policies https://review.opendev.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1818734 16:48:17 thanks for working on those vishakha 16:49:16 675303 is interesting 16:49:32 that would mess up the API contract 16:50:58 oh hey, they will be conveyed via "extras", kmalloc's favorite :-) 16:51:28 don't do that 16:51:29 please 16:53:10 -2, request for more information 16:53:31 i want to know the use case and what is being solved rather than a "hey this is a thing" 16:53:38 ++ 16:54:00 yeah, I agree 16:54:16 i'm also hoping someone not-me can reproduce the issues in https://review.opendev.org/674782 and https://review.opendev.org/674139 and help verify the fixes 16:54:59 I'll take a look at 674782 16:55:09 thanks gyee 16:55:39 relevant ml post on that one http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008210.html 16:55:53 #topic open floor 16:56:00 5 minutes for any other topics? 16:56:13 no office hours after this 16:57:34 674139 is a good one. I've seen that error before. But didn't have the time to investigate how bad of leak that was. 16:58:26 it seems to make sense but i first couldn't verify the fix and now for some reason can't reproduce the bug 16:58:52 so just wanted someone to sanity check it 16:59:24 yeah, a unit test would be nice 16:59:34 ++ 16:59:36 time's about up, thanks everyone 16:59:39 #endmeeting