[00:14] <davecheney> yay, thanks lp ,https://launchpadlibrarian.net/145125461/buildlog.txt.gz
[00:20] <thumper> davecheney: hi
[00:20] <thumper> davecheney: whazzup?
[00:22] <davecheney> thumper: everything OSCON related
[00:23] <thumper> everything? wow
[00:23] <davecheney> thumper: https://codereview.appspot.com/11333043/
[00:23] <thumper> that's a lot
[00:23] <davecheney> ^ if this lands, does that mean we can say 1.11.3 will have a local providerr
[00:23] <thumper> yes
[00:23] <thumper> it won't be perfect
[00:23] <davecheney> or is the reality more nuanced ?
[00:23] <thumper> but it works
[00:23] <thumper> there are a few rough edges
[00:24] <thumper> 1. containers don't restart on reboot yet
[00:24] <davecheney> i ask because when we add providers to all.go
[00:24] <thumper> 2. outside addresses for machines is broken
[00:24] <davecheney> then they show up in juju init
[00:24] <thumper> right
[00:24] <thumper> it is functional
[00:24] <thumper> as it, you can bootstrap, deploy to it, and it works
[00:24] <thumper> and destroy
[00:24] <thumper> etc
[00:25] <davecheney> right
[00:25] <davecheney> sweet
[00:26] <bigjools> how do you work out which goroutine caused the "fault" here: http://paste.ubuntu.com/5881651/
[00:26] <thumper> bigjools: the one that paniced L(
[00:26] <davecheney> bigjools: always the top one
[00:27] <bigjools> davecheney: good to know, ta
[00:27] <davecheney> bigjools: it might look like they are sorted
[00:27] <davecheney> but that is just a fluke
[00:27] <bigjools> next question, WTF
[00:27] <davecheney> the faulting goroutine is the one on the top
[00:27] <davecheney> 0xb is SIGSEGV
[00:27] <bigjools> how readable :)
[00:28] <bigjools> is this a golang bug?
[00:28] <davecheney> bigjools: very likely, this was go 1.0.2
[00:28] <bigjools> on raring
[00:28] <davecheney> bigjools: that fault is a very 'fuck what happened'
[00:28] <davecheney> last ditch error
[00:29] <davecheney> normal nil derefs are less cryptic
[00:29] <bigjools> same code works on precise
[00:29] <davecheney> precise has a differnt version 1.0
[00:29] <davecheney> bigjools: is it reproducable
[00:29] <davecheney> the panic ?
[00:29] <davecheney> s/panic/fault
[00:30] <bigjools> I believe so (no personal experience)
[00:30] <davecheney> ie, always crashes on raring/1.0.2
[00:30] <bigjools> just catching up with email and saw that rvb had this
[00:30] <bigjools> I am wondering how he built the binaries now
[00:31] <bigjools> ie did he build on precise for precise deployment, raring for raring, etc
[00:32] <bigjools> is this a known bug? ERROR juju runner.go:200 worker: fatal "machiner": unauthorized
[00:33] <davecheney> bigjools: i do not think so
[00:33] <davecheney> i haven't seen anything like that reported recently
[00:33] <bigjools> oh apparently Roger and William are investigating
[00:33] <bigjools> only happens on saucy
[00:39] <bigjools> 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] <davecheney> bigjools: i have no access to the bot :(
[00:40] <bigjools> \o/
[00:40] <bigjools> this dependency situation is riduclous
[00:41] <bigjools> and other, better spelled, things
[00:43] <davecheney> http://25.media.tumblr.com/tumblr_lo9qb4Narf1qdw1bro1_500.gif
[00:58] <thumper> davecheney: when is oscon?
[00:58] <bigjools> much better
[00:58] <bigjools> next week
[00:58] <thumper> davecheney: and are you talking about juju?
[00:58] <thumper> ah, that's right
[00:58] <thumper> and mramm is there too right?
[00:59]  * thumper goes to write some tests
[01:01] <davecheney> thumper: yes
[01:12] <thumper> davecheney: is that a yes to you talking about juju?
[01:32] <thumper> wallyworld__: we are landing machines today
[01:32] <thumper> go go go
[01:33] <wallyworld__> indeed
[01:33] <wallyworld__> i only have one more to go but am making changes and may need another +1 from william
[01:34] <wallyworld__> 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] <thumper> wut?
[01:34] <wallyworld__> till now i've been able to rely on go fmt to Do The Right Thing
[01:34] <wallyworld__> i got a code review comment about it
[01:34] <thumper> oh
[01:34] <thumper> a while back
[01:34] <wallyworld__> since go fmt didn't Do The Right Thing
[01:35] <wallyworld__> was there an email i missed?
[01:35] <thumper> it just mixes them
[01:35] <thumper> wallyworld__: probably
[01:35] <thumper> it was to the list
[01:35] <thumper> from jam
[01:35] <wallyworld__> go fmt puts things in alphabetical order
[01:35] <thumper> right, but it is better to have:
[01:35] <thumper> standard libs
[01:35] <thumper> blank
[01:35] <thumper> other deps
[01:35] <thumper> blank
[01:35] <thumper> juju-core
[01:36] <wallyworld__> sigh. sure. but the tooling doesn't support it :-(
[01:36] <thumper> it does sort each block
[01:36] <thumper> so it kinda does
[01:36] <thumper> it just doesn't split into blocks for you
[01:36] <wallyworld__> ok. if it sorts each block that's kinda ok
[01:37] <wallyworld__> too bad there isn't a tool like we had for lp
[01:37] <wallyworld__> to fix them up
[01:37] <thumper> you could write one :)
[01:37] <wallyworld__> still is tedious without one
[01:37] <wallyworld__> i could in my copious spare time
[01:38] <thumper> that's the spirit
[01:38] <wallyworld__> blood from stone and all that
[01:38] <wallyworld__> gotta sleep and eat sometimes
[01:38] <wallyworld__> first world problem i know
[01:40] <thumper> :)
[01:44] <thumper> wallyworld__: hangout?
[01:44] <wallyworld__> ok
[01:45] <thumper> i'll start?
[01:46] <thumper> https://plus.google.com/hangouts/_/c8ac9986272fa8ed8fcdc3983ab3deeb0297ad2d?hl=en
[01:57] <thumper> wallyworld__: https://codereview.appspot.com/11327043/
[01:58] <thumper> wallyworld__: and https://codereview.appspot.com/11327044/
[01:58] <wallyworld__> ok
[02:38] <wallyworld__> 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] <wallyworld__> \o/
[02:48] <thumper> value TBD
[03:20] <thumper> wallyworld__: https://codereview.appspot.com/11333043/ needs a look too
[03:20] <thumper> wallyworld__: it is the last
[03:20] <thumper> wallyworld__: the previous three are all approved and awaiting the merge bot
[03:20]  * thumper does a little dance
[03:20] <wallyworld__> ok
[03:49] <davecheney> thumper: fuck year
[03:50] <thumper> a whole year of fuck?
[03:50] <davecheney> ... berserker
[03:50] <thumper> wallyworld__: I'll make a branch that uses an environ watcher for the config
[03:51] <thumper> wallyworld__: instead of the env variables
[03:51] <thumper> wallyworld__: once the others are in
[03:51] <thumper> davecheney: re golang backports
[03:51] <thumper> gpg: requesting key 448413DC from hkp server keyserver.ubuntu.com
[03:51] <thumper> gpgkeys: key B4CA2F7AA7F663D0B585869B1CB4303F448413DC not found on keyserver
[03:51] <wallyworld__> thumper: ok
[03:52] <thumper> wallyworld__: then a branch to make containers restart
[03:52] <davecheney> thumper: how do I fix that ?
[03:52] <wallyworld__> sounds good
[03:52] <thumper> davecheney: I don't know, normally by pushing that key to the keyserver
[03:52] <davecheney> thumper: that isn't my key
[03:52] <davecheney> i don't think
[03:52] <davecheney> it isn't my PPA
[03:52] <thumper> yeah, I know
[03:53] <thumper> technically I think it should be there
[03:53] <thumper> as the ppa thing does that.
[03:53]  * davecheney is lost
[03:53]  * thumper looks at bigjools
[03:53] <thumper> davecheney: got it this time
[03:53] <thumper> seems like a transient error
[03:54]  * thumper twiddles thumbs
[03:54] <thumper> time for another coffee I think
[03:55] <jtv> Coffee?  Good idea.
[03:55] <thumper> hmm...
[03:55] <thumper> wallyworld__: isn't that simple actually
[03:56] <thumper> wallyworld__: as the worker doesn't know about the config internals
[03:56] <thumper> 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] <wallyworld__> hmmm. should we pass config to workers
[03:57] <wallyworld__> shouldn't we
[03:57] <wallyworld__> env variables seem out of band
[03:57] <thumper> the workers know generic config
[03:57] <thumper> but not environment specific config
[03:57] <thumper> as that is private
[03:58] <thumper> using environment variables is actually very common
[03:59] <wallyworld__> sure, but here we are talking pass stuff between application internal moving parts
[03:59] <wallyworld__> if our config doesn't support that it's broken imo
[04:00] <thumper> wallyworld__: they are separate executables
[04:00] <thumper> wallyworld__: in this case, the worker is a special case
[04:00] <thumper> wallyworld__: I don't advocate using this by default
[04:00] <thumper> wallyworld__: but the local provider is always going to be a bit /special/
[04:01] <wallyworld__> ok
[04:25] <jtv> Hi jam — did you hear we have another gwacl update pending?
[04:33] <thumper> jtv: jam is only on for half a day
[04:33] <jtv> ah
[04:33] <thumper> jam: we need to make sure someone else knows about tarmac
[04:33] <thumper> jam: and how to poke it
[04:33] <jtv> We'll need someone to update its gwacl.
[04:33] <thumper> jam: before you go on holiday
[04:34] <thumper> davecheney: I wish I could write a test that checked the imports of a package
[04:34] <thumper> davecheney: can we use magic meta-shit for that?
[04:36] <jtv> Out of curiosity: what do you want to check them for?
[04:37] <davecheney> MEGA_SHIT!
[04:37] <davecheney> COCK!
[04:37] <davecheney> # launchpad.net/juju-core/environs/azure
[04:37] <davecheney> src/launchpad.net/juju-core/environs/azure/environ.go:401: not enough arguments in call to gwacl.NewNetworkConfigurationSet
[04:37] <davecheney> https://launchpadlibrarian.net/145136519/buildlog_ubuntu-precise-i386.juju-core_1.11.3-4~1472~precise1_FAILEDTOBUILD.txt.gz
[04:38] <davecheney> the build is broken til we can land that change via the bot
[04:38] <jtv> davecheney: yes, we were just trying to get the tarmac updated.
[04:38] <davecheney> fucksticks
[04:38] <davecheney> oh well
[04:38] <davecheney> the recipe should work after taht
[04:38] <jtv> "oh well": EINCONGRUOUS
[04:39] <jtv> Will the upcoming Go release finally fix this just-the-tip dependencies crap?
[04:41] <wallyworld__> jtv: what, and adopt best practice used throughout the software industry? don't count on it
[04:41] <thumper> jtv: I want to make sure that when I fix agent so it doesn't depend on the world
[04:42] <thumper> jtv: that I have a test to enforce that
[04:43] <jtv> 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] <thumper> jtv: hopefully
[04:43] <thumper> I know that the go doc is able to walk the package dependencies
[04:43] <jtv> 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] <thumper> so I'm hoping it should be easy enough
[04:44] <thumper> pitty we don't do that
[04:44] <jtv> IIRC I saw a strings function re-implemented in the url package.
[04:44] <thumper> the minimizing imports thing
[04:44] <thumper> obviously we do the duplication
[04:44] <jtv> "Let's do both!"
[04:44] <thumper> \o/
[04:44] <thumper> WINNING
[04:45] <jtv> 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] <jtv> 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] <jam> 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] <jtv> Hi jam!
[04:47] <thumper> jam: awesome, is it documented anywhere?
[04:47] <jam> thumper: I've sent emails, but I don't think there is a simple wiki page sort of thing.
[04:48] <jtv> Maybe it's time for one...  There does seem to be a lot of oral tradition in this project.
[04:50] <thumper> hmm... arse biscuits
[04:50] <thumper> just got a failure from the merge bot
[04:50] <thumper> has to do with looking for the lxc bridge network adapter
[04:50] <thumper> which it obviously doesn't have
[04:50] <thumper> hmm...
[04:55] <thumper> double hmm...
[04:58] <jam> jtv: gwacl is currently on rev 179, pull will bring it to 186, does that sound correct toy ou?
[04:58] <jtv> My local one was on 179 as well actually.  Must have had a real burst of landings.
[04:58] <jtv> I'm checking the log.
[05:00] <jtv> 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] <jam> 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] <jtv> jam: OK — the only build failure I'm getting is the one that that pending juju-core branch fixes.
[05:01] <jam> thumper: so it is possible to do, rogpeppe has probably done some of it
[05:01] <jtv> So please hit the update button!
[05:01]  * thumper nods
[05:05] <jam> jtv: update has finished please land your branch
[05:06] <jtv> Thanks!
[05:06] <jtv> It's on the way in.
[05:07] <thumper> davecheney: I've just updated go, how do a force a rebuild of everything?
[05:08] <thumper> davecheney: is there a go clean?
[05:08] <jam> thumper: rm $GOPATH/{pkg,bin}  ?
[05:09] <thumper> yeah, that worked
[05:09] <jtv> Better make very very sure GOPATH is set though.  :)
[05:09] <jam> 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] <thumper> jam: did it manually
[05:10] <thumper> but I got the idea
[05:10] <davecheney> thumper: jam that is the ticket
[05:10] <thumper> davecheney: I'm about to land the branch that enables the local provider
[05:10] <davecheney> thumper: excellent
[05:10] <jtv> jam: No worries, it was clear that you were paraphrasing because there was no "-r" either :-)
[05:10] <thumper> just had to mock out the interface functions for tests
[05:11] <thumper> it failed the first time
[05:11] <davecheney> i'll come nagging about some word for the release notes for Evil Nick
[05:11] <thumper> passed locally because I have a lxcbr0
[05:11] <davecheney> 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] <jam> I believe someone just poked me, but my IRC window hung
[05:12] <jam> please resend
[05:13] <jtv> If it was me, it wasn't important.
[05:14] <jam> ah it was just dave agreeing with me
[05:21] <davecheney> jam: was me, was not important
[05:22] <davecheney> 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] <davecheney> bigjools will bollock me
[05:24] <jtv> \o/
[05:25] <jtv> Trunk is updated for the gwacl change.
[05:25] <jtv> Please update your gwacl, everyone, before trying to build the latest trunk.
[05:26] <davecheney> whoop whoop
[05:40] <jtv> Anyone available to review https://codereview.appspot.com/11409043 ?
[05:42] <davecheney> ... 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] <davecheney> shitter
[05:42] <davecheney> this is going to be (lower case) run
[05:42] <davecheney> s/run/fun
[05:43] <jtv> Missing dependency?
[05:43] <jtv> thumper, have you got anything to do with that?  ^
[05:43] <davecheney> lucky(~) % lxc-ls
[05:43] <davecheney> The program 'lxc-ls' is currently not installed. You can install it by typing:
[05:43] <davecheney> sudo apt-get install lxc
[05:44] <thumper> davecheney: there are a few bits around there
[05:44] <thumper> davecheney: what in particular are you looking at?
[05:48] <thumper> ah...
[05:48] <thumper> I need to mock out lxc there too
[05:48] <thumper> forgot about that
[05:48] <davecheney> jtv: reviewing
[05:49] <jtv> Thanks
[05:49] <davecheney> jtv: why is ec2 special ?
[05:49] <davecheney> (probably a silly question)
[05:50] <davecheney> ie, why doesn't the ec2 provider call ComposeUserData like the others did ?
[05:54] <thumper> and try to land it again...
[05:54]  * thumper waits the requisite 15 minutes
[05:56] <jtv> davecheney: did I forget a bit there!?
[05:57] <jtv> davecheney: yup, I did!  But it's the exact same recipe as openstack.  Please stand by while I fix.
[05:57] <davecheney> jtv: cool, I was wondering why ec2 was different
[05:57] <davecheney> you called it out in the description
[05:58] <wallyworld__> thumper: i've just removed InstanceId() from local env provider. i don't think it was actually used, right?
[05:58] <davecheney> but that didn't marry with what I saw
[05:58] <thumper> wallyworld__: it was used in bootstrap
[05:58] <davecheney> thumper: 4 changes per hour, 24 hours per day
[05:58] <wallyworld__> even for local?
[05:58] <jtv> 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] <davecheney> the progenitor, the scion
[05:59] <jtv> Thank you.  I knew there were better terms but couldn't think of any.
[05:59] <jtv> Except Urvater, but that's not English.
[05:59] <wallyworld__> thumper: so local bootstrap does call jujud --bootstrap-state? i didn't see it using that or cloud init anywhere
[06:01] <davecheney> jtv: ooh, nice word
[06:01] <jtv> Oh good, now I have a conflict!
[06:01] <jtv> Please bear with me.
[06:01] <davecheney> you need the überlagern
[06:02] <wallyworld__> thumper: in fact, local bootstrap just writes the state file directly from what i can see
[06:02] <thumper> wallyworld__: it was used in one and only one place
[06:02] <wallyworld__> so provider.InstanceId() is not used unless i am on crack and can't see it
[06:02] <thumper> wallyworld__: if you removed it, you've fixed it
[06:02] <wallyworld__> used != defined
[06:02] <wallyworld__> it was implemented
[06:02] <wallyworld__> but i was asking if anything called it
[06:03] <jtv> davecheney: überlagern...  isn't that a verb for to spend the night in camb?
[06:03] <jtv> *camp
[06:04] <davecheney> jtv: internets says it means to overlay one on top of another
[06:04] <thumper> wallyworld__: yes, one thing called it
[06:04] <wallyworld__> really?
[06:04] <jtv> 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] <thumper> well it did when I grepped the code for it
[06:05] <wallyworld__> in local?
[06:05] <thumper> no,
[06:05] <wallyworld__> right, i already removed that then
[06:05] <wallyworld__> thanks :-)
[06:05] <davecheney> I can't even type the ü, i had to copy pasta it
"u
[06:05] <wallyworld__> 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] <jtv> wallyworld__: isn't InstanceId() required?
[06:06] <wallyworld__> jtv: not with my latest code
[06:06] <jtv> We went through a lot of pain to implement that...
[06:06] <wallyworld__> jtv: the fact that it was there at all sucks
[06:06]  * thumper twiddles thumbs some more
[06:06] <thumper> about 4 minutes to wait
[06:06] <jtv> I can try to do a live test tomorrow, yes.  It'll be my first one.
[06:07] <jtv> You're right, it was always a pain and a disappointment.  Can you do the maas side as well then?
[06:07] <wallyworld__> jtv: sorry about the implementation pain. we had similar pain with openstack
[06:07] <thumper> if it doesn't land this time...
[06:07] <thumper> it can wait for tomorrow
[06:07] <wallyworld__> jtv: maas already done
[06:07] <wallyworld__> in my branch
[06:07] <jtv> Great.
[06:07] <wallyworld__> tests pass fwiw :-)
[06:08] <jtv> There's probably a lot of code that can disappear from  the Azure provider without this.
[06:08] <jtv> All the WALA stuff AFAIK.
[06:08] <thumper> wallyworld__: btw, \o/ to removing the dumb method
[06:08] <jtv> ../gwacl/storage.go:14: import /home/jtv/go/pkg/linux_386/launchpad.net/gwacl/logging.a: not a package file
[06:08] <jtv> wtf?
[06:08] <wallyworld__> jtv: i removed some maas stuff too already
[06:09] <jtv> wallyworld__: cleanups.  Always feels good.
[06:09] <wallyworld__> yes. indeed
[06:10] <wallyworld__> that particular method was nasty
[06:10] <jtv> 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] <thumper> MERGED!!!! \o/
[06:12] <jtv> davecheney: diff should be updated...  this drives the line count for my branch even further into the negative.  :)
[06:12] <jtv> Wow but the Rietveld part of "lbox propose" takes a long time.
[06:12] <davecheney> delete everything for the win!
[06:12] <davecheney> thumper: did you do it ?
[06:12] <davecheney> do we have an lxv provider ?
[06:12] <thumper> yes
[06:12] <thumper> yes we do
[06:12]  * davecheney golf clap!
[06:13] <jtv> 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] <thumper> see ya later
[06:14] <wallyworld__> jtv: from what i can see, you could have returned "" for that InstanceId() method cause azsure is not using cloud init
[06:14] <wallyworld__> and the only thing that used provider.InstanceId() was jujud bootstrap-state which was called from cloud init
[06:14] <wallyworld__> whereas the azsure provider is saving the bootstrap state directly
[06:15] <jtv> Wait...  we didn't have an *Ubuntu  image* for Azure that supported cloudinit.  But AIUI we do use cloudinit on Azure.
[06:15] <jtv> In some highly modified way, I'm sure.
[06:18] <wallyworld__> ah i think you are right
[06:18] <jtv> If we'd done all that work for nothing, that would be a bit of a wet blanket.
[06:18] <wallyworld__> but i'm almost sure it doesn't require or use InstanceId()
[06:19] <wallyworld__> hence i can just delete that method, but i'll keep checking to be sure
[06:19] <jtv> Well with any luck we'll never know.  :)
[06:27] <davecheney> awwww shit
[06:27] <davecheney> can someone moderate my message to juju-dev https://lists.ubuntu.com/mailman/confirm/juju-dev/cffced6f12ee7bde9b7a60b938cd49ece99e601d ?
[06:31] <jtv> It seems I'm not privileged.  :(
[06:32] <davecheney> bradm is fix0ring for me
[06:32] <jtv> ah
[06:32] <jtv> btw davecheney, did you get the diff update for the branch you're reviewing?
[06:33]  * jtv reboots
[06:44] <davecheney> jtv: just looking now
[06:44] <davecheney> might have to wait a bit
[06:44] <davecheney> about to walk out the front door
[08:00] <rogpeppe1> mornin' all
[08:00] <rogpeppe1> i'm going to be unavailable for a little while as i'm reinstalling this laptop from scratch
[08:00] <rogpeppe1> which, hopefully, will fix lots of stuff. crossed fingers.
[09:04] <davecheney> bzr: ERROR: bzrlib.errors.InvalidHttpResponse: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
[09:04] <davecheney> thanks for nothing lp
[09:04] <davecheney> that is twice today a build hsa failed becuase lp soiled itself
[09:11] <bigjools> 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] <bigjools> the panic is.... interesting
[09:14] <bigjools> or anyone?
[09:16]  * davecheney looks
[09:16] <davecheney> bigjools: is it repeatable ?
[09:17] <bigjools> davecheney: so far yes
[09:17] <davecheney> bigjools: got a branch I can poke ?
[09:17] <bigjools> davecheney: lp:gwacl
[09:18] <bigjools> we were using 1.0 until your email
[09:18] <davecheney> ok, it's the gwacl branch
[09:18] <TheMue> bigjools: cleaned the pkg dir after upgrade and before testing?
[09:18] <bigjools> yes
[09:18] <bigjools> it bombed out much quicker when I didn't :)
[09:18] <davecheney> the compiler would have refuse to link to old packages
[09:18] <davecheney> it might have given a confusing error
[09:18] <bigjools> yes
[09:18] <davecheney> but it would not have worked
[09:19] <bigjools> it looks like a bug in the 1.1 runtime
[09:19] <bigjools> [fp=0x2aaaaac6f4f8] runtime.sigpanic()
[09:19] <bigjools>         /usr/lib/go/src/pkg/runtime/os_linux.c:239 +0xe7
[09:20] <davecheney> bigjools: maybe
[09:20] <davecheney> checking
[09:26] <davecheney> bigjools: yup, i see a panic
[09:26] <davecheney> investigating
[09:26] <bigjools> davecheney: ok ta
[09:34] <davecheney> bigjools: as well as the crash
[09:34] <davecheney> are you also getting other test failures ?
[09:34] <bigjools> no
[09:34] <bigjools> well we were but trivial
[09:34] <bigjools> xml formatting stuff
[09:35] <davecheney> bigjools: http://paste.ubuntu.com/5883598/
[09:35] <davecheney> this is what I see
[09:35] <bigjools> davecheney: pull again
[09:35] <bigjools> they're fixed
[09:38] <davecheney> ok
[09:40] <davecheney> bigjools: confirmed. other failures have ceased, i'm down to the segv now
[09:41] <bigjools> roger
[09:41] <rogpeppe> all reinstalled, hopefully this machine will behave better now.
[09:43] <jtv> Oh, was part of the failure just an omission to mangle calling conventions into the linkage?
[09:49] <davecheney>  // libcurl go bingding
[09:49] <davecheney> ^ what can possibly go wrong
[09:49] <bigjools> spelling
[09:51] <davecheney> bigjools: please run go test github.com/andelf/go-curl
[09:52] <bigjools> davecheney: /o\
[09:52] <bigjools> sigh
[09:54] <davecheney> [09:54] <davecheney> unexpected fault address 0xfffff8250c8b4864
[09:54] <davecheney> well, there's your problem
[09:54] <bigjools> davecheney: given the reluctance on https://code.google.com/p/go/issues/detail?id=5742 to implement renegs, I am at the point of grabbing chunks of what hair I have left
[09:55] <davecheney> bigjools: understood
[09:55] <davecheney> i know your on that thread with gavin
[09:55] <bigjools> yeah
[09:55] <davecheney> please save your pate
[09:56] <bigjools> believe me I want to - it's easier to get sunburn here
[09:58] <bigjools> davecheney: how do we work out where go-curl is breaking? the trace is useless
[09:58] <bigjools> debug build of Go?
[09:59] <davecheney> bigjools: psychic debugging
[09:59] <davecheney> i started with a bias against go-curl
[09:59] <davecheney> ran their tests
[09:59]  * bigjools ohmms
[09:59] <davecheney> saw there was the same failure
[10:00] <davecheney> ran go test -v
[10:00] <davecheney> saw it was related to callbacks from C to Go
[10:00] <davecheney> then I went to get another beer
[10:00] <bigjools> lol
[10:00] <bigjools> I gather there's some game of rugby league on tonight
[10:00] <davecheney> translatoin: i was equal parts pesimistic and lucky
[10:05] <davecheney> bigjools: https://github.com/andelf/go-curl/issues/15
[10:06] <bigjools> davecheney: I'm positive there's a solution hidden behind the, errr, whatever language that is
[10:07] <bigjools> google translate FTW
[10:08] <davecheney> what is mandarin for 'eat a dick'
[10:08] <davecheney> "Suspected cgo callback go when blocked go running. Consider other ways to make trouble. . ."
[10:08] <bigjools> 吃鸡巴
[10:09] <davecheney> http://www.toplessrobot.com/2010/11/fireflys_15_best_uses_of_chinese_profanity.php
[10:09] <davecheney> my favorite is number 7 followed by a number 3
[10:10] <bigjools> this is kind of a blocker then.  Which pot of piss shall we consume?
[10:10] <davecheney> that is a number 6
[10:14] <davecheney> unrelated, https://twitter.com/davecheney/status/357443014064480259
[10:16] <bigjools> trololol
[10:17] <davecheney> i think you mean
[10:17] <davecheney> trolololo, boom, splash, *debris noises*
[10:30] <rogpeppe> sigh
[10:30] <davecheney> rogpeppe: still not awesome ?
[10:31] <rogpeppe> davecheney: some things are now working again
[10:31] <rogpeppe> davecheney: others are broken
[10:31] <rogpeppe> davecheney: like currently i can't raise the side menu
[10:31] <rogpeppe> davecheney: oh, now i can
[10:32] <rogpeppe> davecheney: and acme is now interpreting a left button click as a right  button click, so i can't select anything
[10:34] <davecheney> bigjools: calling in favors now

