16:00:22 <cmurphy> #startmeeting keystone
16:00:27 <openstack> Meeting started Tue Mar 12 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:31 <openstack> The meeting name has been set to 'keystone'
16:00:41 <vishakha> o/
16:00:42 <hrybacki> o/
16:00:57 <cmurphy> lbragstad has a conflicting meeting
16:01:06 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:01:20 <cmurphy> feel free to add things to the agenda
16:01:20 <lbragstad> o/
16:01:26 * lbragstad lingers in the back
16:01:31 <gagehugo> o/
16:02:48 <knikolla> o/
16:03:00 <ayoung> o/
16:03:05 <cmurphy> #topic announcements
16:03:14 <cmurphy> #info RC1 target week next week
16:03:21 <cmurphy> #link https://releases.openstack.org/stein/schedule.html release schedule
16:03:23 <ayoung> How'r we looking?
16:03:30 <cmurphy> pretty good i think
16:03:43 <cmurphy> i started going through bugs and marking them for rc1
16:04:30 <lbragstad> cmurphy are there any major ones on your radar after doing that?
16:05:05 <cmurphy> #link https://launchpad.net/keystone/+milestone/stein-rc1 Stein-RC1 bugs
16:05:43 <lbragstad> nice - i'm happy to see 1819036 made the target
16:05:53 <cmurphy> lbragstad: I targed some of the rbac ones for rc1, especially the ones marked high priority or already in progress
16:06:05 <kmalloc> mmmmmmm
16:06:10 <kmalloc> cooooofffffffffffffeeeee time.
16:06:17 <kmalloc> also... grump at time change.
16:06:17 <cmurphy> yeah that one was one i noticed too while working on the access rules token validation
16:06:38 <cmurphy> also #1817313 may be one kmalloc could have a look at
16:06:44 <lbragstad> validating tokens twice you mean?
16:06:48 <cmurphy> lbragstad: right
16:07:00 <ayoung> Wouldn't app creds be more important than some of the others/
16:07:01 <kmalloc> is that a LP bug?
16:07:01 <ayoung> ?
16:07:16 <kmalloc> ah yeah it is.
16:07:17 <lbragstad> i remember dolph and i noticed that when we benchmarked keystone in public cloud in 2015, but we never dug into it
16:07:53 <cmurphy> hmm if it's been like that since 2015 then maybe not a good target for stein
16:08:06 <cmurphy> or not a top priority anyway
16:08:14 <lbragstad> it's been around for a while for sure
16:08:20 <knikolla> true
16:08:20 <kmalloc> the double validation is from when we converted over to KSM
16:08:23 <lbragstad> the fix *seems* trivial?
16:08:29 <kmalloc> it's really not a huge priority
16:08:36 <kmalloc> especially with caching.
16:08:42 <kmalloc> but we can totally land it for stien
16:08:48 <kmalloc> it is not a big deal either way
16:09:05 <lbragstad> i think tim recording a 23% performance improvement
16:09:09 <lbragstad> with caching configured
16:09:14 <lbragstad> recorded*
16:09:16 <kmalloc> with caching properly configured?
16:09:20 <lbragstad> yeah
16:09:22 <kmalloc> that seems high.
16:09:30 <lbragstad> he has some pretty extensive performance numbers
16:09:49 <lbragstad> they're trying to get keystone as fast as possible, including benchmarks under pypy
16:09:50 <kmalloc> if he was using py-spy i found py-spy abnormally increases performance "increase" numbers when used.
16:10:04 <kmalloc> because of the heavy intropection.
16:10:11 <cmurphy> feel free to change the target on any of these if you don't think it's appropriate for rc1, and help with triaging the rest of the bug list is welcome
16:10:21 <kmalloc> if it was another benchmark it's probably closer to real
16:10:29 <lbragstad> fwiw - i noticed a similar performance improvement but i based it on raw timing
16:10:54 <lbragstad> ( i didn't use repoze, py-spy, or anything like that)
16:11:01 <kmalloc> there is crypto activity
16:11:11 <kmalloc> so, sure, like i said, we can totally land it
16:11:28 <kmalloc> my view is it is fairly trivial change if we pass all testing
16:12:13 <lbragstad> ack - i need to test it, but i was going to attempt that with a mock (shrug)
16:12:22 <kmalloc> re bug 1817313 - this looks like lack of testing bit us.
16:12:23 <openstack> bug 1817313 in OpenStack Identity (keystone) "RBAC Enforcer Programming Error raised for malformed federation protocol request" [High,Triaged] https://launchpad.net/bugs/1817313
16:12:45 <kmalloc> or well lack of voting testing.
16:12:48 <kmalloc> at least
16:13:16 <kmalloc> and that should be a 400 probably not a 404.
16:13:53 <ayoung> Malformed request
16:14:04 <kmalloc> yeah, it's a bad request afaict
16:14:18 <ayoung> Agreed
16:14:35 <kmalloc> also, using paste as a link in the LP bug is a bad idea, paste may purge the data
16:14:42 <ayoung> /opt/stack/keystone/keystone/server/flask/common.py", line 153, in _assert_rbac_enforcement_called
16:14:44 <kmalloc> we should ensure to capture the paste data as an attachment.
16:14:50 <ayoung> on it
16:14:54 <kmalloc> i'll cover that
16:15:01 <kmalloc> ayoung: ^ working on it already
16:15:15 <cmurphy> I'll remember that for next time
16:15:28 <cmurphy> I just don't like putting logs in the bug description
16:15:43 <kmalloc> cmurphy: totally
16:15:46 <ayoung> yeah, but next comment is ok, right?
16:15:57 <kmalloc> cmurphy: i wouldn't put it in the description either :)
16:16:02 <kmalloc> ayoung: yep.
16:16:26 <cmurphy> anything else on bugs or questions about the RC?
16:16:59 <kmalloc> that one should be pretty easy to fix fwiw.
16:17:44 <kmalloc> it's just routing some data to the handler in a way that the name is missing from the put
16:18:05 <kmalloc> it is probably a mis-matched routing rule actually.
16:18:31 <ayoung> It looks like a Flaskism
16:20:10 <cmurphy> #topic Technical Vision/Mission Statement draft
16:20:19 <cmurphy> #link https://review.openstack.org/641374 technical vision draft
16:20:28 <cmurphy> the commit message explains what this is about
16:20:59 <cmurphy> right now it's mostly a mirror of the TC's technical vision document, but i think we should feel free to change it into whatever format makes sense for the keystone team
16:21:18 <cmurphy> would like some eyes from the team before I ask the TC for feedback
16:21:19 <kmalloc> yep, https://github.com/openstack/keystone/blob/master/keystone/api/os_federation.py#L161 that needs to probably be split out into it's own resource
16:21:30 <kmalloc> i'll add it to the bug
16:21:39 <cmurphy> thanks kmalloc
16:23:12 <cmurphy> any questions about the vision document? we can discuss on the review, mostly just wanted to make it known that it was in progress
16:23:48 <kmalloc> vision doc looked good at the first pass
16:23:55 <kmalloc> i need to do a deeper read
16:23:58 <lbragstad> i agree
16:24:06 <lbragstad> about it looking good
16:24:23 <lbragstad> i've parsed it a couple times and i don't have anything constructive to add
16:24:25 <kmalloc> but i didn't see anything that was "OMG wrong" that i would hold up the merge on
16:24:36 <cmurphy> sweet
16:24:43 <cmurphy> deeper reading will be appreciated
16:25:24 <vishakha> Yes it is a good read. Thanks cmurphy for it.
16:25:56 <cmurphy> :)
16:26:03 <cmurphy> #topic RBAC work
16:26:09 <cmurphy> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003552.html
16:26:15 <cmurphy> lbragstad: floor is yours
16:26:23 <lbragstad> ok - this will be quick
16:26:30 <lbragstad> but last week we talked about this in the meeting
16:26:59 <lbragstad> but we didn't really have an exact bead on where things were with all the bugs/work we have in flight for scope types and reader role work
16:27:09 <lbragstad> that email is an attempt at sharing that
16:27:40 <lbragstad> i think it's safe to assume that we're not going to get all scope types and default role work done in stein :(
16:28:05 <lbragstad> so - i'm curious if people want to weigh in on what we should prioritize, if anything, for the next two weeks for reader role and scope types work
16:29:46 <cmurphy> looking at https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope it's interesting that they're all marked high priority except for two?
16:30:01 <lbragstad> yeah... that could probably be adjusted
16:30:12 <vishakha> I have started on grant API, and role_assignment is in mid-way due to some tempest test cases failing
16:30:29 <lbragstad> i was probably a little over zealous in marking priority for those
16:31:25 <cmurphy> lbragstad: you came to an agreement with gmann that will let us move forward on some of them? (was it domain reader?)
16:31:39 <lbragstad> yeah - i can fill people in there
16:31:41 * lbragstad grabs a link
16:32:23 <lbragstad> we were having a whole bunch of issues with tempest and domain reader functionality for projects
16:32:25 <lbragstad> #link https://review.openstack.org/#/c/624218/8
16:32:38 <lbragstad> ^ that patch is where we start incorporating domain default roles
16:32:58 <lbragstad> the problem is due to a tempest setting that assumes people with domain role assignments are actually system/cloud administrators
16:33:44 <lbragstad> the tempest test was creating projects in a domain that the domain admin didn't have authorization on, but the test asserts that user can list all projects in that domain, even though they don't have any authorization there
16:34:10 <lbragstad> which, i assume we can agree that isn't what we want
16:34:42 <lbragstad> so gmann put up a patch to tempest that corrects the test cases to use the proper domain, instead of creating a new domain https://review.openstack.org/#/c/642102/
16:35:05 <lbragstad> so it updates things to work with domain-scope, the way we (in keystone) expect domain scope to work
16:35:17 <lbragstad> ^ that fix is specific to project resource tests in tempest
16:35:41 <lbragstad> but we will likely have to take a very similar approach to get https://review.openstack.org/#/c/623319/7 passing
16:38:19 <cmurphy> sounds good
16:38:53 <cmurphy> personally I'll prioritize reviewing and merging the things that are already in progress, i think that's easily achievable
16:39:12 <lbragstad> ++
16:39:16 <lbragstad> i agree
16:39:27 <lbragstad> i think it would be amazing if we could get projects and users done
16:39:44 <cmurphy> i think it's also not unreasonable to get these four that aren't started yet done https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope
16:40:07 <cmurphy> but https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles may be a bit more work than we can manage
16:40:26 <vishakha> thanks lbragstad cmurphy
16:40:36 <lbragstad> the default roles work impacts every api, where as scope work is specific to a few areas
16:41:01 <lbragstad> so - i'm happy to punt limits scope work until Train
16:41:16 <lbragstad> people aren't using it yet, and it would be nice to get oslo.policy support for that weird edge case we hit
16:41:33 <lbragstad> but i'll defer to whatever the team wants to do
16:41:39 <cmurphy> wfm
16:43:08 <cmurphy> #agreed prioritize reviewing and merging in-progress system scope and reader role work
16:43:18 <cmurphy> #agreed punt limits scope work till Train
16:43:49 <cmurphy> anything else on this topic?
16:43:51 <lbragstad> if anyone has questions or wants to divvy up work, let me know
16:44:03 * lbragstad is done
16:45:05 <cmurphy> #topic reviews
16:45:22 <cmurphy> any other reviews people want eyes on?
16:46:16 <cmurphy> #link https://review.openstack.org/#/c/638563/ scope documentation for devs
16:46:20 <cmurphy> from lbragstad ^
16:48:19 <cmurphy> I don't have anything to call out
16:48:51 <lbragstad> people could throw suggestions for testing on https://review.openstack.org/#/c/641499/ if they want
16:49:28 <cmurphy> #link https://review.openstack.org/#/c/641499/ validating tokens only once
16:50:58 <cmurphy> #topic open discussion
16:51:04 <cmurphy> floor is open
16:52:04 <lbragstad> when do we want to start formalizing the PTG schedule?
16:52:49 <cmurphy> #link https://etherpad.openstack.org/p/DEN-keystone-forum-sessions forum/ptg topic brainstorm
16:53:15 <cmurphy> probably in the next couple of weeks i guess
16:53:15 <kmalloc> i need to book a flight... or plan to drive out to the PTG.
16:53:32 <cmurphy> i still need to do that too
16:53:41 <lbragstad> i'm booking the marathon week special
16:53:52 <lbragstad> i get in on the 27th and leaving the following saturday
16:54:03 <cmurphy> i am going to be toast by the end
16:54:20 <kmalloc> depending on when the talk we're giving is...
16:54:25 <kmalloc> i might skip the first part of the summit.
16:54:43 * cmurphy will be breaking new barriers in caffeine consumption
16:54:56 <vishakha> lol
16:55:02 <kmalloc> cmurphy: should we all chip in to pre-ship a couple extra flats of the monster for you?
16:55:16 <cmurphy> ;)
16:55:34 <lbragstad> lol
16:55:49 <cmurphy> btw please keep adding to the ptg topic brainstorm if there are things you want to talk about
16:56:24 <lbragstad> also - cross-project sessions might be tough to schedule
16:56:34 <lbragstad> just because we have less time
16:56:35 <cmurphy> yeah
16:57:29 * lbragstad thinks divide and conquer is going to be the name of the game this time
16:57:38 <kmalloc> FWIW, I'm really not looking forward to the week-long thing
16:57:53 <cmurphy> lbragstad: how many cross-project topics do you have in mind that aren't already forum sessions?
16:58:03 <lbragstad> well - that's a good question
16:58:12 <lbragstad> some seems like they could use both?
16:58:43 <lbragstad> i mean, traditionally, we have forum sessions to tailor the content towards the user community and operators
16:58:49 <cmurphy> i sorta feel like with the condensed time we're gonna have to limit cross-project things to forum sessions
16:59:06 <cmurphy> 1 minute warning
16:59:27 <lbragstad> the PTG are so developer specific, i fear consolidating both groups into a forum session is going to overrun content
16:59:43 <cmurphy> fair
16:59:45 <lbragstad> (e.g., we'll focus on design things, or we'll focus on operator communication)
17:00:03 <cmurphy> definitely the time with the qa team will be worth having as a ptg session rather than forum session
17:00:08 <cmurphy> anyways
17:00:08 <lbragstad> ++
17:00:11 <cmurphy> #endmeeting