[00:22] any ~charmers around? [00:22] I think most folks have started their weekend [00:22] o/ [00:23] blahdeblah: it's failing lint [00:24] DEBUG:runner:call ['/usr/bin/make', '-s', 'lint'] (cwd: /tmp/bundletester-FGMSmT/ntp) [00:24] DEBUG:runner:hooks/ntp_hooks.py:77:80: E501 line too long (97 > 79 characters) [00:24] DEBUG:runner:hooks/ntp_hooks.py:118:80: E501 line too long (90 > 79 characters) [00:24] DEBUG:runner:make: *** [lint] Error 1 [00:24] DEBUG:runner:Exit Code: 2 [00:24] marcoceppi: thanks - those run *after* the amulet tests? [00:25] blahdeblah: first [00:25] http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3531 [00:25] blahdeblah: that's a better breakdown of that output [00:26] Right - that is much better; I'll get an update to that MP done over the weekend. [00:28] marcoceppi, wow still around :-) [00:29] marcoceppi: seems I can't find the MP for http://review.juju.solutions/review/2342 [00:29] arosales: it was deleted [00:29] arosales: I'll remove from queue [00:30] blahdeblah: but looks like the ntp tests pased DEBUG:runner:The ntp deploy test completed successfully. [00:30] marcoceppi: thanks [00:30] * arosales will move onto the next one [00:30] arosales: removed ;) [00:31] arosales: Yeah - those tests aren't terribly sophisiticated [00:31] well at leasts there is tests [00:31] :-) [00:32] good news is, the tests pass, bad news is pep8 hates you ;) [00:38] There's a way to tell those tests to override on a given line, isn't there? [00:38] * blahdeblah asks Google [00:41] marcoceppi does charm proof check for pep8? [00:41] arosales: it checks the charm if there's a "lint" target [00:41] the charm author has a make lint target so we run it as part of bundle tester [00:41] so it's basically, bundletester will do the following: [00:42] - charm proof [00:42] - make lint (if available) [00:42] - make test (if available - unit tests) [00:42] - run the charm integration tests === med_ is now known as Guest17963 [00:43] marcoceppi: ok, thanks [00:55] marcoceppi: Have you given any thought to making charm proof wrt. layers? [00:56] Charm layers tend to fair ok, but not so much base or interface layers [00:56] cory_fu: I really want to make charm create for layers and charm add [00:56] cory_fu: like charm create layer, charm add layer:nginx. I keep messing up the damn includes syntax like a dope [00:57] Agreed [00:57] cory_fu: it's not a bad idea, it's not on the road map for this iteration but could make it on there before EOY [00:58] * marcoceppi packs up computer for the weekend [00:58] T'was just an errant thought [01:01] marcoceppi: For monday, note charm CI is marking charm CI as green even though LXC fails, (aws pass) [ref = http://review.juju.solutions/review/2350] [01:02] arosales: the logic for that might not be nessisarily bad [01:03] do we want to weight failures higher than passes? [01:03] esp. given the flakiness of some of the substrates [01:03] lxc failed because of a provider problem (I restarted the tests) [01:03] one school of thought was that it had to pass on local and public cloud [01:04] arosales: yes, but a failure doesn't always mean it's a charm problem [01:04] in this case the failure is due to timeout, most likey due to infrastructure [01:04] agreed [01:04] but charm CI doesn't tell us why it failed [01:04] just that it failed [01:04] it does tell us [01:04] well doesn't surface up infrastructure or charm fail [01:04] DEBUG:runner:Deployment timed out (900s) [01:05] sorry, I didn't state the correctly [01:05] arosales: the output we link people to is kind of crap [01:05] it's hard to find that [01:05] arosales: I agree we should work to distinguish infrastructure failure vs testing failure [01:05] but we don't have that atm [01:05] but to your point, is it a charm failure or a infrastructure failure [01:05] but regardless [01:05] agent-state-info: lxc container cloning failed [01:05] it was infrastructure [01:05] the question is when do we mark a Charm CI test as a green box, ie passing [01:05] LXC was broken for about 20 test runs because of some weird lingering issue [01:06] * arosales saw that in a couple of test runs [01:06] arosales: right, and the icon says "some tests have passed" it's never a definitive. It hink we favor passing over failing given how often we have substrate issues [01:06] re my questions when to mark a charm CI as passing I thought it had to pass on local and a cloud [01:06] arosales: we can reverse that logic, without problem, but it needs some discussion [01:06] but it seems currently it marks it as passing if it passes on just 1 cloud [01:07] arosales: at the moment yes, I can see how the logic is confusing there [01:07] I think passing on 1 cloud is fair for green [01:07] but just wanted to confirm my understanding [01:07] as soon as it gets one test result back we say the status, where passing > failing [01:07] oh [01:07] so, it'll say "some tests are passing" for any result that comes back that's testing [01:07] so if it failed on 2 cloud, but passed on 1 it would be red? [01:07] not sure [01:08] I'm doing a terrible job of explaining this [01:08] sorry, I was taking you litterally on passing > failing [01:08] I think I follow you though [01:08] I'm saying pass is weighted greater than failure if there's a mix result [01:08] because of infra flakiness [01:08] but we can easily reverse that logic where fail is if any one test has failed [01:08] I've got to catch a plane so I need to EOD and pack, but we can chat more on Monday [01:09] the new review queue will be a bit better at explaining this [01:09] by just showing the numerical result [01:09] X pass / Y fail [01:09] explicit :) [01:13] I like the weight on passing [01:14] later marcoceppi, travel safely [01:20] marcoceppi: Pushed fix to that MP; does it retry testing automatically? === StoneTable is now known as aisrael === Tristit1a is now known as Tristitia === CyberJacob is now known as Guest72473 [06:32] Anyone had problems with juju under wily not starting? === scuttle` is now known as scuttle|afk === scuttle|afk is now known as scuttlemonkey [21:16] i