16:00:04 <lbragstad> #startmeeting keystone
16:00:05 <openstack> Meeting started Tue Jun 12 16:00:04 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:07 <lbragstad> ayoung, breton, cmurphy, dstanek, gagehugo, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy, sonuk
16:00:08 <openstack> The meeting name has been set to 'keystone'
16:00:16 <hrybacki> o/
16:00:23 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:00:26 <lamt> o/
16:00:27 <sonuk> o/
16:00:38 <wxy|> o/
16:00:46 <ayoung> Oyez oyez
16:00:50 <knikolla> o/
16:00:55 <kmalloc> o/
16:01:11 <cmurphy> o/
16:01:45 <gagehugo_> o/
16:02:24 <lbragstad> #topic Announcements
16:02:35 <lbragstad> #info Specification freeze is in effect
16:02:41 <lbragstad> last friday was rocky-2
16:02:52 <lbragstad> so - we're past the specification deadline
16:03:02 <lbragstad> and with that
16:03:10 <lbragstad> #info feature freeze is in a month
16:03:55 <lbragstad> #topic Reviews
16:04:15 <lbragstad> there are several efforts/specifications that are in need of feedback
16:04:49 <lbragstad> jgrassler: has asked for early feedback on the migration for app creds
16:04:54 <lbragstad> #link https://review.openstack.org/#/c/572776/
16:05:12 <lbragstad> hrybacki: has been working on the default roles support, which is ready for reviews now that tempest is passing
16:05:17 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:basic-default-roles
16:05:26 <lbragstad> wxy|: has a bunch of things up for unified limits
16:05:34 <lbragstad> #link https://review.openstack.org/#/q/topic:bp/unified-limits+status:open
16:05:40 <lbragstad> #link https://review.openstack.org/#/q/topic:bp/strict-two-level-model+status:open
16:05:45 <lbragstad> #link https://review.openstack.org/#/q/topic:bug/1754184+status:open
16:05:50 <lbragstad> #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/unified-limit-improve
16:06:08 <lbragstad> and there is a patch up for MFA receipts
16:06:13 <lbragstad> #link https://review.openstack.org/#/c/572776/
16:06:24 <lbragstad> so - plenty of things to review
16:06:48 <hrybacki> :)
16:07:01 <lbragstad> does anyone else have things to share as far as feature/spec reviews?
16:07:08 <lbragstad> or specific reviews to call out?
16:07:29 <kmalloc> to unblock the triple-o folks we need eyes on https://review.openstack.org/#/c/574735/
16:07:55 <wxy|> and this one yaml catalog backend: https://review.openstack.org/#/c/483514/
16:08:06 <ayoung> I guess that means me
16:08:06 <kmalloc> the flask-conversion dispatching support caused an issue with JSON Home on / (I also need to add an added test)
16:08:51 <ayoung> and you hrybacki
16:09:05 <ayoung> need a non RH er to look at is as well.  We should remember that rule
16:09:23 <lbragstad> i have the flask reviews pulled up, i can take a look too
16:09:28 <hrybacki> always a best practice
16:09:54 <kmalloc> ayoung: it's not really a "rule" due to small(er) numbers of cores. but all added eyes, red hat or not are welcome
16:10:15 <ayoung> kmalloc, yeah.  Just realized how the dynamic has changed.  Any IBMers left?
16:10:28 <kmalloc> Henry is still core
16:10:54 <lbragstad> henry posted to the mailing list last week
16:11:00 <ayoung> and stevemar does drivebys...ok
16:11:30 <knikolla> been looking at that patch for the last half-hour, took me a bit to decrypt the router composition
16:11:40 <lbragstad> http://lists.openstack.org/pipermail/openstack-dev/2018-May/130854.html
16:11:51 <kmalloc> ah henry has said he's hanging up his core status.
16:11:58 <ayoung> knikolla, yeah, I can see how that is funky.
16:12:17 <ayoung> I guess I've been deep enough in it.
16:12:19 <kmalloc> the router composition stuff is ... dense
16:12:22 <knikolla> ayoung: It's routers all the way down!
16:12:25 <ayoung> Heh
16:12:30 <kmalloc> it's all going away
16:12:48 <kmalloc> but it's a slow roll to go away- losing the composing router code is a win.
16:12:55 <ayoung> Yes
16:13:12 <ayoung> there was another flask side effect I just saw
16:13:12 <knikolla> \o/
16:13:23 <ayoung> https://review.openstack.org/#/c/568377/
16:13:33 <ayoung> no not that
16:13:34 <ayoung> one sec
16:14:01 <ayoung> ah, yes...last comment there:
16:14:09 <ayoung> after transition to flask:-
16:14:09 <ayoung> below unversioned url is not working:-
16:14:09 <ayoung> python -c "import requests,json;r=requests.get('http://<ip>:5000',verify=False,headers={'Accept': 'application/json-home'});print(r.content)"
16:14:09 <ayoung> versioned one works:-
16:14:09 <ayoung> python -c "import requests,json;r=requests.get('http://<ip>:5000/v3',verify=False,headers={'Accept': 'application/json-home'});print(r.content)"
16:14:20 <ayoung> need to bump that to its own bug
16:14:21 <lbragstad> ayoung: kmalloc has a patch up to fix that
16:14:27 <kmalloc> right, that is bug https://bugs.launchpad.net/keystone/+bug/1776506
16:14:28 <openstack> Launchpad bug 1776506 in OpenStack Identity (keystone) "Keystone JSON HOME on / fails" [High,In progress] - Assigned to Morgan Fainberg (mdrnstm)
16:14:31 <ayoung> cool
16:14:37 <kmalloc> and closed by https://review.openstack.org/#/c/574735/
16:14:46 <kmalloc> but https://review.openstack.org/#/c/574735/ needs another test to ensure we don't regress.
16:14:53 <ayoung> ++
16:14:56 <kmalloc> i'll get that test post meeting
16:15:00 <kmalloc> and expand commit message
16:15:09 <ayoung> OK
16:15:15 <kmalloc> ayoung: that is the triple-o blocking bug, btw
16:15:28 <ayoung> +2 from me.
16:15:45 <kmalloc> my plan is to add a test but otherwise leave the code as is, extra eyes are welcome to ensure the code is good
16:16:03 <kmalloc> i can rebase it off the chain i think, but it's in a flask chain right now.
16:16:11 <kmalloc> so it has parent patches.
16:16:57 <ayoung> lbragstad, of the ones you posted above, what is burining?
16:17:29 <lbragstad> hmm
16:17:33 <lbragstad> that's a tough questions
16:17:42 <lbragstad> because i'm inclined to say everything :)
16:17:45 <ayoung> Ha
16:17:53 <lbragstad> IMO - the unified limits stuff needs eyes
16:17:59 <lbragstad> because it's a lot of moving pieces
16:18:13 <lbragstad> same with default roles
16:18:29 <lbragstad> there isn't a ton up for review for app creds or MFA receipts, yet...
16:18:34 <lbragstad> but early feedback is always valuable
16:19:52 <lbragstad> i'm also going to be spending a bunch of time working on unified limit support in the clients, so that should help people if they want to test manually
16:20:25 <kmalloc> please review the client parts of limits, there are few people with experience in clients, at least this gets folks familiar with it.
16:20:48 <kmalloc> and anything default roles.
16:21:00 <kmalloc> the other things are smouldering vs outright on fire :)
16:21:08 <lbragstad> yeah - we're going to have a lot of patches queued up for default role usage after that patch lands
16:21:36 <hrybacki> please help me make sure I'm covering bases with those tests
16:21:37 <ayoung> hrybacki, on the default roles. The code as is looks good.  BUt, have we done the "how will we resolve conflicts?"  analysis if, say a role exist but is not in the config file or something?
16:21:57 <hrybacki> ayoung: in an automated fashion?
16:22:16 <ayoung> hrybacki, lets start with "written down somewhere" first
16:22:30 <hrybacki> ayoung: in the spec, yes
16:22:43 <hrybacki> and will likely be in release note verbage
16:22:49 <ayoung> OK, so we've asked "how can someone break default roles."  THos need to end up in the tests somehow
16:23:29 <hrybacki> good point
16:24:58 <ayoung> All we are doing is creating the role if it does not exist.  That should not break anything
16:25:13 <lbragstad> right
16:25:25 <ayoung> we have not yet done the "banana test" as that is outside the scope.  Ok.  I think I can endorse this patch
16:25:42 * lbragstad has no idea what a banana test is
16:26:03 <ayoung> lbragstad, that was from the summit
16:26:20 <ayoung> the guy from....Verison?  had a test where he creaded a role called banana
16:26:24 <ayoung> and assigned it to  user
16:26:38 <ayoung> since no policy was written to use that role, it should have had 0 effect
16:26:51 * hrybacki comes back from internal convo reads up
16:26:55 <ayoung> if it allowed the user to perform some operation, "it slipped on the banana"
16:27:11 <hrybacki> Verizon or AT&T (felipe?)
16:27:23 <lbragstad> lol
16:27:29 <lbragstad> that's clever
16:27:32 <ayoung> Wanna say it was Verison
16:27:45 <ayoung> lbragstad, yeah, I want that in Tempest
16:28:28 <ayoung> anything else burninating?
16:28:45 <ayoung> Oh, on default roles
16:28:49 * hrybacki ayoung american politics are burninating
16:28:49 <lbragstad> i think those are the main ones
16:28:51 <kmalloc> well, by default, remember *any* role on a project allows some level of access
16:28:55 <ayoung> do we want to add a rule that says "admin implies memeber?"
16:29:08 <kmalloc> it's the core concept of what "member" was.
16:29:11 <ayoung> except spelled right
16:29:13 <knikolla> in the current state yes
16:29:20 <kmalloc> so, i'm not surprised banana allowed that.
16:29:33 <knikolla> but I assume we want to fix that with default roles
16:29:38 <hrybacki> ayoung: can we do implications in policy files?
16:29:46 <kmalloc> that's a hard fix knikolla, but i'd like to seethat fixed
16:29:59 <ayoung> hrybacki, yes, but it is messy
16:30:09 <ayoung> role:member or role:admin becomes a rule
16:30:27 <ayoung> and then rule:member:  role:memeber or role:admin
16:30:31 <knikolla> hrybacki: but i don't think you need to. keystone will expand implications on token validation IIRC.
16:30:36 <hrybacki> ah, interesting. I didn't realize you could do that
16:30:39 <ayoung> and then update the various rules...it is messy
16:30:51 <ayoung> knikolla, it is a config option to expand
16:30:51 <knikolla> so you only need member in the policy file.
16:30:57 <knikolla> ayoung: argh.
16:31:12 <ayoung> on by defualt
16:31:16 <ayoung> we gave them an opt out
16:31:20 <hrybacki> my next question ^^
16:32:24 <ayoung> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/conf/token.py#n114
16:32:47 <ayoung> on by default: [token] infer_roles = True
16:32:53 <knikolla> can we deprecate and eventually remove that option?
16:32:58 <ayoung> Yes
16:33:21 <kmalloc> we can deprecate and remove a bunch of the token revoke options.
16:33:24 <kmalloc> but that one, definitely
16:33:26 <ayoung> knikolla, oh yes
16:34:27 <knikolla> Remove in S? T?
16:34:48 <kmalloc> the net impact of just dropping the option on the floor is effectively zero
16:34:50 <lbragstad> i think S would be too soon to remove it
16:35:01 <kmalloc> we could just deprecate and never reference it.
16:36:04 <ayoung> So, one reason that was in there was if we were going to generate the policy files from the keystone side.  I think we are safe in saying we are not going to do that
16:36:15 <kmalloc> ++
16:36:30 <ayoung> If we generated the policy, then it would be more efficient to expand implied roles in the policy file.
16:38:25 <lbragstad> does anyone have anything else regarding reviews or specs?
16:38:44 <lbragstad> otherwise i'll switch to open discussion
16:40:16 <lbragstad> #topic open discussion
16:40:35 <lbragstad> floor is open if anyone has anything they'd like to talk about
16:41:29 <hrybacki> I think you are all swell people. EoM
16:42:23 <lbragstad> ha
16:42:47 <kmalloc> <success command omitted> hrybacki is a positive influence on the keystone community (he always was, but specifically told everyone they are swell)
16:43:00 <hrybacki> lol
16:43:08 <knikolla> \o/
16:43:16 <hrybacki> o/\o
16:43:32 <hrybacki> angry bird or high five, the real topic of discussion
16:44:02 <kmalloc> ^  ^
16:44:02 <kmalloc> o/\o
16:44:49 <kmalloc> (^_^)/\(^_^)
16:44:53 <kmalloc> ^5
16:44:56 <lbragstad> sounds like we can get some time back before office hours
16:45:07 <hrybacki> :)
16:45:33 <lbragstad> thanks for coming!
16:45:38 <lbragstad> #endmeeting