[10:38] <TheMue> rogpeppe: that really sounds evil
[10:38] <TheMue> rogpeppe: done a fresh install?
[10:39] <rogpeppe> TheMue: yes, from total scratch
[10:39] <TheMue> rogpeppe: then it's even worse
[10:43] <davecheney> bigjools: ok, sitrep
[10:44] <davecheney> the package is broken because it depends on an exact representation of a function pointer in Go 1.0
[10:44] <davecheney> that was changed in Go 1.1
[10:44] <bigjools> ahahahahahaha
[10:44] <davecheney> http://golang.org/doc/go1.1#method_values
[10:45] <davecheney> the last line of that sectoin may need some revision
[10:45] <jam> davecheney: probably no "Go" code is affected, but "cgo" code is.
[10:46] <davecheney> jam: semantics semantics
[10:46] <mgz> jam: the bot seems unhappy? I can't ssh to it.
[10:46] <jam> mgz: there are 1000s of files in /tmp/mongodb*.sock
[10:46] <jam> I'm trying to "ls" all of them
[10:46] <jam> and it is bringing the machine to a halt
[10:46] <mgz> joy
[10:46] <davecheney> jam: that is standard behavior for our test suite :)
[10:46] <davecheney> tmpwatch ftw
[10:46] <jam> mgz: I sent a mail to the list, but can you check your own machine?
[10:46] <jam> I have 535 of them
[10:47] <davecheney> i have /tmp on tmpfs
[10:47] <mgz> I have a few hundred
[10:47] <davecheney> i konw it's time to clean them out when my machine starts to page
[10:47] <mgz> my machine is pretty disposable though, so tmp doesn't last that long
[10:49] <bigjools> unreadable variable names in Go doc examples obfuscates things
[10:49] <jtv> On an unrelated note, is Tarmac stuck again?
[10:49] <jam> jtv: it is "running" but I'm doing stuff like ls too-many-files*
[10:49] <jtv> Gulp
[10:49] <jam> jtv: it is currently trying to merge your patch
[10:50] <jtv> Good to know, thanks.
[10:50] <jam> jtv: but it was stuck trying to run mine
[10:50] <jam> and timing out
[10:50] <jam> because of aforementioned "too-many-files*"
[10:50] <jam> jtv: apparently the test suite leaks /tmp/mongodb-*.sock files
[10:50] <jtv> Just saw the email...  New behaviour?
[10:50] <jam> my guess being we start and stop mongo a lot and it may not clean up the sock file
[10:50] <jam> jtv: from what davecheney said, no
[10:50] <jam> just bot has been running long enough to be a $SERIOUS problem
[10:51] <jam> bot has no swap file, so it can't page anything :)
[10:51] <davecheney> sadbot
[10:51] <jtv> Maybe the test suite should run with a TMPDIR that gets cleaned up from out-of-process afterwards?
[10:53] <davecheney> jtv: it does, c.Mkdir does that
[10:53] <davecheney> obviously whatever is creating the mgo files isn't using it
[10:53] <jam> davecheney: I don't think it sets TMPDIR for mongo
[10:53] <jam> right
[10:54] <jtv> davecheney: c.Mkdir makes a directory *in* TMPDIR, but does it set TMPDIR!?
[10:54] <jtv> It would surprise mme.
[10:54] <jam> jtv: It doesn't set TMPDIR, but IME most tests are good about using c.Mkdir for the actual testing
[10:54] <jtv> Most.  :)
[10:55] <jtv> My point is that the thing that runs the test suite should try to insulate itself a bit from the test suite, rather than rely on the tests' good behaviour.
[10:55] <jtv> Because this kind of thing will just happen from time to time.
[10:56] <jam> jtv: interesting thought. The question there is: TMP, TMPDIR, TEMP, .... ?
[10:56] <jtv> The beauty of standards...
[10:57] <jtv> I thought TMPDIR was more or less the Unixy standard, but I could well be wrong.
[10:57] <jtv> Another option might be chroot.  Not as any kind of security measure, but to facilitate cleanup.
[10:58] <jam> jtv: I'm going to have to kill your process so that I can cleanup the machine. forgive me and please re-approve in a while
[10:58] <jtv> No worries.  I hope it helps!
[11:00] <jtv> No, Rietveld, this is *not* what I was asking you to do.
[11:00] <jtv> Why does Rietveld error out so often?
[11:01] <jtv> Invalid XSRF token.
[11:01] <bigjools> davecheney: feck. So 1.0.2 doesn't work with ec2, 1.1 doesn't work with Azure.  Fucking score.
[11:01] <davecheney> bigjools: yup, we hit the jackpot there
[11:02] <hazmat> how much work is implementing the tls renegotiation?
[11:02] <jtv> Any other reviewers for a cleanup job that'll eliminate some duplicate code across providers?  https://codereview.appspot.com/11409043/
[11:02] <davecheney> hazmat: step back
[11:02] <davecheney> is it known that TLS renegotaion is what we require ?
[11:02] <hazmat> yes
[11:02] <davecheney> [citation needed]
[11:03] <jtv> It seems likely, but we're not actually certain.
[11:03] <jtv> That's my assessment.  Anyone disagrees, I would be very very happy to hear the rest of the story.  :)
[11:04]  * hazmat digs around for a ref
[11:05] <jam> ok, we had *only* 8000 mongodb sock ifles
[11:05] <jtv> What a relief!
[11:05] <mgz> kittens
[11:06] <davecheney> jam: i have some spare if you need 'em
[11:10] <hazmat> jtv, davecheney most of the refs seem to refer to our own usage, or the renegotiation attack (for which recommends are disable renegotation or augment with extension from rfc 5746)
[11:11]  * jam heads to put gas in the car, I should be back in time for standup
[11:11] <jtv> Yes... we figured that was one of the reasons why the Google folks thought renegotiation was too messy to implement.  But the question was really: is renegotiation really what's needed to solve this problem?  Or is the renegotiation only happening to work around an avoidable condition?
[11:11] <mgz> gaspoweredcar
[11:13] <rogpeppe> weird, X is sending mouse events with Mod1Mask set.
[11:14] <TheMue> jtv: you've got a review
[11:14] <TheMue> jtv: a real good cleanup
[11:14] <jtv> Dankeschön
[11:14] <TheMue> jtv: Bitteschön
[11:14] <jtv> Ah yes, forgot about the underscore...
[11:14] <TheMue> :D
[11:15] <dimitern> jam: btw i noticed that in addition to mnogo-*.sock files (1751 before i removed them) my /tmp contained also quite a few test-mgo* subdirs
[11:15] <wallyworld__> dimitern: mgz: i will missing the meeting. HUGE game of football on right now
[11:15] <dimitern> wallyworld__: enjoy ;)
[11:15] <wallyworld__> i am :-)
[11:16] <wallyworld__> we are winning but only just
[11:17] <hazmat> if i had to get a working version of juju-core for a demo with openstack today. what's the recommend? go 1.1 rel branch + juju + trunk?
[11:17] <mgz> hazmat: what's in saucy should be fine
[11:18] <hazmat> i'm on precise for this
[11:20] <mgz> then you can download the tarball and build with the go backport, also the devel ppa is probably okay
[11:22] <hazmat> mgz, thanks.. i'll try tarball with a dl of go1.1.1
[11:24] <mgz> ppa:juju/golang should be fine for you
[11:33] <hazmat> hmm.. hasn't juju init been around for a while.. a build of the tarball says its not a valid command  http://pastebin.ubuntu.com/5883893/
[11:35] <mgz> hazmat: what does `juju version` say?
[11:36] <hazmat> doh.. pyjuju
[11:36] <hazmat> doing  pyjuju for maas -> openstack and then juju-core for openstack workload..
[11:50] <hazmat> mgz, is there a way to get the openstack provider to ignore invalid certs? http://paste.ubuntu.com/5883925/
[11:51] <mgz> ho ho ho
[11:51] <mgz> I think that's another thing we didn't port over from pyjuju
[11:51]  * hazmat files a bug
[11:52] <mgz> rogpeppe: ^have a look in a sec
[12:03] <hazmat> its bug 1202163 for ref
[12:03] <_mup_> Bug #1202163: openstack provider should have config option to ignore invalid certs <juju-core:New> <https://launchpad.net/bugs/1202163>
[12:05] <rogpeppe> hazmat: you can configure the http stack to always ignore invalid certs, or ignore them for just a single request
[12:06] <rogpeppe> hazmat: for the former, you can set http.DefaultClient.Transport to &http.Transport{TLSClientConfig: tls.Config{InsecureSkipVerify: true, (maybe more here)}}
[12:07] <rogpeppe> hazmat: for the latter, you can create a new http.Client and call Do (or Get or whatever) on that
[12:07]  * rogpeppe goes for lunch
[12:08] <hazmat> rogpeppe, thanks
[12:13] <jam> jtv: your maas loggo patch has landed.
[12:13] <jtv> Yup, just saw it thanks.
[12:13] <jtv> Does that mean I can land the next one too?
[12:17] <jam> jtv: there is currently a fair backlog of things to land, but you should be able to mark it approved and the bot will get to it
[12:17] <jtv> Thanks.
[13:10] <jam> to whom it may concern, we should add to the release notes that we can upgrade a 1.10 deployment to 1.11.3
[13:10] <jam> But I couldn't find the 1.11.3 release notes in my quick search
[13:14] <mgz> jam: dave linked them in his message in the "local provider revies" thread
[16:22] <gary_poster> evilnickveitch, arosales, jcastro this is the proposed replacement for the hooks tab.  AOK?  http://ubuntuone.com/1jW3lOgQLDNRup1bOX5xWf
[16:24] <jcastro> gary_poster: so "source" instead of "hooks"?
[16:24] <gary_poster> jcastro, yes per evilnickveitch bug 1201840
[16:24] <_mup_> Bug #1201840: hooks section lists more than just hooks <charmbrowser> <juju-gui:Triaged by lucapaulina> <https://launchpad.net/bugs/1201840>
[16:34] <evilnickveitch> gary_poster, cool, where does that link go to?
[16:34] <evilnickveitch> (the Contribute to this charm one)
[16:35] <gary_poster> evilnickveitch, https://juju.ubuntu.com/docs/authors-charm-store.html
[16:35] <gary_poster> evilnickveitch, AOK?  need to run
[16:36] <evilnickveitch> gary_poster, yeah, that's fine
[16:36] <gary_poster> cool, will land after lunch
[16:36] <gary_poster> thanks
[16:37] <arosales> gary_poster, taking a look
[16:38] <arosales> gary_poster, my only fear is that is is "different" that what we have from the existing charms
[16:41] <marcoceppi> gary_poster: what about just "Files"
[16:44] <jcastro> I would just call it "Code"
[16:45] <jcastro> charms are code, so just call it code
[16:45] <arosales> gary_poster, talking with eco team
[16:45] <arosales> gary_poster, seems it is ok to rename that tab to something else, consensus is looking like "code" but we wouldn't be heart broken if you kept source
[16:52] <jcastro> gary_poster: what do you think about having the Juju home button go to the browse mode and not the canvas?
[16:56] <jcastro> https://bugs.launchpad.net/juju-gui/+bug/1202306
[16:56] <_mup_> Bug #1202306: We need an "all" category <juju-gui:New> <https://launchpad.net/bugs/1202306>
[17:17] <rogpeppe> rvba: which revno of gwacl should we be using currently?
[17:19] <rogpeppe> rvba: sorry, ignore me, i hadn't pulled
[17:36] <rogpeppe> done for the day. see y'all tomorrow.
[19:14] <marcoceppi> Hey guys, compiling from source, but I already compiled juju-core a while ago. So I ran `got get -u launchpad.net/juju-core/...` which exited 0, ran go install -v launchpad.net/juju-core/... no output exit 0 but my GOPATH/bin/juju has the old version still
[19:14] <marcoceppi> anything I'm missing?
[19:20] <ahasenack> marcoceppi: try deleting it
[19:21] <marcoceppi> ahasenack: cool, I was just doing that actually
[19:36] <marcoceppi> ahasenack: http://paste.ubuntu.com/5885337/ libcurl3 is installed on the system, ran apt-get dep-build for juju-core as well same response
[19:37] <ahasenack> marcoceppi: hm, no clue, I run go get -v -u everyday
[19:37] <ahasenack> and ran it just now
[19:37] <ahasenack> marcoceppi: trash $GOPATH maybe
[19:37] <marcoceppi> ahasenack: I did, found the issue. libcurl4-gnutls-dev was needed
[19:37] <ahasenack> ok
[19:38] <marcoceppi> ahasenack: thanks!
[19:38] <ahasenack> marcoceppi: have you tried lxc? I just get "connection refused" when I bootstrap, but telnet to that host/port shows no problems
[19:38] <ahasenack> it's the mongo port
[19:38] <marcoceppi> ahasenack: I just got it compiled, about to give it a go
[19:38] <ahasenack> I get
[19:38] <ahasenack> 2013-07-17 19:36:23 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
[19:38] <ahasenack> and tcpdump indeed shows a syn and a rst
[19:39] <ahasenack> but when I telnet to the same address and port, I get a connection established
[19:39] <ahasenack> so no clue what is going on
[19:39] <marcoceppi> odd
[19:39] <ahasenack> I also don't know which mongo to use, I grabbed the raring one
[19:39] <ahasenack> 2.2.4, seems to be listening in ssl mode at least
[19:40] <ahasenack> marcoceppi: it also complained there was no secret in the env, the juju init template for local: needs admin-secret it seems
[19:41] <marcoceppi> ahasenack: I just copied the one from cheney's email
[19:41] <ahasenack> marcoceppi: it's the same as juju init, let's see if it will complain in your case
[19:43] <marcoceppi> ahasenack: ah, yeah it complains
[19:43] <marcoceppi> makes sense since that's needed for the api
[19:44] <ahasenack> makes you wonder if they really tried it ;)
[19:44] <ahasenack> then you need sudo
[19:45] <ahasenack> and install mongodb
[19:45] <ahasenack> and that's where I'm stuck now, bootstrap fails to connect to mongo, even though it's running
[19:46] <marcoceppi> ahasenack: well, it's a first cut, I'm not expecting perfection. I'm here to report bugs!
[19:47] <ahasenack> sure
[19:47] <marcoceppi> technically you had to use "root" to bootstrap the last local provider
[19:48] <marcoceppi> it just prompted for sudo password during bootstrap
[19:49] <marcoceppi> ahasenack: seems to have worked for me, waiting for status to return
[19:49] <ahasenack> marcoceppi: what did you get for bootstrap -v?
[19:49] <marcoceppi> ahasenack: http://paste.ubuntu.com/5885365/
[19:50] <marcoceppi> ahasenack: I didn't -v that command :(
[19:50] <ahasenack> marcoceppi: ok, that it was probably full of connection refused too
[19:50] <ahasenack> because it exits silently
[19:50] <marcoceppi> I'll destroy and try again in a second
[19:50] <ahasenack> then status shows what you pasted for me too
[19:50] <marcoceppi> well I'm getting connection estabilished
[19:51] <marcoceppi> finally errors with 2013-07-17 19:50:38 ERROR juju supercommand.go:235 command failed: cannot log in to admin database: auth fails
[19:51] <marcoceppi> error: cannot log in to admin database: auth fails
[19:51] <marcoceppi> mongodb is 1:2.2.4-0ubuntu1
[19:52] <ahasenack> so, the mongodb package starts mongo
[19:52] <ahasenack> juju creates another upstart job
[19:53] <ahasenack>  /etc/init/juju-db-<something>.conf
[19:53] <ahasenack> I think it starts mongo on another port, so it doesn't conflict
[19:53] <ahasenack> that job starts a mongo on port 37017
[19:53] <ahasenack> with ssl
[19:53] <ahasenack> marcoceppi: did you try bootstrap -v?
[19:53] <marcoceppi> ahasenack: bootstrapping now
[19:54] <marcoceppi> ahasenack: yeah, getting conn fail
[19:54] <ahasenack> and my juju status also fails with a ton of "connection established"
[19:54] <ahasenack> like several per second
[19:54]  * marcoceppi changes port
[19:54] <marcoceppi> nvm
[19:54] <ahasenack> I stopped the main mongodb service
[19:54] <ahasenack> so just the one started by juju is in play
[19:55] <ahasenack> even it I let it run, it's on a different port
[19:55] <ahasenack> tcp        0      0 0.0.0.0:38017           0.0.0.0:*               LISTEN      10851/mongod
[19:55] <ahasenack> and
[19:55] <ahasenack> hm, wait
[19:56] <ahasenack> it didn't start
[19:56] <ahasenack> that's the one from juju
[19:58] <marcoceppi> ahasenack: well we're in the same boat now
[19:59] <ahasenack> so when juju's mongo is running, the packaged mongodb won't start, I don't know why
[19:59] <ahasenack> not sure if it's even relevant
[20:00] <marcoceppi> ahasenack: it looks like juju mongo runs both 38017 and 37017
[20:00] <ahasenack> marcoceppi: maybe one is the web admin port
[20:00] <ahasenack> I'm trying ssl on it, but chrome is being stupid
[20:01] <ahasenack> "You attempted to reach localhost, but the server presented an invalid certificate."
[20:01] <ahasenack> and doesn't allow to continue
[20:01] <ahasenack> ok, firefox works
[20:01] <ahasenack> so 38017 is some sort of web status page
[20:01] <ahasenack> like apache's /server-status
[20:01] <marcoceppi> ack
[20:02] <ahasenack> 37017 is the client port
[20:02] <ahasenack> what clients should use
[20:02] <ahasenack> it shows some logs, that's good
[20:02] <ahasenack>            17:02:12 [conn26]  authenticate db: admin { authenticate: 1, nonce: "dd1208d655bae7f3", user: "admin", key: "770f106419a82fc861b9d03103b0cda6" }
[20:02] <ahasenack>            17:02:12 [conn26] auth: couldn't find user admin, admin.system.users
[20:02] <ahasenack> so something needs to create that user somehow
[20:02] <ahasenack> maybe that's the bootstrap step that failed
[20:02] <ahasenack> (this was as a result of juju status)
[20:05] <ahasenack> I think it's a timing issue
[20:05] <ahasenack> it starts juju-db-andreas-local (upstart job)
[20:06] <ahasenack> and I kept trying that port in another terminal, also getting connection refused
[20:06] <ahasenack> after a while, it worked
[20:06] <marcoceppi> ahasenack: yeah, so I'm running Umongo against it, it seems like core stops trying to connect too soon
[20:06] <ahasenack> agreed
[20:06] <marcoceppi> about 45 seconds after bootstrap stops trying to connect, it works
[20:07] <ahasenack> it's an aggressive retry even
[20:07] <marcoceppi> this is a little disappointing
[20:08] <ahasenack> need to stash a sleep in there somewhere, or increase the number of retries
[20:08] <ahasenack> i counted 38
[20:08] <ahasenack> 28
[20:11] <marcoceppi> I'm going to try to piss it off, see if I can past the retries
[20:16] <ahasenack> marcoceppi: worked here, I increased the timeout 10x
[20:16] <ahasenack> marcoceppi: https://pastebin.canonical.com/94586/
[20:17] <ahasenack> juju status works now
[20:18] <marcoceppi> ahasenack: brilliant
[20:18] <marcoceppi> I need to figure out how to patch that in my install
[20:18] <ahasenack> I ran go install launchpad.net/juju-core/... after that, it rebuilt the binary
[20:19] <marcoceppi> ahh, just patch it in the src
[20:19] <marcoceppi> cool
[20:19] <ahasenack> right
[20:21] <marcoceppi> ahasenack: I ended up putting it to 60, a minute seems like a fair amount of time
[20:21] <marcoceppi> ahasenack: have you opened a bug yet?
[20:21] <ahasenack> no
[20:22] <ahasenack> so far it's that (too short a timeout) and the admin-secret missing from the template
[20:22] <ahasenack> doing a deploy now, I see wget action in the process list
[20:23] <ahasenack> container running
[20:24] <marcoceppi> wow it's fast as hell
[20:26] <marcoceppi> It's a shame you still have to download the cloud image on first run
[20:26] <ahasenack> how big is that?
[20:26] <marcoceppi> I thought there was going to be a way to seed the cloud images before dpeloyment
[20:26] <marcoceppi> ~200MB
[20:27] <marcoceppi> it's used to build the template, so once it's downloaded (as it is during the first deploy command) all furture deploys are fast because it's cached
[20:27] <ahasenack> that's good enough
[20:27] <marcoceppi> in pyjuju the cache was cleared during each destroy, I wonder if it'll keep this cache around longer
[20:29] <jcastro> I remember bashing out the workflow with thumper on the cloud image sync
[20:29] <jcastro> and we asked specifically for a sync-like command to preload the image
[20:33] <ahasenack> anyway, worked, got wordpress up (with mysql) on lxc
[20:33] <ahasenack> almost
[20:33] <ahasenack> got a 502 from nginx
[20:33] <ahasenack> will debug later
[20:38] <jcastro> marcoceppi: thumper is online in a few, I'm going to snag him on G+ and ask a buncha questions
[20:38] <marcoceppi> jcastro: excellent
[20:39] <marcoceppi> ahasenack: got it running over here
[20:39]  * marcoceppi shrugs
[20:40] <marcoceppi> jcastro: dude, local provider is awesome already. But I too have a few qs for thump
[20:42] <jcastro> indeed
[20:42] <jcastro> hey do we still need sudo? maybe we can answer that dude's question
[20:43] <marcoceppi> jcastro: you need sudo for local juju-core provider
[20:44] <marcoceppi> to bootstrap and destroy
[20:44] <marcoceppi> jcastro: but I don't think his question is about using juju local provider
[20:56] <thumper> morning
[20:56] <marcoceppi> thumper: \o/
[20:57] <thumper> hi marcoceppi
[21:47] <marcoceppi> thumper: the other thing that ahasenack found while using local provider is admin-secret is not put in the local privider init template. Would you like me to open a bug for that as well?
[21:47] <thumper> marcoceppi: yes please
[21:47] <thumper> I'll look to address ASAP
[21:47] <marcoceppi> thumper: ack
[21:47] <ahasenack> thumper: congrats thumper, consider me impressed
[21:47] <thumper> ahasenack: uh... ok
[21:47] <thumper> just doing my job :)
[21:48] <ahasenack> :)
[22:51] <hazmat> thumper, local provider is pretty nice
[22:51] <thumper> hazmat: thanks
[22:51]  * thumper is working on surviving reboot
[22:51] <thumper> auto-restart containers
[22:53] <sidnei> thumper: there was a question from marcoceppi earlier about why go get -u + go install doesn't update the built version. i have the same question. :)
[22:54] <sidnei> i still have 1.11.1-saucy-amd64 after doing that
[22:54] <thumper> sidnei: I'm not entirely sure I understand your question
[22:55] <jcastro> thumper: I like that you're swamped with people asking about local. :D
[22:55] <thumper> perhpas because GOBIN isn't in your path?
[22:55] <jcastro> this is a pretty awesome milestone dude
[22:55] <thumper> jcastro: shouldn't you be not working/
[22:55] <thumper> ?
[22:55] <sidnei> thumper: did you mean GOPATH?
[22:55] <jcastro> I'm back
[22:55] <jcastro> gotta play with local. :D
[22:56] <thumper> GOPATH/bin even
[22:56] <thumper> there are several different go env vars
[22:56] <sidnei> it's there yeah
[22:56] <sidnei> $ which juju
[22:56] <sidnei> /home/sidnei/src/go/bin/juju
[22:57] <sidnei> the timestamp is fine even
[22:57] <sidnei> $ ls -la /home/sidnei/src/go/bin/juju
[22:57] <sidnei> -rwxr-xr-x 1 sidnei sidnei 13907104 Jul 17 17:05 /home/sidnei/src/go/bin/juju
[22:57] <sidnei> so i guess it got updated after all, just reports an odd version?
[22:58] <sidnei> uhm, no, it just got rebuilt but still no local
[22:59] <thumper> sidnei: haha
[22:59] <thumper> I know what it is
[22:59] <thumper> sudo ~/go/bin/juju bootstrap --debug
[22:59] <thumper> your GOPATH isn't in root's path
[22:59] <thumper> this goes away when we have it packaged
[23:00] <sidnei> uhm, i don't think that's it
[23:00] <sidnei> juju init | grep local doesn't show anything
[23:00] <sidnei> so it smells like it wasn't updated after all
[23:01] <sidnei> source is at the right revno
[23:01] <sidnei> sidnei@sidnei-laptop:~/src/go/src/launchpad.net/juju-core$ bzr revno
[23:01] <sidnei> 1279
[23:02] <sidnei> or?
[23:02] <thumper> that isn't tip
[23:02] <thumper> not even close
[23:02] <thumper> bzr info?
[23:02] <sidnei>   parent branch: http://bazaar.launchpad.net/~juju/juju-core/trunk/
[23:02] <sidnei> wtf
[23:03] <sidnei> seems like the branch changed location
[23:03] <thumper> yeah
[23:03] <thumper> sidnei: bzr pull lp:juju-core --remember
[23:03] <thumper> that'll use bzr+ssh as well
[23:04] <sidnei> fun that go get -u didn't think of looking at the new location
[23:04] <sidnei> i guess it just did a pull locally
[23:06] <sidnei> thanks thumper! eager to try local :)
[23:06]  * sidnei dinners
[23:10]  * marcoceppi continues to throw papercut fixes
[23:16] <davecheney> http://msdn.microsoft.com/en-us/library/windowsazure/gg551722.aspx
[23:16] <davecheney> how the bloody hell am I supposed to do this ?!?
[23:16]  * davecheney throws table
[23:26] <davecheney> bigjools: jtv how do you create an x509 cert for azure with openssl, is it possible ?
[23:26] <davecheney> can you get ms to create one for your ?
[23:47] <sidnei> thumper: 2013-07-17 23:45:58 ERROR juju runner.go:200 worker: fatal "machiner": unauthorized
[23:47] <sidnei>  am i missing something?
[23:47] <davecheney> jtv: bigjools oh hey, it's in the README, thanks heaps!
[23:49] <davecheney> sidnei: nope, sounds like a bug
[23:50] <sidnei> davecheney: this is with the local provisioner fwiw, i saw a mention of missing settings in the juju init -spitted template
[23:50] <davecheney> shit you guys are keen
[23:51] <davecheney> that code only landed yesterday
[23:54] <sidnei> couldn't help it, im subscribed to commits :)
[23:54] <sidnei> it keeps looping around with: 2013-07-17 23:45:58 ERROR juju runner.go:200 worker: fatal "machiner": unauthorized
[23:54] <sidnei> oops
[23:54] <sidnei> 2013-07-17 23:54:14 INFO juju runner.go:246 worker: restarting "state" in 3s
[23:55] <sidnei> looks like it might fill the disk if i leave it :)
[23:57] <thumper> hmm...
[23:57]  * thumper poks
[23:57] <thumper> pokes
[23:57] <thumper> sidnei: where are you seeing that?
[23:57] <thumper> sidnei: mine seems to be working fine
[23:58] <sidnei> thumper: locally here, in ~/.juju/local/log/machine-0.log
[23:58] <sidnei> i ran: sudo /home/sidnei/src/go/bin/juju bootstrap -v -e local
[23:59] <thumper> hmm, I don't get that
[23:59] <thumper> sidnei: missing the secret?
[23:59] <thumper> I have to fix that