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