12:00:45 <david-lyle> #startmeeting Horizon
12:00:45 <openstack> Meeting started Wed Aug 19 12:00:45 2015 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:48 <r1chardj0n3s> hullo
12:00:49 <openstack> The meeting name has been set to 'horizon'
12:00:51 <fnordahl> o/
12:01:01 <tsufiev> hello
12:01:31 <mrunge> hello o/
12:02:03 <betherly> hello o/
12:03:36 <kzaitsev_mb> o/
12:03:55 <david-lyle> ok, let's get rolling
12:04:20 <david-lyle> First and foremost, L-3 is in 2 weeks
12:05:51 <david-lyle> and there's a lot hanging out there
12:06:21 <david-lyle> of the top priorities on
12:06:25 <david-lyle> #link https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities
12:06:32 <david-lyle> we're looking pretty meek
12:07:51 <david-lyle> what was JSCS and now eslint is finally all merged and voting in the gate
12:07:58 <david-lyle> so that one was completed
12:08:22 <david-lyle> I owe plugin documentation still :( which I will have ready for L
12:08:42 <robcresswell> The angular translation stuff is mostly there folowing a fix the other day, I believe, so thats good too.
12:09:49 <neillc> hello
12:10:23 <david-lyle> right that's done too
12:10:35 <david-lyle> slow because looking at status on those
12:10:41 <betherly> I am new to openstack and working with HP. Will probably be working on horizon panels for Ironic but have been talking to hurgleburgler re CSS theming stuff also. Definitely up for helping Horizon meet targets for L-3.
12:10:46 <david-lyle> if anyone has updates note them
12:11:11 <david-lyle> betherly: a large part is reviews
12:11:24 <david-lyle> we are very close on django 1.8
12:11:27 <r1chardj0n3s> I got a system up and running today so I can run the selenium suite using firefox, so hope to make progress on that...
12:11:34 <david-lyle> mrunge: is there anything else missing
12:11:51 <robcresswell> I thought dj18 was now done?
12:11:55 <david-lyle> r1chardj0n3s: I got derailed on that yesterday by the horrid state of our docs build
12:12:04 <david-lyle> almost done with patches to fix
12:12:09 <betherly> david-lyle: ok great. If theres any urgent ones please do ping me but I will keep my eye on them
12:12:11 <robcresswell> ah
12:12:11 <mrunge> david-lyle, it's not yet voting on the gate
12:12:20 <david-lyle> robcresswell: I have to release d-o-a
12:12:37 <r1chardj0n3s> david-lyle: I'll be focusing on it if you want to focus on other stuff
12:13:10 <david-lyle> which I have a couple of patches I'm waiting on for d-o-a, 1 has 2 +2s and could merge, the other is related and further
12:13:15 <robcresswell> betherly: Best bet is to review patches on https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities, although they may not be terribly accessible to newer reviewers. Pull code, check it doesnt explode horizon, and comment on anything that looks odd.
12:13:17 <david-lyle> might have to release without it
12:13:23 <mrunge> ah yes, david-lyle d-o-a release is due for django-1.8 support, too
12:13:32 <robcresswell> Gotcha.
12:13:47 <david-lyle> then make that the minimum version in g-r
12:13:52 <david-lyle> running out of time on that one
12:14:02 <betherly> robcresswell: will do :) will have horizon up and running successfully soon then will get started
12:14:11 <robcresswell> We have 2 weeks yet. Still time.
12:14:59 <david-lyle> dependent library releases and g-r changes usually get locked 2 weeks ahead of release
12:15:07 <robcresswell> david-lyle: What was the state of docs after your patches? More work needed? I'd seen the bugs before, but not prioritised it over things
12:15:09 <david-lyle> so we're about at the limit
12:15:11 <robcresswell> Ah, I see.
12:15:44 <david-lyle> robcresswell: just one more patch required to handle duplicate object definitions
12:16:11 <david-lyle> then, I think we can turn on doc errors in the build to block like pep8
12:16:15 <david-lyle> I think
12:16:26 <david-lyle> without it, it's just a mess
12:16:51 <david-lyle> any other priority items people want to mention?
12:17:10 <mrunge> we had this patch from rdopiera about using ini based configs
12:17:17 <david-lyle> err, updates on said items
12:17:32 <ducttape_> the recent changes in the nav should be corrected
12:17:36 <mrunge> since a configuration change requires changes with installers: now or never
12:17:48 <tsufiev> also I'd like to discuss the state of integration tests
12:17:52 <david-lyle> mrunge: I think that one's very late in the release for such a change
12:18:03 <david-lyle> and there's no real migration path defined
12:18:16 <mrunge> yupp, as I said: now or never
12:18:17 <david-lyle> I'm happy to revisit in M
12:18:31 <ducttape_> I think never might be a bit strong of a word
12:18:35 <ducttape_> ;)
12:18:42 <mrunge> agreed ;-)
12:19:32 <ducttape_> the nav thing needs some fixing, around display of large data amounts and the multi region login thing.... not seeing that on the list
12:19:38 <david-lyle> we lost rdopiera and with him a lot of the momentum on that
12:19:40 <mrunge> I know r1chardj0n3s wanted to look ad Radomirs patch. I must admit I stopped with it.
12:19:47 <mrunge> yes
12:20:11 <david-lyle> I still think it's a good idea overall, but needs more
12:20:53 <david-lyle> ducttape_: just the look, or is there a functional problem?
12:21:01 <mrunge> david-lyle, for reference, https://review.openstack.org/#/c/100521/
12:21:04 <doug-fish> ducttape_: do you have bugs to link? I'm not aware of what "the nav thing" is?
12:21:08 * tsufiev steps in with making integration tests voting again
12:21:10 <mrunge> this patch already has 2 +2
12:21:35 <ducttape_> https://bugs.launchpad.net/horizon/+bug/1485764  was the one I saw a couple of days ago
12:21:35 <openstack> Launchpad bug 1485764 in OpenStack Dashboard (Horizon) "left hand nav border color does not work on big tables" [Undecided,New] - Assigned to Diana Whitten (hurgleburgler)
12:21:46 <doug-fish> thx
12:22:07 <ducttape_> there is another one Diana is looking at for multi region login stuff (which does not apply to me, but seems important none the less)
12:22:21 <david-lyle> mrunge, I hadn't seen the other
12:22:29 <david-lyle> let me look again
12:22:45 <mrunge> david-lyle, *thank you*
12:23:32 <mrunge> tsufiev, thanks for stepping up with integration tests
12:23:54 <mrunge> we should think about, how to integrate them even more, to get a faster feedback
12:23:57 <david-lyle> mrunge: I put a -2 on it, so I can take another look
12:24:15 <mrunge> ok, awesome
12:24:24 <david-lyle> ducttape_: I think there's a fix on that one too
12:24:33 <tsufiev> mrunge, I'm waiting for Jenkins feedback on last patchset, all should pass except 2 Sahara tests
12:24:41 <david-lyle> s/fix/patch/
12:25:19 <david-lyle> tsufiev: yes, thank you, I've wandered away from that :(
12:25:33 <david-lyle> the 2 sahara tests may be my issue
12:25:43 <tsufiev> david-lyle, mrunge, as I said before, even if that commit gets merged, w/o making integration tests voting again, they soon will be broken
12:25:43 <david-lyle> but not entirely sure
12:25:46 <mrunge> it's so easy to switch off integration tests. if we could get them into other gates, we would be safer
12:25:56 <r1chardj0n3s> mrunge: hey, sorry I got called away. I did look at Radomir's ini patch, and it seemed pretty complex, and I didn't have time to get into the full ramifications of moving from python to ini - I reckon a pretty broad review of operators / deployers configs would be needed before making such a change
12:26:20 <ducttape_> +1 r1chardj0n3s
12:26:30 <mrunge> r1chardj0n3s, thanks anyways. I agree, this change is pretty disruptive with deployers
12:26:35 <tosky> well, if the other tests are fixed, checking the failing Sahara tests would be easier
12:26:47 <tsufiev> david-lyle, perhaps, we should somehow split sahara integration tests into a separate job?
12:26:49 <r1chardj0n3s> (then I got distracted by trying to fix the selenium suite ;)
12:26:50 <tosky> it could be related to some change in the page structure, but I couldn't check before
12:26:56 <tsufiev> given that sahara is moved to contrib
12:27:00 <david-lyle> mrunge, tsufiev I understand the push to reenable, that said, even when enabled they have been fragile
12:27:01 <mrunge> hahaha r1chardj0n3s
12:27:17 <r1chardj0n3s> hey, half of it is fixed now, so that's a thing
12:27:28 <tosky> david-lyle: but not fixing them would make them always fragile
12:27:29 <tsufiev> david-lyle, yes, I found one cause of such fragility - the tests were relying on exact ordering of fields in forms
12:27:41 <r1chardj0n3s> phantomjs is a no-go tho, 'cos we test file uploads and that's not supported in ghostdriver :(
12:27:49 <tsufiev> fixed that for forms, should be fixed as well for table actions
12:28:23 <david-lyle> some wonderful people look at all the gate failures every day, and our integration tests create a ton that are hard to categorize which means it keeps requiring work every time they fail
12:28:24 <mrunge> unfortunately, being fragile is the nature of tests running on top of the stack
12:29:24 <david-lyle> not sure that needs to be true, but to a degree yes
12:29:40 <tsufiev> david-lyle, mrunge: also there is an idea about untying integration tests selectors from horizon layout and use some special 'selenium-*' classes
12:30:16 <david-lyle> tsufiev: I would like to see at least a week of no failures before making voting again
12:30:34 <david-lyle> no, being a very small percentage
12:30:49 <david-lyle> there will always be random failures
12:30:56 <tsufiev> david-lyle, what if the patch where they fail introduces the breakage?
12:31:15 <david-lyle> then reviewers should be looking at that
12:31:23 <doug-fish> david-lyle: I don't know how to track integration test failures - is that striaghtforward?
12:31:33 <r1chardj0n3s> ... and at the moment it's very difficult indeed to figure out why selenium tests break, which is something else I need to look at fixing
12:31:33 <david-lyle> if we think they are fixed, that should be a review consideration
12:32:04 <david-lyle> doug-fish: there is a log for the integration tests on check runs
12:32:37 <tsufiev> david-lyle, doug-fish: also there is patch in progress to save screenshots on failures
12:32:43 <doug-fish> right, but is there a way to get a summary of what's failed over the last day for example?
12:32:51 <tsufiev> https://review.openstack.org/#/c/194646/
12:32:56 <david-lyle> currently it dumps the html source
12:33:03 <doug-fish> yeah, I've seen that
12:33:06 <david-lyle> doug-fish: oh
12:33:07 <r1chardj0n3s> yeah, the failurs I was debugging yesterday just said "500 Error" in the browser window
12:33:09 <r1chardj0n3s> so yeah
12:33:25 <david-lyle> http://status.openstack.org//elastic-recheck/
12:33:35 <r1chardj0n3s> screenshots will help tho
12:33:44 <david-lyle> which is why recheck # is important over just recheck
12:34:08 <doug-fish> will the source remain available as well? (I haven't looked at the screen shot patch yet)
12:34:11 <doug-fish> david-lyle: thanks!
12:34:39 <tsufiev> doug-fish, yes, I think they're orthogonal
12:34:47 <david-lyle> beyond that ... logstash.openstack.org
12:34:48 <doug-fish> agreed
12:35:23 <tsufiev> unfortunately, while fixing integration tests locally, I didn't find the html source very helpful
12:35:42 <doug-fish> david-lyle: so I'm loosely aware of both of those sites, but I can't quite put together how I'd check how many Horizon integration tests failed today
12:35:42 <tsufiev> the most useful was python stacktrace + examining tests sourcecode in debugger
12:36:20 <doug-fish> tsufiev: I've had cases where the source was helpful - I could see the test was looking for a particular element, but it wasn't present on the page
12:37:02 <tsufiev> doug-fish, yes, it's possible to find it there... just too inconvenient :)
12:38:07 <doug-fish> david-lyle: no reason we have to sort though teaching me to use the tool available during our meeting time. I think I know some people I can ask.
12:38:19 <david-lyle> doug-fish: we could build a query for logstash, I just can't on the fly in the meeting :)
12:38:32 <doug-fish> understood. Thx!
12:38:43 <tsufiev> david-lyle, mrunge, doug-fish: I'm going to create a blueprint for integration tests hardening - all the things to make them less fragile
12:38:55 <david-lyle> tsufiev: great, thank you
12:39:05 <mrunge> thank you tsufiev
12:39:06 <robcresswell> There is an item on the agenda btw, someone has put up a bp, just looking at time :)
12:39:23 <david-lyle> so other reviews on off the radar but could use help
12:39:44 <david-lyle> #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon
12:39:45 <david-lyle> and
12:40:07 <david-lyle> #link https://etherpad.openstack.org/p/trove-reviews-in-horizon
12:40:22 <wimdc> It's mine. There's not much text in the bp really, but it would be great if I could get some guidance on how to proceed from here. There's also a bunch of code in gerrit. But I'm kinda stuck without the blueprint approved.
12:40:42 <david-lyle> reminder that with trove and sahara in /contrib, +1s from the service team can account for 1 +2
12:40:59 <david-lyle> so just one horizon core is needed to +2, +A
12:41:12 <david-lyle> I will be getting back to those soon too
12:42:33 <david-lyle> sorry wimdc
12:42:46 <david-lyle> so the bp linked is neutron, no?
12:43:23 <david-lyle> is there a corresponding Horizon bp?
12:43:23 <wimdc> oh, did I copy the wrong link... lemme see
12:44:16 <wimdc> It's supposed to be the implementation of that neutron link in horizon :)
12:44:27 <wimdc> https://blueprints.launchpad.net/horizon/+spec/port-allowed-address-pairs-extension
12:45:02 <wimdc> updated the page.
12:45:17 <david-lyle> Seems like a reasonable addition to me
12:46:01 <doug-fish> agreed
12:46:05 <robcresswell> Oh nice, looks like the code is all done
12:46:13 <david-lyle> the python-neutronclient code seemed to have been merged long ago
12:46:20 <david-lyle> so no dependency issues
12:46:26 <wimdc> Yea I gave it a -1 myself cause I need to update a small thing though.
12:47:18 <david-lyle> ok, updated the status of the bp
12:47:24 <robcresswell> Nice
12:47:38 <wimdc> Thanks
12:47:57 <david-lyle> I would ask amotoki kindly for a review
12:48:48 <david-lyle> let me rephrase, wimdc, you should ask amotoki kindly for a review
12:49:07 <amotoki_> oh, i was moving. which review? I will check.
12:49:22 <david-lyle> https://blueprints.launchpad.net/horizon/+spec/port-allowed-address-pairs-extension
12:49:25 <wimdc> https://review.openstack.org/#/c/193079/ is the gerrit link.
12:49:33 <david-lyle> ah even better
12:49:41 <david-lyle> thanks amotoki_
12:50:21 <david-lyle> 10 minutes left. Other topics?
12:50:53 <tsufiev> do we have plan B for Keystone changes and LDAP :)?
12:51:09 <mrunge> drop keystone?
12:51:20 * mrunge runs...
12:51:21 <david-lyle> LOL
12:51:36 <mrunge> tsufiev, it seems, we can not really fix it directly
12:51:39 <r1chardj0n3s> lol
12:51:54 <mrunge> I'm counting on integration of searchlight
12:51:54 <r1chardj0n3s> won't searchlight fix it for us? /ducks
12:51:59 <r1chardj0n3s> snap mrunge
12:52:01 <david-lyle> tsufiev: short answer, no
12:52:02 <mrunge> :P
12:52:05 <tsufiev> mrunge, yeah, that's why I think time to rethink UX there...
12:52:26 <ducttape_> the issue w ldap and keystone is the searching / pagination - right?
12:52:30 <r1chardj0n3s> we do have a bunch of places in the UI where we just blindly list users, where a search might be more appropriate
12:52:31 <david-lyle> so searchlight would be useful if keystone didn't punt on pagination across hthe board
12:52:34 <tsufiev> ducttape_, yes
12:52:35 <david-lyle> *the
12:52:36 <mrunge> ducttape_, yes
12:52:49 <robcresswell> Ha, I very much enjoyed this discussion on the mailer.
12:52:52 <david-lyle> because you could take a project list and build from there
12:53:07 <ducttape_> I can't imagine that many deployments would be ok with keeping a shadow copy of ldap in the searchlight db
12:53:17 <ducttape_> for security reasons
12:53:18 <david-lyle> with out anything available in a complete list, there's no way to  do that
12:53:24 <mrunge> shut up ducttape_
12:53:32 <ducttape_> just saying ;P
12:53:33 <mrunge> it's probably good ;-)
12:53:34 <robcresswell> lol
12:54:09 <david-lyle> that's not really the request
12:54:11 <tsufiev> so we need a couple of jedis to convince Keystone folks )
12:54:21 <ducttape_> attn: lhcheng
12:54:33 <mrunge> tsufiev, there is no pagination in ldap-backend
12:54:34 <david-lyle> I want a map of the user project assignments in the searchlight
12:54:39 <mrunge> so, keystone can not fix it
12:54:41 <doug-fish> I'm not sure they can be convinced - without changes to LDAP they just can't do it
12:54:59 <david-lyle> doug-fish: not sure if can't or won't
12:55:06 <david-lyle> but yeah
12:55:08 <ducttape_> here is what I would say, as alternative.....
12:55:19 <ducttape_> users almost always have at least one role assignment
12:55:26 <mrunge> I wonder if it'd be ok to keep a cache of results somewhere for a short lived time
12:55:34 <ducttape_> use the role assignment stuff as a psuedo user listing
12:55:58 <david-lyle> ducttape_: the things is there's no part of the v3 API that supports pagination
12:56:04 <mrunge> we should keep in mind, there are installs out there with 10k of users
12:56:07 <david-lyle> so always an incomplete list
12:56:22 <david-lyle> 10k in elastic search is trivial
12:56:24 <r1chardj0n3s> and Active Directory will error if you ask for > 1000 results
12:56:52 <r1chardj0n3s> filtering (roles, I think is what ducttape_ was getting at) is the only solution with AD
12:56:52 <david-lyle> again, users is not the only way to build such a list
12:57:09 <david-lyle> I want the project list
12:57:16 <ducttape_> yep, we are all saying same thing :D
12:57:22 <david-lyle> and index from there
12:57:24 <david-lyle> yeah
12:57:27 <tsufiev> r1chardj0n3s, btw, Horizon is not robust against that kind of errors. Encountered a customer bug with stripping users of their roles while updating project quotas
12:57:28 <r1chardj0n3s> yep
12:57:34 <r1chardj0n3s> tsufiev: I know :(
12:57:53 <r1chardj0n3s> tsufiev: we had a customer run smack into that too. fortunately we could hard-code an LDAP filter
12:58:18 <david-lyle> we could take a keystone type stance and say you shouldn't do identity management in Horizon
12:58:27 <r1chardj0n3s> oooh
12:58:28 * david-lyle kidding
12:58:29 <doug-fish> ha!
12:58:31 <ducttape_> lolwut
12:58:32 <r1chardj0n3s> d'oh!
12:58:34 <david-lyle> sort of
12:58:43 <r1chardj0n3s> david-lyle for emperor
12:58:55 <fnordahl> hehe. openldap/ad does indeed have paging though. so keystone should be able to cope with it. i'll try to have a look at what they're doing.
12:59:01 <tsufiev> the domino effect for refusals )
12:59:03 <ducttape_> horizon: helpful for 87% of your cloud interactions™®
12:59:06 <doug-fish> tsufiev: r1chardj0n3s is there a bug open for the role-stripping issue?
12:59:13 <robcresswell> ducttape_: hahaa
12:59:33 <r1chardj0n3s> doug-fish: sorry, was some time ago
12:59:39 <tsufiev> doug-fish, think we should create it, the problem is that's hard to reproduce
12:59:54 <tsufiev> without LDAP with >1k of users
13:00:08 <doug-fish> oh I see
13:00:17 <r1chardj0n3s> hm, actually, the problem we had wasn't role stripping, it was just a basic UI break because of the error returned for the >1k user request
13:00:25 <mrunge> fnordahl, not for every backend, at least, what I know
13:00:34 <mrunge> fnordahl, and that's the issue
13:00:43 <david-lyle> food for thought for the afternoon meeting, with plugins building on the REST API we've recently built, does the disclaimer that you can't count on this for anything really hold
13:00:48 <tsufiev> r1chardj0n3s, interesting... https://bugs.launchpad.net/horizon/+bug/1434241 like that?
13:00:48 <openstack> Launchpad bug 1434241 in OpenStack Dashboard (Horizon) " Internal Server Error while updating project quota when using Keystone LDAP backend" [Undecided,New]
13:00:59 <david-lyle> afternoon meeting being Horizon Blueprint Roundtable chat
13:01:06 <r1chardj0n3s> tsufiev: yep, that's the one
13:01:12 <david-lyle> at the alternating horizon meeting time
13:01:20 <david-lyle> because our time is up for now
13:01:20 <tsufiev> r1chardj0n3s, so there are at least 2 problems
13:01:28 <doug-fish> you're asking if our REST API is truely an API with expectations like stability, deprecation cycles, etc?
13:01:45 <david-lyle> Thanks everyone! Feel free to move to #openstack-horizon
13:01:50 <david-lyle> doug-fish: yes
13:01:54 <david-lyle> #endmeeting