12:00:14 <david-lyle> #startmeeting Horizon
12:00:15 <openstack> Meeting started Wed Jul 22 12:00:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:19 <openstack> The meeting name has been set to 'horizon'
12:00:34 <david-lyle> anyone here for Horizon?
12:00:42 <fnordahl> yes
12:01:17 <mrunge> sure
12:01:25 <pkarikh> Yep
12:01:29 <tsufiev> hi there
12:02:18 <david-lyle> A couple of general items to open with
12:02:36 <david-lyle> The Horizon midcycle started yesterday
12:02:49 <david-lyle> approximately 20 people in attendance
12:03:14 <robcresswell> o/
12:03:16 <david-lyle> topics covered were reviewing the liberty priorities
12:03:28 <david-lyle> #link https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities
12:03:44 <amotoki> hi
12:03:57 <david-lyle> a small discussion on translation status
12:04:26 <david-lyle> a small discussion on the code reOrg (related to javascript)
12:04:59 <david-lyle> and finally trying to close the webroot bug
12:05:30 <mrunge> david-lyle, there came 2 bugs connected to that yesterday and the day before
12:05:32 <david-lyle> in the new launch instance, although the scope had crept to a couple more places
12:05:57 <mrunge> metadata admin ui fails the same way
12:06:19 <david-lyle> mrunge: I'll have to test that with the new patch
12:06:25 <mrunge> https://bugs.launchpad.net/horizon/+bug/1476439
12:06:26 <openstack> Launchpad bug 1476439 in OpenStack Dashboard (Horizon) "update_metadata for flavors and images shows blank. static basePath not set correctly." [Undecided,Confirmed]
12:06:57 <mrunge> and a duplicate of that, javascript callbacks didn't work
12:07:14 <david-lyle> ok, I will look today
12:07:49 <mrunge> great
12:08:52 <david-lyle> looks like the patch was approved 3 hours ago and got lost in the gate
12:09:31 <mrunge> there was an issue on the gate, they rebooted the whole thing
12:09:35 <mrunge> if I'm right
12:10:01 <david-lyle> The other topic covered was ducttape_ demoed how his company uses and deploys horizon
12:10:17 <robcresswell> Oh nice
12:10:22 <mrunge> yes!
12:10:29 <mrunge> I'd love to see it
12:10:31 <robcresswell> Any recordings?
12:10:50 <david-lyle> we have a dialin set up and vidyo feed. I don't believe it was recorded
12:11:12 <robcresswell> Ah, I hadn't realised the vidyo was up
12:11:18 <robcresswell> Dang.
12:11:34 <mrunge> yupp, same here
12:11:34 <david-lyle> linked on the etherpad, which I will find
12:12:20 <fnordahl> did the demo give any takeaways / new perspectives from your point of view?
12:12:21 <david-lyle> #link https://etherpad.openstack.org/p/horizon-liberty-midcycle
12:13:32 <david-lyle> I think it was helpful for the group in general, but it's fairly close to how I did it before
12:13:58 <david-lyle> robcresswell, you may be able to talk ducttape_ into a limited repeat
12:14:15 * ducttape_ not sure what I have gotten myself into
12:14:24 <david-lyle> your demo yesterday
12:14:30 <david-lyle> just detailing what was covered
12:14:39 <ducttape_> ah yeah.... only $500 and I can do it again ;)
12:15:04 <mrunge> cough
12:15:10 <david-lyle> the rest of the time was spent split into smaller working/discussion groups
12:15:12 <ducttape_> I can do it again, no worries....  although $500 doesn't hurt
12:15:13 <mrunge> adding to the 3000 to get there
12:15:46 <robcresswell> ducttape_: That would be really helpful. Would definitely help understand your perspective better.
12:16:14 <david-lyle> the wireless bandwidth is not great at the midcycle, so it may be better to do it post midcycle
12:16:20 <ducttape_> if we can get Sean's change merged for the ordering thing, I can show you deploying the fix
12:16:34 <ducttape_> yep. I can do it afterwards
12:16:51 <ducttape_> the wifi at the location is not good
12:16:54 <mrunge> yes, I'd be interested as well
12:16:54 <david-lyle> screen lag became an issue
12:17:24 <david-lyle> that's the report out of the midcycle so far
12:17:32 <david-lyle> 2 more days
12:18:00 <david-lyle> the last general item I wanted to point out is that the UX project was approved by the TC yesterday
12:18:08 <robcresswell> Cool, thanks
12:18:33 <david-lyle> so our fledgling UX effort that's been ramping for a couple of years now is official
12:18:49 <david-lyle> hopefully that will help pull in more UX folks
12:19:29 <david-lyle> There were no items on the agenda for today, so I'll open it up
12:19:35 <david-lyle> #topic Open Discussion
12:20:03 <robcresswell> I got one
12:20:05 <robcresswell> https://review.openstack.org/#/c/141078/
12:20:07 <robcresswell> Curvature
12:20:10 <mrunge> yeah, me too
12:20:17 <mrunge> oh, robcresswell great
12:20:22 <tsufiev> robcresswell, and the linked commit as well ))
12:20:34 <robcresswell> Its now open and has Angular work going on it too
12:20:48 <robcresswell> (ack, forgot the link hash)
12:20:58 <robcresswell> Would be great to get reviews on that
12:21:32 <robcresswell> If the midcycle discussion could fit it in for 5 minutes, that would also be appreciated, but no worries if time doesnt allow.
12:21:38 <robcresswell> That is all :)
12:21:39 <amotoki> one question: it is great but do we replace it completely in this cycle?
12:22:03 <david-lyle> There were a couple of questions about the status yesterday
12:22:28 <david-lyle> amotoki: good question
12:22:52 <robcresswell> How widely used is the current topology? I'm afraid I don't have much info on that
12:23:00 <david-lyle> I'll admit I haven't tried it in a bit, but the last time I wasn't sure it was ready to be a full replacement
12:23:23 <mrunge> I see bug reports based on current topology
12:23:24 <robcresswell> bradjones: ping
12:23:27 <mrunge> so: it is used
12:23:49 <david-lyle> robcresswell: as a visualization tool, I believe it's used
12:23:54 <mrunge> yes!
12:23:59 <amotoki> robcresswell: AFAIK the current topology is usually used to check the current status.
12:24:02 <david-lyle> whether the launch actions etc, I'm not sure
12:24:32 <tsufiev> I remember some buttons (i.e. Terminate Instance) in new topology didn't work for me
12:24:37 <amotoki> most folks I know do create/change/delete from individual panels.
12:24:42 <robcresswell> Not sure if Brad is about. A deprecation path could be considered, perhaps with settings similar to the Launch Instance in Kilo?
12:24:51 <tsufiev> haven't checked though if it was the same for an old topology
12:24:52 <mrunge> yes, you can use it to launch instances, but it is easier to launch it from launch instance workflow
12:25:02 <ducttape_> the current topology page is very helpful / used
12:25:03 <amotoki> robcresswell: +1
12:25:10 <robcresswell> Also if you get a moment, add the concerns to the patch
12:25:21 <mrunge> I wouldn't try to implement launch instance from topology map
12:25:23 <robcresswell> ducttape_: Thanks!
12:25:53 <tsufiev> mrunge, if it's just an overlaying modal, why not?
12:25:55 <robcresswell> mrunge: My point was that we could perhaps include a setting called LEGACY_TOPOLOGY etc
12:26:14 <mrunge> tsufiev, for what?
12:26:17 <robcresswell> and doc it, so it can be enabled by choice, then remove in M cycle.
12:26:26 <robcresswell> something along those lines.
12:26:29 <ducttape_> as soon as you have more than a few instances, and certainly when you have more than one network.... current topology is VERY helpful
12:26:39 <tsufiev> mrunge, well, I meant that technically it's not that difficult :)
12:26:57 <david-lyle> let's get people trying the curvature patch and provide reviews
12:27:06 <robcresswell> david-lyle: +1
12:27:09 <david-lyle> and we'll have a better idea on the steps forward
12:27:13 <ducttape_> if you have docs on how to turn it only, lemme know
12:27:25 <david-lyle> ducttape_: just the patch linked above
12:27:29 <ducttape_> thanks
12:27:35 <david-lyle> it's a full replacement in that patch
12:27:36 <mrunge> tsufiev, I'm speaking about the old one
12:27:42 <robcresswell> ducttape_: Good to know. Curvature aims to solve the issue of larger deployments though. It tends to arrange itself better, iirc. Up for debate though, so please review :)
12:27:46 <bradjones> sorry was reading backlog
12:28:10 <mrunge> but still: do we really need to add stuff already integrated in other functionality?
12:28:49 <david-lyle> mrunge: I think the aim was convenience, I don't know if that was achieved
12:29:28 <mrunge> david-lyle, I agree
12:30:17 <david-lyle> I'll ask for reviews at the midcycle
12:30:29 <robcresswell> david-lyle: Thanks
12:30:33 <bradjones> david-lyle: that will be great thanks
12:30:49 <robcresswell> mrunge, you had something to discuss?
12:30:50 <mrunge> it would be pretty cool, if one could click on a network to launch an instance in that network
12:31:04 <mrunge> yes, it's about django-1.8
12:31:14 <mrunge> I have a few patches up for review
12:31:20 <ducttape_> 1.8 seemed pretty much ready, right?
12:31:25 <mrunge> and I'll be away for next 14 days
12:31:28 <mrunge> yes! it is
12:31:42 <ducttape_> first patch is horizon for auth stuff, then doa - right?
12:31:58 <ducttape_> then back to horizon for final patch
12:32:06 <mrunge> the first thing would be: https://review.openstack.org/201734
12:32:23 <mrunge> then doa
12:32:36 <mrunge> and finally: https://review.openstack.org/201467
12:32:44 <mrunge> to add gating on django-1.8
12:32:54 <mrunge> (non voting first)
12:33:19 <mrunge> doa patch is this one: https://review.openstack.org/167981
12:33:43 <mrunge> and a horizon patch: https://review.openstack.org/#/c/201066/
12:34:47 <david-lyle> ok, I'll test those out again
12:35:01 <mrunge> if there are changes required, please go ahead and change
12:35:06 <robcresswell> Nice work
12:35:15 <david-lyle> I bumped 1.8 supported up in the priority list yesterday
12:35:19 <robcresswell> mrunge: +1, that was going to be my next question
12:35:20 <mrunge> thank you
12:35:44 <david-lyle> thanks mrunge
12:35:53 <david-lyle> and have a nice 2 weeks
12:35:56 <mrunge> most complicated thing is to coordinate doa horizon and project-config
12:36:00 <robcresswell> By end of cycle, will we by testing py34dj18? I've been reviewing alot of the python3 work
12:36:13 <mrunge> uhm in best case: yes
12:36:22 <ducttape_> maybe testing py18dj34 perhaps too?  ;)
12:36:36 <mrunge> but python3 might be a more bumpy road
12:37:08 <mrunge> I'm not sure about xstatic and python3
12:37:12 <mrunge> or other deps
12:37:56 <amotoki> xstatic-* only contain data, so I don't think we have a problem in them. I don't know for other deps.
12:38:46 <ducttape_> I wanted to also bring up https://review.openstack.org/#/c/204197/   I don't want it merged unless it is really ready, but if you guys like it - that bug is a pain point right now.   Not sure if mrunge has more to add
12:39:01 <ducttape_> sorry for changing subject
12:39:24 <mrunge> ducttape_, I really need to do a review there
12:39:35 <mrunge> I am quite sure, it's a major pita for you
12:39:49 <ducttape_> yep that is great / fine.  I don't want to rush it, but I also don't want that one to wait too long  :D
12:41:04 <kzaitsev_mb> ducttape_: it also depends on a commit with unittests.
12:41:23 <kzaitsev_mb> The tests look a bit suspicious though. is it good practice to use assert?
12:41:33 <mrunge> ducttape_, no backport to kilo required, right?
12:41:56 <ducttape_> I don't think so, I think this bug occured in the last 6 weeks
12:42:15 <kzaitsev_mb> mrunge: I think js file discovery was intorduced in liberty, just recently
12:42:42 <david-lyle> yes that was a liberty addition
12:42:54 <mrunge> ok, just to clarify
12:43:06 <ducttape_> js_files.random()  ->  new feature ;)
12:43:34 <david-lyle> kzaitsev_mb: probably not ideal with the asserts, but that file already has that issue, I think that cleanup would be separate
12:44:26 <kzaitsev_mb> david-lyle: actually commit with unit tests is also not merged yet. (=
12:44:46 <david-lyle> oh, that's from a parent patch?
12:44:59 <david-lyle> then we can certainly fix it before it lands
12:45:07 <ducttape_> https://review.openstack.org/#/c/201418/6
12:45:24 <ducttape_> that's a bit of a missed opportunity, merging without tests
12:45:56 <david-lyle> I'm still on the schedule for a rant about process at the midcycle
12:46:01 <david-lyle> :)
12:46:04 <kzaitsev_mb> but yep, the issue does look important enough, to be fixed asap, with cleanup happening later. It was actually me, who asked to add tests to 1st patchset, cause the code looked fragile.
12:46:22 <ducttape_> drop the bomb david-lyle.  hulk angry
12:46:49 <tsufiev> just another topic: i've got news from my colleague who has just returned from keystone midcycle. Seems that they really need some sort of policy editor (with the introduction of dynamic keystone policies)
12:46:55 * david-lyle wonders if he approved that patch
12:46:55 <ducttape_> thanks for asking for that kzaitsev_mb, that was the right way
12:47:18 <kzaitsev_mb> But I guess it could be a commit, that fixes the issue and a separate, dependant, that introduces all the tests. The 1st one would be 1-line and easy to merge. And the 2d one would add all the tests, including the order tests.
12:47:50 <robcresswell> Oh actually, do I have time for another point? I drafted an email, but now might work too
12:47:54 <david-lyle> switch how the asserts is done is just a replace operation, 2 minutes total
12:47:57 <ducttape_> tsufiev - will dynamics polices be done by Oct ?
12:48:14 <david-lyle> tsufiev: that would be my question too
12:49:00 <tsufiev> ducttape_, david-lyle: I do not know estimates because I wasn't there. I will ask him to start the related email thread
12:49:50 <david-lyle> tsufiev: we might check what the Congress team has, I think they've been working on an editor plugin as well
12:49:59 <david-lyle> not sure how great the overlap might be
12:50:02 <ducttape_> robcresswell - your point to bring up?
12:50:11 <david-lyle> bring it
12:50:22 <tsufiev> david-lyle, well, the Congress policies seem quite a different beast to me, more complicated
12:50:43 <david-lyle> you haven't seen the dynamic policy implementation yet ;)
12:51:04 <ducttape_> Congress always seemed simple, easy and efficient.... just like, well.... US Congress   ;)
12:51:21 <david-lyle> was just a thought to avoid duplication of effort
12:51:29 <david-lyle> I'm silly like that
12:51:39 <robcresswell> Since Karma generates pretty JS coverage reports, I was wondering if we could enforce 100% test coverage. Karma is far from perfect in its detection anyway; it is very relaxed, so 100% is not *really* 100% and we can ask for more granularity where needed. Any thoughts? Just been writing a mailer post too. Seems like it would be a very easy way to prevent untested code.
12:52:10 <robcresswell> On the JS side that is. I've rejected a few patches already because the test coverage was far too low (40%)
12:52:32 <david-lyle> robcresswell: my fist question is what are the tests really testing to hit this 100% value?
12:52:40 <amotoki> related to the test coverage, i have one thing to share.
12:52:48 <amotoki> https://bugs.launchpad.net/horizon/+bug/1349841
12:52:50 <openstack> Launchpad bug 1349841 in OpenStack Dashboard (Horizon) juno ""Error: Unable to connect to Neutron" is displayed when instance table displays many instances over 150" [High,Fix released] - Assigned to Matthias Runge (mrunge)
12:52:55 <amotoki> horizon icehouse reached EOL with a big bug. Please see #10 comment.
12:53:16 <robcresswell> david-lyle: It's a mixture of functions being defined etc, branches being tested (if/else)
12:53:32 <robcresswell> My thinking is, that this could be a documented "minimum"
12:54:05 <robcresswell> And then we could ask for more when required. This at the very least, encourages people to write basic testing for all of their code and functions
12:54:41 <robcresswell> It's also very easy to verify; just look at the automated report. Doesn't need a core to block it.
12:55:37 <ducttape_> amotoki - I think that is a bug for sure, but the instance page is going to be terribly slow.  I think we have found any more than 40 or so, and things go pretty slow.   It's not ideal, but there is a workaround to show fewer instances
12:56:49 <david-lyle> ducttape_: we're making a check that isn't valid in icehouse
12:56:56 <david-lyle> due to backpor
12:56:57 <david-lyle> t
12:57:01 <ducttape_> ah ok
12:57:07 <amotoki> ducttape_: the bug does not solve the slowness. my point is that icehouse horizon has a bug in launch instance and EOP icehouse has a prblem
12:57:31 <amotoki> the reason I share is it means we need more testing coverage.
12:58:04 <amotoki> I wonder why we could not catch the bug in the tests :-(
12:58:10 <david-lyle> amotoki: that would have required an integration test
12:58:31 <david-lyle> there was some work on a launch instance integration test but that stalled
12:58:42 <amotoki> david-lyle: agree
12:59:28 <david-lyle> I know tosky has been working hard to make sure the integration tests continue to run
13:00:15 <david-lyle> we just need to keep them stable and continue to grow the coverage
13:01:10 <david-lyle> which goes back to my question to robcresswell, test coverage is nice, but not always a meaningful measure or insurance of correctness
13:01:54 <robcresswell> david-lyle: I agree, but it gives reviewers a workable minimum, rather than just relying on perception
13:02:11 <robcresswell> If we can clearly say, this is only 40%, go and work on it more... I think that helps.
13:02:32 <david-lyle> I would prefer to have 40% coverage where the tests are integration tests at some level (maybe API still mocked) vs 100%, I've mocked everything this method calls and in a vacuum it works perfectly
13:02:44 <robcresswell> But this is karma, its just the UTs
13:02:47 <david-lyle> not that I think that's what the 40% is testing
13:03:23 <david-lyle> oops, over time. Please continue with the mailing post
13:03:29 <robcresswell> Will do, thanks
13:03:54 <david-lyle> Thanks everyone and have a good week. I will post in the horizon room when someone is presenting at the midcycle
13:03:58 <david-lyle> #endmeeting