15:04:26 #startmeeting keystone 15:04:26 Meeting started Tue Sep 28 15:04:26 2021 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:26 The meeting name has been set to 'keystone' 15:04:36 #topic Roll Call 15:04:38 o/ 15:04:57 Courtesy ping for ayoung, bbobrov, crisloma, d34dh0r53, dpar, dstanek, gagehugo, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, spilla, jdennis, ruan_he, wxy, sonuk, vishakha,Ajay, raildo, rafaelweingartner, redrobot, xek 15:05:03 o/ 15:05:08 o/ 15:05:25 Can you add me to the courtesy ping list, please? 15:05:35 As usual the agenda can be found here: 15:05:46 #link https://etherpad.opendev.org/p/keystone-weekly-meeting 15:06:07 ayoung, already on the ping :) 15:06:34 o/ 15:06:34 Looks like we've got a few topics to cover so let's get started 15:06:36 Ah...cool 15:06:45 #topic Review Past Meeting Action Items 15:07:00 #link https://meetings.opendev.org/meetings/keystone/2021/keystone.2021-09-21-15.00.html 15:07:02 o/ hello. it's the first time for me to attend this meeting. can i join? 15:07:08 o/ 15:07:26 > redrobot to investigate who the Keystone liaisons are 15:07:44 I did not do this :( 15:07:48 * redrobot punts it to next week 15:07:51 #action redrobot to investigate who the Keystone liaisons are 15:07:59 That was the only action item 15:08:01 moving on ... 15:08:29 we'll skip the Liaison Update since we don't know who they are 15:08:46 #topic Suggestion for OAuth2.0 support from OpenStack Tacker team (h-asahina) 15:08:48 h_asahina: welcome :) 15:08:56 thanks 15:09:03 h_asahina, floor is yours 15:09:10 redrobot: i think i'm most liasons, hah 15:09:55 knikolla, ack ... I'll circle back after this topic 15:10:49 Looks like the summary from h_asahina 's topic description in the etherpad is: 15:10:51 > we would like to propose OAuth2.0 support as an option of Keystone in the next PTG and implement it in Yoga. 15:11:23 yes 15:11:50 Meaning you get SSO without Fedration? 15:12:12 no. we want to support Oauth2 for API calls. 15:12:19 is there a spec discussing the proposal? 15:12:25 like oauth1 extension. 15:12:40 h_asahina, the usual first step is to submit a Spec patch to our spec repo: 15:12:40 > is there a spec discussing the proposal?. sorry not yet. 15:12:44 #link https://opendev.org/openstack/keystone-specs 15:12:54 ayoung: i think this is about having keystone as a oauth 2.0 identity provider 15:13:08 so that services can validate jwt tokens 15:13:09 ^^^ that's the impression I got too 15:14:01 So, reuse an existing library, or implement custom? 15:14:33 we considering implementing a new custom extension 15:15:07 we're also want to submit spec for next PTG. can we make it in time? 15:15:58 yeah, please propose a spec in the keystone-specs repository describing the API and some implementation details (choice of library, support in clients, etc) 15:16:30 ok, when is the deadline for yoga 15:17:01 https://releases.openstack.org/yoga/schedule.html 15:17:42 h_asahina, feature freeze is the week of February 21 15:18:19 got it. but i think we have to submit it before the next PTG, right? 15:18:31 though the spec would have to be approved before that, ideally shortly after the PTG. if there are needs for revising with feedback from the PTG. 15:18:34 h_asahina, yeah, it would be good to have a spec submitted before the PTG 15:18:40 #link https://etherpad.opendev.org/p/yoga-ptg-keystone 15:18:52 You can add it as a topic to be discussed during the PTG session 15:19:10 ok, thanks. 15:20:02 h_asahina, thank you. looking forward to reviewing your spec. 15:20:12 OK, moving on ... 15:20:42 #topic PTG 15:20:50 Just a reminder to sign up for the PTG 15:21:16 Our session will be on Monday October 18 @ 1400-1600 UTC 15:21:30 you can add topics to the etherpad I linked above. 15:23:24 Moving on ... 15:23:59 #topic Migrations Backport 15:24:22 #link https://review.opendev.org/c/openstack/keystone/+/806381 15:24:35 I wanted to follow up on last week's discussion of xek's patch 15:24:43 I spent a little bit of time looking at it 15:25:03 and realized that Keystone uses an NIH migration library that hasn't been updated in years. 15:25:18 so forget everything I mentioned about Alembic because I had no idea what I was talking about. 15:25:24 :) 15:25:29 SQL Alchemy? 15:25:33 long live slqalchemy 15:25:49 ayoung, yeah, it's a custom lib that uses SQLAlchemy 15:25:53 fwiw - we've had alembic on the backlog forever 15:25:56 sqlalchemy-migrate 15:25:58 I know it well 15:26:09 _member_ FTW 15:26:14 the outstanding question was whether it was safe to backport to Wallaby 15:26:27 because we didn't merge the placeholders before the wallaby release 15:27:39 In my limited undestanding of sqlalchemy-migrate, I _think_ it should be OK, given that it's the only migration that landed 15:27:49 but I'll defer to someone with better understanding of the lib 15:28:12 ++, i have the same general feeling, given that there's nothing to mess up the ordering yet 15:28:18 So we are cool with the 256 character limit, right? 15:28:31 THis is just about the backportability of the patch? 15:28:48 ayoung, right ... the patch has already landed on master 15:29:38 And the migration in that patch is SQL alchemy. I assume that means that we've moved to Alembic since then? 15:29:50 And the question is whether a SQL A migration can still land? 15:29:53 ayoung, negative, no alembic support yet 15:30:10 * redrobot was confused about what migration strategy keystone uses 15:30:27 Its more of a tactic than a strategy 15:32:00 And...why is the actual work done in contract? 15:32:15 disregard 15:32:22 I read them in ABC order. All makes sense 15:33:28 OK, so this change is only going to adjust the size of the column in the database to a larger size. Why would there be an issue with the migration? Is there a Wallaby migration <079? 15:33:42 Er > thatn 079 15:33:46 no 15:34:15 we typically merge a series of placeholders before every release to allow for backporting migrations 15:34:18 but - we didn't do that 15:34:28 but we also haven't merged a migration in a long time 15:34:39 Yes, I recall that practice. 15:34:52 so - we wanted to make sure we weren't screwing anything up by backporting a migration without a placeholder 15:35:10 i think the saving grace in this case is that both wallaby and master would have the latest migration 15:35:12 Since the migration numbers would be consistant from Wallaby on forward, I would think there would be no risk. It would not break a future upgrade 15:35:44 So long as there is no compacting of migrations, you will always get 0179 on top of 078 15:36:01 (I'm sure you've missed my typos) 15:36:02 i think it would be a problem if we implemented 79 and then xek's patch was 80 15:36:12 then, we would have a problem 15:36:22 because we would have to backport 79 and 80 15:36:27 Right. 15:37:31 So it sounds like we're clear to go ahead and merge? 15:37:42 i think so? 15:38:23 but we should probably 1.) make sure we do the placeholders or 2.) figure out if alembic makes the problem go away 3.) move to alembic anyway since sqlalchemy-migrate is on life-support 15:38:53 i think we're one of the only projects still using -migrate 15:38:54 placeholders would make sense at the end of a release with a lot of database migrations 15:39:07 2) Yes. Alembic uses uuid-like strings to identify changes, and they point to the parent, and it's smart enough to know when a patch has already been applied. 15:39:18 nice 15:39:18 Alembic is also good about squashing migrations 15:39:35 it gives the option of backporting fixes prior to any real work 15:39:52 Alembic is like git for Databases. I liked it when we evaluated it years back 15:39:59 yeah 15:40:22 But, moving from SQL A to Alembic should be done in a release before any migrations land 15:40:28 regardless, we probably need to adopt something soon, we've been putting it off for a long time 15:40:32 It was nice enough to get merged into SQLAlchemy proper 15:40:53 ok - so should we plan and stage that work for Z? 15:41:20 Actually, it would be a good plan to do it at the end of Y 15:41:27 lbragstad, we can always Upstream Friday the work. :) 15:41:27 instead of "the first thing" make it the last 15:41:46 someone could PoC it, propose it for review, and we can merge it after plenty of time to play with it in review 15:41:58 reminds me of https://review.opendev.org/c/openstack/keystone/+/760678 15:42:42 oof 15:42:42 Hmm...now that I think of it, I don;t know that it needs to be first thing. Just needs to be an explicit cut over 15:42:58 agreed - but i need more time to think about the migration 15:43:11 the good thing is that we don't really have many migration in flight 15:43:23 I think we are OK so long as we agree that 00X is the last SQL A migration 15:43:33 right 15:43:37 ayoung++ 15:43:38 and then DB sync does the right thing 15:43:43 (tm) 15:44:33 There's a few more patches in the agenda, so I want to move on from this, since it sounds like we have a plan. 15:45:51 lbragstad, ayoung, knikolla, please +1/+2 the migration backport patch when you get a chance. 15:45:58 moving on ... 15:46:04 #topic Review Requests 15:46:06 i'd like to get some reviews on some trivial patches 15:46:09 #link https://review.opendev.org/c/openstack/keystone/+/806243 15:46:16 #link https://review.opendev.org/c/openstack/keystone/+/806205 15:46:22 #link https://review.opendev.org/c/openstack/keystone/+/810324 15:46:29 i already pushed them through :) 15:46:38 knikolla noice 15:46:40 thanks! 15:46:44 nevermind then :) 15:46:50 that was fast! 15:47:04 we should back port those to the train release if possible 15:47:12 or as far back as possible 15:47:23 I'll keep an eye out for cherry-picks 15:47:25 because the default sample doesn't make sense and is misleading 15:49:23 submit them for backport and tag reviewers 15:49:37 ^^^ 15:49:46 OK, last topic for today 15:49:52 #topic Bug Review 15:49:59 NOt quite last...I added one 15:50:03 :) 15:50:10 #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:50:40 Looks like no new keystone bugs in the last week 15:50:52 lot of untraiged bugs 15:51:11 The region thing came up years ago 15:51:19 #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:51:28 And no new bugs in python-barbicanclient 15:51:38 lbragstad, yeah, we've got a topic for PTG to try to triage some of those 15:51:53 Although there is a lot 15:52:07 so maybe we should set up a recurring triage meeting until those are all triaged 15:52:17 something to think about for PTG anyway 15:52:35 And a last minute topic 15:52:48 #topic ayoung requests core again 15:52:48 Just add the bugs to the end of the Keystone meeting that we want to triage and we get through as many of them as we can until the meetingruns out of time 15:53:00 Yeah, so I'm back in an OpenStack world. 15:53:00 ayoung, that's also a good suggestion 15:53:08 ayoung, Welcome back! 15:53:11 ++ 15:53:12 And I am happy to help move patches along again. 15:53:21 ack - i think we've only had to do this one other time 15:53:25 and that was with gyee 15:53:26 (lord knows we need it) 15:53:34 And I know where most of the bodies are buried 15:53:47 including gyee's 15:53:55 I mean, he's alive, I mean the bodies that he buried 15:55:11 lol 15:55:17 #link https://review.opendev.org/admin/groups/036b9e3b26007375b712b2fa8565e63f652fa3e9,members 15:55:18 ayoung how familiar are you with the current code? i know we've changed quite a bit with the flask migration, policy stuff, application credentials, token provider refactor 15:55:44 I was there for flask migrations and app creds 15:55:48 but i can't remember where we were with all that when you stepped away 15:55:49 ok 15:55:50 cool 15:55:52 token provider refactor needed to happen 15:55:57 * redrobot moves aside and lets ayoung cut in line to core 15:56:14 policy stuff...I've been keepingtrack of, and It started before I left 15:56:40 its not a queue, redrobot 15:56:57 and I am pretty sure Keystone has no quota on core 15:57:22 I only know enough Keystone to be dangerous 😁 15:58:24 THat goes for all of us 15:58:31 Keystone IS dangerous 15:58:57 Almost at the top of the hour 15:59:05 so we may need to let ayoung's request marinate 15:59:16 Yeah, that is fine 15:59:28 this is just the point where I let you know I am willing 15:59:37 much appreciated, ayoung 15:59:42 agreed 15:59:47 tag me on reviews, please 16:00:01 #info tag ayoung on all reviews 16:00:07 fwiw - i think gyee reviewed for a few weeks until he was comfortable with the code again 16:00:11 that should keep you busy for a while 16:00:22 ++ 16:00:26 and then cmurphy reinstated him 16:00:49 we'll revisit next week 16:00:54 but - we can work through that - ayoung let me know if there is an area of code you have questions about 16:01:00 ++ 16:01:13 thanks for joining, everyone! 16:01:25 #endmeeting