16:00:10 #startmeeting keystone 16:00:11 Meeting started Tue Sep 10 16:00:10 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:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:14 The meeting name has been set to 'keystone' 16:00:17 * kmalloc pours coffee 16:00:29 #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda 16:01:00 o/ 16:01:27 o/ 16:01:31 o/ 16:01:52 o/ 16:01:53 o/ 16:05:11 #topic announcements 16:05:32 okay first announcement: 16:05:33 o/ 16:05:56 thanks ayoung for joining - ayoung has let me know that he's stepping back from the keystone core team 16:06:05 :( 16:06:09 i want to sincerely thank ayoung for all the years he has put into this project, keystone would not be what it is today without him 16:06:20 Thanks. 16:06:34 * lbragstad remembers ayoung helping him get onboarded to keystone back in 2013 16:06:49 thanks for all your contributions ayoung 16:06:49 I’ll buy you a beer Adam when I’m back in Boston. 16:07:01 This is an acknowledgement that I no longer have my finger on the pulse of the project. I'll be around, and if anytthing changes, I can be back up to speed quickly 16:08:10 i'm sure we'll still pester you with questions 16:08:42 :) 16:10:58 I'm done. 16:11:51 ayoung, thanks for everything! I am sure not just Keystone, everyone in the OpenStack community have one of those "I remember ayoung helped me out" stories. 16:12:58 so what are we going to do with those #FIXME(ayound) thingies in the code? :-) 16:13:19 haha 16:13:20 Fix them 16:13:43 second announcement, now that the election is over i wanted to mention that at the moment i am not planning on running for a third term as ptl, unless there is really no other option, so if anyone has an inkling that they might want to step up and fill the role please let me know and i'll be happy to answer questions 16:14:03 [ayoung@ayoungP40 keystone]$ grep -rni ayoung keystone 16:14:03 keystone/assignment/core.py:1330: # TODO(ayoung): Add notification 16:14:03 keystone/auth/core.py:302: # TODO(ayoung): when trusts support domains, fill in domain data 16:14:03 keystone/identity/backends/ldap/core.py:435: # NOTE(ayoung): LDAP_SCOPE is used here instead of hard- 16:14:04 keystone/tests/unit/test_v3_protection.py:226: # TODO(henry-nash, ayoung): It would be good to expand this 16:14:07 keystone/tests/unit/test_v3_auth.py:3811: # NOTE(ayoung): not deleting token3, as it should be deleted 16:14:10 Heh 16:14:32 thanks for the heads up cmurphy 16:14:45 definitely not planning on going anywhere though 16:14:48 so don't worry about that 16:15:00 i'm not worried about another great PTL rising up to the challenge. we have great people in the community 16:15:43 ayoung: soo... about LDAP integration in keystone :P 16:17:04 remove it 16:17:18 LOL 16:18:08 let's move on, agenda is not small today 16:18:38 #topic reviews 16:18:48 lbragstad: you mentioned the ksa one on the agenda 16:19:09 yep - i'm just curious about following up this discussion 16:19:16 since there was discussion on it a while ago 16:19:31 i address some of the concerns, but wanted to give folks a chances to give it another look 16:19:38 or raise any issues they have with it 16:20:22 the retry bits? 16:20:27 yeah 16:20:36 i don't like it. i think the alternative almost requires a ksa2 16:21:02 the alternative? 16:21:15 adding in explicit retry settings for all auth-path 16:21:26 which impacts get_endpoint, get_auth, etc 16:21:43 or explicit retry options for each auth path method. 16:21:51 which i like less than global retry setting 16:22:00 s/global/session/ 16:22:07 oh - i think the current approach reuses the session object 16:22:13 yeah it does 16:22:24 which makes it the least obnoxious option for end users to consume 16:22:47 short of breaking the contract and making things cleaner in how KeystoneAuth processes auth path. which would require ksa2 16:23:10 so... tl;dr, i don't like it but i don't have a good alternative if we need this retry logic in the session 16:23:34 auth is "special" (unfortunately) and we'll probably have subsequent questions in the future on retry's on auth 16:23:39 so... we can land it as is 16:24:01 sounds good - we can continue to discuss offline, too 16:24:14 i wanted to raise awareness 16:24:40 that's it from me cmurphy 16:24:48 thanks lbragstad 16:24:52 np 16:25:13 i want to specifically beg for reviews on the remainder of the stack starting at https://review.opendev.org/668238 16:25:26 cmurphy: just +2'd that one 16:25:34 thanks kmalloc 16:25:35 and i think i have +2 on the rest of the stack 16:25:44 i have a talk on it and would be super sad if it didn't make it in 16:25:50 i'm just reading your response to my question now 16:26:07 so - access rules are reusable across users today, yeah? 16:26:21 lbragstad: no, access rules are owned by a user 16:26:36 a user can reuse them in different app creds though 16:26:43 "An access rule record isn't specific to a particular app cred, they are only specific to a user, so they won't be duplicated except when different users create the same ones." 16:27:01 so - if we both create app creds and we both specify the same access rule 16:27:15 there are going to be two access rules persisted in the backend even though they're the same? 16:27:25 yes because we have a user_id in the model 16:27:32 ok - got it 16:27:58 in the future we could refactor and migrate to share app creds, it sounds like 16:28:06 yes i think so 16:28:25 awesome - sorry, i'm not trying to pre-optimize 16:28:32 :) 16:28:34 just something that cross my mind when i was looking at the object model 16:29:25 besides that i made a list of things we're aiming to land this week 16:29:35 #link https://etherpad.openstack.org/p/keystone-train-feature-freeze-todo feature freeze reviews 16:30:23 knikolla: i didn't include the expiring group work, it didn't look ready and isn't passing ci 16:30:41 so i think we need to let it slip unless i've missed something? 16:31:33 Yeah, I’m sorry. Had to take a step back and focus on mental health. 16:31:53 i support that 16:32:03 I’ll be on vacation through the 29th 16:32:34 nice, enjoy and thanks for the headsup 16:32:41 ++ 16:33:03 knikolla enjoy 16:33:16 Thank you 16:33:32 on the topic of vacation 16:33:34 FYI I'll be starting vacation around sept. 30... and then uhm. i'll be dealing with new kid 16:33:54 so. yeah. 16:34:18 kmalloc: just come back with baby pictures 16:34:35 hehe 16:37:20 on the topic of reviews, we bumped the timeouts for most of the tox jobs so that we could try to get more throughput (missed one https://review.opendev.org/681161 it's going through now) but i suggest that once all the policy changes are merged that we merge https://review.opendev.org/680788 which is a slightly more robust hack to workaround the issue 16:37:47 i like that idea 16:38:01 and any help reviewing everything in https://etherpad.openstack.org/p/keystone-train-feature-freeze-todo is much appreciated 16:39:14 anything else on the reviews topic? 16:39:41 i appreciate folks picking up the slack on the policy/system-scope/default roles work 16:40:00 i walked through most of the outstanding review last night and they look great 16:40:00 you laid solid groundwork to follow 16:40:08 thanks for all the reviews 16:40:18 it's the least i could do 16:41:33 #topic forum planning 16:41:47 #link https://etherpad.openstack.org/p/PVG-keystone-forum 16:41:59 i split out the forum etherpad 16:42:08 I know most people aren't planning on being there 16:42:30 is the plan to cover things there and post recaps? 16:42:46 or are you planning on attempting to host a virtual presence of some kind? 16:42:55 i will certainly be taking notes and posting recaps 16:43:11 i definitely do not want to try to manage virtual attendance 16:43:16 in china 16:43:21 * lbragstad nods 16:43:50 timezones are going to make that really tough anyway 16:44:10 (let along trying to find a VC solution) 16:44:14 alone* 16:44:37 there are only two topics proposed, personally i don't need to propose other topics - i think we're moreorless set wrt app creds and i think federation topics can be covered in the virtual ptg if we need to 16:45:19 but i'm open to moderating more sessions if people think there are other things worth proposing 16:45:23 I would also add alembic migrations for PTG 16:46:19 vishakha: that was my next topic, go ahead and add it to the ptg etherpad https://etherpad.openstack.org/p/keystone-shanghai-ptg 16:46:43 :) 16:46:56 bnemec: how do you feel about proposing/moderating the oslo.limit forum session? 16:47:36 Sure, I can do that. 16:47:40 * lbragstad nods vigorously 16:47:53 I'm assuming that means lbragstad won't be there. :-/ 16:48:01 lbragstad: did you figure out whether you would make it? 16:48:02 tbd 16:48:11 i'll know by eow 16:48:18 mmk 16:48:18 er - thursday actually 16:48:32 cool 16:49:06 i'll plan on proposing a session on policy 16:49:17 lbragstad: you can co-moderate one or both if you end up making it :) 16:49:26 +1 16:49:50 sweet - if that means take notes, i'm all in 16:49:54 ;) 16:49:57 lol 16:50:12 If it means I _don't_ have to take notes, +1000. :-) 16:50:16 ++ 16:50:41 moderating while attempting to take notes is a pain 16:52:09 last topic, few minutes left 16:52:14 #topic ptg planning 16:52:19 #link https://etherpad.openstack.org/p/keystone-shanghai-ptg 16:52:31 we discussed doing a pre- and post- virtual ptg 16:52:59 i wrote up a straw man schedule but not really sure how many hours/days to take 16:53:05 depends on how many topics there are to discuss 16:53:09 so - the virtual ptg is going to be similar to the one we did for Train, right? 16:53:21 lbragstad: you mean the midcycle? 16:53:30 yeah - midcycle 16:53:37 yeah that's pretty much what i had in mind 16:53:42 cool 16:53:57 any other ideas for how to organize it? 16:55:34 any comments on the straw man schedule or any other topic ideas? 16:56:11 * lbragstad wonders what spectroscope is 16:56:25 lbragstad: the proxy idp 16:56:32 oooooo 16:56:41 i didn't realize it had a name 16:57:33 if we keep it a short-ish session (2-3 hours) then i would probably suggest we hold it over the normal meeting time, one week before and one week after the summit 16:58:03 if we decide we need more time i'll start a scheduling poll 16:58:53 #topic open discussion 16:59:07 anything else to bring up in the next two minutes? 17:00:17 okay thanks everyone 17:00:18 #endmeeting