20:01:20 #startmeeting horizon-keystone 20:01:21 Meeting started Tue Nov 8 20:01:20 2016 UTC and is due to finish in 60 minutes. The chair is r1chardj0n3s. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:25 The meeting name has been set to 'horizon_keystone' 20:01:25 \o/ 20:02:02 Hi everyone, this is the kickoff for what we hope is a regular series of meetings to discuss Horizon/Keystone cross project issues. 20:02:16 o/ 20:02:20 The etherpad from the summit session is https://etherpad.openstack.org/p/ocata-keystone-horizon 20:02:40 o/ 20:02:53 o/ 20:03:13 It has some actions we wanted to take, so I think a good place to start is to get an update on those. 20:03:29 do we want to select an official time for this meeting? 20:03:41 Not this one 20:03:47 o/ 20:03:52 david-lyle: in general? oh 20:03:58 stevemar: oh, yes, I was going to come to that. We could do it first tho :-) 20:04:03 david-lyle lbragstad proposed a patch for that: https://review.openstack.org/#/c/395106/ 20:04:06 r1chardj0n3s: :) 20:04:26 so, meeting time - should I put up a doodle, or are there more concrete suggestions? 20:04:54 Just move one hour later or earlier? 20:05:08 if folks have an opinion on the meeting time we can iterate on it in review https://review.openstack.org/#/c/395106/ 20:05:28 r1chardj0n3s: around this time definitely works for me, just doubled booked with the tc meeting atm 20:05:46 ++ 20:05:50 ah, right! 20:06:01 one hour earlier is the tc meeting which robcresswell mentioned to me ealier as well 20:06:24 Tc is now 20:06:34 oh - right 20:06:59 :) 20:07:14 this time is a sweet spot for me, I'm afraid. an hour earlier could be doable, if you're happy with Zombie Richard :-) 20:07:21 i'm all sorts of mixed up when it comes to the times, the one proposed to the meetings repo does not conflict with the tc meeting 20:07:23 then lets keep it as is 20:07:35 ha, lbragstad, yeah, 2000 is the tc meeting is what I said, so this particular one collides - 1900 is better 20:07:55 ok, so does 1900 work for everyone? 20:08:00 ++ 20:08:09 There are other days of the week with the same time 20:08:48 i'm good for tomorrow 20:09:06 but i think r1chardj0n3s doesn't want to start his friday at an awful time 20:09:19 Wednesday works 20:09:24 and clears the tests 20:09:25 (if we move it to thursday) 20:09:31 tomorrow is Horizon meeting at this time :-) 20:09:32 wed 2000 is horizon 20:09:37 hehe 20:09:40 Doh 20:09:43 thu 2000 would work for me 20:09:44 maybe a little earlier? It's 23:00 here now :( 20:10:14 breton: heh, it's 0700 here :-) 20:10:15 breton: earlier won't work, r1chardj0n3s is in AUS 20:10:30 oh 20:10:38 o/ sorry im late 20:10:40 yeah, richards attendance is key since he is ptl 20:10:42 i'm good with any of the times that have been discussed thus far 20:10:42 :) 20:10:56 2000 Thursday? 20:11:07 (if free) 20:11:08 2100 wednesday? 20:11:23 maybe a doodle would be better :) 20:11:32 or someone just pick one 20:11:47 ++ for doodle 20:11:47 Unless there's any objections, 2000 Thursday 20:11:54 it'll be 1900, 2000, 2100 on tuesday/wednesday/thursday 20:12:09 r1chardj0n3s: works for me 20:12:14 +1 to 2000 on Thursday 20:12:29 all work for me 20:12:30 r1chardj0n3s ++ 20:12:38 +1 2000 Thurs 20:12:41 do it up, lbragstad update the patch please 20:13:10 we actually discussing technical things today or just coming up with a new meeting time? 20:13:12 #agreed the new weekly meeting time will be Thursdays 2000 UTC 20:13:15 thanks lbragstad 20:13:20 stevemar robcresswell r1chardj0n3s done - https://review.openstack.org/#/c/395106/ 20:13:30 (starting next week of course ;) ) 20:13:38 yes! 20:13:41 :-) 20:14:14 shall we run through the action items from the summit? 20:14:25 as long as stevemar and r1chardj0n3s sign off on the time i'll push to get it approved and merged (set in stone) 20:15:23 #topic Keystone to remove the hardcoded "Federated" domain (rderose) 20:16:14 rderose: will this one go away once we get a better mapping engine in ocata? 20:17:02 stevemar: I don't think this is dependent on mapping engine. federated users are normal users now and can just use default domain 20:17:34 Wouldn't default be problematic? 20:17:37 is there a bp/bug/patch that we could reference here? 20:17:46 rderose: i'm not sure that's accurate though 20:18:26 r1chardj0n3s: of course there isn't one :\ 20:18:28 is there a review/spec so i can catch up on the ask? 20:18:37 stevemar: which part, federated users are in the user table now 20:18:52 dstanek: I think at the moment all we have is in the etherpad 20:18:58 https://etherpad.openstack.org/p/ocata-keystone-horizon 20:19:16 i think its related to https://bugs.launchpad.net/keystone/+bug/1627098 20:19:16 Launchpad bug 1627098 in OpenStack Identity (keystone) "federated users cannot user heat" [Undecided,New] 20:19:19 https://bugs.launchpad.net/keystone/+bug/1589993 20:19:19 Launchpad bug 1589993 in Murano "Murano cannot deploy with federated user" [Wishlist,Incomplete] 20:19:27 stevemar: david-lyle: why would default be problematic, federated users are no longer ephemeral 20:19:56 Thinking of role mapping and admin 20:20:04 rderose: right, but they don't exist in the default domain 20:20:26 rderose: i was thinking the idp -> domain relationship should be leveraged here 20:20:30 stevemar: hmm... 20:20:46 stevemar: I see 20:20:53 this might be a bad start here, it's gotten very keystoney 20:21:12 Especially if you're federating multiple idps 20:21:22 Shouldn't mix 20:21:24 yep, it's probably a good idea to avoid bogging down in detailed discussion here 20:21:36 but we can take away that we need to better flesh out the issues we're trying to solve, we need bugs and bps 20:21:37 unless it's crossproject 20:22:06 yep, could we get an action from someone to better define the problem/solution? 20:22:23 (he calls out to the void for a volunteer ;-) 20:22:35 I think I can look into it from a heat perspective 20:22:43 r1chardj0n3s: i'll add it to https://etherpad.openstack.org/p/ocata-keystone-horizon 20:23:05 In any case, federated users are no longer ephemeral in newton? 20:23:07 great, thanks 20:23:21 o/ kenji-i 20:23:27 we might not have a backportable solution for Mitaka, then 20:23:36 r1chardj0n3s:o/ morning! 20:23:39 kenji-i: correct 20:24:30 rderose: when did that change land? I was seeing them ephemeral pretty late in Newton 20:25:10 r1chardj0n3s: pretty late in newton it landed i think? 20:25:11 (ephemeral == "Federated" as their domain, yes?) 20:25:25 r1chardj0n3s: so not really 20:25:40 r1chardj0n3s: ephemeral == we didn't save a record of the user in the SQL backend 20:25:41 r1chardj0n3s: https://review.openstack.org/#/c/279162/68 20:25:43 r1chardj0n3s: now we do 20:25:44 that works was started in mitaka - https://github.com/openstack/keystone-specs/blob/master/specs/keystone/mitaka/shadow-users.rst 20:25:53 ok 20:25:55 thanks 20:26:08 how about we move on, we've got a few other things to cover 20:26:12 BUT the domain stayed as "FEDERATED" or whatever it is 20:26:14 eyah 20:26:17 can't use a Trust if you don't have a user 20:26:28 lets add more content to the etherpad 20:26:28 it was continued in Newton - https://github.com/openstack/keystone-specs/blob/master/specs/keystone/newton/shadow-users-newton.rst 20:26:30 so we need a non-ephemeral user in order for Heat to work 20:26:56 stevemar: correct, but we're not saving the domain in the db 20:27:06 r1chardj0n3s: crinkle has a few patches up, how about we discuss those? 20:27:40 * david-lyle owes crinkle some more reviews 20:27:51 stevemar: we could - I was going to get status updates on the current etherpad tasks 20:28:18 yeah those patches don't exactly correspond to any of the tasks 20:28:20 I'm happy for this meeting to take whatever direction is useful 20:28:48 could we continue to use the etherpad to track the combined interest tasks? 20:29:06 r1chardj0n3s: totally 20:29:25 rderose: thank you! 20:29:34 crinkle: would you mind adding some info about what you're doing to https://etherpad.openstack.org/p/ocata-keystone-horizon please? 20:29:44 r1chardj0n3s: sure 20:29:58 thanks 20:30:04 and we'll come back to it 20:30:14 #topic Horizon to remove token revocation upon logout & project switch 20:30:21 Would be nice to get patches/bps/bugs linked if possible. Etherpads are a bit transient. 20:30:30 this one is a win \o/ it's all done 20:30:35 sweet 20:30:40 r1chardj0n3s: yay 20:30:40 #link https://github.com/openstack/django_openstack_auth/commit/5810f9c6d92f8e1febbb25f5486778dbf416991c is the commit 20:30:56 So, token revocation is done in master and released, also backported to stable/newton and has a patch in releases waiting for approval. 20:31:04 jamielennox could not make it, but he's the one hammering home on the "expired tokens are still useful" work 20:31:12 so - what happens after I log out and I go back to horizon? 20:31:32 lbragstad, it dumped the session, should prompt you for login again 20:31:37 lbragstad: your tokens are not revoked 20:31:48 ah ha 20:31:51 lbragstad: thats the only change 20:32:02 i'm assuming horizon uses some sort of session cookie that is invalidated on logout? 20:32:03 all your old work is still valid. Any tokens that are stored with long workloads are still valid 20:32:08 lbragstad: so if you kicked off a long operation, and logged out, it won't fail 20:32:10 dstanek: correct 20:32:15 so it prompts for a username and password because the session was dumped instead of revoking the token 20:32:51 #topic Roles: there are two related workflows that actually behave differently; investigate why one has a default 20:33:06 so, there wasn't a concrete action with a name against this one 20:33:07 i didn't investigate this yet 20:33:22 i think the TODO is to investigate 20:33:24 I didn't look either 20:33:35 Put my name on it 20:33:52 david-lyle_: done! 20:33:59 always happy to put your name against things :-) 20:34:11 there was addd user to project tha was using the default role 20:34:23 that needs to be replaced with only doing "assign user a role on the project" 20:34:33 ayoung: yeah 20:35:03 when i tried to assign a user a role on a project, it automatically went for the "_member_" role or whatever that thing is 20:35:14 there wasn't a drop down for me to select the role 20:36:33 #topic K2K support 20:37:02 This is crinkle's moment to shine, right? 20:37:03 one more note on the previous topic, if we could move away from the whole _member_ thing, that would be all kinds of awesome 20:37:17 r1chardj0n3s: nope! it's all about edtubill now :P 20:37:24 d'oh! 20:37:26 hey, so I'm happy to support whatever method to go with. 20:37:53 we've got a few options to pick from 20:38:18 There's this new blueprint I made: https://blueprints.launchpad.net/horizon/+spec/k2k-horizon 20:38:37 This is the old patch that's been here forever K2K with Regions drop down https://review.openstack.org/#/c/159910/21 20:38:37 hey, I have to run in a few minutes. On Browsing LDAP users... https://review.openstack.org/#/c/314829/ 20:38:59 raildo is making it happen 20:39:04 gotta phase. 20:39:05 and here's the patch I created which requires configuration in local_settings. K2K at Log In Time https://review.openstack.org/#/c/325901/ 20:39:28 r1chardj0n3s: to level set k2k is where a user can use a different keystone in a completely different cloud 20:39:45 these other keystones are called service providers according to our APIs 20:40:06 in the catalog, theres a list of these service providers, so they are in the token 20:40:26 so, is the plan that a user can manage both clouds through one horizon? 20:40:31 I think we settled on a post login approach. But I owe a review on the bp 20:40:37 yes through a single pane of glass 20:41:05 david-lyle_: so the one operator that has chimed in is kfox 20:41:10 and he writes... 20:41:15 I prefer the dropdown asking for service provider at login, as I think its likely that in multi region situations the user will want to know where they are going, especially in the case of hybrid public/private federated clouds. Making a mistake there could cost real money. 20:41:25 can they manager an arbitrary # of clouds or just the two? 20:42:09 stevemar that list is open api or we have to hard code? 20:42:33 dstanek: I think they can manage an arbitrary # of clouds which have keystone service providers 20:42:53 david-lyle_: you can get that list in an access info object with a token. 20:43:10 So login becomes multistepped? 20:43:15 david-lyle_: it's not open 20:44:28 ok, I think y'all have enough to work on there :-) 20:44:40 #topic Support for browsing LDAP users 20:45:04 Adam mentioned this review just before https://review.openstack.org/#/c/314829/ 20:45:57 We don't have anyone on the Horizon side of this that I'm aware of 20:46:10 r1chardj0n3s: tsufiev 20:46:17 r1chardj0n3s: he's not here though 20:46:19 i don't think this solves the problem? 20:46:21 cool, now I'm aware :-) 20:46:30 http://lists.openstack.org/pipermail/openstack-dev/2016-November/106923.html 20:46:37 please review the patches mentioned there 20:46:49 after that i'll be able to push mine patch too 20:46:59 then horizon will have to consume the flag 20:47:11 breton: oh that's to consume the limit flad 20:47:13 flag 20:47:23 breton: would you mind updating the etherpad with that info please? 20:47:40 r1chardj0n3s: will do 20:47:44 Oh, the limit flag would be good 20:47:54 I'm not sure the first review does anything for horizon 20:48:06 also 20:48:32 keystoners, please review https://review.openstack.org/#/c/339294/ 20:48:35 Allowing list all on keystone doesnt work around other limits imposed outside keystone I thought, like the 500 user limit that was mentioned? 20:48:35 oh 20:48:42 ooooh, it is already merged 20:48:53 super-efficient keystoners :-) 20:48:56 the way i always envision browsing ldap users is the same way we do it with our internal ldap... we have a search bar and when you start typing in names it does a dynamic search 20:49:17 yep 20:49:20 so if you type in "steve" you get the first 50 steve's 20:49:23 stevemar: yes, that's what we plan to do too 20:49:38 if you type in "steve mar" i show up, along with a few others 20:49:49 breton: those patches accomplish that? 20:49:53 what am i missing? 20:50:22 stevemar: we decided that we need a flag that would signal to Horizon that there are more users 20:50:31 breton: how does disabling user list fix that? 20:50:40 stevemar: /me doesn't know 20:51:04 breton: well then 20:51:18 stevemar: i am asking to review the patches related to the flag :) it wasn't me who mentioned the disabling 20:51:29 r1chardj0n3s: so when you click on the users tab now, it tries to list all right? 20:51:36 yes 20:51:52 r1chardj0n3s: btw you already can partially implement the search 20:52:01 stevemar: I think the flag breton is mentioning is unrelated to the list all enable/disable 20:52:02 r1chardj0n3s: because filtering already works for LDAP 20:52:12 robcresswell: right 20:52:24 we have a few places in the UI where we just list all users rather than search first, and will need to change all of those 20:52:59 which would be unfortunate for folks that have a lot of sql users :( 20:53:24 The flag is just a way of saying "here's some results, there are loads more though" so Horizon can indicate this on the UI. I think right now, we don't consume anything from keystone indicating whether we've hit a return limit. 20:53:26 stevemar: it works for sql too 20:53:28 iirc 20:53:40 robcresswell: ++ 20:53:47 robcresswell: good explanation 20:53:52 stevemar: you know, the startswith__ stuff 20:53:59 breton: yep, i recall that 20:54:10 so what we need to do 20:54:13 1. review patches 20:54:24 2. start implmeneting things in horizon 20:54:24 you just summed up openstack, breton. 20:54:29 lol 20:54:31 :) 20:54:31 1. review patches. 20:54:36 :) 20:55:18 ok we're just about out of time, so could I just ask folks to make sure that the etherpad is up to date, that'd be great. We'll retire stuff that's done to the bottom of the pad, I think. 20:55:23 breton which patches? 20:55:36 All the patches! 20:55:37 lbragstad: http://lists.openstack.org/pipermail/openstack-dev/2016-November/106923.html 20:55:51 r1chardj0n3s stevemar do we want a separate etherpad for this meeting? 20:55:59 lbragstad: nah 20:56:04 -1 20:56:09 ok 20:56:10 lets just keep re-using this 20:56:19 Once we clean the etherpad meetings are done a 20:56:29 r1chardj0n3s: i might clean up the etherpad when we're done 20:56:35 (i will update etherpad tomorrow) 20:56:55 david-lyle_: right, once we have all the topics moved to "Done" we can stop meeting :) 20:56:56 david-lyle_: naturally 20:57:05 Could we link bps/bugs too please... not a huge fan of etherpads. They get lost over time, but bugs and bps can be searched (via google ofc, LP search is terribad) 20:57:24 robcresswell: yeah, we can start creating bugs and bPs 20:57:30 \o/ 20:57:33 yes, all work must be captured in bugs/bps, please link them in the etherpad too 20:58:19 OK, thanks everyone for coming along, see you next week (Thursday 2000) 20:58:28 #endmeeting