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