[00:08] <davecheney> good news everyone, save joyent, http://paste.ubuntu.com/7517545/
[00:08] <davecheney> ppc64el is passing
[00:14] <wallyworld> davecheney: o/
[00:14] <wallyworld> i am fixing joyent this morning
[00:14] <wallyworld> davecheney: have you seen the jenkins job? it fails with a compile error
[00:15] <wallyworld> what's your take on that?
[00:15] <wallyworld> eghttp://juju-ci.vapour.ws:8080/job/walk-unit-tests-ppc64el-trusty-devel/309/console
[00:15]  * davecheney looks
[00:15] <davecheney> is there a bug raised for this ?
[00:16] <wallyworld> not that i know of, i only just saw it this morning. there's a history of job failures we should extract bugs for
[00:16] <wallyworld> how is the jenkins set up different to your?
[00:17] <davecheney> it is possible that the gccgo fix has not landed in main yet
[00:17] <davecheney> i am running the fix from the ppa
[00:17] <wallyworld> ah
[00:17] <davecheney> can you ssh tot he test machine and look at dmesg
[00:18] <davecheney> the last 20 lines should be sufficient
[00:18] <wallyworld> i'll have to determine what the machine is
[00:18] <wallyworld> let me get the upstream oyent fixes in the core first
[00:25] <davecheney> ummm
[00:25] <davecheney> + juju_version=juju-core_1.19.3
[00:25] <davecheney> + set -x
[00:25] <davecheney> + set +e
[00:25] <davecheney> I think this is wrong
[00:39] <wallyworld> where is the above from?
[00:43] <davecheney> that link
[00:43] <davecheney> you posted
[00:43] <davecheney> +e turned off break on error afaik
[00:44] <wallyworld> we can talk to curtis about the test scripts used
[00:44] <wallyworld> davecheney: this will make the joyent tests go faster https://codereview.appspot.com/101740043
[00:50] <wallyworld> davecheney: is this the ppa i would need to use to get the same gccgo as you? https://launchpad.net/~ubuntu-toolchain-r/+archive/ppa/?field.series_filter=trusty
[00:56] <axw> morning all
[00:56] <thumper> davecheney: juju-ci.vapour.ws:8080/job/walk-unit-tests-ppc64el-trusty-devel/312/console
[00:57] <thumper> davecheney: ec2 tests paniced
[00:57] <thumper> davecheney: is this new or known about?
[00:58] <thumper> actually, that isn't ec2
[00:58] <axw> looks like it panicked in the go tool itself
[00:58] <thumper> is it joyent?
[00:58] <thumper> yeah, looks like compiling error somewhere
[00:58] <thumper> doesn't seem like it gives good feedback as to which bit causes the problem
[00:59] <thumper> reminds me of the "internal compiler error" I used to get with gcc and hairy templates
[00:59] <wallyworld> the gccgo on jenkins is old apparently
[00:59] <wallyworld> doesn't have the latest fixes
[00:59] <wallyworld> the one from the ppa is better
[00:59] <thumper> ah...
[00:59] <wallyworld> i'm trying it out now
[00:59] <thumper> that makes sense
[00:59] <wallyworld> see my above link
[01:00] <wallyworld> axw: morning. if you have a moment, could you +1 this small mp. fixes the joyent tests. https://codereview.appspot.com/101740043
[01:00] <axw> sure, looking
[01:00] <wallyworld> ta
[01:00] <axw> yay, they merged
[01:00] <wallyworld> yeah, finally :-)
[01:01] <wallyworld> the tests still take a little too long, but much better
[01:02] <davecheney> thumper: we're just discussing that
[01:02] <thumper> kk
[01:02] <davecheney> my hunch is the gccgo fix hasn't landed in trusty-updates yet
[01:02]  * thumper nods
[01:03] <davecheney> wallyworld: doko moves ppa's more often than the tide
[01:03] <davecheney> that one will probably work
[01:04] <wallyworld> cool, trying it locally
[01:06] <thumper> heh
[01:20] <davecheney> Guest78498: trying the joyent fixes now
[01:20] <Guest78498> davecheney: sadly, i don't get a clean test run. http://pastebin.ubuntu.com/7517679/
[01:20] <Guest78498> a test failure or two and compile errors
[01:20] <Guest78498> that's with the ppa
[01:21] <Guest78498> but joyent tests pass :-)
[01:21] <Guest78498> still 3 times slower than maas tests, or 6 times slower tahn ec2
[01:21] <Guest78498> but, it's a start
[01:22] <thumper> Guest78498: what have you don't with wallyworld?
[01:22] <thumper> s/don't/done/
[01:22] <davecheney> Guest78498: can you send me the last 20 lines of dmesg from that host
[01:22] <Guest78498> thumper: computer crashed, and freenode takes way too f*cking long to drop the connection, so it won't let me back in
[01:22] <davecheney> cmd juju ran too long
[01:22] <thumper> Guest78498: ghost wallyworld
[01:23] <thumper> hmm...
[01:23] <Guest78498> davecheney: i ran the tests on my laptop, you want dmesg from that?
[01:23] <davecheney> signal: segmentation fault (core dumped)
[01:23] <davecheney> FAIL    launchpad.net/juju-core/environs/simplestreams  1.552s
[01:23] <davecheney> Guest78498: gotta be on ppc
[01:23] <davecheney> that is where the bug is
[01:23] <davecheney> skip the dmesg request
[01:24] <davecheney> you don't need to apply the ppa to gccgo on amd64
[01:24] <davecheney> it is unaffected
[01:24] <davecheney> looking at the rest of these tests
[01:24] <davecheney> looks like they just took to long
[01:25] <Guest78498> what about the seg fault
[01:25] <davecheney> no idea
[01:25] <davecheney> check dmesg
[01:25] <davecheney> (yes, I know i just told you no to)
[01:26] <Guest78498> davecheney: oh joy, lookie
[01:26] <Guest78498>   674.033377] CPU7: Core temperature above threshold, cpu clock throttled (total events = 1921)
[01:26] <Guest78498> [  674.034391] CPU7: Core temperature/speed normal
[01:26] <Guest78498> [  674.034392] CPU3: Core temperature/speed normal
[01:26] <Guest78498> [  675.690153] mce: [Hardware Error]: Machine check events logged
[01:27] <Guest78498> maybe that had something to do with it?
[01:27] <davecheney> Guest78498: if I had to guess, 8 tests compiled with gccgo plus 8 mongodbs is causing you to swap
[01:27] <Guest78498> i have 16GB RAM
[01:27] <Guest78498> but no swap partition
[01:27] <davecheney> some of the tests consume gigabytes when run under gccgo
[01:28] <Guest78498> i've never needed a swap partition till now with that much memory. sigh
[01:28] <davecheney> adding swap won't help
[01:28] <davecheney> probably reducing the number of tests run concurrently will
[01:28] <davecheney> go test -p 4 ./...
[01:29] <davecheney> go test -p 4 -compiler=gccgo ./...
[01:29] <Guest78498> even if i don't have gomaxprocs set currently?
[01:30] <davecheney> unrelated
[01:30] <davecheney> go test tries to start as many test jobs in parallel as you have cpis
[01:30] <Guest78498> ok, i'll try that after getting the jpyent branch landed
[01:32] <Guest78498> ffs, how long does freenode want to hold open my old connection for
[01:33] <davecheney> ok, good news and bad news
[01:33] <davecheney> good news: ok  launchpad.net/juju-core/provider/joyent127.919s
[01:34] <davecheney> bad news: some other transient error, http://paste.ubuntu.com/7517706/
[01:34] <davecheney> usual unreachable servers bullshit
[01:41] <axw> Guest78498: I managed to reproduce the issue kapil had where kvm containers are leaking. I'll be looking at that today
[01:41] <Guest78498> \o/ great thanks
[01:41] <axw> I think it doesn't happen in 1.19.3, but I'd like to figure out what's going out to be sure
[01:42] <Guest78498> sounds good
[01:42] <Guest78498> davecheney: that replicset stuff has been so f*cking unreliable
[01:42] <Guest78498> it's been made more robust, but......
[01:42] <Guest78498> still can fail
[02:19] <wallyworld> davecheney: much better with -p 4. the jujud watcher error occurs sometimes on amd64 also, but there's a fault in the openstack provider tests http://pastebin.ubuntu.com/7517849/
[02:30] <wallyworld> davecheney: here's the dmesg from the CI ppc machine used to run the tests every hour and for which i posted the output with all the faults etc earlier http://pastebin.ubuntu.com/7517890/
[03:10] <wallyworld> thumper: have you run a local provider with kvm before?
[03:11] <thumper-otp> yes
[03:11] <wallyworld> seenthis?
[03:11] <wallyworld> ian@wallyworld:~$ juju status
[03:11] <wallyworld> ERROR failed getting all instances: exit status 1
[03:11] <wallyworld> ERROR Unable to connect to environment "local-kvm".
[03:11] <wallyworld> Please check your credentials or use 'juju bootstrap' to create a new environment.
[03:11] <wallyworld> i just bootstrapped, no errors
[03:11] <thumper-otp> no
[03:11] <wallyworld> :-(
[03:13] <wallyworld> hmmm, seems KVMObjectFactory.List() is sad
[03:14] <wallyworld> ian@wallyworld:~$ virsh -q list --all
[03:14] <wallyworld> error: failed to connect to the hypervisor
[03:14] <wallyworld> error: no valid connection
[03:14] <wallyworld> error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
[03:14] <wallyworld> thumper: could it be that we need sudo and it's not prompting?
[03:31] <axw> wallyworld: seems odd that "juju status" is trying to list providers; that implies your .jenv doesn't have a valid API server address cached
[03:32] <wallyworld> axw: works fine for local with lxc
[03:32] <axw> wallyworld: you should add your user to the group that owns libvirt-sock tho
[03:32] <wallyworld> ok
[03:32] <axw> then you should be able to use virsh
[03:32] <axw> I think it's libvirtd
[03:33] <wallyworld> if we need that for local kvm to work, we should check for it
[03:33] <axw> it shouldn't be necessary, sounds like something else is wrong
[03:33] <axw> but it's useful for using virsh
[03:33] <wallyworld> does local with kvm work for you?
[03:33] <axw> yes
[03:33] <axw> just works
[03:33] <wallyworld> hmmmm
[03:34] <wallyworld> i'm trying to reproduce bug 1322281
[03:34] <_mup_> Bug #1322281:  local provider deployment of mysql to kvm hangs in pending state <cloud-installer> <juju-core:Triaged> <https://launchpad.net/bugs/1322281>
[03:34] <axw> I am in the group, however all the important bits run under root anyway
[03:34] <axw> I tried that, it just worked for me
[03:34] <axw> i.e. I installed mysql in a kvm container and it worked fine
[03:34] <wallyworld> :-(
[03:34] <wallyworld> so my setup is screwed somehow
[03:35] <wallyworld> we might need to ask for the cloud init log
[03:35] <wallyworld> for the user of that bug
[03:36] <axw> yeah may be useful
[04:18] <thumper> Guest21046: crash again?
[04:18] <thumper> Guest21046: I have a branch where the only failing bit is tool selection and syncing
[04:19] <Guest21046> thumper: nah, had to log out and back in so a new group membership would stick
[04:19] <thumper> Guest21046: not sure why... perhaps you could take a look?
[04:19] <Guest21046> sure
[04:19] <thumper> Guest21046: lp:~thumper/juju-core/enable-alpha-versions
[04:19] <thumper> Guest21046: I can't see where the version comparison stuff is different for tool selection
[04:19] <thumper> and since you most recently touched it, you may know more
[04:20] <Guest21046> sure, no problem
[04:24] <Guest21046> thumper: just pulling your branch and looking without running tests, ottomh there are a number of tests which rely on minor version being odd to be a dev version. and that is now no longer the case in you branch
[04:26] <thumper> ah...
[04:26] <thumper> ok
[04:26] <Guest21046> i'll run the tests though to conirm
[04:26] <thumper> almost certain that'll be the problem then
[04:27]  * thumper goes to enfixorate
[04:27] <Guest21046> ok
[04:27] <Guest21046> let me know i you want me to do anything to help
[04:30] <jam> axw: sorry I missed this a few days ago, but the fix here https://code.launchpad.net/~axwalk/juju-core/lp1321025-mongod-path-1.18/+merge/220544
[04:30] <jam> should really be to default to juju-mongodb except for precise and raring (I think)
[04:30] <jam> otherwise everything will fail again when V is released.
[04:31] <davecheney> jam: and raring is out of support
[04:33] <axw> jam: that is what it does, see the code above
[04:33] <axw> jam: it's using the result of MongoPackageForSeries, which was already doing the right thing
[04:34] <jam> axw: ah, I see. It was just that we had a line that was using == trusty, gotcha
[04:34] <axw> yup
[04:34] <jam> I misread the diff given you added explicit "utopic: juju-mongodb" line
[04:34] <jam> 	but that was just in tests
[04:37] <axw> wallyworld: I think you put the wrong LP# in the replicaset card
[04:37] <wallyworld> sigh yes
[04:38] <wallyworld> bigjools was distracting me with drivel
[04:38] <axw> heh :)
[04:38] <bigjools> he's easy to distract
[04:39] <bigjools> I just throw a ball
[04:39] <wallyworld> ball? where?? me fetch? can I? huh? huh?
[04:39] <menn0> hmmm... i'm trying to add a field to the FullStatus API response and everything hangs if I use a map keyed by int but it's fine if the map is keyed by string
[04:39] <bigjools> I am NOT rubbing your tummy
[04:39] <menn0> is this a known thing?
[04:39]  * wallyworld tries so hard to be pc
[04:40] <bigjools> makes a change :)
[04:40] <menn0> does our API serialisation only like string keys on maps?
[04:40] <wallyworld> as thumper says, it's a family channel
[04:40] <bigjools> hello menn0, apparently you used to work with my brother in law at BATS
[04:40] <thumper> heh
[04:40] <menn0> what's his name?
[04:40] <bigjools> Glyn
[04:41] <menn0> yep :)
[04:41] <menn0> I know Glyn well
[04:41] <wallyworld> unlike his brother in law, gyln is an awesome guy
[04:41] <bigjools> I've known him for 19 years, some say 19 years too many
[04:41] <menn0> Glyn is awesome... if a little grumpy at times :)
[04:41] <bigjools> lol
[04:42] <menn0> any takers on my question? what's our serialisation format for the API?
[04:43] <wallyworld> davecheney: apart from replicaset shite, ppc tests on CI server now pass also http://juju-ci.vapour.ws:8080/job/walk-unit-tests-ppc64el-trusty-devel/317/consoleFull
[04:43] <menn0> if it's JSON I can see how there could be a problem...
[04:43] <wallyworld> i think it is
[04:43] <menn0> right
[04:43] <menn0> that make ssense
[04:43]  * menn0 will use strings
[04:44] <wallyworld> don't ya love json for that stuff
[04:44] <menn0> it's not a big deal in this case
[04:48] <davecheney> wallyworld: w00t
[04:48] <wallyworld> davecheney: i upgraded gccgo-4.9 from the ppa
[04:48] <davecheney> cool
[04:49] <davecheney> we're just waiting for that to land in trusty-updates
[04:49] <wallyworld> davecheney: did you see my local test run? fault in opestack tests http://pastebin.ubuntu.com/7517849/
[04:50] <davecheney> wallyworld: have you run godeps ?
[04:50] <wallyworld> i did earlier
[04:50] <wallyworld> which dep in particular?
[04:56] <jam> wallyworld: did you see https://bugs.launchpad.net/bugs/1321009
[04:56] <_mup_> Bug #1321009: juju-metadata doesn't produce content that 1.19.2 bootstrap can use <landscape> <metadata> <regression> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1321009>
[04:56] <davecheney> mgo
[04:57] <jam> hmm,, mail client shows me the old stuff, but not the new
[04:57] <jam> looks like you already fixed it
[04:57] <wallyworld> jam: yes, fixed, it wasn't a simplestreams data format bug but rather bootstrap looked up the simplestreams data for supported arches before it was uploaded in the case the --metadatasource was specified
[05:09] <wallyworld> davecheney: i've got rev 275 o mgo locally even though juju-core's dep file says 273
[05:10] <davecheney> ... o_O
[05:12] <wallyworld> that shouldn't cause the test failures though
[05:12] <wallyworld> looking at the logs, it seems a mongo process is just dying unexpectedly
[05:13] <davecheney> we had a bug a few days ago where our client was causing mongo to crash
[05:13] <davecheney> looks like the replica set stuff is a bit fragile
[05:13] <davecheney> as in, mongos'
[05:13] <wallyworld> and the test doesn't recover. it gets EOF, refreshes and calls Ping(), but tries to reach the process that has just died
[05:13] <wallyworld> yeah, i reckon mongo itself is fragile :-(
[05:13] <wallyworld> wish we didn't use it
[05:18] <wallyworld> jam: how detailed is you mgo ha knowledge?
[05:21] <jam1> wallyworld: I wouldn't say it is amazing, but I'm willing to tell you want I can :)
[05:21] <wallyworld> jam: quick hangout?
[05:21] <jam> sure
[05:21] <jam> link?
[05:21] <wallyworld> https://plus.google.com/hangouts/_/gxweywbcs523zdbqunelr5u4uua
[05:21] <vladk> jam: morning
[05:21] <jam> wallyworld: says the party is over..
[05:21] <jam> morning vladk
[05:22] <wallyworld> invite sent
[05:58]  * wallyworld -> school run bbiab
[06:01] <vladk> jam: hangout time
[06:27] <dimitern> morning all
[07:54] <TheMue> morning
[08:04] <axw> fwereade: on closer inspection, my assumption about the keymanager test was correct; it's tested by TestImportKeys above. going to take that test back out again...
[09:00] <wallyworld_> mgz: standup?
[09:23] <mgz> wallyworld: lost you
[09:23] <wallyworld_> mgz: we're here
[09:23] <wallyworld_> you're muted
[09:23] <mgz> I.. can't now hear anything
[09:23] <wallyworld_> mgz: you dropped out and came back
[09:24] <TheMue> jam: I lost you. I can see you’re in, but muted and no video.
[09:25] <jam> TheMue: you're frozen for me as well, I'll reconnect
[09:51] <TheMue> jam: could it be that I’m not allowed to write into the team calendar?
[09:52] <jam> TheMue: fixed
[09:59] <TheMue> thx
[10:16] <jam> dimitern: fwereade: https://codereview.appspot.com/96600043 adds a caching layer to the srvRoot code so that all facades are now cached
[10:16] <dimitern> jam, looking
[10:43] <dimitern> jam, LGTM
[10:43] <jam> hx
[10:43] <jam> thx
[10:45] <dimitern> TheMue, fwereade, standup?
[10:55] <jam> dimitern: we lost you after "I almost"
[12:03] <frankban> hi all, is anyone available for reviewing https://codereview.appspot.com/92610045 ? thanks!
[12:05] <perrito666> good morning everyone
[12:20] <jam> vladk|offline: we're done for now, don't worry about coming back
[12:54] <fwereade> frankban, LGTM
[12:54] <frankban> fwereade: thank you!
[13:17] <jam> fwereade: so for modelling "environ tag" as part of the data we store in the .jenv, we currently have a split of EnvironInfo.SetAPIEndpoint() and EnvironInfo.SetAPICredentials()
[13:17] <jam> I'm tempted to just put EnvironUUID into APIEndpoint informationd
[13:17] <jam> Which currently holds Addresses and CACert
[13:18] <jam> but seems a decent fit
[13:18] <fwereade> jam, +1
[13:19] <jam> k, thanks for confirming it was sane
[13:19] <jam> now I just have to figure out the spaghetti mess to figure out how to hook it together... :)
[14:02] <jam> perrito666: wwitzel3  is natefinch gone today?
[14:02] <perrito666> jam: natefinch and wallyworld_
[14:02] <perrito666> aghh
[14:02] <perrito666> wwitzel3:
[14:02] <perrito666> holiday
[14:03] <jam1> ah right memorial day
[14:03]  * perrito666 goes again
[14:03] <perrito666> jam1: nate and wwitzel3 and voidspace are on holiday today
[14:20] <bodie_> greetings
[14:25] <jcw4> bodie_: o/
[14:25] <jcw4> fwereade: I'm trying to gather my thoughts to ask you some questions about cleanup.go
[14:26] <jcw4> fwereade: are you going to be around for a bit?
[14:39] <fwereade> jcw4, let's talk now
[14:39] <fwereade> jcw4, if you can?
[14:39] <fwereade> jcw4, otherwise we can do the one in 80m
[14:40] <fwereade> jcw4, I have a meeting in 20m but if I can save you a bit of time I would be delighted
[14:42] <jcw4> fwereade: I've started working on cleanupDeadUnit
[14:43] <jcw4> fwereade: and it's unclear if it should be called in unit destroyOps
[14:43] <jcw4> fwereade: or in a new *Ops on the unit?
[14:43] <jcw4> fwereade: seems there should be some hook for EnsureDead
[14:43] <jcw4> fwereade: to call some *Ops fn
[14:44] <fwereade> jcw4, hmm, so, Destroy will go from alive to either dying or removed
[14:44] <fwereade> jcw4, if it's in fast-forward mode, we should add a cleanup there in destroy
[14:44] <jcw4> fwereade: I see... so EnsureDead is not guaranteed to run... makes sense.
[14:44] <fwereade> jcw4, wondering whether it makes more sense to tack it onto the remove ops
[14:45] <jcw4> fwereade: okay, so just add it as another op right after the cleanupDyingUnit...
[14:45] <fwereade> jcw4, the cleanups would not be guaranteed to run before the unit was removed anyway
[14:46] <fwereade> jcw4, not sure I follow you there
[14:46] <jcw4> fwereade: unit.go:325
[14:46] <fwereade> jcw4, nah, that'll run while the unit is still dying and not necessarily dead
[14:47] <jcw4> fwereade: ok. that's what I was stumbling against.  so removeOps... line 367...
[14:47] <jcw4> I see
[14:47] <fwereade> jcw4, I'd add it in Service.unitRemoveOps
[14:48] <jcw4> fwereade: okay.. that makes sense
[14:48] <fwereade> jcw4, sorry, removeUnitOps
[14:48] <fwereade> jcw4, cool
[14:49] <jcw4> fwereade: I'll start looking there and ping you with further questions as needed
[15:23] <bodie_> looks like the dirt in xeipuuv/gojsonschema is in sigu-399/gojsonreference
[15:24] <bodie_> I need to make sure there's not more in gojsonschema itself, but gojsonpointer looks pretty OK if not terribly beautifully written
[16:00] <bodie_> mgz, you around?
[16:00] <bodie_> :)
[16:03] <jcw4> fwereade: If we cleanup actions in removeOps it seems that we could miss actions added while the unit is Dying...
[16:05] <perrito666> hey what does it means when godeps yields "blah is not clean"
[16:05] <perrito666> where blah is a dependency path
[16:08] <fwereade> jcw4, I don't think so?
[16:21] <jam> fwereade: should we be versioning the Admin api and not changing Login without a version bump?
[16:21] <fwereade> jam, ha, yes, good point
[16:21] <fwereade> jam, excellent testbed
[16:21] <jam> ... :(
[16:22] <jam> true, though more work for me
[16:22] <fwereade> jam, we will probably notice of login fails
[16:22] <jam> fwereade: well, it is our entry point where we were going to tack on the compat stuff
[16:22] <jam> so it is a bit hard to get right
[16:23] <jam> fwereade: namely old servers will happily pay no attention to a "Version: 2" in the Admin login request
[16:23] <jam> is that good/ok ?
[16:23] <jam> (as in, you pass V2, but you just get login v1)
[16:23] <jam> well, v0 at least
[16:24] <fwereade> jam, it's not ideal, but I think it's inescapable... trying to figure out the worst that could happen
[16:39] <jam> fwereade: well, we can just "Login", 2 and have it just work but not give us back the actual v2 of the call.
[18:22] <bodie_> okay this gojsonreference module is weird
[18:24] <bodie_> heh, discarding errors in the test....
[18:24] <bodie_> let's see how much of gojsonschema is broken once this is unbroken
[19:35] <bodie_> okay, implemented some much better testing in gojsonschema
[19:35] <bodie_> I'm pretty sure they just had some dumb typos, but it looks like there might be a problem with their implementation of gojsonpointer regarding URL scheme
[19:36] <bodie_> (fwereade, mgz, rogpeppe)
[19:36] <bodie_> sorry, implemented testing in gojsonreference, not gojsonschema
[19:36] <bodie_> the uglier of the dependencies
[19:37] <jcw4> bodie_: o/
[19:37] <bodie_> :)
[19:38] <jcw4> bodie_: you haven't pushed back up to github yet?
[19:38] <bodie_> I have, actually.  it's under a dev branch
[19:39] <jcw4> bodie_: I see now.. tx
[19:39] <bodie_> pushed up latest bits
[19:42] <bodie_> oy, just noticed Go playground is more verbose about errors than my vim plugin.
[19:42] <bodie_> that's very annoying.
[19:42] <jcw4> oh?
[19:43] <bodie_> http://play.golang.org/p/dXHaRCeB_l
[19:43] <bodie_> mine was giving me something like "expression expected"
[19:44] <jcw4> ah, but not the actual syntax error "unexpected comma..."
[19:46] <bodie_> right
[20:08] <bodie_> urg.... found the really ugly bits of this
[20:39] <hazmat> jam, if you expect an echo/assert of the version in the response the client could handle appropriately
[20:39] <hazmat> with absence -> v0
[20:43] <thumper> fwereade: around maybe?
[21:10] <jimmiebtlr> Any hints as to where in the code I would find a machine tag being calculated, or how to get a machine tag from an id?
[21:13] <jcw4> jimmiebtlr: names/machine.go ?
[21:13] <fwereade> thumper, heyhey
[21:13] <thumper> fwereade: got some time to chat?
[21:13] <fwereade> thumper, 5 mins?
[21:13] <jcw4> fwereade: me next if possible ;)
[21:13] <thumper> fwereade: as in "in 5 minutes" or "only have 5 minutes" ?
[21:13] <jcw4> (after thumper )
[21:14] <fwereade> thumper, sorry, in 5 minutes
[21:14] <fwereade> jcw4, sure
[21:14] <thumper> fwereade: that's fine
[21:16] <jimmiebtlr> thanks
[21:18] <jcw4> jimmiebtlr: yw
[21:41] <jcw4> fwereade: I know it's late there... I'll just post my question and you can respond at your convenience
[21:41] <jcw4> fwereade: https://codereview.appspot.com/92630043 is the WIP branch
[21:42] <jcw4> fwereade: all good except the cleanup test TestCleanupEnvironmentServices is now failing because somehow the actions cleanup is getting queued but not run
[21:43] <jcw4> fwereade: when I explicitly call Unit.Remove() and then Service.Cleanup() it works...
[21:45] <jcw4> fwereade: and AFAICT cleanupUnitsForDyingServices *should* call unit.Destroy() and trigger the actions cleanup, but I *think* the unit is gone before that line of code gets run
[21:46] <jcw4> fwereade: http://paste.ubuntu.com/7524594/
[21:49] <jcw4> fwereade: I see that cleanupUnitsForDyingServices only processes Units that are Alive...
[22:05] <fwereade> jcw4, it's ok, I think: you clean up the environment services, but those cleanups schedule more cleanups because some units got removed; you then need to clean up *again* before there are no cleanups left
[22:06] <jcw4> fwereade, I think that's what I just came to
[22:06] <fwereade> jcw4, unit.Destroy will *queue* the actions cleanup but not run it
[22:06] <jcw4> I'm busy adding one more assertCleanupsRun to the test + comments explaining
[22:06] <fwereade> jcw4, assertCleanupCount is what I introduced last branch for exactly that reaosn wrt dying-unit cleanups
[22:07] <fwereade> jcw4, comments explaining why it's used will generally be appreciated, indeed
[22:07] <jcw4> fwereade: Okay, I'll plan on using assertCleanupCount too to make sure we're not succeeding accidentally
[22:07] <fwereade> jcw4, cool
[22:07] <jcw4> fwereade: tx
[22:07] <jcw4> fwereade: btw... do you have involvement in the ubuntu sprint in your neck of the woods this week?
[22:08] <jcw4> fwereade: I just saw niemeyers comment on G+ and thought it was an interesting co-incidence:)
[22:17] <fwereade> jcw4, not really, but I will surely pop down into sliema to say hi
[22:17] <fwereade> jcw4, it's client stuff really
[22:17] <jcw4> fwereade: i see :)
[22:18] <jcw4> fwereade: tests passing now.. .I think I'll do a real lbox propose now
[22:18] <fwereade> jcw4, cool, I need to do tidying up and stuff now, if I still have enrgy when I'm done I'll pass by and see what I can do
[22:19] <jcw4> fwereade: thx, no pressure :)
[22:35] <jcw4> fwereade, fwiw https://codereview.appspot.com/92630043/
[22:58] <waigani> why does this test not run: http://pastebin.ubuntu.com/7524918 ?
[22:59] <waigani> it is not inside juju-core, just an exercise to understand the testing setup
[23:10] <wallyworld_> waigani: you need to register the test
[23:10] <wallyworld_> func Test(t *testing.T) {
[23:10] <wallyworld_> 	gc.TestingT(t)
[23:10] <wallyworld_> }
[23:10] <wallyworld_> not the test i mean, but you need to set up to run with gocheck
[23:24] <davecheney> wallyworld_: is ppc passing in ci yet ?
[23:24] <wallyworld_> davecheney: yes andno. intermittent mongo failures, not releated to ppc http://juju-ci.vapour.ws:8080/job/walk-unit-tests-ppc64el-trusty-devel/
[23:24] <wallyworld_> there's a good run of blue there
[23:25] <davecheney> awesome
[23:25] <davecheney> do you think the mongo failure are because mongo on ppc is not well tested ?
[23:32] <wallyworld_> davecheney: it fails on amd64 too. mongo is not my favourite db, let's put it that way to stay polite
[23:36] <waigani> wallyworld_: Thank you! so that is how gc stitches up to the standard go testing package?
[23:36] <wallyworld_> yep
[23:37] <wallyworld_> a lot of our packages have a package_test.go in them - that's the convention we use since there is often more than one test file
[23:37] <wallyworld_> and we only want to register once per package