16:00:22 #startmeeting keystone 16:00:23 Meeting started Tue Aug 6 16:00:22 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:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:26 The meeting name has been set to 'keystone' 16:00:33 #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda 16:00:38 o/ 16:00:42 o/ 16:03:14 o/ 16:04:03 o/ 16:04:30 hi everyone 16:04:37 #topic Spec implementation/roadmap check-in 16:04:37 o/ 16:05:21 we're getting close to feature proposal freeze so i wanted to do a check-in about how our planned work is progressing 16:05:35 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/capabilities-app-creds.html app cred access rules 16:06:09 status of this is that server side work just needs reviews, i haven't started client side work but will do that this week 16:06:24 questions/concerns about that one? 16:06:55 nah no concerns 16:07:07 it looks fine and needs more eyes, but is on point 16:07:17 cool 16:07:20 cmurphy: I too can give hands or client side, if needed 16:07:30 s/or/for 16:07:46 thanks vishakha, maybe we can coordinate that 16:07:57 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/expiring-group-memberships.html expiring group membership 16:08:02 cmurphy sure 16:08:05 knikolla: anything noteworthy about that one? ^ 16:08:20 i'm on a good pace with the implementation 16:08:25 haven't pushed anything yet though 16:08:33 awesome 16:08:42 nice. 16:08:56 anyone have questions/concerns about that? 16:09:50 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/immutable-resources.html immutable resources 16:10:15 I had started a WIP of this but was waiting on resource options for all to build on top of 16:10:42 i'll continue working on the keystone-manage part while we get the resource options part squared away 16:10:53 which brings us to 16:10:57 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/resource-options-for-all.html resource options for all 16:11:03 kmalloc: how's that going? 16:11:41 slow 16:11:45 but it should speed up 16:11:54 mostly it's been slow because the code shuffle has been real 16:12:50 mostly it's moving the user options to common 16:12:57 and migrations 16:13:28 the plan is to centralize the options themselves, and then allow any resource to "opt in" [code wise] to having them. 16:13:54 each resource opted into resource options will also be explicitly allowed to use any code definition (e.g. "immutable") of an option 16:14:17 this means we have 1 definition of the option and it may be shared across resource types 16:14:23 and lean on the validation in the same way 16:14:49 and we will have 1 option table with heavy indexing to make the option lookups as efficient as possible when loading the resource 16:15:01 i expect to have code up in the not-too-far out. 16:15:23 * kmalloc kicks endless doctor appointments interrupting workflow (but those are now set on the calendar so i cna work around them)( 16:15:46 sounds good 16:16:01 anyone have questions on that? 16:17:25 #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/support-federated-attr.html federated attributes 16:17:40 knikolla: looked like you started pushing patches up for that one ^ 16:17:52 yup, rebasing and updating the release notes 16:17:58 should be pretty straightforward 16:18:11 i know adam had some concerns about the creating users with fed attributes part 16:18:20 and if it conflicts with predictable ids 16:18:28 so i'll check on that to make sure all is good 16:19:19 okay 16:19:44 where do we stash the fed attributes? in extras? 16:20:03 * gyee hides from kmalloc 16:20:09 >.< 16:20:30 whatever, if that is the place you're going to stash em, just do it. 16:20:42 and don't tell me 16:20:55 haha 16:21:06 nothing as obscene. i think it mostly uses the federateduser table 16:21:12 and the references from there 16:21:54 no new models jumped out at me, except new driver methods 16:24:28 sounds like it will be straightforward 16:24:32 any questions about that one? 16:25:46 the last priority effort i wanted to mention was finishing the system-scope/default-roles conversion 16:26:01 last cycle we rammed a bunch of these in after feature freeze and it was kind of a mess 16:26:18 this cycle i would really like if *all* of them were done before feature freeze 16:26:34 i would rather not keep piling on deprecation warnings for many cycles 16:27:12 and lance certainly can't get it done all by himself so i encourage anyone with extra time to pick some of these up 16:29:58 anything else anyone wants to cover wrt the roadmap and specs? 16:30:41 looks like train will arrive on time 16:30:51 which is uncommon in the US, lol. 16:31:00 >.> 16:31:28 lol 16:32:14 lol 16:33:18 #topic review requests 16:33:20 any requests? 16:35:56 i need another review on https://review.opendev.org/674122 to fix a bug i helped write 16:37:20 you got it. 16:37:45 tyvm 16:38:21 knikolla: could you also slide https://review.opendev.org/655166 up your priority list 16:38:39 i know you have infinite time >.> 16:39:21 kmalloc: if you could give that a onceover too ^ 16:39:23 will do 16:39:33 you, i have a picture which ages instead of me 16:39:34 ++ 16:39:35 will do 16:39:36 yup* 16:39:45 lol 16:40:18 any other reviews that are ready to call out? 16:42:08 #topic open floor 16:42:29 as mentioned in the newsletter i didn't plan a topic for office hours so no office hours after this 16:42:44 anything else to discuss or should we call it early? 16:42:47 when are we deprecating those openidc auth plugins in keystoneauth1? same with v3kerberos 16:43:08 if anybody think they are still useful, I would like to know how are they being used. 16:43:47 i need to refresh myself on them but i think they may all still be useful for different types of oauth flows 16:44:35 the oauth2/oidc specs mention all of them 16:44:59 i use them 16:45:07 the oidc ones 16:45:52 knikolla, as part of openstack CLI? 16:45:57 https://osticket.massopen.cloud/kb/faq.php?id=16 16:46:23 osc is not the only consumer of ksa either 16:46:43 yup, either through osc, the clients or keystoneauth session directly 16:47:24 granted, it would only take a couple of lines to rewrite what they do in plain requests, but since oidc isn't gonna change anytime soon they don't need maintenance. 16:47:31 gyee: krb should be fine to go. but keep in mind deprecation in keystoneauth is fine we can never remove them 16:47:33 and they're already there. 16:47:59 gyee: ksa has a strict "we will not break you" contract, we can roll keystoneauth2 if we want to drop support wholesale for any api/thing 16:48:07 k 16:50:44 anything else? 16:52:08 alright thanks everyone 16:52:11 #endmeeting