16:00:57 <cmurphy> #startmeeting keystone
16:00:58 <openstack> Meeting started Tue May 21 16:00:57 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:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:01 <openstack> The meeting name has been set to 'keystone'
16:01:11 <cmurphy> anyone around for the keystone meeting?
16:01:30 <gagehugo> o/
16:02:05 <vishakha> o/
16:02:16 * bnemec lurks
16:02:38 <knikolla> o/
16:03:06 <cmurphy> yay there are people here
16:03:27 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:03:41 <cmurphy> #topic action item review
16:03:48 <cmurphy> we had some action items from last week
16:04:03 <cmurphy> #link http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-05-14-16.00.html last week's meeting minutes
16:04:14 <cmurphy> 1. vishakha to take on fast8 tooling
16:04:25 <cmurphy> i saw you started this :)
16:04:29 <cmurphy> you had a question about it?
16:04:57 <vishakha> yes I wanted to ask. I should merge this with every module in keystone?
16:05:38 <cmurphy> i think it only really matters for keystone because the other projects have such a small amount of code that regular pep8 is already fast
16:05:44 <cmurphy> anyone else have thoughts on that?
16:06:03 <bnemec> cmurphy: +1
16:06:15 <gagehugo> I don't see why not, but yeah, keystone is currently the slowest one and should be first priority
16:06:33 <gagehugo> the other projects do run it pretty quickly
16:07:33 <knikolla> ++
16:07:37 <cmurphy> yeah i wouldn't -1 adding it to other projects but i don't really think it's needed
16:08:40 <vishakha> ok. So I think other projects dont have need for fast8. Thanks
16:08:46 <cmurphy> thanks vishakha
16:08:56 <cmurphy> 2. lbragstad propose definition of low-hanging-fruit tag in contributor documentation
16:09:17 <cmurphy> lbragstad did this but he's going to be out for a bit so someone else may have to finish it up
16:09:31 <cmurphy> i can do that unless someone else wants to volunteer
16:10:04 <cmurphy> #link https://review.opendev.org/659141
16:10:46 <cmurphy> it's not urgent so i'll let it sit for a bit
16:10:54 <vishakha> sure
16:11:20 <cmurphy> #topic Admin endpoint in keystonemiddleware
16:11:30 <cmurphy> frickler has been working on this
16:11:39 <cmurphy> #link https://review.opendev.org/651790
16:12:30 <cmurphy> the idea is that keystonemiddleware is currently hardcoded to use keystone's admin endpoint
16:12:42 <cmurphy> which should be entirely unnecessary now
16:13:05 <cmurphy> fricker's change makes it configurable but still defaulting to admin
16:13:57 <cmurphy> ideally we should have a deprecation period/upgrade path so that it can default to public
16:14:48 <cmurphy> not sure if frickler can be here but he wanted us to discuss the path forward
16:16:12 <cmurphy> anyone have thoughts on it?
16:16:40 <knikolla> new option that preserves the current behavior as default seems sensible
16:17:01 <knikolla> and then deprecation
16:18:56 <cmurphy> should the current default of the new option immediately be deprecated? oslo.config doesn't have a mechanism for that so we'd have to add an explicit log warning if the option is unset
16:19:30 <bnemec> Maybe deprecate the entire option?
16:19:41 <bnemec> It won't do anything once the admin endpoint goes away, right?
16:20:05 <cmurphy> people could still want to switch it between public or internal
16:20:11 * gagehugo has to run to another meeting, will be back later
16:20:19 <knikolla> ++ cmurphy
16:20:26 <bnemec> Oh, but that doesn't help notify people if they're still using the old behavior by default.
16:20:42 <cmurphy> bnemec: also that
16:21:03 <bnemec> So yeah, maybe an explicit log message is better.
16:21:57 <cmurphy> alright i'll try to provide some guidance on that on the patch
16:23:26 <cmurphy> #topic Milestone 1 check-in and retrospective
16:23:45 <cmurphy> at the PTG we talked about doing more regular check-ins to try to keep momentum going
16:23:57 <cmurphy> M1 is in two weeks so it's already time for one
16:24:22 <knikolla> oh nice
16:24:23 <cmurphy> i think there's not enough people at this meeting to really schedule it so i'll send out emails
16:24:31 <knikolla> ++
16:26:27 <cmurphy> i'm hoping to do maybe a 1.5-2 hour video meeting
16:27:09 <cmurphy> anyways, will follow up in email
16:27:25 <cmurphy> #topic Office hours future
16:27:55 <cmurphy> last week was kind of a bust because people scattered, this week i also expect low attendance
16:28:23 <cmurphy> wondering if people still feel like office hours is worth doing? or what should we do to have them be productive?
16:29:34 <vishakha> Attending office hours is little difficult for me. But I can give the updates the very next day
16:31:18 <cmurphy> vishakha: that's fair, we could consider rescheduling it but that's always going to be tricky
16:32:31 <vishakha> Yes I can understand. I dont recommend scheduling
16:34:39 <vishakha> I will try to attend :)
16:35:51 <cmurphy> i think we should skip today since there's not many people here and we can revisit next week
16:36:19 <knikolla> yeah
16:36:44 <cmurphy> alright
16:36:49 <cmurphy> last topic
16:37:15 <cmurphy> #topic liaison review
16:37:32 <cmurphy> i just went and reached out to people privately and filled out https://etherpad.openstack.org/p/keystone-liaison-review-2019
16:37:45 <cmurphy> and will update the wiki accordingly
16:37:58 <cmurphy> so not much to discuss i think, more of an fyi
16:39:19 <cmurphy> #topic open discussion
16:39:27 <knikolla> awesome, thanks cmurphy
16:39:27 <cmurphy> anything else to bring up?
16:39:35 <cmurphy> :)
16:42:13 <cmurphy> okay thanks for attending everyone
16:42:17 <cmurphy> #endmeeting