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