16:00:34 <cmurphy> #startmeeting keystone
16:00:35 <openstack> Meeting started Tue Oct 15 16:00:34 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:39 <openstack> The meeting name has been set to 'keystone'
16:00:46 <vishakha> o/
16:00:47 <gagehugo> o/
16:00:49 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:01:28 <cmurphy> i didn't prepare much due to meeting just before this
16:04:50 <lbragstad> o/
16:05:29 <cmurphy> #topic PTG reminder
16:05:47 <cmurphy> #link https://etherpad.openstack.org/p/keystone-shanghai-ptg PTG agenda
16:06:04 <cmurphy> reminder that we'll be doing our pre-PTG virtual meeting in two weeks
16:06:30 <cmurphy> and please add your name to the etherpad if you plan on attending
16:08:40 <cmurphy> #topic python2
16:09:27 <cmurphy> so I think starting this release we're allowed to drop python2 support
16:09:50 <cmurphy> was wondering if the team has any thoughts on continuing to test python2 versus dropping those tests?
16:10:40 <gagehugo> iirc kmalloc expressed great joy in ripping out the six library
16:12:11 <gagehugo> I'm up for dropping py2 support
16:12:25 <cmurphy> personally i would prefer not to spend effort refactoring existing code that's currently working when we have so many other things to do
16:12:38 <cmurphy> but i'm okay with dropping the zuul jobs
16:13:36 <lbragstad> ++
16:13:41 <gagehugo> sure
16:14:10 <vishakha> Yeah this can take our time to solve many errors by dropping py2
16:15:20 <bnemec> Note that this probably needs to be coordinated with the other projects.
16:15:36 <cmurphy> that was my next thought
16:15:46 <bnemec> If Keystone breaks py2, even accidentally, while the other projects are still gating on it the world will be on fire.
16:16:00 <lbragstad> good point
16:16:04 <bnemec> I know there was some discussion in the tc meeting last week about coordinating this.
16:16:06 <cmurphy> i think there was chatter in the tc channel about coordinating this but i'm not sure where it landed
16:16:10 <cmurphy> yeah
16:16:30 <bnemec> I can't remember if I saw that email afterward.
16:17:50 <cmurphy> I see one from stephen about nova but not a general one
16:18:05 <cmurphy> I'll clarify with the tc about whether there's a coordinated plan
16:18:24 <bnemec> Oh look, there's an etherpad: https://etherpad.openstack.org/p/drop-python2-support
16:19:05 <cmurphy> oh and there's a meeting planned
16:20:14 <bnemec> Yeah, so probably need to wait until that is sorted before doing anything drastic.
16:20:22 <cmurphy> ++
16:20:26 <cmurphy> agreed
16:20:34 <cmurphy> thanks for finding that
16:21:06 <bnemec> np
16:21:45 <bnemec> Hehe, the same discussion is going on in #openstack-meeting
16:22:01 <cmurphy> lol
16:22:10 <cmurphy> well i think that's settled for now so moving on
16:22:17 <cmurphy> #topic review requests
16:22:48 <cmurphy> #link https://review.opendev.org/687753 drop project.id foreign keys
16:22:51 <vishakha> #link https://review.opendev.org/#/c/685260/  https://review.opendev.org/#/c/685402/
16:23:01 <vishakha> Small one
16:23:06 <cmurphy> #link https://review.opendev.org/687756 reverts sql-only resource driver
16:23:57 <cmurphy> wanted to bring those up to see if there were any concerns with the migration
16:24:29 <lbragstad> so - we're going back to using other backends for domains and projects?
16:25:03 <cmurphy> to being able/allowed to
16:25:41 <cmurphy> how do you feel about that?
16:25:58 <lbragstad> traditionally - we've moved to only allowing identity information to come from other backends
16:26:12 <lbragstad> and we pushed everything else to sql
16:26:32 <cmurphy> how have we done that?
16:26:39 <cmurphy> all of the drivers are pluggable
16:26:43 <cmurphy> except the resource driver
16:27:25 <lbragstad> i think we did it by deprecating everything but the sql driver and leaving things pluggable
16:27:42 <lbragstad> (e.g., giving people only one supported option upstream)
16:28:27 <cmurphy> this isn't adding a new upstream driver, it's just re-allowing it to be pluggable
16:29:27 <lbragstad> don't the FKs give us performance improvements?
16:30:52 <cmurphy> how so? i don't think we do any kind of joins on them
16:32:01 <lbragstad> i'm can't remember the reason for introducing the foreign key
16:32:06 <lbragstad> i can't*
16:32:49 <cmurphy> https://review.opendev.org/409874
16:33:15 <cmurphy> i think it was just for db-level enforcement of existence
16:34:05 <lbragstad> hmm
16:34:24 <lbragstad> according to your commit message we check that constraint before we get to the database, anyway?
16:34:41 <cmurphy> right
16:36:14 <lbragstad> is someone asking for https://review.opendev.org/#/c/687756/2 ?
16:36:50 <cmurphy> no, it's just something that's bothered me for a long time and something i had as an action item from the last ptg
16:36:57 <lbragstad> ah
16:37:33 <cmurphy> and as far as i can tell it seems to be an easy fix, but i could be missing something
16:38:00 <cmurphy> like i think this should work fine with rolling upgrades but maybe it's more complicated than i imagine
16:38:01 <lbragstad> i wish i could dust off discussions david and ron had when they were working on this
16:38:08 <cmurphy> heh yeah
16:38:58 <lbragstad> from a rolling upgrade perspective, we're being less restrictive, right?
16:39:45 <lbragstad> keystone should always guarantee that a user maps to a domain
16:39:57 <cmurphy> right, and also the manager code isn't changing and enforces the behavior we want to i think it's safe to make the db more permissive during the contract part of the upgrade
16:40:24 <lbragstad> so the migration doesn't technically have to do anything but remove the key
16:40:34 <cmurphy> right
16:40:41 * lbragstad nods
16:41:13 <cmurphy> it's not terribly urgent so i can leave this up for a while if people want to mull it over
16:41:15 <lbragstad> i wish i could remember if there was a pre-determined reason for that key
16:42:12 * lbragstad will think on it
16:42:21 <cmurphy> cool
16:42:29 <cmurphy> any other review requests?
16:45:26 <cmurphy> #topic open floor
16:45:37 <cmurphy> anything else to discuss?
16:47:35 <cmurphy> okay thanks everyone
16:47:39 <cmurphy> no office hour today
16:47:43 <cmurphy> #endmeeting