16:00:58 #startmeeting keystone 16:00:59 Meeting started Tue Aug 20 16:00:58 2019 UTC and is due to finish in 60 minutes. The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:02 o/ 16:01:03 The meeting name has been set to 'keystone' 16:01:11 #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda 16:01:13 o/ 16:01:14 o/ 16:01:28 o/ 16:01:45 o/ 16:02:06 o/ 16:02:38 hey everybody 16:03:07 #topic cmurphy on vacation 16:03:29 endmeeting? ;-) 16:03:36 \o/ woohoo, haha 16:03:37 lol 16:03:39 as an fyi I'll be away with no laptop and little cell service August 26-September 4 16:03:45 OK everyone, pack it up. we're done ;) 16:03:50 :P 16:03:53 lol 16:03:55 lol 16:03:59 kmalloc: you don't get off the hook that easy :P 16:04:04 kmalloc has agreed to step up as acting ptl while i'm gone 16:04:18 (thank you!) 16:04:28 hehe np 16:04:33 is doggo vice acting ptl? 16:04:46 Always 16:04:59 figure it's the least i can do, considering i'm going to be disappearing for Good Reasons(tm) soon 16:05:24 i'll be missing the next two meetings and office hours 16:05:26 also so cmurphy can get a well deserved break. 16:05:49 kmalloc: and everyone, do you want to keep the next two meetings or cancel them? 16:06:08 just joined, is it open floor time? 16:06:13 hm. lets see. 16:06:26 lets keep next meeting and we'll see if we want to skip the following one 16:06:27 prometheanfire: 6 minutes in? not yet :P 16:06:55 kmalloc: sounds good 16:07:00 if there is no agenda, we'll just start and let folks go early 16:07:22 how about office hours? or do you want to wait to decide? 16:07:32 * prometheanfire has one bug to bring up 16:07:47 prometheanfire: it's on the agenda already 16:08:28 office hours i think we'll skip 16:08:34 uniless there is a good reason to do them. 16:08:48 meeting check in is more important imo, office hours have been slow-ish anyway 16:09:06 agreed 16:10:05 thanks again kmalloc 16:10:26 #topic oauthlib requirements fix 16:10:34 prometheanfire: this is what you wanted to talk about right? 16:10:57 https://bugs.launchpad.net/keystone/+bug/1839393 16:10:59 Launchpad bug 1839393 in OpenStack Identity (keystone) "oauthlib===3.1.0 fails tests (requirements update)" [Low,Triaged] 16:11:23 just that freeze is coming up in a couple of weeks so it'd be nice to clear that out 16:12:02 I haven't looked at it but I'm hoping it will be easyish, any volunteers to take it? 16:12:32 If I wasn't swamped with resource options and ... doctor appointments, i'd offer 16:12:49 I can look inti it 16:12:49 maybe vishakha or gagehugo ? ;) 16:12:53 haha ty 16:12:55 thanks 16:13:00 once i'm done with resource options, etc, if no one else has looked, I'll try and throw something at it, but i think it would be better if I could review. 16:13:00 yw :) 16:13:11 so we can land it qu... yay vishakha !!! :) 16:13:39 prometheanfire: when's the deadline again? 16:13:46 vishakha: ping me if you need any help with that 16:13:47 13th iirc 16:14:03 alrighty 16:14:05 gagehugo sure 16:14:06 anything else on that? 16:14:25 sept 9-13 time 16:14:38 https://releases.openstack.org/train/schedule.html 16:15:09 Thanks prometheanfire for the information 16:15:13 #info requirements freeze september 9-13 16:15:21 #action vishakha to look into https://bugs.launchpad.net/keystone/+bug/1839393 16:15:22 Launchpad bug 1839393 in OpenStack Identity (keystone) "oauthlib===3.1.0 fails tests (requirements update)" [Low,Triaged] 16:16:10 #topic Forum, pre-PTG and post-PTG planning 16:16:40 on this topic, I don't have anything solid to offer yet but wanted to get people thinking about it so we can start working out the details when I get back 16:17:13 even if you don't plan on going to shanghai I'm hoping people can contribute ideas that they want to see discussed at the forum, I'll be happy to moderate them 16:17:43 #link https://etherpad.openstack.org/p/keystone-shanghai-ptg Shanghai PTG/Forum brainstorm 16:18:37 do we know what the next cycle is going to look like, roughly? milestones, etc? 16:19:00 trying to gauge how much of the cycle i'm going to be missing while i am on leave. 16:19:28 at the moment I assume it's going to be a regular six-month cycle with the same milestone markers 16:19:48 ok, so, since i'm bad at math... when would you expect m1 to be? 16:20:07 i can bug you out of the meeting on this. 16:20:11 table it. 16:20:18 yeah i would have to do some counting 16:21:08 anyone already have topic ideas they want to throw out there? 16:21:25 oslo.limit 16:21:46 that's a good one 16:21:52 I suppose I should just add that to the etherpad. 16:21:56 ++ 16:23:02 I put it in both sections since I'm guessing there will be both cross-project and in-Keystone discussion needed. 16:23:24 yes probably 16:24:03 Maybe the policy scope stuff for the forum? 16:24:14 I know you're wrapping it up, but the other projects will probably need some guidance. 16:24:53 yep, hopefully we'll have our side done, maybe nova will also have part of theirs done 16:25:02 in which case we could start talking about making it a community goal 16:25:58 Like the fuchsia etherpad color. :-) 16:26:13 * bnemec has no idea if that's spelled right 16:26:47 for the virtual PTG i think we decided to do both pre- and post- IRL ptg meetings 16:27:31 will the week before and after work for most people? ie sometime in oct 28-nov 1 and nov 11-15 16:28:16 as a note, none of those work for me, but that is to be expected 16:28:33 please just expect i'll be missing the virtual ptg(s) 16:29:08 I promise to share some photos in lieu of my joining the PTGs :) 16:29:14 kmalloc: i'm guessing we won't easily be able to work around your time off 16:29:20 yay :) 16:29:35 An acceptable trade. :-) 16:32:01 how many hours/days should we do for each meeting? 16:35:35 okay well maybe please start adding topics to the etherpad for the ptgs and i'll try to come up with a plan that allows us to cover everything 16:35:44 and will send out a scheduling poll 16:36:06 #topic renewable group membership 16:36:06 ok 16:36:16 knikolla: all you 16:36:26 o/ 16:36:34 so i wanted some feedback on a few things 16:37:00 first: should these renewable group memberships appear in the API response for list groups in use and list users for group? 16:37:40 Should they appear in a separate API or with a special flag? Or should they just be a backend thing and not really be exposed with listing. 16:40:42 the only way these users become members of groups is through mappings right? 16:40:49 yes 16:41:11 creating these directly will not be supported, just through mappings. 16:41:43 hmm 16:42:50 is there any need for a user to be able to view their own expiring group membership? or for admins to be able to see whose memberships are about to expire? 16:44:06 i think it might be nice if a user could see it 16:44:07 just for info, cause they won't be able to act on that info returned. 16:44:21 but ^ yeah, it's informational strictly 16:44:38 i was thinking of a include_expiring=True flag on listings 16:44:53 ?include_expiring 16:44:59 yes 16:45:06 hm. sure 16:45:20 filter_by=expiring 16:45:54 if it's not too difficult to implement it doesn't seem like a bad idea 16:45:55 hmmm.... it does seem a bit of a lie if you "filter" by returning different content 16:46:13 otoh if it's a pain then we could keep it just on the backend for now and expose it later if we decide we need it 16:46:44 ^ 16:46:46 ++ 16:46:51 wfm 16:47:04 expose it unless it's a royal PITA then, expose it later if needed 16:47:17 sure 16:47:49 the other point i had, is that the dependencies between identity backend and federation backend are growing stronger 16:47:58 and if it makes sense to just merge the two together in a future cycle 16:48:20 FederatedUser has a foreign key on IdentityProvider 16:48:31 ExpiringUserGroupMembership will have one as well 16:52:11 *shrug* they can merge. 16:52:19 it's not really that big a deal imo. 16:52:38 I don't really think of idps/mappings/protocols as in the same category as users/groups 16:53:00 it would feel a little weird to me to merge them 16:53:30 also - the federation stuff can't be backed by ldap 16:54:44 that's all i had, we don't have to take a decision now 16:54:49 just wanted to get an overall feeling 16:55:11 * knikolla yields floow 16:55:13 floor 16:56:00 knikolla: i guess my last message was more of a question - what happens when the identity backend is backed by ldap, if federation merges with it? 16:56:20 i think with FKs, it kindof breaks as is 16:56:41 cmurphy: there shouldn't be any difference to how it works today. 16:56:56 I think domain specific drivers would still be applicable. 16:57:14 hmm okay 16:57:19 You kinda have to use a shadow backend with sql anyway with ldap 16:57:31 that's true 16:58:00 this was more of a realization that we've separated two things and required using them together 16:58:59 i can propose a spec to backlog with a more argumentative problem description and gather feedback there. 16:59:12 sounds good 16:59:23 wfm 16:59:25 #action knikolla propose spec to backlog about merging federation and identity backends 16:59:33 #topic open floor 16:59:51 i proposed an office hours topic to discuss the spec features in flight 17:00:14 and we're out of time 17:00:17 #endmeeting