[10:14] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Convert reporting handlers to be instantiated.  https://review.openstack.org/202960
[11:53] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Implementation of a simple registry.  https://review.openstack.org/202990
[12:08] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Convert reporting handlers to be instantiated.  https://review.openstack.org/202960
[13:24] <smoser> Odd_Bloke, what is ropeproject ?
[13:24] <smoser> https://review.openstack.org/#/c/202960/2/tox.ini
[13:35] <Odd_Bloke> smoser: A Python refactoring library which vim can use.
[13:36] <smoser> you can teach me how to use that sometime.
[13:36] <smoser> please
[13:37] <smoser> do you have any idea why py26 was broken and is now fixe d?
[13:37] <smoser> ie, initially jenkins https://review.openstack.org/#/c/202576/ failed. the 'review' comment made it happy
[13:37] <smoser> er.. recheck
[13:58] <Odd_Bloke> smoser: It looks like a new version of mock was released between the first and the second.
[13:58] <Odd_Bloke> 1.1.3 is installed in the failing one, and 1.1.4 in the succeeding one.
[13:58] <Odd_Bloke> Which would make sense; I'd heard from someone else that they'd broken 2.6 support in mock.
[13:58] <Odd_Bloke> Presumably they have now fixed it.
[13:58] <Odd_Bloke> smoser: The registry is just a library thing that we can use where we need it.
[14:00] <Odd_Bloke> smoser: I'm going to use it in two ways in the reporting stuff: firstly, a registry of available reporters (i.e. mapping config names to actual classes), and secondly, a registry of the instantiated reporters (which the actual event reporting code will use).
[14:01] <Odd_Bloke> smoser: There will probably be further changes to it, but I figured getting the basic stuff out of the way would make other changes easier to review.
[14:01] <smoser> i really hate the internet
[14:02] <Odd_Bloke> ?
[14:07] <smoser> Odd_Bloke, i hate that random dude on the interenet uploads mock 1.1.3 and breaks my tests
[14:07] <smoser> causing me to have to spend time figuring out why they're broken.
[14:07] <smoser> i find that anti-productive.
[14:08] <Odd_Bloke> smoser: Random dude on the Internet also wrote mock, meaning that writing our tests is much easier.
[14:08] <Odd_Bloke> So I wouldn't be too harsh on him. ;)
[14:08] <smoser> clearly. and he probably makes less stupid mistakes than i do.
[14:09] <smoser> but being human the number of stupid mistakes per unit of time > 0.
[14:09] <smoser> and the count of random dudes is > 0
[14:09] <smoser> so the time lost on such things is definitely non-zero
[14:10] <Odd_Bloke> I'd still argue less than the cost of reimplementing everything yourself.
[14:10] <Odd_Bloke> So net gain is positive.
[14:10] <smoser> i'm not complaining about using libraries
[14:10] <Odd_Bloke> We should consider pinning our dependencies though.
[14:10] <smoser> i'm complaining about them moving
[14:10] <smoser> i complain when you break something in an ubuntu sru
[14:11] <smoser> i like stable
[14:26] <smoser> Odd_Bloke, i'll pll your reporting handlers instantiated
[14:26] <smoser> i know its obnoxious
[14:27] <smoser> i know its painful.. but please do not just throw additional changes in
[14:27] <smoser> you're more than welcome to keep me honest on that also
[14:29] <Odd_Bloke> smoser: 'do not just throw additional changes in'?
[14:29] <smoser> ropeproject
[14:30] <Odd_Bloke> Ah, yeah.
[14:30] <Odd_Bloke> Yep, will avoid doing it in future.
[15:04] <smoser> Odd_Bloke, you have a thought on how to fix http://logs.openstack.org/43/202743/1/check/gate-cloud-init-python27/1cf650f/console.html
[15:05] <smoser> http://paste.ubuntu.com/11893139/ is what ihave, an dit does work, but what is in that review now seems prettier
[15:09] <Odd_Bloke> smoser: Having a look now.
[15:09] <smoser> if i dont catch stderr, it goes to console
[15:12] <Odd_Bloke> smoser: Patch 'cloudinit.shell.sys.stderr' and then look at .write on the object passed to the test method.
[15:12] <Odd_Bloke> The problem is trying to swap out just the 'write' method.
[15:12] <Odd_Bloke> smoser: Also, you have shell.py and test_main.py; would be good to make those the same name (as it took me a while to find one from the other). :)
[15:13] <smoser> k
[15:13] <smoser> so you can do 'cloudinit.shell.sys.stderr' ?
[15:13] <smoser> and that patches cloudinit.shell's usage of sys.stderr only ?
[15:15] <Odd_Bloke> Yep.
[15:16] <Odd_Bloke> (Unless anywhere else is doing something stupid like 'from cloudinit.shell import sys', but that shouldn't every make it past code review :p)
[15:20] <harlowja_at_home> smoser, https://github.com/openstack/oslotest/blob/master/oslotest/output.py is what most of openstack does for this
[15:20] <harlowja_at_home> perhaps u can do something similar?
[15:20] <harlowja_at_home> yes yes, i know, more fixtures :-P
[15:20] <harlowja_at_home> but something like https://github.com/openstack/oslotest/blob/master/oslotest/output.py#L46 might work for u
[15:25] <openstackgerrit> Merged stackforge/cloud-init: Convert reporting handlers to be instantiated.  https://review.openstack.org/202960
[15:26] <openstackgerrit> Merged stackforge/cloud-init: README.rst: mention bugs are tracked in launchpad  https://review.openstack.org/202576
[15:32] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Implementation of a simple registry.  https://review.openstack.org/202990
[15:38] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Use a registry to configure reporting handlers.  https://review.openstack.org/203093
[15:38] <openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Implement a DictRegistry.  https://review.openstack.org/203094
[15:39] <smoser> harlowja_at_home, Odd_Bloke http://paste.ubuntu.com/11893290/
[15:39] <smoser> that looks pretty nice, and works in py27 and py34, but raises
[15:39] <smoser>  http://paste.ubuntu.com/11893291/
[15:40] <smoser> on py26.
[15:40] <smoser> i believe that we discussed something about this , but i am not recalling details.
[15:40] <Odd_Bloke> smoser: This comes back to my not wanting to use testtools' TestCase, because you can't use that assertRaises syntax on 2.6.
[15:40] <Odd_Bloke> (Whereas you can if you use unittest2.TestCase)
[15:41] <harlowja_at_home> trade-offs either way
[15:41] <smoser> ok. i'll avoid it for now. it does look pretty though :)
[15:44] <Odd_Bloke> testtools should be using unittest2 by default (at some point).
[15:45] <Odd_Bloke> Oh, it does.
[15:45] <Odd_Bloke> But overrides the context-manager assertRaises. /o\
[15:50] <smoser> Odd_Bloke, http://paste.ubuntu.com/11893330/
[15:50] <smoser> that works, does it seem sane to you ?
[15:51] <Odd_Bloke> smoser: You should be able to do something like 'sys_exit_exc = self.assertRaises(SystemExit, ...)', but I'm happy with that.
[15:52] <Odd_Bloke> smoser: Though maybe go for 'assertIsNotNone' instead of 'assertTrue', to make it clearer that you're trying to avoid the value you set initially.
[15:53] <smoser> i tried that.
[15:53] <smoser> AttributeError: 'TestMain' object has no attribute 'assertIsNotNone'
[15:53] <Odd_Bloke> Everywhere or on 2.6?
[15:53] <smoser> 2.6
[15:53] <Odd_Bloke> *flips table*
[15:53] <smoser> Odd_Bloke, with self.assertRaises ...
[15:54] <smoser> can i get the exception that was raised ?
[15:54] <smoser> cause otherwise i can't check the .code
[15:54] <Odd_Bloke> smoser: Yeah, it should return it.
[15:54] <smoser> oh. i didn't realize that. nice.
[15:54] <Odd_Bloke> smoser: But maybe not on Python 2.6, because apparently everything I know about unittest isn't true there. ;)
[16:00] <smoser> i dont think it does.
[16:03] <smoser> http://paste.ubuntu.com/11893374/
[16:03] <smoser> produces http://paste.ubuntu.com/11893375/
[16:04] <smatzek_> unittest lacks various assert methods in 2.6 and it's a pain.  I ended up having to write my own that mimiced the 2.7 methods in a parent test class to UT on 2.6 when my project used to support that level.
[16:04] <Odd_Bloke> smoser: What about with testtools.TestCase?
[16:05] <smoser> yeah, there its fine.
[16:06] <Odd_Bloke> Right, that's the superclass of cloud-init's TestCase.
[16:06] <Odd_Bloke> So you _should_ be fine.
[16:06] <Odd_Bloke> But, again, YMMV. :p
[16:07] <Odd_Bloke> smatzek_: unittest2 FTW. :)
[16:07] <Odd_Bloke> Unless you're working on a project with harlowja_at_home, apparently. ;)
[16:07] <harlowja_at_home> and/or all of openstack, lol
[16:08] <Odd_Bloke> harlowja_at_home: Aren't those the same thing? :p
[16:08] <harlowja_at_home> :)
[16:08] <harlowja_at_home> perhaps, hahaha
[16:08]  * harlowja_at_home pumps out various thousands of lines of code a day (under different names)
[16:08] <harlowja_at_home> don't tell anyone....
[16:08] <Odd_Bloke> I've never actually seen harlowja_at_home in the same room as anyone else.
[16:08] <harlowja_at_home> why testtools overrode assertRaises u got me
[16:09] <Odd_Bloke> So you could theoretically be everyone.
[16:09] <Odd_Bloke> That's hard science.
[16:09] <harlowja_at_home> quantum space-time
[16:09] <Odd_Bloke> harlowja_at_home: I'm guessing it was for 2.6 backwards compatibility before they used unittest2.
[16:09] <harlowja_at_home> prob
[16:09] <harlowja_at_home> and the api stuck
[16:10] <harlowja_at_home> and thats how the story was written
[16:10] <Odd_Bloke> Well, it's their own implementation of assertRaises.
[16:10] <Odd_Bloke> So it would probably take work to make it a context manager.
[16:10] <Odd_Bloke> So I suspect it's just that no-one has cared. :p
[16:10] <Odd_Bloke> Perhaps I'll care at some point.
[16:11] <harlowja_at_home> ya, or the api they created for assertRaises in testtools can't now be changed (since people depend on its behavior) and its just unforutante that python/unittest2 used the same name
[16:12] <harlowja_at_home> but probably really easy to add a proxy method to the unittest2 one under a different name...
[16:12] <Odd_Bloke> You could make it a context manager without changing the API for non-CM uses.
[16:12] <harlowja_at_home> ok, or that
[16:12] <harlowja_at_home> get er done
[16:12] <Odd_Bloke> :p
[16:24] <openstackgerrit> Scott Moser proposed stackforge/cloud-init: add cloud-init main  https://review.openstack.org/202743
[20:04] <openstackgerrit> Scott Moser proposed stackforge/cloud-init: add cloud-init main  https://review.openstack.org/202743
[21:26] <openstackgerrit> Scott Moser proposed stackforge/cloud-init: improve test coverage  https://review.openstack.org/203249