[02:44] Bug #1511589 opened: maas provider, hwclock out of sync means juju will not work [07:53] axw: how would i use gocov to merge coverage profiles? it's not clear from the README [07:54] rogpeppe: sorry, IIANM you can "gocov convert profile [profile...]". but it's going to give you gocov JSON output, if it's not clear [07:56] axw: so my aim here was to try and see the combined test coverage of juju/api when running the juju/apiserver/client and juju/api tests [07:56] axw: and i like the nice red-green line-by-line HTML output of the usual coverage tool [07:56] axw: can i use gocov to do that? [07:57] rogpeppe: cmars added support to gocov for testing multiple packages, so you should be able to "gocov test juju/api juju/apiserver/client" [07:58] rogpeppe: there's command-line "gocov annotate" for annotated source, and https://github.com/matm/gocov-html if you want HTML [08:01] rogpeppe: (and I just noticed that doesn't do red/green, assuming the screenshot is representative; sorry) [08:03] axw: trying it anyway. we'll see. [08:07] axw: hmm, doesn't seem to have worked: http://paste.ubuntu.com/13007149/ [08:07] axw: and /tmp/cov.out is empty [08:08] rogpeppe: hrm, I'll take a look [08:08] rogpeppe: did you just fetch gocov? [08:08] axw: hmm, maybe i should've used go test then gocov convert [08:08] axw: yeah [08:08] rogpeppe: that should work [08:08] axw: um [08:09] axw: it looks like i didn't [08:09] % ls -l `{whatis gocov} [08:09] -rwxrwxr-x 1 rog rog 3907964 Mar 22 2013 /home/rog/src/go/bin/gocov [08:09] oops :) [08:10] axw: ah! [08:10] axw: the command isn't in the top level dir [08:10] axw: i did go install github.com/axw/gocov [08:14] rogpeppe: hrm, I've just realised that "gocov test " does not tell you about dependent packages. so you'll need to specify -coverpkg [08:14] axw: ah, i wondered about that [08:14] rogpeppe: original gocov used to do it, but then it became a shim around "go test -cover" [08:15] it should probably do it again, since it supports multiple packages now [08:15] axw: hmm [08:15] % gocov test -coverpkg ./api ./api ./apiserver/client > /tmp/cov.out [08:15] warning: no packages being tested depend on github.com/juju/juju/api [08:16] * axw tries [08:16] axw: that doesn't seem right to me - both those packages depend on juju/api [08:16] rogpeppe: maybe something to do with relative package path? [08:16] axw: i'll try abs [08:16] rogpeppe: I just tried it on a dummy package [08:17] worked ok [08:17] axw: using absolute path didn't help [08:17] axw: i'll try go test then gocov convert [08:18] rogpeppe: weird, putting "-coverpkg ./api" *after* the package names seems to work ... [08:19] rogpeppe: hmm or maybe not [08:19] ok just do it your way ;p [08:19] axw: trying it now [08:20] * rogpeppe wishes command line flag parsing wasn't context-sensitive [08:20] rogpeppe: oh it does work, I was seeing warnings for another reason (I was using ./... and not all packages depend on it) [08:21] dimitern, please could you take a look at http://reviews.vapour.ws/r/3030/ [08:22] rogpeppe: http://paste.ubuntu.com/13007210/ [08:23] rogpeppe: I read that as: api tests 56% of api, apiserver/client tests 43.7%, together they do 77.78% [08:24] axw: that doesn't look right to me [08:24] axw: for example EnsureAvailability is well tested by apiserver/client but comes up as 0% [08:24] hrm [08:25] frobware, sure, looking [08:28] rogpeppe: seems to happen regardless of whether I'm merging... checking what happens when I just use "go test -cover" [08:28] axw: so i get the same issue when manually using gocov convert with multiple files [08:29] frobware, lgtm [08:32] rogpeppe: just tested with "go test -coverpkg github.com/juju/juju/api " and it shows 0% coverage for Client.EnsureAvailability [08:32] axw: yeah, i just saw that too. maybe our tests are at fault [08:33] rogpeppe: ah... it's calling the apiserver/client code directly I think [08:34] axw: ah, so it is [08:34] axw: ok, we're all mixed up in our testing approaches here [08:34] axw: thanks [08:34] rogpeppe: nps [08:34] rogpeppe: one of these days I'd like to get coverage generated by CI [08:35] merged for the whole tree [08:35] axw: yes, that would be great [09:08] axw, hey, since you're here - a question: do you know if there's any way in a manual environment to add a new machine and a new container on it in a single command? [09:08] e.g. like in other envs you can add-machine lxc [09:08] I guessed not, but wasn't completely sure [09:08] Bug #1511659 opened: Destroyed leader, new leader not elected. [09:14] Bug #1511659 changed: Destroyed leader, new leader not elected. [09:18] Bug #1511659 opened: Destroyed leader, new leader not elected. [09:32] fwereade, hey, how's that for a better UX: http://paste.ubuntu.com/13007523/ [09:33] I'll fix the typo [09:35] dimitern, nice [09:35] fwereade, I've added a PrecheckContainerHost method on the state.Policy.Prechecker [09:36] fwereade, which can be called with or without the host being provisioned (the latter in the case you've done $ juju add-machine lxc) [09:36] dimitern, excellent [09:38] fwereade, yeah, I agree it's much cleaner like this; now just a couple of provisioner API methods are needed to allow the worker to notify the apiserver that it's about to start/stop a container, so the NICs can be created with the pre-generated MAC etc. [09:39] dimitern, yeah, sgtm [09:39] dimitern, lovely [10:01] jam, dooferlad, standup? [11:02] anybody else see "cannot load cookies: json: cannot unmarshal object into Go value of type []cookiejar.entry" - this from 'juju ssh 0' [11:25] frobware, you probably need to update the deps [11:25] dimitern, done that [11:25] frobware, so that's not a build error? [11:26] dimitern, bootstrap works, trying to 'juju ssh 0' borks [11:29] frobware, hmm I haven't seen this - try with juju ssh --debug 0 [11:38] dimitern, just starting a git bisect to see if it is just me, or something recent. [12:05] frobware, I think I noticed some sort of bug related to loading cookies and bootstrap issues today or yesterday - might be worth a quick search [12:15] * dimitern is surprised to find out $ juju deploy mysvc --to 0,lxc:1,2,lxc works but it's not documented [12:42] Bug #1511717 opened: Incompatible cookie format change [12:45] Bug #1511717 changed: Incompatible cookie format change [12:54] Bug #1511717 opened: Incompatible cookie format change [13:39] Bug #1511589 changed: maas provider, hwclock out of sync means juju will not work [14:11] dimitern, forward port to master - http://reviews.vapour.ws/r/3031/ (do these need reviewing if they have been reviewed on 1.25?) [14:20] frobware, will have a look in a bit; yes - they do need reviewing (albeit a quick one, since it's a port) [14:21] dimitern, well this was a cherry-pick [14:34] frobware, ship it! ;) [15:05] natefinch: sorry, what's the status on http://reviews.vapour.ws/r/2814/ ? [15:06] ericsnow: you should have your reviews from me [15:06] katco: thanks! [15:07] katco: I have to write a couple small tests and then I have a shipit from william [15:07] natefinch: k, i know it's friday labs, but extenuating circumstances, can you land that today? [15:08] katco: yeah... I think friday labs is only friday afternoons anyway, right? [15:08] natefinch: i think we can spare a day :) [15:08] katco: regardless, it should be very fast to finish up [15:08] natefinch: cool [15:25] Is there a way to make a new unit without having to invoke methods on state? there's a state.newUnit, which is obviously not exported, and the fields of Unit are not exported... [15:25] (this is for testing) [15:26] fwereade, dimitern, rogpeppe, wwitzel3, ericsnow, katco, etc ^ [15:27] natefinch: there's the factory [15:27] natefinch: I've only ever used the state stuff (see the helper in state/workloads_test.go) [15:27] natefinch: but that uses ConnSuite [15:27] natefinch: ericsnow: sec, hunting for this [15:28] natefinch: what are you trying to do? [15:28] natefinch, why without calling a state method? [15:28] natefinch: https://github.com/juju/juju/blob/master/testing/factory/factory.go [15:28] rogpeppe: test a function that takes a unit without doing a full stack test [15:28] natefinch: but forgot it still uses state =/ [15:29] dimitern: because using state will make my test take 100 times longer [15:29] natefinch: you could always use an interface type [15:29] natefinch: don't dwell on this too long. your budget is spent [15:29] natefinch: that's not a problem to be solved in isolation [15:29] natefinch: someone should spend some time looking at how to speed up *all* state-based tests [15:30] natefinch: i can't believe noone seems to have allocated any time for that [15:30] rogpeppe: I don't have time to solve the problem in general. I just want to write a unit test [15:30] rogpeppe: i think what he's saying is that he doesn't want it to be state based at all [15:30] natefinch: so write the test the same way as all the other tests are written [15:30] natefinch, ah, well - interfaces & mocking then [15:30] the code in the function that I'm testing is very very simple [15:30] natefinch: making it different will only make things harder in the long run [15:31] natefinch: what does your function look like? [15:31] rogpeppe: I think I can fix it with judicious application of a tiny special-case interface, actually [15:31] natefinch: that's often the case [15:32] instead of casting a state.Entity to *state.Unit. cast to an interface with the one function I need from Unit. [15:42] cherylj, ping - any chance we could quickly chat about https://bugs.launchpad.net/juju-core/+bug/1412621 [15:42] Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap [15:46] natefinch, +100 to that, if you must cast cast to the narrowest possible interface [15:48] fwereade: yep, just a single function. And now my 3 tests take less than a millisecond each to run. [15:48] natefinch, <3 [15:48] natefinch, and you can get nice coverage of weird errors as well, and it'll still take less than a ms :) [15:49] fwereade: yep. tested the error paths as well. [15:49] natefinch, perfect :) [15:51] natefinch: well done :) [15:52] Bug #1511771 opened: regression setting tools-metadata-url [15:52] * wwitzel3 goes to look at those tests to remember the implementation [16:02] This branch has conflicts that must be resolved [16:02] noooooooo!!! [16:03] I guess it's to be expected given that it's a 29 day old PR :/ [16:08] gah, why does git rebase master tell me I'm up to date when github says there's conflicts merging? [16:10] ahh, my local master was out of date [16:16] katco: merging the unitassigner stuff now.... assuming the bot is working and will pick it up, which is looking somewhat questionable currently. [16:17] natefinch: eh? why, what's going on with the bot? [16:18] katco: nevermind, it was just being slo [16:18] except that master is blocked now... sonofa [17:23] frobware, cherylj is out today [17:29] I need a volunteer to help with a friday afternoon activity [17:29] anyone around and willing? [17:32] alexisb: I'm around. I'd rather work on minjujuversion, but can do other things as needed [17:33] natefinch, this shouldnt take long, I just have a couple of qs to get me unstuck [17:52] Bug #1511812 opened: 1.25.0 cannot bootstrap local environment on wily host [17:55] Bug #1511812 changed: 1.25.0 cannot bootstrap local environment on wily host [17:58] Bug #1511812 opened: 1.25.0 cannot bootstrap local environment on wily host [18:34] Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [18:37] Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [18:46] Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed === natefinch is now known as natefinch-afk [18:49] Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [18:52] Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [22:02] Bug #1511865 opened: juju run output is unusable === benonsoftware is now known as MisterHiyas [22:32] Bug #1511865 changed: juju run output is unusable