20:03:18 <david-lyle> #startmeeting Horizon
20:03:18 <openstack> Meeting started Wed Jul 15 20:03:18 2015 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:21 <openstack> The meeting name has been set to 'horizon'
20:03:25 <btully> %/
20:03:31 <kzaitsev_mb> o/
20:03:32 <peristeri> o/
20:03:36 <crobertsrh> hello/
20:03:48 <doug-fish> hi
20:04:26 <bpokorny> Hi
20:05:13 <david-lyle> the gangs all here
20:05:23 <r1chardj0n3s> yep
20:06:39 <david-lyle> The only general lead in I have is that the midcycle is next week
20:06:59 <david-lyle> we are working on a video conf solution for remote participants
20:07:08 <david-lyle> and by we, I mean someone else ;)
20:07:16 <kzaitsev_mb> (=
20:07:46 <r1chardj0n3s> I've been told that vidyo should support >10 participants
20:08:04 <robcresswell> \o/
20:08:22 <david-lyle> There was a question around the weekly meeting next week. It will be at 6am Fort Collins time, so I can still run it if desired
20:08:23 <robcresswell> Yeah if there's some type of video, that would be great
20:08:45 <r1chardj0n3s> getting a camera/mic is up to someone else, as I tried the one I have and it didn't work :)
20:08:54 <esp> I think hp myrooms suports 250
20:08:56 <robcresswell> Me or Matthias could run it, if thats easier. It was more if it should still be held with all the cores busy?
20:09:09 <david-lyle> other than r1chardj0n3s and doug-fish I don't think anyone that usually attends will be here
20:09:20 <david-lyle> rather than home
20:09:44 <david-lyle> probably asking the wrong group
20:09:48 <david-lyle> :)
20:10:10 <mrunge> yeah, maybe
20:10:14 <david-lyle> I'll just hold it
20:10:20 <robcresswell> Sure
20:10:27 <david-lyle> if we quit early, so be it
20:10:59 <david-lyle> There is a UX project proposal up, from Piet to add UX to openstack
20:11:08 <david-lyle> which may be of interest to some
20:11:27 <Piet> Terrible idea!  -1!
20:11:39 <robcresswell> Who even is that piet guy
20:11:46 <robcresswell> :)
20:11:47 <david-lyle> #link https://review.openstack.org/199768
20:11:50 <Piet> mouth breather
20:11:57 <david-lyle> don't get me started
20:12:17 <david-lyle> seemed to be generally supported, some minor concerns from the TC
20:13:11 <david-lyle> last general thing, I posted some review criteria, to explicitly spell out expectations
20:13:15 <david-lyle> #link https://wiki.openstack.org/wiki/Horizon/Reviews
20:14:05 <david-lyle> IMO we've been getting a little lax and I'd like to see that corrected
20:14:26 <ducttape_> do we need more rules, or better adoption of those listed?
20:14:29 <r1chardj0n3s> +1 guidelines
20:14:55 <mrunge> better adoption, I think the rules are clear
20:14:59 <david-lyle> ducttape_: in the past the guidelines were tribal knowledge, this just documents them
20:15:18 <david-lyle> tribal knowledge doesn't share as easily
20:15:23 <ducttape_> should we have listed that each +2 should be from a different company?
20:15:27 <robcresswell> One nitpick to tag on, when you approve patches, can you please also make sure the bug is targeted/ prioritised and the patch is attached properly (sometimes auto-infra doesnt work)
20:15:41 <doug-fish> listing them in a wiki is a great idea
20:16:02 <mrunge> robcresswell +1
20:16:09 <mrunge> it's a wiki, that should be added
20:16:13 <doug-fish> ducttape_: is that true? (each +2 from a different company) I thought as long as the submitter and both approvers were not from the same company all was good
20:16:41 <ducttape_> not sure, I have heard different versions of the "lets get broad adoption for merging" rule
20:16:41 <doug-fish> I don't see it in the wiki
20:16:57 <david-lyle> ducttape_: the rule I've been advocating is of the author, and two core reviewers one of the three needed to be from a different company
20:17:13 <doug-fish> david-lyle: maybe you could capture that in the wiki?
20:17:17 <david-lyle> sure
20:17:21 <doug-fish> thx
20:17:22 <david-lyle> I'll add it post meeting
20:17:55 <mrunge> and please add to check, bug is targeted correctly, prioritized
20:18:02 <mrunge> as robcresswell mentioned
20:18:49 <robcresswell> Yeah, and listed against the bug, recently infra keeps saying Fix Commited without linking the patch so I end up chasing them down.
20:18:55 <david-lyle> if there are concerns that the 1 of 3 rule is causing problems please raise it privately or publicly
20:19:40 <david-lyle> I also cleaned up the d-o-a project in launchpad today, will try to tackle horizon in the next few
20:19:50 * david-lyle knows that will go much slower
20:20:13 <david-lyle> so you can target bugs in d-o-a to a milestone as well
20:20:36 * ducttape_ looks forward to doa and django 1.8
20:20:52 <david-lyle> Today's agenda can be found at:
20:20:55 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/Horizon
20:20:59 <mrunge> if there's a milestone missing, it seems I am able to create tags, versions etc. in launchpad. too
20:21:05 <lhcheng> my concern is although 1 of 3 is followed, but all three have the same motive. It kinda work around the rule.
20:21:38 <kzaitsev_mb> david-lyle: seems like I added the only item to the agenda =)
20:21:52 <david-lyle> lhcheng: if that goal of the motive is outside the scope of the project, then we have a problem
20:22:15 <david-lyle> if the goal is correct and the means to get there are a problem, we should discuss that
20:22:54 <david-lyle> let's table that for just a minute and hear kzaitsev_mb
20:23:00 <ducttape_> lhcheng  - I think the spirit of the rule is "the change should try to gather broad input, and see reasonable effort made so that anyone interested can review"
20:23:11 <david-lyle> #topic Choosing a CPL (https://wiki.openstack.org/wiki/CrossProjectLiaisons) for OSLO
20:23:19 <lhcheng> david-lyle: sure
20:23:49 <david-lyle> so kzaitsev_mb you're volunteering, is that correct?
20:24:08 <kzaitsev_mb> well, the topic actually says it all. I've been contacted by dims_ earlier this week, and he asked if I'd like to volounteer for that position
20:24:21 <kzaitsev_mb> david-lyle: yep, I pretty much would like to )
20:24:27 <david-lyle> there's a lot of competition ;)
20:24:31 <kzaitsev_mb> if that's ok with everyone )
20:24:45 <kzaitsev_mb> I'll try to do my best (=
20:25:03 <david-lyle> I have no issue with it, anyone else?
20:25:07 <lhcheng> ++ for me
20:25:17 <mrunge> 1+ from me
20:25:24 <doug-fish> no concern here - thanks for volunterring kzaitsev_mb!
20:25:38 <mrunge> and if he doesn't behave, we'll kick him out again?
20:25:49 <mrunge> thank you for stepping up kzaitsev_mb !
20:25:49 <david-lyle> kzaitsev_mb: please add yourself to the wiki, and thanks for stepping up
20:25:58 <kzaitsev_mb> ok, will do =)
20:25:59 <lhcheng> thanks kzaitsev_mb
20:26:12 <david-lyle> agenda complete!
20:26:20 <kzaitsev_mb> "And now my watch begins" or something (=
20:26:21 <david-lyle> #topic Open Discussion
20:26:31 <david-lyle> go ahead lhcheng
20:26:41 <david-lyle> sorry to cut you off before
20:27:46 <lhcheng> no worries, I guess the reason we have the 1 of 3 rule is so that we can control code getting pushed without broader review
20:28:15 <doug-fish> lhcheng: are you thinking patches get approved too quickly and there is no chance for review?
20:28:39 <doug-fish> *some patches, not all
20:28:39 <mrunge> iirc, that was to prevent code rushed in, which was dominated by just a single company
20:28:40 <lhcheng> doug-fish: approved too quickly
20:29:59 <doug-fish> lhcheng: maybe we should have some minimum age/time we generally let the patches sit before they get merged?
20:30:11 <tqtran> isn't that the point of having many cores? to get eyes on things. usually it takes a day or two to merge, is that not enough time?
20:30:14 <ducttape_> right, what would be reasonable review time?
20:30:54 <david-lyle> Ok, the historical reason was when I started 2 companies were the most active contributors and had different motivations, but worked well together. My original concern was getting two major currents going in horizon that wouldn't necessarily line up
20:31:24 <david-lyle> it seems we may have those two currents now and the split is no longer at company boundaries
20:31:42 <david-lyle> so the rule is too simple
20:31:45 <ducttape_> +1
20:32:02 <david-lyle> there is a strong push to change and change rapidly
20:32:06 <lhcheng> doug-fish: at least get the patch pass gate first even before approving
20:32:19 <doug-fish> david-lyle: : just to make those 2 current clear to those of us who lack social sensitivity can you spell out the 2 currents you see?
20:32:24 <david-lyle> and there is a strong push by those deploying horizon and actively use it, to do so more sanely
20:32:27 <doug-fish> lhcheng: yeah, that's probably a good idea!
20:33:24 <david-lyle> and developers in those two camps don't necessarily understand the implications of changes for the other
20:33:38 <ducttape_> doug-fish - this is an oversimplification, but new code right away vs the need to be able to have horizon in a good working state 100%
20:33:54 <doug-fish> yeah ok, I got it now.
20:34:06 * david-lyle thinks he said something like that
20:34:09 <tqtran> i agree, but isnt majority of new code disabled by default?
20:34:30 <david-lyle> tqtran: only the end features of it
20:34:41 <ducttape_> I think that's missing the point
20:34:47 <mrunge> yupp
20:34:52 <tqtran> there are a few infra changes that did get through, i agree those should have been more strict
20:35:00 <ducttape_> if you can check in whatever you like, so long as it is disabled.... thats not correct
20:35:13 <david-lyle> and building iteratively is ok, as long as code is not the only thing being created
20:35:14 <lhcheng> hmm even if its disabled code, it should still be working code
20:35:21 <lhcheng> with test too
20:35:28 <mrunge> and it should be checked on the gate properly
20:35:44 <tqtran> nothing merges without getting checked at gate?
20:35:52 <david-lyle> tests and docs are not a tax, they protect the developer too
20:36:03 <mrunge> if you don't write tests, it's not checked
20:36:16 <david-lyle> otherwise the next partial piece comes along and breaks the change you just made
20:36:49 <tqtran> i agree some of the patches didn't include tests, but i would say most of the newer patches do contain them, in fact more so than previously
20:37:44 <tqtran> if you guys took a look at them, you would notice that a majority of the time, the spec files are bigger than the code
20:37:47 <david-lyle> the lack of tests is not just a angular vs django thing either
20:37:57 <mrunge> it's not fingerpointing at anyone, we just need to make sure, code is production ready, not ready to be tested by other developers
20:38:00 <tqtran> i agree, some infra stuff did get in w/o proper tests
20:38:15 <tqtran> but theres only one that i can think of off the top of my head
20:38:56 <tqtran> mrunge: understood, i agree that going forward, tests and docs should be prioritize
20:39:12 <ducttape_> tqtran:  this change was +2 within a 3 min window - https://review.openstack.org/#/c/200324/
20:39:25 <ducttape_> and I didn't see any tests
20:39:27 <lhcheng> mrunge: agree, we want to agree to some guideline on quality of code
20:39:54 <david-lyle> For the me the goal here is make clear the expectations and do a bit of a reset
20:39:59 <tqtran> ducttape_: how would you test that?
20:40:04 <david-lyle> otherwise we will all be paying down the road
20:40:17 <tqtran> sure thats fair
20:40:25 <doug-fish> david-lyle: yeah that's a good approach.
20:40:35 <ducttape_> tqtran - thats the question a core should be asking ;)
20:40:38 <david-lyle> tqtran: load the panel and test that it renders, much like any of the index views
20:40:47 <doug-fish> I've been contributing here and there to other projects - they are much more strict about testing that we have been in Horizon
20:40:48 <tqtran> as in manual testing?
20:41:14 <david-lyle> tqtran: we have the ability to write selenium tests if need be
20:41:30 <lhcheng> doug-fish: true, no tests/doc is immediately -1
20:41:34 <tqtran> so, do we normally tests new panels/dashboards via selenium?
20:41:46 <lhcheng> doug-fish: at least for keystone
20:41:49 <tqtran> im just trying to setup a consensus and norm
20:41:52 <david-lyle> tqtran: with django we didn't need selenium to do that
20:41:58 <doug-fish> even heat requires unit tests!
20:41:59 <ducttape_> we usually use django's test runner
20:42:02 <mrunge> tqtran, in the past, we didn't need selenium
20:42:07 <david-lyle> because the page was rendered server side
20:42:12 <mrunge> now, we need some rendering engine
20:42:50 <tqtran> so my question is simple, for new panels/dashboards, do we have existing tests for them? and if not, are we expecting programmatic tests for them?
20:42:58 <david-lyle> but we did use selenium to validate some Javascript code
20:43:32 <david-lyle> that has been the case yes
20:43:36 <mrunge> tqtran, for django based panels: as david said. and yes, we're expecting programmatic tests
20:43:41 <tqtran> i have a feeling that many more panels are going to get angularize going forward, so this is something i would be interested to know
20:44:27 <tqtran> i think david-lyle is referring to just manual testing, so we'd have to come up with a programmatic way to test it then. sounds about right?
20:44:37 <david-lyle> tqtran: no programmatic
20:44:42 <ducttape_> this would be something to be done with the first commit....  "this is how you test ng stuff"
20:44:51 <mrunge> tqtran, manual testing should be an exception
20:45:10 <mrunge> we need automatic testing
20:45:15 <tqtran> ok, you guys are telling me two different things here
20:45:29 <david-lyle> tqtran: I don't think we are
20:45:33 <tqtran> ducttape_: most of the patches include testing messages in the commit body
20:45:53 <david-lyle> ok, that is different
20:45:59 <david-lyle> but yes that is necessary too
20:46:01 <ducttape_> I mean automated tests, not in a commit message
20:46:31 <mrunge> how can we exclude regressions, if features are not tested at each commit?
20:46:32 <ducttape_> I mean as you guys blaze that trail, to have a solid example for others to follow
20:46:33 <tqtran> would someone like to volunteer on creating this automated test for new panel/dashboard?
20:46:49 <mwhagedorn> most of the new angular stuff seems to have jasmine tests.. what am I missing?
20:47:27 <tqtran> if that is something you guys want, someone should step up to the plate, i sure got mine full :P
20:47:41 <david-lyle> huh
20:47:42 <lhcheng> mwhagedorn: that only test the client side, how the data is passed from rest to client is not.
20:48:24 <doug-fish> lhcheng: are you talking about integration tests?
20:48:27 <mwhagedorn> like end to end testing/selenium
20:48:29 <mwhagedorn> ?
20:48:41 <tqtran> lhcheng:  you mean like integration tests? or https://github.com/openstack/horizon/blob/master/openstack_dashboard/test/api_tests/keystone_rest_tests.py ?
20:48:42 <ducttape_> https://i.imgflip.com/o91iz.jpg
20:49:04 <mrunge> tqtran, integration tests would be ideal
20:49:04 <lhcheng> doug-fish: not integration test
20:49:11 <mwhagedorn> ducttape_: moce
20:49:15 <mwhagedorn> nice
20:49:17 <mwhagedorn> :)
20:49:19 <mrunge> but, that's probably too much
20:49:22 <lhcheng> integration tests means horizon is tested with other services
20:49:42 <tqtran> so just unit rest tests?
20:49:45 <tqtran> we have those....
20:49:45 <david-lyle> most horizon tests to this point have been a hybrid
20:50:02 <david-lyle> they're not really unit tests
20:50:11 <david-lyle> because we're not testing one method at a time
20:50:26 <mwhagedorn> do we need to set expectations in the docs for what a good test looks like then?
20:50:36 <david-lyle> we're testing that methods work in association with the pages that are rendered
20:50:56 <tqtran> david-lyle: for legacy code? or the newer code?
20:51:01 <david-lyle> testing get_context_data while mocking the data source is worthless
20:51:22 <david-lyle> tqtran: django based code
20:52:44 <david-lyle> so the goal of a core reviewer is ultimately a stable and functioning project
20:53:12 <david-lyle> change is done with respect to that stability and continued functionality
20:53:28 <david-lyle> if something needs to change drastically, it needs to be documented
20:53:35 <david-lyle> so that people can consume it
20:53:49 <david-lyle> without ripping out their hair for days on end
20:54:04 <david-lyle> I'm not saying we've been perfect at that
20:54:08 <david-lyle> it is the goal
20:54:29 <mrunge> yes!
20:55:03 <mwhagedorn> I am still a little in the dark then what qualifies as a good test from the core perspective
20:55:07 <mwhagedorn> whats lacking
20:55:18 <mwhagedorn> whats needed to get things more in line with larger goals
20:55:27 <ducttape_> mwhagedorn - I think there are patterns for old school horizon changes
20:55:53 <ducttape_> and the new stuff is all over the map on how much it does or does not have for tests, and which type
20:56:09 <ducttape_> we are struggling to reach consensus on what is correct
20:56:16 <mwhagedorn> ducttape_ : sure but wouldnt you agree that its hard to tell what the legacy tests actually test sometimes?
20:56:43 <mrunge> oh, mwhagedorn that's easy
20:56:44 <hurgleburgler> There is some old stuff that isn't currently being tested at all as well
20:56:46 <ducttape_> I'm strange, I understand the old tests very well.  you should ask a normal person
20:56:50 <hurgleburgler> do we know what kind of coverage we currently have?
20:56:51 <tqtran> ducttape_: i think thats an unfair statement, most of the angular patches come with spec files (there were exceptions in kilo).
20:56:54 <david-lyle> mwhagedorn: depends on if you understand how mox and django work
20:57:32 <mwhagedorn> mox is pretty much user-viscious imho
20:57:32 <tqtran> but test for the patches in kilo have since been added
20:57:39 <david-lyle> tqtran: again, to me this is not a clean cut case of angular vs django
20:57:50 <ducttape_> tqtran - would you agree we are trying to reach consensus on what is appropriate for ng style testing, when you are adding a new feature?
20:57:53 <peristeri> code coverage can help the reviewer see what has not been tested. It is not bullet proof but better then nothing
20:58:16 <tqtran> right, thats what karma is there for
20:58:41 <hurgleburgler> that's just js thought, right?
20:58:45 <hurgleburgler> though*
20:58:56 <tqtran> correct, just js part
20:58:56 <mrunge> tqtran, for example, new launch instance couldn't create a volume during launching an instance
20:58:58 <david-lyle> coverage can be run on any horizon build
20:59:09 <mrunge> that would have been caught very early
20:59:15 <mwhagedorn> you can get coverage on the django stuff hurgleburgler....
20:59:20 <mrunge> if there was a test for it
21:00:28 <david-lyle> looks like time is up.
21:00:43 <tqtran> ok, so what im hearing is, more tests and docs. but going back to mwhagedorn, what are expections/standards for them?
21:00:50 <mwhagedorn> yes
21:00:55 <mwhagedorn> someone help me :)
21:01:06 * robcresswell is following all this, btw, but also eating dinner :)
21:01:14 <tqtran> and popcorn
21:01:17 <tqtran> hahaha
21:01:34 * esp just finished some nachos and a coke
21:01:45 * ducttape_ always brings a cold beverage to these things
21:01:54 <robcresswell> The drama here is better than tv :)
21:02:17 <hurgleburgler> Good Times ಠ◡ಠ
21:02:18 <mrunge> you can switch off tv and don't need to care about it any more
21:02:30 <hurgleburgler> I'll have to bring pop corn to the mid cycle
21:02:36 * david-lyle bites tongue
21:02:39 <robcresswell> I'm happy to help out with docs stuff. Me and bradjones are working on a formal doc for angular panels/dashboards and adding external plugins etc
21:02:41 <david-lyle> #nedmeeting
21:02:48 <r1chardj0n3s> ned meeting who?
21:02:52 <hurgleburgler> stark??
21:02:53 * r1chardj0n3s ducks
21:03:06 <david-lyle> #action david-lyle document testing
21:03:12 <david-lyle> #endmeeting