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