20:02:11 <r1chardj0n3s> #startmeeting keystone_horizon
20:02:12 <openstack> Meeting started Thu Nov 17 20:02:11 2016 UTC and is due to finish in 60 minutes.  The chair is r1chardj0n3s. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:17 <openstack> The meeting name has been set to 'keystone_horizon'
20:02:39 <r1chardj0n3s> #link https://etherpad.openstack.org/p/ocata-keystone-horizon Meeting agenda/minutes/work items
20:02:49 <david-lyle> o/
20:02:56 <dolphm> \o
20:02:58 <edtubill> o/
20:03:36 <tqtran> [=_=]/
20:03:55 <rderose> o/
20:04:01 <r1chardj0n3s> So, unless anyone has a better idea, I'll work through the etherpad and see if there's any updates
20:04:18 <r1chardj0n3s> #topic sort projects by name please!
20:04:35 <r1chardj0n3s> I don't think there's been any movement on this one - is anyone aware of relevant work?
20:05:29 <r1chardj0n3s> I'm gonna take that as a no :-)
20:05:52 <r1chardj0n3s> #topic Proper Domain-admin support
20:06:05 <r1chardj0n3s> Looks like there's a patch for this now
20:06:12 <r1chardj0n3s> #link https://review.openstack.org/#/c/399157/
20:06:33 <rderose> started this effort, first part is to require a domain_id when registering an idp
20:06:35 <dstanek> r1chardj0n3s: i think that's something different
20:06:47 <rderose> then federated users will be mapped to real domains
20:07:21 <rderose> my part "removed hardcoded federated domain"
20:07:27 <r1chardj0n3s> dstanek: I think there's a number of issues, but the federated users not being mapped to a real domain was one of them
20:07:49 <r1chardj0n3s> rderose: so this is the death of the ephemeral "Federated" domain?
20:08:01 <rderose> yes
20:08:06 <r1chardj0n3s> \o/
20:08:30 <dstanek> r1chardj0n3s: can you not have a federated user be in a domain admin group at all right now?
20:08:37 <david-lyle> question on requiring domain id
20:08:51 <r1chardj0n3s> dstanek: no, at the moment federated users can't have domains at all
20:08:51 <david-lyle> is that just generated?
20:09:20 <david-lyle> does a name have to be specified?
20:09:24 <rderose> david-lyle: no, admins will be required to create the idp domain before registering the idp
20:09:35 <david-lyle> and just pick one ?
20:09:45 <david-lyle> hopefully the correct one?
20:09:47 <david-lyle> :)
20:10:00 <david-lyle> trying to track future horizon work
20:10:13 <david-lyle> you can setup federation in Horizon
20:10:14 <rderose> david-lyle: yeah, they have to associate the domain_id with the idp; could pick the wrong one
20:10:18 <dstanek> david-lyle: ideally it'll be easy because domain admins will only have access to one domain
20:10:20 <rderose> the idp does have a description
20:10:22 <david-lyle> so this would change the workflow
20:10:51 <david-lyle> not a blocking issue, but we should capture the follow-on work
20:11:07 * david-lyle goes to capture
20:11:12 <r1chardj0n3s> thanks david-lyle
20:11:26 <dstanek> r1chardj0n3s: i need to get the federation CLI stuff working so i can test that out
20:11:27 <rderose> david-lyle: the docs do say create a domain as part of configuring federation
20:11:36 <r1chardj0n3s> david-lyle: in the etherpad, ya?
20:11:40 <david-lyle> yes
20:12:41 <r1chardj0n3s> ok, moving on (but waiting for david-lyle to stop typing as the next bit's his ;-)
20:12:46 <r1chardj0n3s> #topic Roles
20:13:22 <david-lyle> I did not sign up for splitting the quota step out
20:13:37 <david-lyle> so that's still a todo waiting for an owner
20:13:55 <david-lyle> I did add some comments on the _member_ situation
20:14:09 <r1chardj0n3s> I think that should be moved to be a separate item in the etherpad
20:14:24 <lbragstad> looks like david-lyle did the investigation
20:14:53 <david-lyle> the choice is, do we want a default role? or force the user to select
20:15:23 <david-lyle> of the two workflows one is easier to change to no defaults
20:15:34 <david-lyle> the other is a bit of a hardcoded JS mess
20:15:57 <david-lyle> the latter being update members on project
20:16:38 <david-lyle> Theoretically all that lovely JS is going to be replace with even lovelier JS soon
20:17:13 <david-lyle> but I've been holding my breath for quite some time now and have gone through many shades of blue toward green now
20:17:17 <r1chardj0n3s> david-lyle: yes, we have https://blueprints.launchpad.net/horizon/+spec/angularize-identity-projects
20:17:52 <r1chardj0n3s> but I think we need to fix the current interface also
20:18:11 <david-lyle> I'm glad you volunteered r1chardj0n3s
20:18:13 <david-lyle> :)
20:18:16 <r1chardj0n3s> wait what
20:18:41 <r1chardj0n3s> If nothing else it would be good to capture the two broken interfaces in bugs please
20:19:40 <r1chardj0n3s> Then hopefully someone will pick it up
20:20:27 <r1chardj0n3s> #topic Roles and Quotas
20:20:34 <r1chardj0n3s> there's no names at all against this one :-(
20:21:04 <david-lyle> separating shouldn't be overly difficult TBH
20:21:09 <r1chardj0n3s> the colour of the Action line looks like lbragstad so I guess that's ownership, right? ;-)
20:21:35 <david-lyle> just moving a step to a new form
20:21:38 <lbragstad> hah - not anymore!
20:21:59 <r1chardj0n3s> david-lyle: agreed
20:22:13 <r1chardj0n3s> #topic K2K support
20:22:21 <r1chardj0n3s> edtubill: update?
20:22:36 <edtubill> hey, I think the items need to be reviewed still
20:22:43 * david-lyle has failed to review
20:23:02 <edtubill> but I've started to look into the blueprint option and writing code to see what changes we need for it.
20:23:13 <dstanek> these on my list of things i need to look at
20:23:26 <david-lyle> which is the bp option?
20:23:43 <david-lyle> new dropdown?
20:23:44 <edtubill> the new drop down and 'lazy' k2k sign on
20:23:55 <edtubill> yup
20:24:28 <david-lyle> and why not reuse regions?
20:24:54 <david-lyle> nevermind, I'll push it back up to the top of my review list
20:24:59 <edtubill> ok
20:25:19 <edtubill> I don't like reusing regions because I think you would have to sign into all the providers
20:25:31 <edtubill> upon inital log in.
20:25:57 <david-lyle> you would only make the request to the endpoint you selected from regions
20:26:00 <edtubill> and keep large session space for all the tokens and
20:26:07 <david-lyle> but it requires a hardcoded list
20:26:31 <edtubill> hmm
20:26:43 <david-lyle> there is actually a matching region dropdown once you're logged in that can be enabled to
20:26:52 <david-lyle> but it sends you back to the log in page
20:27:31 <edtubill> Yeah I think I saw that code, I wasn't sure what that did. There seems to be two region dropdowns in the code.
20:27:50 <david-lyle> yes, yes there are, you're welcome
20:27:55 <david-lyle> :P
20:27:59 <edtubill> :)
20:28:08 <r1chardj0n3s> ok moving on?
20:28:19 <david-lyle> the hidden one is for different endpoints, not regions in the traditional sense
20:28:29 <david-lyle> well the keystone sense
20:28:32 <david-lyle> sure
20:28:39 <edtubill> ok
20:28:51 <r1chardj0n3s> #topic Password about to expire info
20:29:09 <r1chardj0n3s> we have two patches for this, which I've added to our priority review list
20:29:22 <r1chardj0n3s> I think that's probably all to say on this one
20:29:51 <r1chardj0n3s> I'm going to skip to the new biggie at the end
20:29:52 <rderose> we also need to handle password strength requirements
20:30:17 <r1chardj0n3s> rderose: ok, that sounds like a separate issue we need to note then
20:30:23 <rderose> cool
20:30:27 <r1chardj0n3s> #topic #topic Retire django-openstack-auth-kerberos in favor of django_openstack_auth[kerberos]?
20:30:32 <r1chardj0n3s> topic topic
20:30:43 <r1chardj0n3s> https://bugs.launchpad.net/django-openstack-auth/+bug/1584432
20:30:43 <openstack> Launchpad bug 1584432 in django-openstack-auth-kerberos "deprecate doa-kerberos by using setuptools optional dependencies" [Undecided,In progress] - Assigned to Steve Martinelli (stevemar)
20:31:06 <david-lyle> rderose: https://github.com/openstack/horizon/blob/master/doc/source/topics/settings.rst#password_validator
20:31:13 <david-lyle> rules are optional
20:31:26 <david-lyle> r1chardj0n3s: we're just going to retire the repo
20:31:36 <david-lyle> read the line I added at the end
20:31:52 <r1chardj0n3s> that sounds like a solid plan!
20:31:56 <rderose> david-lyle: looks like we have some duplication in keystone's config
20:32:29 <david-lyle> they're addressing the problem at different points
20:33:07 <david-lyle> but it would be nice to have a shared source, but openstack
20:33:23 <rderose> david-lyle: http://docs.openstack.org/developer/keystone/security_compliance.html
20:33:46 <rderose> password strength requirements
20:34:08 <david-lyle> sure, can we get that via API of an end user?
20:34:15 <david-lyle> s/of/by/
20:35:24 <rderose> david-lyle: no, but the strength description is returned if the user fails password strength
20:35:45 <rderose> during auth
20:35:57 <david-lyle> for a UI that's a roundtrip to the server, where we can do it live on the page
20:36:00 <dstanek> rderose: during auth or user create?
20:36:29 <rderose> dstanke: right, sorry not during auth
20:36:39 <rderose> but anytime your are creating a password
20:36:46 <rderose> *dstanek
20:36:50 <dstanek> david-lyle: having it discoverable makes total sense to me
20:38:21 <david-lyle> discoverable is the answer to most of Horizon's duplicate settings problems, so I'm all for discoverability
20:38:30 <r1chardj0n3s> +1
20:38:55 <r1chardj0n3s> please add a new thing to the etherpad: keystone to make it all discoverable :-)
20:39:19 <r1chardj0n3s> (let's just add that password strength info, yes)
20:39:46 <rderose> have it under PCI
20:40:40 <r1chardj0n3s> #topic Support for browsing LDAP users
20:41:01 <r1chardj0n3s> Any updates here?
20:42:11 <r1chardj0n3s> looks like some patches to fix https://bugs.launchpad.net/keystone/+bug/1582585 went in, fixing the speed issue at least
20:42:11 <openstack> Launchpad bug 1582585 in OpenStack Identity (keystone) "the speed of query user from ldap server is very slow" [Wishlist,Fix released] - Assigned to Andrew Liu (andrew-lhj)
20:43:14 <r1chardj0n3s> so I think the search-instead angle just needs more investigation
20:44:10 <r1chardj0n3s> *crickets* :-)
20:44:49 <rderose> so it will speed things up, but how does horizon handle pagination?
20:45:04 <rderose> because will still return all records, unless filtered
20:45:34 <r1chardj0n3s> rderose: we paginate using service APIs where possible, and we paginate large lists on the client if necessary
20:46:19 <rderose> but it's probably not happening with the user list
20:46:33 <r1chardj0n3s> no server side pagination
20:46:58 <rderose> action item for keystone?
20:47:11 <r1chardj0n3s> as I understand it, you can't paginate for LDAP
20:47:11 <breton> no updates from my side, sorry
20:47:34 <r1chardj0n3s> so we need to implement filtering (filter-first) in our UIs
20:47:43 * stevemar lurks in late
20:47:47 <dstanek> r1chardj0n3s: that's correct on pagination
20:47:51 <rderose> dstanek: is that true
20:47:53 <rderose> :)
20:48:09 <stevemar> on the LDAP topic?
20:48:23 <r1chardj0n3s> yep
20:48:24 <dstanek> there's no way to query is and say 'start at record XYZ'
20:49:17 <stevemar> for pagination you need to setup keystone to use an LDAP admin account: https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L1071-L1077
20:49:31 <stevemar> which for most enterprises, will tell you to buzz off :)
20:49:43 <robcresswell> the filter_first stuff is implemented in half a dozen views already. I'd imagine someone could copy paste the existing implementations
20:49:58 <r1chardj0n3s> robcresswell: the UI just gets a bit tricky though
20:50:03 <stevemar> robcresswell: whats an example of the filter_first stuff?
20:50:13 <robcresswell> r1chardj0n3s: How so?
20:50:24 <david-lyle> error codes and notices to the user
20:50:31 <david-lyle> re: overflow
20:50:33 <r1chardj0n3s> robcresswell: adding users to projects, IIRC, the UI is ... unique
20:50:38 <robcresswell> Ah
20:50:48 <robcresswell> I was thinking of the overall views.
20:50:55 <robcresswell> index views etc.
20:51:00 <r1chardj0n3s> yeah, those are easy
20:51:11 <david-lyle> those would still need work
20:51:11 <robcresswell> Right
20:51:18 <robcresswell> They still aren't done though
20:52:16 <r1chardj0n3s> OK, moving on
20:52:24 <r1chardj0n3s> #topic v3 policy is not parseable using oslo.policy
20:52:36 <stevemar> this one is long and convoluted
20:52:49 <r1chardj0n3s> \o/
20:54:55 <r1chardj0n3s> ok, just quickly, PCI?
20:55:03 <r1chardj0n3s> rderose, this is you?
20:55:15 <stevemar> probably better to cover that one
20:55:23 <stevemar> i need to read up on the policy bug
20:55:30 <r1chardj0n3s> ack
20:55:49 <rderose> yeah, we sort of covered it
20:56:08 <rderose> I moved "Password about to expire info" under PCI
20:56:39 <rderose> PCI stuff is growing
20:56:46 <r1chardj0n3s> ok
20:57:04 <rderose> The last one will require users to changed their password if an admin created it for them
20:57:13 <rderose> Work being done in Ocata
20:57:13 <stevemar> users should be able to change passwords in horizon i think
20:57:15 <r1chardj0n3s> ah, cool, I see the comment added about the password strength discoverability
20:58:00 <stevemar> hmm, we could expose that via an API
20:58:11 <r1chardj0n3s> yes, please :-)
20:58:20 <david-lyle> stevemar we currently have duplicate settings
20:58:24 <david-lyle> at least for that
20:58:28 <stevemar> link?
20:58:37 <david-lyle> once line above
20:58:44 <david-lyle> the not about discoverable
20:58:47 <david-lyle> *note
20:58:55 <david-lyle> *one
20:59:00 <robcresswell> http://docs.openstack.org/developer/horizon/topics/settings.html#password-validator ?
20:59:07 <stevemar> rgr
20:59:21 <stevemar> oh
20:59:25 <stevemar> thats interesting...
20:59:43 <stevemar> you guys had it before we did :)
20:59:52 <rderose> :)
20:59:59 <r1chardj0n3s> :-)
21:00:01 <r1chardj0n3s> ok folks, we're out of time, thanks again!
21:00:05 <stevemar> np
21:00:05 <r1chardj0n3s> #endmeeting