16:00:14 <cmurphy> #startmeeting keystone
16:00:16 <openstack> Meeting started Tue Jul 16 16:00:14 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 <openstack> The meeting name has been set to 'keystone'
16:00:25 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:00:28 <cmurphy> o/
16:00:41 <knikolla> o/
16:01:08 <vishakha> o/
16:01:09 <gagehugo> o/
16:02:36 <kmalloc> o/
16:04:05 <cmurphy> let's get started
16:04:20 <cmurphy> #topic midcycle agenda draft posted
16:04:37 <cmurphy> #link https://etherpad.openstack.org/p/keystone-train-midcycle-topics
16:04:54 <cmurphy> the virtual midcycle will be happening next week
16:05:07 <cmurphy> I started working out an agenda for discussion and hacking topics
16:05:23 <cmurphy> posted in the above etherpad
16:05:39 <cmurphy> feedback welcome - any thoughts on it?
16:06:56 * gagehugo takes a look
16:07:55 <cmurphy> it will be flexible too so if we decide at the time we need to rework the discussion we can do that
16:08:20 <bnemec> The Oslo meeting is during the caching tech review.
16:08:35 <bnemec> But maybe we just cancel the meeting next week and have interested people join the midcycle call.
16:08:58 <cmurphy> bnemec: it's easy enough to switch it around
16:09:53 <cmurphy> although tuesday was iffy for kmalloc
16:10:04 <kmalloc> i'll most likely be around
16:10:07 <bnemec> Yeah, although it would be a bit weird to not have the hackathon for caching follow the tech review, which limits the flexibility there somewhat.
16:10:32 <kmalloc> mostly the caching tech review is to get more people on board with how caching works, concerns, and oslo.cache itself
16:10:41 <kmalloc> we have a very small number of folks who understand it in depth
16:10:59 <bnemec> I also have a conflict on Tuesday, although I may be able to skip that meeting.
16:12:00 <cmurphy> so would it
16:12:03 <cmurphy> er
16:12:19 <cmurphy> so would it work to swap the hackathon days or still a conflict?
16:13:25 <cmurphy> oh you said conflict same time both days
16:13:28 <bnemec> It may still be an issue for me.
16:13:43 <bnemec> Monday is actually more flexible because I can cancel that meeting if I have to.
16:13:50 <knikolla> just realize i have a conflict on tuesday too. but it's only for 1 hour out of the 3 of the meeting.
16:14:34 <cmurphy> bnemec: how about we move up the caching topics by an hour on monday
16:15:21 <cmurphy> then you can be there for the review and do the hackathon only if you feel like canceling the other meeting
16:15:47 <bnemec> Sure, works for me.
16:16:13 <kmalloc> ++
16:16:22 <cmurphy> cool
16:16:24 <cmurphy> done
16:16:51 <cmurphy> knikolla: what time is your conflict on tuesday?
16:16:59 <bnemec> Although that means I have to actually be awake right away on Monday. ;-)
16:17:31 <cmurphy> bnemec: kmalloc and i cry for you
16:17:32 <knikolla> right in the middle of the midcycle. 11am EST to 12.00 EST
16:17:59 <bnemec> cmurphy: I'm sure. :-P
16:18:00 <knikolla> and i might miss the first few minutes on monday if my dental appointment goes long.
16:18:14 <cmurphy> knikolla: okay so you can make it to the retrospective at least
16:18:34 <knikolla> sure
16:18:56 <cmurphy> knikolla: gagehugo can you add your names to the attendees list too
16:19:29 <gagehugo> will do
16:20:14 <gagehugo> I shouldn't have any conflicts afaik
16:20:25 <cmurphy> yay
16:20:35 <cmurphy> any other questions concerns thoughts about the midcycle?
16:22:20 <cmurphy> #topic PTG planning
16:22:32 <cmurphy> planning all the events i guess
16:22:57 <cmurphy> i sent a note to the ml, the foundation wants to know if we want space at the shanghai ptg
16:23:18 <cmurphy> i almost just replied and said yes since we always use it, but i know this one is a little different
16:23:58 <cmurphy> i'm looking for a very rough count of people who are thinking they probably intend to go to shanghai in november
16:24:08 <cmurphy> i know nobody knows for sure at this point
16:24:30 <cmurphy> #link https://etherpad.openstack.org/p/keystone-shanghai-ptg shanghai ptg planning
16:25:59 <cmurphy> please add your names there if you think you're planning to be there
16:26:25 <cmurphy> anyone besides kmalloc already know for sure that they *won't* be there?
16:26:33 <gagehugo> I won't be there
16:27:12 <knikolla> i'm very unlikely to go, given the VISA pains I have to go through to leave the US and get back.
16:27:37 <cmurphy> :(
16:28:12 <knikolla> i basically need to fly to albania from the us, to get a us visa, come back to the us, get a chinese visa, then travel to china.
16:29:05 <kmalloc> knikolla: that sounds... awful
16:29:35 <knikolla> kmalloc: ikr, having to get out of the us to be able to come back... is mind boggling
16:31:10 <cmurphy> that seems extremely inconvenient
16:32:33 <cmurphy> i know sessions will be selected by the end of the month so presentation schedule will probably be out early august, so please try to let me know by around then whether you think you'll make it
16:33:00 <cmurphy> if most of us can't make it then we should probably do a virtual ptg just before the event
16:33:31 <vishakha> cmurphy: sure
16:34:32 <gagehugo> that might be a good idea
16:35:41 <cmurphy> #topic Open reviews and ongoing work
16:36:12 <cmurphy> there are a few reviews to touch base on
16:36:27 <cmurphy> #link https://review.opendev.org/659434 Remove [signing] config
16:36:46 <vishakha> I was waiting for others opinion over it
16:36:48 <cmurphy> we talked about this one last week, i think we're converging on changing the error code to a 410
16:37:10 <cmurphy> anyone have other thoughts on it?
16:39:14 <cmurphy> #link https://review.opendev.org/655166 Allows to use application credentials through group membership
16:40:02 <cmurphy> this one is interesting, we've been back and forth on it for a while
16:40:12 <cmurphy> i restored the original patchset from jose and explained in a comment why i think it's actually the right way to go
16:40:42 <cmurphy> interested in hearing from knikolla about it and whether kmalloc had other thoughts since we talked about it last week
16:41:09 <knikolla> so basically app creds didn't check if the user had permissions from the group and failed?
16:42:06 <cmurphy> right, when the app cred gets created it looks at the effective role assignments but the token was only looking at regular role assignments
16:42:21 <cmurphy> so the app cred could be created but not used
16:43:30 <knikolla> will it distinguish between groups from mapping and groups concretely assigned to?
16:44:02 <cmurphy> yes because only concrete groups can be looked up from the identity driver
16:44:41 <cmurphy> mapped groups go through a completely different code path in a completely different subsystem
16:44:57 <knikolla> i'm ok with this and it's actually a critical fix
16:45:52 <cmurphy> we still need the expiring group membership to make this work for federated users but that's really a separate issue
16:46:02 <knikolla> yup, but the latter depends on this
16:46:09 <cmurphy> yep
16:46:35 <knikolla> ++ will review
16:46:41 <cmurphy> awesome
16:46:54 <cmurphy> #link https://review.opendev.org/633369 Add validation of app cred access rules
16:47:32 <cmurphy> this one should be more readable now that kmalloc helped me with the regex implementation
16:47:42 <cmurphy> i'd like to get that in and do a ksm release asap
16:48:41 <cmurphy> the access rules work in keystone depends on that ksm patch
16:50:09 <cmurphy> #link https://review.opendev.org/669790 update documentation for X.509 tokenless auth
16:50:38 <cmurphy> gyee has been doing amazing work fixing that document
16:51:41 <cmurphy> definitely worth reviewing just to learn more about it :)
16:53:01 <knikolla> nice!
16:54:22 <cmurphy> #link https://review.opendev.org/669959 discourage external auth
16:54:50 <cmurphy> related change from gyee, this took me by surprise a little so i think it's worth discussing
16:55:09 <cmurphy> external auth is one of the default allowed auth methods
16:55:29 <gyee> o/
16:55:39 <cmurphy> hi gyee
16:55:55 <gyee> external auth is kinda dangerous in a multi domain env
16:57:12 <cmurphy> is multidomain the only case when it's a bad idea?
16:57:17 <gyee> and v3 is all about multi-domain so we should discourage using external auth unless deployer have a flat, single-domain IDP
16:58:20 <gyee> and it cannot be used with multiple auth modules within apache either
16:58:27 <cmurphy> we should probably remove it from the default list of auth methods too then
16:58:28 <gyee> i.e. Kerberos and mod_ssl at the same time
16:59:23 <cmurphy> 1 minute remaining
16:59:28 <cmurphy> #link https://review.opendev.org/#/c/666861/ stable/stein doc bug fix
16:59:33 <cmurphy> one for the stable cores
16:59:50 <cmurphy> any other reviews to highlight?
17:00:23 <cmurphy> alright thanks everyone
17:00:26 <cmurphy> #endmeeting