22:08:01 <jpich> #startmeeting horizon
22:08:02 <openstack> Meeting started Tue Jun 11 22:08:01 2013 UTC.  The chair is jpich. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:08:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:08:06 <openstack> The meeting name has been set to 'horizon'
22:08:39 <jpich> Hi everyone, thanks for being here with us today
22:08:41 <jpich> #topic Blueprints and bugs
22:08:59 <jpich> Ok, the main thing I wanted to bring up is on behalf of mrunge, who doesn't seem to be online anymore
22:09:19 <jpich> there are a couple of very big cleanup patches that have been submitted, mostly about cleaning up the imports
22:10:14 <jpich> It probably would be nice for the authors if we could make an effort at reviewing them quickly enough, so they don't have to be rebased which would probably be a misery
22:11:13 <jpich> ...Anything else relating to bugs and blueprints?
22:11:28 * jpich unfortunately not on top of reviews at the moment so no other comments
22:12:48 <lcheng> I am still working on the v3 auth support for keystone-client.  This is blocking the https://blueprints.launchpad.net/horizon/+spec/login-domain-support
22:13:32 <lcheng> It is currently in review, but probably will still be awhile before it gets merged.  Quite a number of files to review.
22:13:59 <lcheng> That's all from my side.
22:14:18 <jpich> Sounds good! We're just starting havana-2 so I'd assume it'll still be good for this milestone, hopefully
22:15:04 <david-lyle> and I have the domain context support bp done except for a few more unit tests
22:15:10 <david-lyle> next day or so
22:15:13 <jpich> yay unit tests :-)
22:15:21 <david-lyle> then hopefully I can catch up on reviews
22:16:05 <jpich> Cool
22:16:29 <david-lyle> is the ceilometer integration to trunk in progress?
22:16:47 <jpich> david-lyle: It's available at https://github.com/yuanotes/horizon/tree/ceilometer
22:17:19 <david-lyle> thanks!
22:17:26 <jpich> I had a look last week, it looks like it should be submittable through gerrit soon (added a few review comments on the blueprint)
22:17:42 <david-lyle> even better :)
22:17:43 <jpich> I'm not sure what's the best way to review something that's not in gerrit yet
22:17:53 <jpich> https://blueprints.launchpad.net/horizon/+spec/ceilometer
22:18:30 <david-lyle> seems a work in progress submission to gerrit would be easier
22:18:31 <jpich> david-lyle: Feel free to have a look too, my devstack ceilometer self-destructed along the way so I couldn't really look at how it works, only what I assume the code does :-)
22:19:01 <jpich> I find multiple commits in a series like that can be awkward to review as well though
22:19:30 <jpich> The git history can definitely be improved with a bit of squashing in this case. We'll see how it goes, I agree we should get it in gerrit soon
22:20:06 <jpich> #topic Open discussion
22:20:43 <jpich> If anyone has anything somewhat Horizon related they'd like to bring up, go for it
22:22:02 <david-lyle> any strong opinions re: HACKING.rst?
22:22:47 <david-lyle> I know there are some patches moving in that direction
22:23:00 <jpich> Not particularly. It looks like it should help make things more consistent?
22:23:13 <jpich> That's the way the consensus seemed to go on the mailing list, yeah. Do you have concerns?
22:23:59 <david-lyle> not really, just didn't really get a feel for a Horizon consensus
22:26:17 <jpich> True. The general feeling seems to be that this increases the consistency with the other projects, and should help with rebases and style consistency
22:26:52 <david-lyle> anything to helps reduce rebases is certainly a plus
22:27:37 <kspear> i'm not too fond of "import only modules" when it comes to classes
22:28:01 <kspear> and i think we should talk about new-style relative imports at some point
22:28:30 <kspear> i don't see the danger of the new-style
22:29:03 <david-lyle> nor do I
22:29:26 <jpich> If that's something that can/should be done as part of the patches for hacking.rst, it sounds like it would be worthwhile bringing up now
22:29:27 <kspear> because of the nesting in openstack_dashboard our import lines can get huge
22:29:30 <jpich> as a bug or a ML dicussion?
22:29:45 <kspear> i'll add a reply to the ML discussion
22:30:12 <kspear> it is important we stay reasonably consistent with the rest of openstack
22:30:20 <kspear> so would be good to get consensus on it
22:30:26 <jpich> thanks kspear
22:30:30 <clarkb> is anyone interested in implementing/fixing https://bugs.launchpad.net/horizon/+bug/1177924 ? we (the CI team) are trying to testr all of the projects where it makes sense (and currently we think that is true for just about all of them). gabrielhurley did some preliminary investigation I think and I would be happy to help someone fix that
22:30:33 <uvirtbot> Launchpad bug 1177924 in cinder "Use testr instead of nose as the unittest runner." [Medium,In progress]
22:30:56 <kspear> clarkb: I looked into that briefly
22:31:10 <kspear> seems we need a django test runner that runs testr?
22:31:25 <clarkb> kspear: are you using a django test runner or just nose?
22:31:30 <clarkb> I thought you guys were just running nose
22:31:42 <kspear> we use django_nose
22:31:48 <kspear> which does the same thing for nose
22:31:56 <kspear> it's a test runner that runs nose
22:32:10 <clarkb> I see
22:32:21 <kspear> the test runner is important because there's special django setup that needs to be done
22:32:35 <lifeless> which is a massive django bug :)
22:33:05 <lifeless> anyhow, what you need is a custom runner that will glue a subunit result object in, which is about 10 lines.
22:33:27 <kspear> lifeless: can you help with that?
22:33:56 <kspear> i don't have any experience with testr/subunit
22:34:50 <lifeless> kspear: I can certainly advise
22:35:02 <lifeless> its been a while since I actively poked at django
22:36:01 <kspear> lifeless: thanks. well i'll see how far I get, couldn't see see any examples on the web of where this has been done before
22:36:26 <lifeless> kspear: if you look at the source for subunit.run it should be pretty obvious:
22:37:30 <lifeless> where you do suite.run(result), result should be a testtools.ExtendedToStreamResult(subunit.v2.StreamResultToBytes(sys.stdout))
22:37:30 <kspear> lifeless: okay, will do.
22:37:52 <lifeless> kspear: + you need to implement the list-tests and load-list features, to let testr enumerate and select tests to run.
22:38:32 <lifeless> kspear: http://testrepository.readthedocs.org/en/latest/MANUAL.html#listing-tests and http://testrepository.readthedocs.org/en/latest/MANUAL.html#running-tests
22:39:29 <kspear> lifeless: cool, thanks for the pointers
22:39:56 <lifeless> kspear: so you should be able to keep your current django suite stuff (per https://docs.djangoproject.com/en/1.2/topics/testing/#defining-a-test-runner) and just override the result, plus add teh load-and-list facilities.
22:40:03 <lifeless> kspear: please reach out on any issues
22:40:29 <kspear> lifeless: will do, thanks
22:42:27 <jpich> Cool, thanks
22:42:32 <jpich> Anything else from anyone?
22:45:06 <jpich> Thank you everyone, have a nice day/afternoon/evening/night :)
22:45:09 <jpich> #endmeeting