=== wgrant_ is now known as wgrant === ahasenac` is now known as ahasenack [00:44] lazyPower: hey there [00:44] o/ [00:44] rick_h_: pong [00:55] lazyPower: ty email away :) [02:16] jrwren: ping - just got a big MP from foli w/ nagios bits targeted at my namespace charm of logstash === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [04:39] Any charmers stil awake? aisrael tells me that as long as "python tests/20-mytest" runs, then any test code should work. But 20-mytest relies on python modules elsewhere in the charm tree; what's the correct method for including it in the python module path? === kadams54 is now known as kadams54-away [11:06] blahdeblah: still around? [11:10] marcoceppi: Sort of; past EOD & dealing with a broken machine at the moment [11:11] you can import sys and patch the pythonpath at the top of the test file if you're unable to import it by normal means [11:12] marcoceppi: Yeah - found that in the latest unit_tests template and used that in my unit_tests. [11:13] Do we have any documentation about the preferred best practice for unit tests at present? [11:13] ah, I figured 7 hours of searching must have yeilded something, sorry we couldn't get you an answer sooner [11:13] blahdeblah: not entirely, no [11:13] np - I know I'm on the wrong side of the planet. :-) [12:05] has anyone run into an issue with local provider and 1.24? === beuno_ is now known as beuno [12:54] marcoceppi: The only problem I had was it wasn't a clean upgrade. I had to destroy and bootstrap my env [12:54] (1.24-beta1) [12:55] blahdeblah: Glad you found a solution! === msbrown-afk is now known as msbrown [13:00] The upgrade from 1.24-beta1 to beta2 went smooth [13:00] ANd we have service-status and workload-status! [14:06] woot === ericsnow is now known as ericsnow_afk === kwmonroe_ is now known as kwmonroe === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === ericsnow_afk is now known as ericsnow === scuttlemonkey is now known as scuttle|afk [15:24] 'ello guys, having some troubles over here [15:24] `juju bootstrap --constraints "cpu-power=0 mem=512M"` is trying to launch a t2.micro instead of a t1.micro [15:25] any idea why? [15:28] "The t1.micro is a previous generation instance and it has been replaced by the t2.micro" [15:29] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts_micro_instances.html [15:33] jrwren: I've continued using t1.micro instances because they suit me for charming, has the core team decided to deprecate them? [15:34] t1.micros can still be launched from the aws console and everything [16:17] sinzui: have you guys noticed issues with juju trying to create vivid containers? [16:17] * sinzui gets bug [16:18] stokachu, bug 1442308 is our nemesis [16:18] Bug #1442308: Juju cannot create vivid containers

[16:18] sinzui: thanks! [16:18] stokachu, in the details of the bug, I think we see that the container logic is using upstart :( [16:20] * sinzui high fixes Core for getting every branch blessed [16:43] hi ses [16:43] I can discuss compatibility tests now === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [17:31] Quick question: what's the incantation for deploying the /next branch of a charm? [17:31] Or do I have to check it out in bzr and deploy it locally? [17:32] lukasa: the latter [17:33] Ok. =) === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away