16:00:56 <cmurphy> #startmeeting keystone
16:00:56 <openstack> Meeting started Tue Jun  4 16:00:56 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:59 <cmurphy> o/
16:00:59 <openstack> The meeting name has been set to 'keystone'
16:01:01 <knikolla> o/
16:01:04 <gagehugo> o/
16:01:17 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:01:20 <vishakha> o/
16:01:37 <lbragstad> o/
16:02:11 <cmurphy> I don't have much for today's agenda...feel free to add things
16:03:43 <cmurphy> #topic announcements
16:04:37 <cmurphy> based on the polling, the best time to do our M-1 retrospective/check-in is pretty much the same times as the meetings, with an edge toward having it next week (which also gives me more time to prepare)
16:04:57 <cmurphy> so it's scheduled for June 11 at 15:00
16:05:31 <cmurphy> i'll set up some kind of video conference call for it
16:05:32 <knikolla> cool
16:05:48 <gagehugo> 1500 utc?
16:05:49 <lbragstad> are we going to use trello?
16:05:59 <gagehugo> nvm I can't read
16:06:01 <cmurphy> gagehugo: yes utc
16:06:15 <gagehugo> lemme make a calender meeting before I forget
16:06:27 <cmurphy> lbragstad: probably, unless you have another tool you want to experiment with :)
16:06:34 <lbragstad> nope
16:08:34 <cmurphy> i'm happy to explore non-proprietary alternatives to trello if someone else wants to put in the effort to finding one :)
16:09:06 <cmurphy> any other questions/concerns about it?
16:09:52 <lbragstad> i don't have an alternative to propose
16:09:52 <kmalloc> o/
16:11:09 <cmurphy> next announcement is that spec proposal freeze is this week
16:11:11 <kmalloc> eh, trello is fine for now
16:11:29 <cmurphy> afaict we're on track with that
16:11:37 <cmurphy> with what we were expecting from the ptg
16:12:55 <cmurphy> but it means we only have six weeks until the spec freeze date and 10 weeks until feature proposal freeze :)
16:13:21 <lbragstad> that's fast
16:13:26 <cmurphy> ikr
16:14:32 <cmurphy> #topic open reviews
16:14:44 <cmurphy> anyone have open reviews they want to highlight?
16:15:13 <knikolla> i renamed and updated the "expiring users" spec
16:15:32 <cmurphy> i started reviewing it right before the meeting
16:15:41 <knikolla> #link https://review.opendev.org/#/c/604201/
16:16:31 <cmurphy> knikolla: anything you want to highlight about the update?
16:16:58 <knikolla> sure
16:17:15 <knikolla> so the expiry is on the user now, and it gets refreshed only by logging in through the idp
16:18:16 <knikolla> the app cred doesn't expire, the user does. but the app cred will get invalidated if the user logs in with less roles than the app cred has.
16:18:26 <knikolla> regardless of user expiry.
16:18:40 <lbragstad> at the ptg - wasn't there a case to set expiry on local users, too?
16:19:08 <knikolla> i'm not sure. that wasn't in my notes.
16:19:25 <cmurphy> lbragstad: do you remember what the case was?
16:19:25 <kmalloc> no
16:19:38 <kmalloc> wait.
16:19:42 <lbragstad> i thought there was someone in the room that asked about that?
16:19:57 <lbragstad> i could be hallucinating
16:19:58 <cmurphy> there would be no way to do that in a backwards compatible way since the ttl is on the idp the user comes from
16:20:09 <kmalloc> so the expiry was strictly for federation granted groups and granted roles
16:20:17 <kmalloc> but no expiry on the local user itself.
16:20:37 <kmalloc> all federation originated grant information would be subject to the expiry
16:20:48 <kmalloc> but otherwise would look like a concrete role assignment until such time as it expires.
16:20:58 <kmalloc> and it can only be refreshed by logging in via the IDP.
16:21:13 <lbragstad> so expiration is only going to be an attribute of federated users?
16:21:25 <kmalloc> of federated conveyed grants
16:21:31 <lbragstad> it won't be a first-class attribute of users
16:21:41 <cmurphy> the spec right now is on the users, not the grants
16:21:47 <cmurphy> which was my understanding from the ptg
16:21:57 <lbragstad> same here
16:22:22 <kmalloc> it was supposed to be the addition of the group to the user and the grants.
16:22:25 <kmalloc> to the user
16:22:40 <kmalloc> the grants/inclusion to a group would have a TTL
16:22:41 <knikolla> discussion was also for disabling users, since federation leaves a lot of db cruft
16:22:46 <kmalloc> concrete user or otherwise
16:23:00 <kmalloc> so federated user or local user linked (future) to federation
16:23:25 * kmalloc only remembers talking about the grant bits
16:23:42 <knikolla> from an implementation perspective, i don't like the expire on role assignment bits too much.
16:23:50 <knikolla> but from a ux perspective it makes more sense.
16:24:14 <kmalloc> originally we talked just about the group inclusion
16:24:34 <kmalloc> because that would unblock group-conveyed roles to app creds
16:24:51 <kmalloc> but it was (at the end) brought up that non-group conveyed roles could/should also be covered
16:26:06 <knikolla> the idea behind my spec update, was that: expiring users, and allowing creation of app creds with non concrete roles (but check them every log in), would give the same result with less work.
16:26:25 <knikolla> (minus trusts)
16:27:09 <kmalloc> if we ever support linking federation to a concrete user for logins (not just mapped)
16:27:15 <kmalloc> that will need to be reworked.
16:27:20 <kmalloc> s/concrete/local user.
16:27:41 <cmurphy> we do support that
16:27:43 <kmalloc> e.g. MOC and Red Hat separate IDPs to the same knikolla, with different permissions
16:27:52 <knikolla> kmalloc: i think that is less important if we do spectroscope and do that there
16:28:03 <kmalloc> knikolla: i'm fine with either way
16:28:16 <kmalloc> just making sure it's clear what we're punting on if the user itself expires
16:28:35 <kmalloc> spectroscope is a ways out still
16:28:43 <cmurphy> spectroscope?
16:28:51 <kmalloc> cmurphy: identity broker project
16:29:03 <kmalloc> *service, whatever
16:29:07 * cmurphy didn't know it had a name
16:29:12 <kmalloc> it does now ;)
16:29:35 <knikolla> i'll have a look at the code/model changes required for expiring role assignment
16:29:36 <kmalloc> needed a name so i could start discussing it without saying "that identity broker service that does a thing"
16:29:37 <kmalloc> ;)
16:30:29 <knikolla> or group membership
16:30:38 <knikolla> cause it has to be on both.
16:30:48 <kmalloc> and like i said, i'm fine with punting on it.
16:31:02 <kmalloc> as long as we are clear on where the lines are drawn for support to the end consumers
16:31:24 <kmalloc> i don't want folks to be too confused on what functionality is provided internal to keystone
16:32:00 <knikolla> ++, i'll propose both approaches as different specs and we can have that discussion during the next meeting
16:32:11 <kmalloc> eh, don't do that
16:32:19 <kmalloc> evaluate and pick one
16:32:29 <kmalloc> offer the other option as an alternative to the spec
16:32:34 <kmalloc> (in the alternative section)
16:32:48 <kmalloc> we can re-spin the spec to swap the alternative if needed.
16:33:08 <knikolla> alright
16:33:15 <kmalloc> i trust you to make the choice that makes the most sense in the spec (implementation and ux wise)
16:33:33 <kmalloc> make sure to get cern's input in either case
16:34:06 * knikolla brushes away impostor syndrome
16:34:11 <knikolla> thanks for the input
16:34:17 <cmurphy> sounds good, thanks guys
16:34:32 <cmurphy> any other reviews people want to highlight?
16:35:08 <cmurphy> i have some patches to undo the app cred access rules config which had already merged https://review.opendev.org/#/q/status:open+project:openstack/keystone+branch:master+topic:undo-access-rules-config
16:35:24 <cmurphy> and the spec update for same https://review.opendev.org/661784
16:37:06 <cmurphy> also some spec repo cleanup which were action items from the ptg https://review.opendev.org/658893 https://review.opendev.org/658894 https://review.opendev.org/659159
16:38:04 <cmurphy> and one more is the vision reflection update https://review.opendev.org/662106
16:40:16 <cmurphy> sounds like no other reviews to highlight
16:40:20 <cmurphy> #topic open discussion
16:40:33 <cmurphy> no office hours after this since there aren't any topics
16:43:13 <cmurphy> if there's nothing else to discuss we can close early and get a few minutes back
16:43:23 <cmurphy> thanks everyone
16:43:27 <cmurphy> #endmeeting