16:00:36 #startmeeting keystone 16:00:36 Meeting started Tue Apr 17 16:00:36 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:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:40 The meeting name has been set to 'keystone' 16:00:45 ping ayoung, breton, cmurphy, dstanek, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy, sonuk 16:00:48 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:00:51 agenda ^ 16:01:01 o/ 16:01:04 o/ 16:01:08 o/ 16:01:09 o/ 16:01:21 o/ 16:01:37 o/ 16:01:49 we're going to have a pretty good crew todya 16:02:02 we'll give everyone a couple more minutes 16:02:41 o/ 16:02:47 o/ 16:03:44 cool - let's get started 16:03:52 o/ 16:03:56 #topic YVR forum topics 16:04:03 #link #link https://etherpad.openstack.org/p/YVR-keystone-forum-sessions 16:04:07 #undo 16:04:07 Removing item from minutes: #link https://etherpad.openstack.org/p/YVR-keystone-forum-sessions 16:04:09 #link https://etherpad.openstack.org/p/YVR-keystone-forum-sessions 16:04:27 so - i ended up taking what we had on that etherpad and creating submissions for them 16:04:46 which really just ended up being the same topics we usually bring to the forum 16:05:00 heh 16:05:08 I've linked each submission in the etherpad 16:05:47 please feel free to give them a once over or leave comments 16:05:55 hrybacki :( 16:05:57 but right now, the forum window is closed 16:06:01 :( 16:06:04 hrybacki: that sucks 16:06:17 I honestly doubt RH will ever send me to a summit 16:06:32 unless I have a presentation 16:07:04 But I think PTGs are of more value (at least considering my role with y'all) 16:07:41 i have mixed feelings on that front, but probably best to get into that another time :) 16:08:11 does anyone have anything else on forum topics? 16:08:59 lbragstad: thanks for your proposal for unified limits. I won't be there as well. :( 16:09:18 wxy|: :( ack 16:09:18 Regarding application credential capabilities: we could have one, I suppose. Not sure if it is needed, though... 16:09:56 jgrassler: yeah - it cross my mind and i asked cmurphy about it over the weekend (not sure if you saw my ping) 16:10:06 I don't feel like we have that much to talk about on it since the PTG 16:10:20 that and nearly all the work it contained within keystone projects 16:10:20 lbragstad: I saw it but forgot replying - which is why I'm chiming up right now :-) 16:10:38 s/it/is/ 16:11:43 i think limits are going to be the big one 16:11:50 * lbragstad needs to start on the oslo.limit library soon 16:12:56 alright - let's move on to specification and if we have anything regarding forum topics afterwords we can revisit 16:12:56 yeah, I have registered oslo.limit on pypi. Once the patch for CI job is merged, we can start to code. 16:13:05 wxy|: i need to resubmit that patch today 16:13:11 #topic specifications 16:13:14 at least for flat model IMO. 16:13:21 #info the application credential spec merged 16:13:28 thanks jgrassler! 16:13:29 woot! 16:13:41 looking forward to reviewing the code for that 16:13:53 we do have a few specs left that need attention 16:14:00 default roles 16:14:06 #link https://review.openstack.org/#/c/523973/ 16:14:14 JWT 16:14:15 #link https://review.openstack.org/#/c/541903/ 16:14:21 and limits 16:14:24 #link https://review.openstack.org/#/c/540803/ 16:14:26 #link https://review.openstack.org/#/c/549766/ 16:14:37 the default roles specification is looking really good imo 16:14:38 so question -- how/when do the rolecall votes get initiated for openstack-specs ? 16:15:06 might be worth a -dev list email to [all] 16:15:20 or at least some tag broader than [keystone] 16:15:20 ack 16:15:43 does anyone want to volunteer to send that note? 16:16:03 * hrybacki shies away 16:16:46 i can do it in between the meeting and office hours 16:16:53 #action lbragstad send note to openstack-dev mailing list to get info on openstack/specs process 16:17:24 we still need some eyes on the hierarchical limit specs and the JWT specification 16:17:26 thanks for providing comfort to my imposter syndrome demons lbragstad :) 16:17:53 hrybacki: oh - i'll mention you in the note ;) 16:18:14 * hrybacki deletes his email account, wipes his computer, heads for the woods 16:18:30 knikolla: and I are planning on digging back into the JWT details during office hours 16:18:56 * cmurphy will start looking at it too 16:19:19 * gagehugo ditto 16:19:24 hopefully the discussion will result in a new patch for the spec that addresses some of the decision we need to make there 16:20:08 does anyone have questions or comments on what we have left in review for Rocky specifications? 16:20:12 FYI, for unified limit, I have merged most of John's into mine to leave it easier for review. 16:20:21 wxy|: oh - awesome 16:20:39 wxy|: does johnthetubaguy_ know about the changes in your proposal? 16:20:55 I left comment in the spec. 16:20:59 o/ sorry a little late 16:21:16 wxy|: awesome - thanks 16:21:42 apparently there are people from CERN interested in that specification, it'd be nice to know who they are 16:22:38 i'll make a point to revisit your spec wxy| 16:22:46 anything else on specs? 16:24:12 #topic identity provider & domain relationships 16:24:18 #link https://review.openstack.org/#/c/559676/5 16:24:40 i have some questions on https://launchpad.net/bugs/1760843 16:24:41 Launchpad bug 1760843 in OpenStack Identity (keystone) "Identity Provider domain is not unique" [Undecided,In progress] - Assigned to wangxiyuan (wangxiyuan) 16:25:18 the current proposal changes the API to return a 201 instead of a 409, but i'm wondering if people have other thoughts on how we can handle this 16:26:24 for some background context - the original implementation of associating a domain to an identity provider described the relationship as one to one 16:26:33 but that's not really the case 16:26:37 #link https://review.openstack.org/#/c/399684/ 16:28:21 so - the question is, what we do want the relationship between domains and identity providers to be? 16:29:30 I like the simplicity of 1-1. But what’s the use case for other types of relationships 16:29:49 i remember an operator in boston asking for one to many 16:29:58 one domain to many identity providers 16:30:25 i suppose you could have customers with multiple sources of identity that you want to keep within the same domain 16:31:20 also - the migration to make that real is going to be pretty intense and pretty long 16:31:32 since today you can associate a domain to multiple idps 16:31:42 That can be accomplished by brokering the idps 16:32:00 if it's not really hurting anything terribly and changing it would break the API then it seems pretty clear to me that we shouldn't change it 16:32:53 cmurphy: is "it" in your statement introducing the 1:1 mapping or leaving everything alone? 16:33:52 hmm i said a lot of "it"s, my point was we should probably leave everything alone and not break the API 16:34:01 ok 16:34:33 hey, the new patch set will not break the API 16:35:05 just fixed the sql model which is not the same with db schema 16:35:20 #link https://review.openstack.org/#/c/559676/5/keystone/tests/unit/test_v3_federation.py@1016 16:36:21 if i'm understanding the patch correcty, aren't we returning a 201 when we used to return a 409? 16:36:37 the test code was wrong because our unit test use sql model to init the db schema 16:37:01 ohhhh 16:37:08 So that the domain_id is unique in test code. 16:37:18 But it's not in the real db 16:37:37 okay that makes more sense 16:38:20 good call wxy| 16:38:36 ok - i'll make a point to pull that down locally and test it again 16:38:50 ok 16:38:54 so - in short 16:38:57 the API isn't changing 16:39:16 and we're still allowing a domain to be associated to multiple identity providers 16:39:51 yeah. If we want 1:1, then it's another task. 16:40:07 and that would require a migration and it would be backwards incompatible 16:40:15 which was done in Patch Set 2. 16:40:16 ++ 16:40:21 cool 16:40:50 this at least makes the migration consistent with the model 16:40:56 which is something that we should do too i suppose 16:41:43 that clears things up, thanks 16:41:54 moving on unless we have more questions related to this 16:42:34 #topic m1 approaches 16:42:37 hrybacki: o/ 16:42:40 o/ 16:42:51 tl;dr we discussed having retrospectives after each milestone 16:43:05 if folks are still on board, I want to set aside an hour during next week's office hours todo so :) 16:43:19 to do* 16:43:26 sure 16:43:40 would we be opposed to having it before the meeting so that our apac contributors can attend? 16:43:51 good call 16:44:01 would that be too early for kmalloc ? 16:44:05 I believe lower constraint is kmalloc ? 16:44:09 cmurphy++ 16:44:39 I can be there during office hours. 16:44:51 * lbragstad wouldn't be opposed to just using the normal meeting time if that's the only common time 16:45:11 versus forcing kmalloc to attend early and making wxy| stay really late 16:45:22 during meeting might be best imo 16:45:47 dnm to me. I'll be ready to rock regardless 16:46:50 i'll defer to wxy| and kmalloc 16:47:08 lbragstad: That's OK. I can go to bed one or two hours later. :) 16:47:14 anytime works for me 16:47:22 wxy| is a night owl :P 16:47:32 apparently :) 16:48:07 I won't make before meetings 16:48:24 I often. Have other pre-meeting commitment 16:49:36 ok - so we can shoot for right after the meeting then 16:49:42 +1 16:49:52 and if we finish the meeting early, we can start early 16:49:59 wfm 16:50:37 i'll send a note to the mailing list 16:50:52 #action lbragstad to send a note about m1 retrospective next week 16:51:00 #topic open discussion 16:53:00 if there is nothing else - we can call it a few minutes early and I'll start office hours at the top of the hour 16:53:48 thanks for coming 16:53:50 #endmeeting