16:00:48 <lbragstad> #startmeeting keystone
16:00:48 <openstack> Meeting started Tue Jan 15 16:00:48 2019 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:51 <openstack> The meeting name has been set to 'keystone'
16:00:56 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:59 <lbragstad> agenda ^
16:01:37 <gagehugo> o/
16:01:50 <vishakha> o/
16:02:03 <knikolla> o/
16:02:20 <lbragstad> we don't have much on the agenda - let's give people a minute or two to join
16:04:11 <lbragstad> alright
16:04:14 <lbragstad> #topic announcements
16:04:31 <lbragstad> #info specification freeze was last week
16:04:41 <lbragstad> note that we can still file exceptions
16:04:55 <lbragstad> #info feature proposal freeze is in a couple weeks
16:04:57 <lbragstad> #link https://releases.openstack.org/stein/schedule.html
16:05:19 <lbragstad> so not far away - something to be aware of if you're planning feature work and have yet to start the implementation
16:05:33 <lbragstad> #topic previous action items
16:05:44 <lbragstad> i sent a note to the mailing list about the unified limits discussions
16:05:52 <lbragstad> and what we need to do to pick that back up again
16:06:00 <lbragstad> i'll be pinging people again this week -
16:06:21 <lbragstad> but if you know of anyone internally or something that is looking forward to this work, feel free to socialize into other circles
16:06:34 <lbragstad> otherwise - we, as a team, had another action item
16:06:45 <lbragstad> #topic keystone team to review TC vision statement
16:07:01 <lbragstad> #link https://governance.openstack.org/tc/reference/technical-vision.html
16:07:29 <lbragstad> does anyone have feedback on this?
16:07:54 <knikolla> not yet
16:08:11 <lbragstad> do people still need more time to look?
16:08:27 <knikolla> ++, i remember reading it around october, but need a refresher
16:08:28 <vishakha> sorry I also missed it.
16:08:42 * gagehugo also should re-read it
16:08:50 <lbragstad> ok - let's reassign the action item for next week
16:09:10 <gagehugo> this is our homework then :)
16:09:16 <lbragstad> essentially
16:09:25 <lbragstad> :)
16:09:57 <lbragstad> #action keystone team to review the TC vision statement for OpenStack Clouds
16:10:14 <lbragstad> i can send out reminder pings on Monday if people need a nudge
16:10:34 <lbragstad> just let me know - moving on
16:10:38 <lbragstad> #topic reviews
16:10:44 <lbragstad> does anyone have reviews up that need attention?
16:11:02 <lbragstad> wxy has a bunch of reviews up for domain_id support in unified limits
16:11:15 <lbragstad> speaking of wxy-xiyuan
16:11:17 <lbragstad> there he is
16:11:30 <lbragstad> caught him trying to sneak in late ;)
16:11:55 <wxy-xiyuan> Just online.
16:11:59 <cmurphy> o/
16:12:13 <vishakha> I have one https://review.openstack.org/#/c/627364/
16:12:36 <lbragstad> vishakha ah - i've seen that one come through a couples times
16:12:39 <lbragstad> i can take a look
16:12:46 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/domain-level-limit is the unified limit work
16:12:51 <vishakha> thanks
16:13:38 <lbragstad> i have a couple of questions on the configuration + keystone-manage commands for jwt
16:13:40 <lbragstad> #link https://review.openstack.org/#/c/628676/1
16:14:04 <lbragstad> otherwise - i was just going to take a stab at implementing whatever and see what people thoguht
16:14:39 * gagehugo looks
16:14:39 <lbragstad> i also have a pile of other reviews up
16:14:41 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles
16:14:56 <lbragstad> if anyone has questions on those - please don't hesitate to ask
16:15:33 <lbragstad> i realize it's a monster of a series, so i'm happy to make myself available for helping people understand the approach or answer questions
16:15:47 <gagehugo> something something of doom
16:15:58 <lbragstad> according to cmurphy, yeah
16:16:16 <lbragstad> does anyone else have reviews up that need attention?
16:18:14 * cmurphy nope
16:18:14 <lbragstad> alright - moving on
16:18:31 <lbragstad> #topic SFE for Renewable Application Credentials
16:18:42 <lbragstad> knikolla o/
16:18:46 <knikolla> o/
16:18:53 <knikolla> whatever the title says :)
16:19:13 <knikolla> any objections to a spec freeze exception?
16:19:15 <lbragstad> #link https://review.openstack.org/#/c/604201/
16:19:39 <lbragstad> looks like it's still pending some updates?
16:19:40 <knikolla> there has been some good feedback which i plan to incorporate, and then take it from there
16:20:02 <knikolla> but wanted to see if people were ok with this being done in stein before i spend the time on that
16:20:10 <cmurphy> how long do you think that will take? and then is there enough time to do the implementation?
16:20:13 <lbragstad> knikolla with the updates you plan to make, do you think you'll have something up code-wise in a couple weeks?
16:20:33 <knikolla> i think so.
16:20:36 <lbragstad> i think, based on the discussions we've had with people, there is agreement on the feature in general
16:21:03 <lbragstad> discussions at summit/ptgs
16:21:09 <cmurphy> after reading the spec I was actually a little confused on the need for the feature, which i documented in the comments
16:21:56 <knikolla> i think i responded to that?
16:22:14 <knikolla> we can rediscuss here though, plenty of time left in the meeting
16:22:50 <cmurphy> well do we need refreshable application credentials if using autoprovisioning instead of group mapping?
16:23:30 <knikolla> autoprovisioning does concrete role assignments, so if the users groups change in the external idp changes, the change will not be reflected in the users permissions
16:24:24 <lbragstad> #link https://review.openstack.org/#/c/604201/2/specs/keystone/stein/renewable-app-creds.rst@29
16:24:38 <lbragstad> in case you're following along at home
16:25:07 <lbragstad> we have always made the assumption that if people are doing concrete role assignments, they need to be prepared to clean up those resources
16:25:09 <knikolla> in case you want the permissions to expire if the user is disabled in the idp, or removed from idp groups, autoprovisioning won't work.
16:26:30 <cmurphy> okay
16:27:03 <lbragstad> cmurphy in your comment - you mention something about moving both federated implementations in the same direction?
16:29:15 <cmurphy> i think in rereading it now it makes a little more sense that they behave differently
16:29:22 <cmurphy> it seemed unintuitive at the time
16:30:24 <lbragstad> ok - is there anything else folks having regarding this?
16:30:48 <lbragstad> otherwise - we'll probably need to see an update to the spec before formally issuing a freeze exception
16:30:58 <lbragstad> (which we can do on the ML)
16:31:09 <knikolla> alright, cool :)
16:31:42 <lbragstad> anything else here?
16:32:11 <lbragstad> #topic open discussion
16:32:26 <cmurphy> I got here late but I did go through the technical vision
16:32:33 <lbragstad> cmurphy awesome
16:32:39 <lbragstad> thank you
16:32:48 <cmurphy> it seems like a lot of it applies to us, either with things we're already doing or working on or things we really should be doing
16:32:57 <cmurphy> i made some rough notes https://etherpad.openstack.org/p/keystone-technical-vision-notes
16:33:19 <cmurphy> can turn that into a vision document but probably won't have time for a while
16:34:11 <lbragstad> i didn't put my notes on etherpad - but i had a few of the same points
16:34:29 <lbragstad> especially with the whole self-service thing
16:35:37 <lbragstad> cmurphy already eluded too it, but is anyone opposed to using this as the basis for keystone vision statement?
16:36:00 <lbragstad> i know we tried doing something like this when we were in denver the first time around
16:36:15 <cmurphy> i think that was part of what julia asked for, wasn't it? to make a vision statement as part of our contributor guide?
16:36:29 <lbragstad> yes
16:37:11 <knikolla> what does a vision statement have to include exactly?
16:37:39 <lbragstad> it can be anything really
16:37:55 <cmurphy> i think the tc made it easy, we can copy bits and pieces from the technical vision that apply to us
16:38:05 <lbragstad> but - it should help us make decisions about the direction of the project and it should help people understand why keystone exists
16:39:03 <knikolla> how in depth should it be?
16:39:10 <knikolla> or mostly just a paragraph or two
16:39:33 <lbragstad> i think it should be deep enough to accurate relay the information we want to relay
16:39:39 <lbragstad> i don't think we have to follow guidelines for it
16:39:57 <lbragstad> and i would hate to constrict detail that would be useful because we have to keep it to 3 sentences
16:40:21 <lbragstad> i would say - let's go through cmurphy's notes and come up with *something*
16:40:30 <lbragstad> and then we can copy-edit it into something more concise
16:40:31 <cmurphy> if i was writing it i would start with just a few sentences on each point describing how we're meeting or planning on meeting that part of the vision
16:40:39 <vishakha> The vision should be based on the these highlights like self service, applcation control etc?
16:40:57 <cmurphy> those are pulled from the statements in the tc technical vision
16:41:43 <vishakha> ok Great.
16:41:58 <cmurphy> we can add more to it if we have thoughts and ideas that aren't encompassed by the tc vision
16:42:16 <lbragstad> exactly
16:42:20 <vishakha> Yes I was about to ask this :)
16:42:29 <lbragstad> the TC wants to encourage that, too
16:42:49 <lbragstad> even if it doesn't completely jive with the TC vision
16:44:47 <lbragstad> if we see something that isn't in the TC vision, but we think it applies to keystone, then we should talk about it and document it - it might be reusable and worked into the TC vision
16:45:36 <cmurphy> ++
16:45:47 <vishakha> ok thanks for the info
16:46:18 <lbragstad> we'll still plan to follow-up on this next week
16:46:42 <lbragstad> i assume we can just keep using cmurphy's etherpad for additional notes
16:46:55 <cmurphy> sure
16:47:18 <lbragstad> cool  - thanks for kicking starting that
16:47:28 <lbragstad> does anyone else have anything for open discussion?
16:47:54 <lbragstad> does anyone know when kmalloc gets back from his forever-long hiatus?
16:49:01 <cmurphy> i think he said 17th?
16:49:10 <lbragstad> sweet
16:50:31 <lbragstad> in other news - i filled out the survey from the foundation about the PTG
16:50:45 <lbragstad> i used a ceiling estimate based on our last PTG
16:51:00 <lbragstad> i also said that we'd like to have 3 days
16:51:13 <lbragstad> but would probably be fine if we had 2 or 2.5 to get through all of our keystone topics
16:51:33 <lbragstad> if anyone disagrees, let me know and I'll see if i can amend my submission
16:52:17 <cmurphy> i think 2.5-3 is good if we're going to use forum time for cross-project things that we would usually have had the first two days of ptg
16:52:37 <knikolla> ++
16:52:47 <lbragstad> i also expect we will be working with the edge group - which i would expect to have their own room, like in denver
16:54:07 <lbragstad> but that could be done in the forum, too i suppose
16:54:43 <lbragstad> if there isn't anything else - we can wrap up
16:56:16 <lbragstad> thanks for the time, everyone
16:56:19 <lbragstad> #endmeeting