[00:14] yay, thanks lp ,https://launchpadlibrarian.net/145125461/buildlog.txt.gz [00:20] davecheney: hi [00:20] davecheney: whazzup? [00:22] thumper: everything OSCON related [00:23] everything? wow [00:23] thumper: https://codereview.appspot.com/11333043/ [00:23] that's a lot [00:23] ^ if this lands, does that mean we can say 1.11.3 will have a local providerr [00:23] yes [00:23] it won't be perfect [00:23] or is the reality more nuanced ? [00:23] but it works [00:23] there are a few rough edges [00:24] 1. containers don't restart on reboot yet [00:24] i ask because when we add providers to all.go [00:24] 2. outside addresses for machines is broken [00:24] then they show up in juju init [00:24] right [00:24] it is functional [00:24] as it, you can bootstrap, deploy to it, and it works [00:24] and destroy [00:24] etc [00:25] right [00:25] sweet [00:26] how do you work out which goroutine caused the "fault" here: http://paste.ubuntu.com/5881651/ [00:26] bigjools: the one that paniced L( [00:26] bigjools: always the top one [00:27] davecheney: good to know, ta [00:27] bigjools: it might look like they are sorted [00:27] but that is just a fluke [00:27] next question, WTF [00:27] the faulting goroutine is the one on the top [00:27] 0xb is SIGSEGV [00:27] how readable :) [00:28] is this a golang bug? [00:28] bigjools: very likely, this was go 1.0.2 [00:28] on raring [00:28] bigjools: that fault is a very 'fuck what happened' [00:28] last ditch error [00:29] normal nil derefs are less cryptic [00:29] same code works on precise [00:29] precise has a differnt version 1.0 [00:29] bigjools: is it reproducable [00:29] the panic ? [00:29] s/panic/fault [00:30] I believe so (no personal experience) [00:30] ie, always crashes on raring/1.0.2 [00:30] just catching up with email and saw that rvb had this [00:30] I am wondering how he built the binaries now [00:31] ie did he build on precise for precise deployment, raring for raring, etc [00:32] is this a known bug? ERROR juju runner.go:200 worker: fatal "machiner": unauthorized [00:33] bigjools: i do not think so [00:33] i haven't seen anything like that reported recently [00:33] oh apparently Roger and William are investigating [00:33] only happens on saucy [00:39] davecheney: the branch of Gavin's that you just approved requires gwacl to be updated too, can you make that happen on the bot or do we need jam? [00:40] bigjools: i have no access to the bot :( [00:40] \o/ [00:40] this dependency situation is riduclous [00:41] and other, better spelled, things [00:43] http://25.media.tumblr.com/tumblr_lo9qb4Narf1qdw1bro1_500.gif [00:58] davecheney: when is oscon? [00:58] much better [00:58] next week [00:58] davecheney: and are you talking about juju? [00:58] ah, that's right [00:58] and mramm is there too right? [00:59] * thumper goes to write some tests [01:01] thumper: yes [01:12] davecheney: is that a yes to you talking about juju? [01:32] wallyworld__: we are landing machines today [01:32] go go go [01:33] indeed [01:33] i only have one more to go but am making changes and may need another +1 from william [01:34] thumper: since when did we decide to block imports? sadly go fmt doesn't know about that and so now i have to tediously inspect each file i change [01:34] wut? [01:34] till now i've been able to rely on go fmt to Do The Right Thing [01:34] i got a code review comment about it [01:34] oh [01:34] a while back [01:34] since go fmt didn't Do The Right Thing [01:35] was there an email i missed? [01:35] it just mixes them [01:35] wallyworld__: probably [01:35] it was to the list [01:35] from jam [01:35] go fmt puts things in alphabetical order [01:35] right, but it is better to have: [01:35] standard libs [01:35] blank [01:35] other deps [01:35] blank [01:35] juju-core [01:36] sigh. sure. but the tooling doesn't support it :-( [01:36] it does sort each block [01:36] so it kinda does [01:36] it just doesn't split into blocks for you [01:36] ok. if it sorts each block that's kinda ok [01:37] too bad there isn't a tool like we had for lp [01:37] to fix them up [01:37] you could write one :) [01:37] still is tedious without one [01:37] i could in my copious spare time [01:38] that's the spirit [01:38] blood from stone and all that [01:38] gotta sleep and eat sometimes [01:38] first world problem i know [01:40] :) [01:44] wallyworld__: hangout? [01:44] ok [01:45] i'll start? [01:46] https://plus.google.com/hangouts/_/c8ac9986272fa8ed8fcdc3983ab3deeb0297ad2d?hl=en [01:57] wallyworld__: https://codereview.appspot.com/11327043/ [01:58] wallyworld__: and https://codereview.appspot.com/11327044/ [01:58] ok === _mup__ is now known as _mup_ [02:38] thumper: you owe me. by +1ing your 2nd mp, i've condemned myself to work fixing it up when my current branch lands [02:38] * thumper hands wallyworld__ a beer voucher [02:38] * wallyworld__ doesn't drink beer :-( [02:48] * thumper hands wallyworld__ a generic drink voucher [02:48] \o/ [02:48] value TBD [03:20] wallyworld__: https://codereview.appspot.com/11333043/ needs a look too [03:20] wallyworld__: it is the last [03:20] wallyworld__: the previous three are all approved and awaiting the merge bot [03:20] * thumper does a little dance [03:20] ok [03:49] thumper: fuck year [03:50] a whole year of fuck? [03:50] ... berserker [03:50] wallyworld__: I'll make a branch that uses an environ watcher for the config [03:51] wallyworld__: instead of the env variables [03:51] wallyworld__: once the others are in [03:51] davecheney: re golang backports [03:51] gpg: requesting key 448413DC from hkp server keyserver.ubuntu.com [03:51] gpgkeys: key B4CA2F7AA7F663D0B585869B1CB4303F448413DC not found on keyserver [03:51] thumper: ok [03:52] wallyworld__: then a branch to make containers restart [03:52] thumper: how do I fix that ? [03:52] sounds good [03:52] davecheney: I don't know, normally by pushing that key to the keyserver [03:52] thumper: that isn't my key [03:52] i don't think [03:52] it isn't my PPA [03:52] yeah, I know [03:53] technically I think it should be there [03:53] as the ppa thing does that. [03:53] * davecheney is lost [03:53] * thumper looks at bigjools [03:53] davecheney: got it this time [03:53] seems like a transient error [03:54] * thumper twiddles thumbs [03:54] time for another coffee I think [03:55] Coffee? Good idea. [03:55] hmm... [03:55] wallyworld__: isn't that simple actually [03:56] wallyworld__: as the worker doesn't know about the config internals [03:56] wallyworld__: I think that the environment variables are the better way to do it [03:56] * thumper moves on to restarting the containers [03:56] hmmm. should we pass config to workers [03:57] shouldn't we [03:57] env variables seem out of band [03:57] the workers know generic config [03:57] but not environment specific config [03:57] as that is private [03:58] using environment variables is actually very common [03:59] sure, but here we are talking pass stuff between application internal moving parts [03:59] if our config doesn't support that it's broken imo [04:00] wallyworld__: they are separate executables [04:00] wallyworld__: in this case, the worker is a special case [04:00] wallyworld__: I don't advocate using this by default [04:00] wallyworld__: but the local provider is always going to be a bit /special/ [04:01] ok [04:25] Hi jam — did you hear we have another gwacl update pending? [04:33] jtv: jam is only on for half a day [04:33] ah [04:33] jam: we need to make sure someone else knows about tarmac [04:33] jam: and how to poke it [04:33] We'll need someone to update its gwacl. [04:33] jam: before you go on holiday [04:34] davecheney: I wish I could write a test that checked the imports of a package [04:34] davecheney: can we use magic meta-shit for that? [04:36] Out of curiosity: what do you want to check them for? [04:37] MEGA_SHIT! [04:37] COCK! [04:37] # launchpad.net/juju-core/environs/azure [04:37] src/launchpad.net/juju-core/environs/azure/environ.go:401: not enough arguments in call to gwacl.NewNetworkConfigurationSet [04:37] https://launchpadlibrarian.net/145136519/buildlog_ubuntu-precise-i386.juju-core_1.11.3-4~1472~precise1_FAILEDTOBUILD.txt.gz [04:38] the build is broken til we can land that change via the bot [04:38] davecheney: yes, we were just trying to get the tarmac updated. [04:38] fucksticks [04:38] oh well [04:38] the recipe should work after taht [04:38] "oh well": EINCONGRUOUS [04:39] Will the upcoming Go release finally fix this just-the-tip dependencies crap? [04:41] jtv: what, and adopt best practice used throughout the software industry? don't count on it [04:41] jtv: I want to make sure that when I fix agent so it doesn't depend on the world [04:42] jtv: that I have a test to enforce that [04:43] thumper: that sounds remarkably close to one of Go's stated design goals, so you'd expect there to be a tool for that. [04:43] jtv: hopefully [04:43] I know that the go doc is able to walk the package dependencies [04:43] They were very very concerned about minimizing imports. Pike says they'd rather duplicate code than import a package for just one function. [04:43] so I'm hoping it should be easy enough [04:44] pitty we don't do that [04:44] IIRC I saw a strings function re-implemented in the url package. [04:44] the minimizing imports thing [04:44] obviously we do the duplication [04:44] "Let's do both!" [04:44] \o/ [04:44] WINNING [04:45] One problem is, with the "unused imports and variables are errors," the Go team seem to feel they've already done a lot to fight the problem — it may have taken the wind out of the sails of further support. [04:46] IME, much of the weight of pointless dependencies comes from unused types, unreachable code, and poor structuring of dependencies. The unused variables & imports are a drop in the bucket by comparison. [04:46] thumper: wallyworld__, dimitern, and mgz all have logged into the tarmac machine before so I know they have creds. Dimitern has done gwacl updates [04:46] Hi jam! [04:47] jam: awesome, is it documented anywhere? [04:47] thumper: I've sent emails, but I don't think there is a simple wiki page sort of thing. [04:48] Maybe it's time for one... There does seem to be a lot of oral tradition in this project. [04:50] hmm... arse biscuits [04:50] just got a failure from the merge bot [04:50] has to do with looking for the lxc bridge network adapter [04:50] which it obviously doesn't have [04:50] hmm... [04:55] double hmm... [04:58] jtv: gwacl is currently on rev 179, pull will bring it to 186, does that sound correct toy ou? [04:58] My local one was on 179 as well actually. Must have had a real burst of landings. [04:58] I'm checking the log. [05:00] jam: I'll try a local test run — but if that new version breaks anything else it doesn't look like a lot of work to fix it up. [05:01] thumper: as for the dependencies stuff, you can do a few things, 1) go has a very strong ast package that lets you introspect the source, 2) the package go/build lets you introspect packages, etc [05:01] jam: OK — the only build failure I'm getting is the one that that pending juju-core branch fixes. [05:01] thumper: so it is possible to do, rogpeppe has probably done some of it [05:01] So please hit the update button! [05:01] * thumper nods [05:05] jtv: update has finished please land your branch [05:06] Thanks! [05:06] It's on the way in. [05:07] davecheney: I've just updated go, how do a force a rebuild of everything? [05:08] davecheney: is there a go clean? [05:08] thumper: rm $GOPATH/{pkg,bin} ? [05:09] yeah, that worked [05:09] Better make very very sure GOPATH is set though. :) [05:09] jtv: well I was meaning cd $GOPATH rm pkg/bin, but you're right you could do the rm via env expansion, but it is a bit risky [05:09] jam: did it manually [05:10] but I got the idea [05:10] thumper: jam that is the ticket [05:10] davecheney: I'm about to land the branch that enables the local provider [05:10] thumper: excellent [05:10] jam: No worries, it was clear that you were paraphrasing because there was no "-r" either :-) [05:10] just had to mock out the interface functions for tests [05:11] it failed the first time [05:11] i'll come nagging about some word for the release notes for Evil Nick [05:11] passed locally because I have a lxcbr0 [05:11] https://docs.google.com/a/canonical.com/document/d/1ZBV6m0D1cfJQGoHW7EzJEc2qZeJFR38teHM_4OiYkeM/edit# [05:12] * thumper waits the 15 minutes for the tests to run [05:12] I believe someone just poked me, but my IRC window hung [05:12] please resend [05:13] If it was me, it wasn't important. [05:14] ah it was just dave agreeing with me [05:21] jam: was me, was not important [05:22] lets hope nobody figures out how I handle dependencies in the LP recipe, http://bazaar.launchpad.net/~dave-cheney/juju-core/package/changes [05:22] bigjools will bollock me [05:24] \o/ [05:25] Trunk is updated for the gwacl change. [05:25] Please update your gwacl, everyone, before trying to build the latest trunk. [05:26] whoop whoop [05:40] Anyone available to review https://codereview.appspot.com/11409043 ? [05:42] ... value *golxc.Error = &golxc.Error{Name:"lxc-ls", Err:(*exec.Error)(0xf840169cc0), Output:[]string(nil)} ("error executing \"lxc-ls\": exec: \"lxc-ls\": executable file not found in $PATH") [05:42] shitter [05:42] this is going to be (lower case) run [05:42] s/run/fun [05:43] Missing dependency? [05:43] thumper, have you got anything to do with that? ^ [05:43] lucky(~) % lxc-ls [05:43] The program 'lxc-ls' is currently not installed. You can install it by typing: [05:43] sudo apt-get install lxc [05:44] davecheney: there are a few bits around there [05:44] davecheney: what in particular are you looking at? [05:48] ah... [05:48] I need to mock out lxc there too [05:48] forgot about that [05:48] jtv: reviewing [05:49] Thanks [05:49] jtv: why is ec2 special ? [05:49] (probably a silly question) [05:50] ie, why doesn't the ec2 provider call ComposeUserData like the others did ? [05:54] and try to land it again... [05:54] * thumper waits the requisite 15 minutes [05:56] davecheney: did I forget a bit there!? [05:57] davecheney: yup, I did! But it's the exact same recipe as openstack. Please stand by while I fix. [05:57] jtv: cool, I was wondering why ec2 was different [05:57] you called it out in the description [05:58] thumper: i've just removed InstanceId() from local env provider. i don't think it was actually used, right? [05:58] but that didn't marry with what I saw [05:58] wallyworld__: it was used in bootstrap [05:58] thumper: 4 changes per hour, 24 hours per day [05:58] even for local? [05:58] davecheney: Absolutely right. EC2 is the Ur-provider where it all starts. I suspect I just assumed at one point that I'd done it before anything else. [05:59] the progenitor, the scion [05:59] Thank you. I knew there were better terms but couldn't think of any. [05:59] Except Urvater, but that's not English. [05:59] thumper: so local bootstrap does call jujud --bootstrap-state? i didn't see it using that or cloud init anywhere [06:01] jtv: ooh, nice word [06:01] Oh good, now I have a conflict! [06:01] Please bear with me. [06:01] you need the überlagern [06:02] thumper: in fact, local bootstrap just writes the state file directly from what i can see [06:02] wallyworld__: it was used in one and only one place [06:02] so provider.InstanceId() is not used unless i am on crack and can't see it [06:02] wallyworld__: if you removed it, you've fixed it [06:02] used != defined [06:02] it was implemented [06:02] but i was asking if anything called it [06:03] davecheney: überlagern... isn't that a verb for to spend the night in camb? [06:03] *camp [06:04] jtv: internets says it means to overlay one on top of another [06:04] wallyworld__: yes, one thing called it [06:04] really? [06:04] Ah. Well if you're going to noun it, you'll need to capitalize it as well. It's a bit like Go's exporting rules. :) [06:05] well it did when I grepped the code for it [06:05] in local? [06:05] no, [06:05] right, i already removed that then [06:05] thanks :-) [06:05] I can't even type the ü, i had to copy pasta it [06:05] "u [06:05] jtv: i'm removing InstanceId() from the Aszure provider. I'll tweak the bootstrap code to make the tests pass. tomorrow after i land can you do a live test for me? [06:06] wallyworld__: isn't InstanceId() required? [06:06] jtv: not with my latest code [06:06] We went through a lot of pain to implement that... [06:06] jtv: the fact that it was there at all sucks [06:06] * thumper twiddles thumbs some more [06:06] about 4 minutes to wait [06:06] I can try to do a live test tomorrow, yes. It'll be my first one. [06:07] You're right, it was always a pain and a disappointment. Can you do the maas side as well then? [06:07] jtv: sorry about the implementation pain. we had similar pain with openstack [06:07] if it doesn't land this time... [06:07] it can wait for tomorrow [06:07] jtv: maas already done [06:07] in my branch [06:07] Great. [06:07] tests pass fwiw :-) [06:08] There's probably a lot of code that can disappear from the Azure provider without this. [06:08] All the WALA stuff AFAIK. [06:08] wallyworld__: btw, \o/ to removing the dumb method [06:08] ../gwacl/storage.go:14: import /home/jtv/go/pkg/linux_386/launchpad.net/gwacl/logging.a: not a package file [06:08] wtf? [06:08] jtv: i removed some maas stuff too already [06:09] wallyworld__: cleanups. Always feels good. [06:09] yes. indeed [06:10] that particular method was nasty [06:10] It came as an unpleasant surprise... You don't expect part of the EnvironProvider suddenly to run on the instance and have to figure out stuff it received from the Environ on the server. [06:11] MERGED!!!! \o/ [06:12] davecheney: diff should be updated... this drives the line count for my branch even further into the negative. :) [06:12] Wow but the Rietveld part of "lbox propose" takes a long time. [06:12] delete everything for the win! [06:12] thumper: did you do it ? [06:12] do we have an lxv provider ? [06:12] yes [06:12] yes we do [06:12] * davecheney golf clap! [06:13] The delay is especially annoying without DCVS because you basically can't get any work done while waiting for lbox. [06:13] * thumper is done [06:13] see ya later [06:14] jtv: from what i can see, you could have returned "" for that InstanceId() method cause azsure is not using cloud init [06:14] and the only thing that used provider.InstanceId() was jujud bootstrap-state which was called from cloud init [06:14] whereas the azsure provider is saving the bootstrap state directly [06:15] Wait... we didn't have an *Ubuntu image* for Azure that supported cloudinit. But AIUI we do use cloudinit on Azure. [06:15] In some highly modified way, I'm sure. [06:18] ah i think you are right [06:18] If we'd done all that work for nothing, that would be a bit of a wet blanket. [06:18] but i'm almost sure it doesn't require or use InstanceId() [06:19] hence i can just delete that method, but i'll keep checking to be sure [06:19] Well with any luck we'll never know. :) [06:27] awwww shit [06:27] can someone moderate my message to juju-dev https://lists.ubuntu.com/mailman/confirm/juju-dev/cffced6f12ee7bde9b7a60b938cd49ece99e601d ? [06:31] It seems I'm not privileged. :( [06:32] bradm is fix0ring for me [06:32] ah [06:32] btw davecheney, did you get the diff update for the branch you're reviewing? [06:33] * jtv reboots [06:44] jtv: just looking now [06:44] might have to wait a bit [06:44] about to walk out the front door [08:00] mornin' all [08:00] i'm going to be unavailable for a little while as i'm reinstalling this laptop from scratch [08:00] which, hopefully, will fix lots of stuff. crossed fingers. === tasdomas_afk is now known as tasdomas [09:04] bzr: ERROR: bzrlib.errors.InvalidHttpResponse: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway [09:04] thanks for nothing lp [09:04] that is twice today a build hsa failed becuase lp soiled itself [09:11] davecheney: any idea what would cause this? we switch from 1.0.2 to 1.1 in the PPA and get failing tests: http://paste.ubuntu.com/5883536/ [09:12] the panic is.... interesting [09:14] or anyone? [09:16] * davecheney looks [09:16] bigjools: is it repeatable ? [09:17] davecheney: so far yes [09:17] bigjools: got a branch I can poke ? [09:17] davecheney: lp:gwacl [09:18] we were using 1.0 until your email [09:18] ok, it's the gwacl branch [09:18] bigjools: cleaned the pkg dir after upgrade and before testing? [09:18] yes [09:18] it bombed out much quicker when I didn't :) [09:18] the compiler would have refuse to link to old packages [09:18] it might have given a confusing error [09:18] yes [09:18] but it would not have worked [09:19] it looks like a bug in the 1.1 runtime [09:19] [fp=0x2aaaaac6f4f8] runtime.sigpanic() [09:19] /usr/lib/go/src/pkg/runtime/os_linux.c:239 +0xe7 [09:20] bigjools: maybe [09:20] checking [09:26] bigjools: yup, i see a panic [09:26] investigating [09:26] davecheney: ok ta === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: fwereade | Bugs: 7 Critical, 79 High - https://bugs.launchpad.net/juju-core/ === jtv1 is now known as jtv [09:34] bigjools: as well as the crash [09:34] are you also getting other test failures ? [09:34] no [09:34] well we were but trivial [09:34]