17:00:28 <cmurphy> #startmeeting keystone
17:00:29 <openstack> Meeting started Tue Jan  7 17:00:28 2020 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:32 <openstack> The meeting name has been set to 'keystone'
17:00:39 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
17:00:42 <cmurphy> o/
17:01:02 <knikolla> o/
17:01:34 <vishakha> o/
17:01:38 <gagehugo> o/
17:02:51 <cmurphy> welcome back everyone
17:02:56 <cmurphy> how were your holidays?
17:03:25 <gagehugo> busier than I wanted, but not bad
17:04:31 <knikolla> went by too quickly
17:04:56 <gagehugo> ^
17:05:25 <cmurphy> i didn't take much time off but it was nice and quiet :)
17:06:06 <vishakha> They were good :) how was yours?
17:06:52 <cmurphy> not bad :)
17:07:02 <cmurphy> #topic Reminder: spec freeze week of Feb 10
17:07:21 <cmurphy> over a month away but just a reminder to help with reviews
17:07:34 <cmurphy> #link https://review.opendev.org/#/q/status:open+project:openstack/keystone-specs+path:%22%255Especs/.*/ussuri.*%2524%22
17:08:13 <cmurphy> #topic L1 duty rotation
17:08:22 <cmurphy> #link https://etherpad.openstack.org/p/keystone-l1-duty
17:08:49 <cmurphy> last time was vishakha - any bugs triaged that you want to discuss?
17:09:43 <vishakha> Yes i wanted to discuss about the bug
17:09:48 <vishakha> https://bugs.launchpad.net/keystone/+bug/1857086
17:09:48 <openstack> Launchpad bug 1857086 in OpenStack Identity (keystone) "Trying to update user options field for ldap user gives 403 forbidden" [Undecided,Invalid]
17:10:51 * lbragstad walks in late
17:10:53 <vishakha> I wasn’t sure about mfa with ldap user
17:11:29 * cmurphy waves to lbragstad
17:11:33 <vishakha> I was wondering if anyone can share some knowledge over this
17:11:49 <lbragstad> vishakha sorry - i jumped on that and tried triaging it yesterday
17:13:32 <lbragstad> IMO - all the resource option for identity APIs is specific to SQL... i don't think we can support MFA with ldap without some serious thought
17:13:39 <vishakha> lbragstad: does mfa works differently for ldap user as compared to normal user?
17:13:46 <cmurphy> abhishek makes a good point, totp is an auth method and not a property of a user
17:14:02 <knikolla> ++, i also feel like if we're delegating auth to ldap, we shouldn't hack mfa on top of that.
17:14:21 <knikolla> from a philosophical standpoint.
17:14:22 <lbragstad> we store MFA keys on the user reference though
17:14:25 <cmurphy> but with the ldap backend auth isn't delegated, it's handled by keystone
17:14:46 <lbragstad> we have to find a way to toggle MFA on and off for ldap, which we don't write to
17:14:46 <knikolla> we're just passing the username/password to the ldap server though.
17:14:56 <knikolla> not doing much on top of that.
17:14:58 <cmurphy> but that's still the 'password' auth method
17:15:22 <gagehugo> do we not store user options separately for mapped users?
17:15:34 <gagehugo> that "enabled" setting will always fail for ldap
17:16:00 <cmurphy> i think user options is a different table
17:16:10 <cmurphy> but maybe the "enabled" option is why they're getting the 403
17:16:27 <gagehugo> that's what I was thinking
17:17:28 <knikolla> IIRC, and from what lbragstad linked, the entire update_user function is 403
17:17:57 <lbragstad> correct - i think we'd have to generalize that up in the manager somehow?
17:18:20 <gagehugo> ah ok
17:18:32 <lbragstad> but - it should have left an "ldap doesn't support writes" 403... not a permission 403
17:18:36 <lbragstad> which kinda threw me off
17:18:46 <cmurphy> right
17:19:20 <lbragstad> that's why i wanted to ask about credentials, just to make sure, since that error looks similar to a permission thing
17:19:30 <knikolla> hmmm... good call.
17:21:54 <cmurphy> so I don't think this is an invalid bug because I think auth methods are separate from identity driver, but the question is whether it's an issue with the credentials they're using, a broken policy rule, an issue with using the "enabled" parameter in PATCH, or a bug in the ldap manager
17:21:58 <cmurphy> does that sum it up?
17:22:50 <gagehugo> I think so
17:22:56 <vishakha> Imo it does sum it up
17:23:25 <knikolla> ah, i see what you mean now. ldap uses the password auth method.
17:24:22 <cmurphy> can someone reopen the bug and add a comment?
17:24:52 <vishakha> Sure i will do it
17:25:13 <cmurphy> thanks vishakha
17:25:16 <lbragstad> thanks for updating
17:25:54 <cmurphy> anyone want to volunteer to take the next bug duty rotation?
17:26:28 <knikolla> i can't do the next one, but can do the one after.
17:27:27 <cmurphy> okay I'll take this week
17:27:58 <knikolla> thanks cmurphy :)
17:28:06 <cmurphy> :)
17:28:09 <cmurphy> anything else on this topic?
17:29:23 <cmurphy> #topic review requests
17:29:30 <cmurphy> anyone working on anything that they want eyes on?
17:30:20 <lbragstad> curious if anyone would like to take another look at https://review.opendev.org/#/c/699743/ ?
17:30:49 <gagehugo> I got https://review.opendev.org/#/c/699013/ if anyone has time
17:31:05 <lbragstad> mordred had a ksa patch he wanted to get reviews on, too
17:32:16 <cmurphy> lbragstad: lgtm
17:32:19 <cmurphy> gagehugo: will review today
17:32:31 <lbragstad> https://review.opendev.org/#/c/662734/ was the other one he had
17:32:37 <lbragstad> ty cmurphy
17:32:46 <gagehugo> ty cmurphy
17:32:50 <cmurphy> i discovered a fun bug while working on functional protection tests for the assignments api https://review.opendev.org/700826
17:33:35 <cmurphy> also easy rst fix https://review.opendev.org/700780
17:35:09 <cmurphy> lbragstad: oh that's an interesting one
17:35:17 <cmurphy> it depends on a devstack change that hasn't merged yet though
17:35:28 <lbragstad> yeah... mordred was asking for feedback
17:36:38 * mordred waves to the nice people
17:36:42 <cmurphy> i think there was either a mailing list discussion or a discussion on another patch about this, i think one of the questions was whether the default should be 'internal' or 'public'
17:36:44 <mordred> for the record, that change is fricklers
17:37:09 <lbragstad> if end users are supposed to use it - i would think it should be public...
17:38:40 <cmurphy> are end users supposed to use it? or is it for service-to-service communication?
17:39:23 <mordred> keystonemiddleware is supposed to be service-to-service no?
17:40:35 <cmurphy> right, i think the only user-facing parameter is the www-authenticate-uri parameter, so i think internal is right for this
17:41:38 <mordred> yeah - that should work in most of the contexts - if people have both public and internal, they likely want services to talk to internal - if they don't, usually they set internal to the same as public, so it should still work for smaller ... as long as it isn't admin :)
17:41:57 <cmurphy> ++
17:44:17 <cmurphy> the change needs a release note, what else do we need to move forward on it? is the devstack change controversial?
17:46:02 <mordred> oh - apparently there is a heat change down in teh depends-on change that's a blocker
17:46:33 <cmurphy> ah :/
17:46:43 <mordred> https://review.opendev.org/#/c/675778/
17:46:50 <mordred> yeah - that's heat using keystoneclient
17:47:08 <mordred> man this is a rat's nest isn't it?
17:48:16 <mordred> ksa has support for interface as a list - that doesn't flow through to ksc does it?
17:49:10 <mordred> if it did, we could update that heat patch to be interface=['internal', 'admin', 'public'] or something - and ksa would then select the right interface in that preference order
17:49:46 <mordred> (at least I'm pretty sure we landed that list support in ksa right?)
17:49:53 <cmurphy> i think so
17:49:56 <cmurphy> and it looks like frickler tried to fix ksc https://review.opendev.org/675870
17:50:18 <cmurphy> i'm not sure why that didn't go anywhere
17:50:48 <mordred> hrm
17:51:06 <mordred> cmurphy: should I try to pick up frickler's ksc patch? maybe update it to default to a list?
17:51:42 <mordred> if we can fix that, then we can drop the heat patch, since it should flow through
17:52:12 <cmurphy> mordred: sounds good to me
17:52:37 <mordred> k. I'll see if I can add that to my list
17:53:05 <cmurphy> thanks mordred
17:53:22 <mordred> \o/ progress!
17:54:40 <cmurphy> #topic open discussion
17:55:03 <cmurphy> anyone else working on something they want to discuss for these last few minutes?
17:57:07 <cmurphy> i know at our last few retrospectives we talked about having more frequent checkins or retrospectives throughout the cycle to try to keep up development momentum, tbh i don't really have time to prepare for big video calls like that these days, but maybe we could use our meeting time to go through the roadmap board every once in a while to check our progress?
17:59:42 <cmurphy> i'll let you mull it over
17:59:47 <cmurphy> thanks for the good discussions today
17:59:50 <cmurphy> #endmeeting