[00:17]  * Makyo is away: EoD
[00:25]  * thumper has another black eye
[00:25] <thumper> I must really get better defence
[00:51] <thumper> hi axw
[00:51] <thumper> axw: do you know how I can test upgrading?
[00:51] <thumper> never done it before
[00:52] <axw> thumper: test upgrading? you mean the upgrade steps?
[00:52] <axw> (hi btw)
[00:52] <thumper> axw: no, looking at bug 1291207 and I want to upload new tools with an incremented version
[00:52] <_mup_> Bug #1291207: juju-run symlink is broken after upgrade-juju <run> <upgrade-juju> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1291207>
[00:52] <thumper> and test the unpacking process
[00:52] <thumper> I think I know where the problem is, but want to confirm
[00:53] <axw> thumper: oh, just "juju upgrade-juju --upload-tools"
[00:53] <axw> that's all I did to trigger the bug
[00:53] <axw> then I tried to "juju run" on one of the machines and found it failed
[00:53] <thumper> kk
[00:53] <thumper> ta
[01:08] <axw> looks like another red eye :(
[01:30] <thumper> axw: fix for  bug 1291207, pretty simple https://codereview.appspot.com/75680043
[01:30] <thumper> axw: ta
[01:30] <thumper> wwitzel3: working, browsing, or just can't leave well enough alone?
[01:30] <_mup_> Bug #1291207: juju-run symlink is broken after upgrade-juju <run> <upgrade-juju> <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1291207>
[01:45] <wallyworld_> axw: out of interest, have you talk to william or anyone to get buy in for the need to be able to specify the principal unit assigned to a machine. just curious to ensure there's not a chance stuff might need to be reworked if not considered the direction we need to go
[01:46] <wallyworld_> i don't have an opinion myself
[01:55] <axw> wallyworld_: it's slightly different from what he and I originally discussed, so I will get his okay before landing anyway
[01:55] <wallyworld_> ok
[01:56] <axw> wallyworld_: this is the simplest approach and can be backed out relatively easily, but there will be changes needed to support Availability Zones for ec2
[01:56] <wallyworld_> ok, i'll review it condiitonal on william's +1
[01:57] <axw> thanks
[02:10] <sinzui> wallyworld_, axw, thumper: did you ever get access to the ppc machines?
[02:10] <thumper> sinzui: yes
[02:10] <wallyworld_> sinzui: i haven't tried yet
[02:10] <sinzui> fab
[02:10] <wallyworld_> but i think i'm good to go
[02:10] <axw> yup we all have batuan and vms
[02:11] <thumper> sinzui: I have a few branches to land before 1.17.5
[02:11] <thumper> sinzui: what is your eta?
[02:11] <sinzui> okay. I heard you don't need batuan. I don't use it. But I was locked out for a few days. Juju CI has its own gateway, and I can offer it if needed to get to the machines
[02:12] <sinzui> thumper, any bug targeted to 1.17.5 is a blocker, so I have no eta
[02:12] <thumper> sinzui: hmm...
[02:12] <thumper> well I'm landing a fix for one of the three outstanding
[02:12] <sinzui> thumper, I could release tomorrow without rogpeppe 's branch, but that would need to land next week for 1.18.0
[02:12] <thumper> the other two are in progress by dimiter and rog
[02:13] <thumper> sinzui: ack
[02:13] <sinzui> thumper, I think dimiter's bug looks like a requirement. Do you agree?
[02:14] <thumper> let me look
[02:14] <thumper> hmm..
[02:14] <thumper> I'd say dimiter's is more important but not sure if it should block it or not
[02:15] <sinzui> thank you thumper. I will review the state of things when I wake. I do want to release what we have as 1.17.5
[02:16] <thumper> I vote yes, but check with william and john
[02:16] <thumper> we should go for a majority
[02:16] <thumper> if they both say no, then go with no
[02:17] <thumper> axw: how long do you think to write 'juju unset-env' ?
[02:17] <axw> thumper: 1/2 day maybe
[02:17] <sinzui> Looks like CI is desperate to make the backup-restore test pass. I'll disable it since it has never passed
[02:17]  * thumper needs coffee
[02:18] <thumper> sinzui: or move it to another CI run
[02:18] <thumper> maybe one day it'll pass :-)
[02:18] <thumper> sinzui: can I get you to add a particular CI test?
[02:18] <thumper> sinzui: after upgrading an environment, run "juju run --machine 1 hostname"
[02:19] <thumper> it shouldn't fail :-)
[02:19] <sinzui> thumper, the test has never passed since I wrote it. in fact I really cannot restore a machine and we have had too. canonistack lost CI a few weeks ago
[02:20] <sinzui> bug https://bugs.launchpad.net/juju-core/+bug/1291022 details that we have not been able to restore on openstack or ec2
[02:20] <_mup_> Bug #1291022: Cannot restore a state-server on ec2 and openstack <backup-restore> <ec2-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1291022>
[02:20] <thumper> hmm...
[02:21] <sinzui> Though I should update the bug with an example of the what we see from start to finish
[02:21] <wallyworld_> sinzui: thumper: dimiter's bug is a blocker imho because upgrades break
[02:21] <thumper> wallyworld_: ack
[02:22] <sinzui> wallyworld_, yeah. my sense was is that you could upgrade once to 1.17.5, then never upgrade again
[02:22] <wallyworld_> yep that' it
[02:22] <wallyworld_> i partially fixed it
[02:23] <wallyworld_> but not all attributes that needed setting, only datadir
[02:23] <wallyworld_> and my fix was not for local, but other providers
[02:23] <wallyworld_> dimiter wrote the original code so he is running with it
[02:32] <thumper> wallyworld_: https://codereview.appspot.com/75700043
[02:33] <thumper> wallyworld_: nm, axw did it
[02:34] <axw> wallyworld_: thanks for the reviews, I've sent an email to William to get his OK
[02:35] <axw> and will address those comments now
[02:36] <wallyworld_> np
[02:41] <davecheney> sinzui: what is the current ip of the jenkins server ?
[02:42] <sinzui> davecheney, http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/
[02:43] <sinzui> davecheney, Sorry, I need to send am email about that a juju reports, with a request for a friendly host name too
[02:44] <thumper> davecheney: do you have a doc listing the steps needed to compile juju core on ppc?
[02:46] <davecheney> sinzui: no worries
[02:46] <davecheney> thanks
[02:46] <davecheney> thumper: yes
[02:47] <davecheney> i shared it with you
[02:47] <davecheney> thumper: https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
[02:58] <axw> thumper: should Azure be in the availability mode by default?
[02:58]  * axw thinks the answer is yes
[03:00] <davecheney> [03:00] <davecheney> --- FAIL: TestDeepEqual (0.00 seconds)
[03:00] <davecheney>  deepequal_test.go:106: deepEqual(map[2:two 1:one], map[2:two 1:one]); unexpected error "mimatch at top level: type mismatch map[uint]string vs map[int]string; obtained map[uint]string{0x2:\"two\", 0x1:\"one\"}; expected map[int]string{2:\"two\", 1:\"one\"}", want "mismatch at top level: type mismatch map\\[uint\\]string vs map\\[int\\]string; obtained map\\[duint\\]string\\{0x1:\"one\", 0x2:\"two\"\\}; expected map\\[int\\]string\\{2
[03:00] <davecheney>  "github.com/juju/testing/checkers"
[03:01] <davecheney> probably map ordering expectatoin
[03:03] <axw> yup
[03:04] <axw> 0x1/0x2 are swapped
[03:04] <davecheney> https://github.com/juju/testing/issues/1
[03:05] <axw> I thought gc randomised map range
[03:05] <axw> davecheney: does it not?
[03:05] <davecheney> axw: it does
[03:06] <davecheney> but technically that is an implementatoin detail
[03:06] <axw> I guess not random enough
[03:06] <davecheney> right
[03:06] <axw> yeah I know
[03:06] <davecheney> but depending on something that is random sounds
[03:06] <davecheney> 1. hard
[03:06] <davecheney> 2. wrong
[03:06] <axw> yeah I just wondered why it wasn't failing before
[03:07] <davecheney> right now, small maps, less than 64 bytes are not that random
[03:07] <davecheney> 1.3 will make them more random
[03:07] <axw> okey dokey
[03:07] <davecheney> i lost that argument
[03:07] <davecheney> nobody should depend on map ordering
[03:24] <davecheney> thumper: some good news
[03:24] <davecheney> the go http client _does_ obey no_proxy
[03:24] <davecheney> ubuntu@winton-02:~/src$ go run noproxy.go
[03:24] <davecheney> &{403 Forbidden 403 HTTP/1.0 1 0 map[Connection:[close] X-Squid-Error:[ERR_ACCESS_DENIED 0] X-Cache-Lookup:[NONE from batuan.canonical.com:3128] X-Cache:[MISS from batuan.canonical.com] Date:[Fri, 14 Mar 2014 03:23:05 GMT] Content-Length:[1173] Content-Type:[text/html] Server:[squid/2.7.STABLE7] Via:[1.0 batuan.canonical.com:3128 (squid/2.7.STABLE7)]] 0xc210427fc0 1173 [] true map[] 0xc2104331a0} <nil>
[03:24] <davecheney> ubuntu@winton-02:~/src$ env no_proxy="google.com" !!
[03:24] <davecheney> env no_proxy="google.com" go run noproxy.go
[03:24] <davecheney> ^Cexit status 2
[03:26] <davecheney> ubuntu@winton-02:~/src$ go run noproxy.go
[03:26] <davecheney> &{403 Forbidden 403 HTTP/1.0 1 0 map[Connection:[close] X-Squid-Error:[ERR_ACCESS_DENIED 0] X-Cache-Lookup:[NONE from batuan.canonical.com:3128] X-Cache:[MISS from batuan.canonical.com] Date:[Fri, 14 Mar 2014 03:25:57 GMT] Content-Length:[1169] Content-Type:[text/html] Server:[squid/2.7.STABLE7] Via:[1.0 batuan.canonical.com:3128 (squid/2.7.STABLE7)]] 0xc210427fc0 1169 [] true map[] 0xc2104331a0} <nil>
[03:26] <davecheney> ubuntu@winton-02:~/src$ env no_proxy="10.0.3.1" go run noproxy.go
 Get http://10.0.3.1:80/: dial tcp 10.0.3.1:80: connection refused
[03:26] <davecheney> and it looks like it works for ip addrsses
[03:26] <wallyworld> thumper: guess what? i updated my packages and now unity crashes, i have no mouse, and wireless networking is broken \o/
[03:26] <davecheney> so i think it might be custom http transports inside jju that are the problem
[03:27] <davecheney> wallyworld: did you expect something else ?
[03:27] <wallyworld> well yes :-(
[03:27] <wallyworld> we are pretty close to release
[03:27] <wallyworld> i'm not sure what to do except reinstall beta 1
[03:27] <wallyworld> cause not having a mouse kinda sucks
[03:28] <davecheney> wallyworld: fuck, are we at beta 1
[03:28] <davecheney> that is terrible
[03:28] <wallyworld> and, well, networking is important too
[03:28] <davecheney> i can still hear you
[03:28] <davecheney> can't be that bad
[03:28] <wallyworld> i'm on wired
[03:28] <wallyworld> so i'm tied to a corner next to my router
[03:29] <wallyworld> not very comfortable
[03:31] <axw> wow, I think I might not update for a bit
[03:31] <axw> seeing as I have no rj45 and no adapter
[03:31] <wallyworld> it could just be my hardware or something
[03:32] <davecheney> wallyworld: what wifi ?
[03:32] <davecheney> intel or atheros ?
[03:32] <wallyworld> hmmm. can't recall. intel maybe
[03:33] <davecheney> erk
[03:42] <thumper> wallyworld: awesome...
[03:42] <wallyworld> yeah, tell me about it
[03:42] <thumper> wallyworld: I'd say wait a bit, do another apt-get update/dist-upgrade
[03:42] <thumper> and reboot
[03:42] <thumper> that's what fixed it for me
[03:42] <thumper> just package skew as I was downloading
[03:42] <wallyworld> tried that, may have to wait a bit more
[03:42] <thumper> kk
[03:59] <thumper> davecheney: https://github.com/juju/testing/pull/2
[04:00] <axw> thumper: OT question, have you flown UA? are they ok?
[04:00] <thumper> axw: not that I recall
[04:00] <thumper> may have for internal flights
[04:00] <thumper> axw: is this a long flight?
[04:01] <thumper> I have heard they aren't that good for long haul
[04:01] <axw> thumper: yeah. it's $500 more for QF :/
[04:01] <davecheney> axw: DO NOT FLY UA
[04:02] <davecheney> remember how when you were 5 and your parents took you on your first trip
[04:02] <davecheney> UA ARE STILL FLYING THAT VERY PLANE
[04:02] <axw> hehe
[04:02] <thumper> davecheney: how do you run go on ppc
[04:02] <thumper> I installed gccgo-4.9
[04:02] <thumper> but that didn't install a go binary
[04:03] <thumper> davecheney: are you in the github.com/juju team?
[04:04] <davecheney> https://docs.google.com/a/canonical.com/document/d/1m9R2n6LPLNLGjdopcNkQYVG8D5V4FTyvc1vvn-9ZifM/edit
[04:04] <davecheney> $ sudo apt-get install gccgo-4.9 gccgo-go
[04:04] <davecheney> don't forget the second package
[04:04] <davecheney> thumper: NFI
[04:04] <thumper> davecheney: can you comment on the pull request above?
[04:05] <davecheney> yeah, looks like I can
[04:05] <thumper> oh yeah, "ssh rock<tab>"
[04:06] <davecheney> WHOOT
[04:07] <thumper> davecheney: I don't see a comment from you...
[04:07] <davecheney> got a little bit closer to deploying ubuntu charm on ppc
[04:07] <davecheney> thumper: i didn't write anything
[04:07]  * thumper wants a LGTM
[04:07] <davecheney> oh, lemmie test it
[04:10] <davecheney> http://paste.ubuntu.com/7088244/
[04:10] <thumper> davecheney: tested with cgo and gccgo locally (on amd64)
[04:10] <davecheney> inching closer
[04:11] <thumper> davecheney: ah, no aufs on ppc?
[04:12] <thumper> davecheney: export JUJU_TESTING_LXC_FORCE_SLOW=true
[04:13] <davecheney> 14:58 < davecheney> a send to a nil channel blocks forever
[04:13] <davecheney> 14:58 < davecheney> a send to a closed channel panics
[04:13] <davecheney> 14:59 < davecheney> a receive from a nil channel blocks forever
[04:13] <davecheney> 14:59 < davecheney> a receive from a closed channel returns the zero value immediately
[04:13] <davecheney> oops
[04:13] <davecheney> thumper: the trick is i need to export no_proxy=... during bootstrap
[04:13] <davecheney> so those values are passed to the bootstrap agent
[04:13] <davecheney> it took a while to figure out who was making the http call
[04:14] <davecheney> also, there will be no precise image for ppc64
[04:15] <davecheney> ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy cs:trusty/ubuntu
[04:15] <davecheney> ERROR charm not found: cs:trusty/ubuntu
[04:15] <davecheney> fuck me
[04:15] <thumper> so make one dear liza
[04:16] <davecheney> the whole trick is I cant/shouldnt use a local charm repo
[04:16] <thumper> davecheney: flick the aufs lxc clone bug at hallyn
[04:17] <davecheney> thumper: http://paste.ubuntu.com/7088260/
[04:17] <davecheney> setting that setting doesn't appear to set anything
[04:17] <thumper> davecheney: if we need to disable the aufs clone for ppc, we can make it a real setting maybe
[04:17] <thumper> davecheney: you need it all the time
[04:17]  * davecheney strokes non existant beard
[04:17]  * thumper thinks
[04:17] <thumper> hmm...
[04:17] <davecheney> lemmie ask hallyn
[04:17] <thumper> poo
[04:18] <thumper> davecheney: I'm not propogating that env var into the upstart job
[04:18] <thumper> davecheney: to really test it, we'll need it stored as a setting
[04:18] <davecheney> thumper: which package is it in ?
[04:18] <davecheney> i'll hack the codeze
[04:18] <thumper> if you want to hack the codeze, just edit your upstart script
[04:18] <thumper> for jujud
[04:19] <davecheney> ok
[04:19] <davecheney> imma going to raise a bug
[04:19] <davecheney> that we can throw at ahllyn
[04:19] <thumper> ah...
[04:19] <thumper> let me think
[04:19] <thumper> davecheney: what shall we call the local provider setting
[04:20] <thumper> lxc-no-clone ?
[04:20] <thumper> or lxc-clone
[04:20] <thumper> default to true
[04:20] <thumper> allow false
[04:20] <thumper> actually, default to true IFF trusty
[04:23] <thumper> davecheney: are you testing that github.com/juju/testing branch?
[04:24] <davecheney> thumper: not right now
[04:24] <thumper> kk
[04:26] <thumper> davecheney: I'm fetching it...
[04:26] <thumper> just to confirm on ppc, I know it passes with gccgo locally
[04:35] <thumper> davecheney: http://paste.ubuntu.com/7088314/
[04:36] <davecheney> lgtm
[04:36] <davecheney> i was getting there
[04:36] <thumper> that's ok
[04:36] <thumper> merged
[04:37]  * thumper updates juju-core dep
[04:38] <davecheney> thumper: confirmed working on ppc
[04:38] <davecheney> thanks
[04:39] <thumper> np
[04:39] <thumper> that's what I'm here for :-)
[04:39] <davecheney> thumper: https://bugs.launchpad.net/juju-core/+bug/1292346
[04:39] <_mup_> Bug #1292346: juju deploy fails on ppc64el because aufs is not available <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1292346>
[04:39] <davecheney> fails on both precise and trusty
[04:39] <davecheney> deploy 'said images
[04:40] <thumper> ok
[04:40] <thumper> did you hack up the upstart script so it didn't try to use clone?
[04:41] <thumper> to test normal lxc?
[04:41] <davecheney> let me do some hacking
[04:41] <davecheney> i was distracted twisting marcoceppi 's arm to get a trusty ubuntu charm in the store
[04:42] <thumper> axw or davecheney: https://code.launchpad.net/~thumper/juju-core/update-testing/+merge/210960
[04:42] <axw> thumper: done
[04:42] <thumper> ta
[04:43] <marcoceppi> thumper: I'm about to compile juju to test the local provider, anything I should know before going in to it?
[04:43] <thumper> marcoceppi: depends
[04:43] <thumper> what filesystem do you have at /var/lib/lxc
[04:43] <marcoceppi> ext4
[04:43] <thumper> and I'm assuming you are on trusty
[04:44] <marcoceppi> saucy
[04:44] <thumper> ha
[04:44] <thumper> won't work
[04:44] <thumper> trusty only baby
[04:44] <marcoceppi> but I can be on trusty pretty quickly
[04:45] <thumper> marcoceppi: ok, what it will do is the first time you deploy a charm for a series, it will create a template container 'juju-<series>-template" like juju-precise-template
[04:45] <thumper> don't touch it
[04:45] <davecheney> thumper: marcoceppi http://paste.ubuntu.com/7088331/
[04:45] <thumper> first time it starts it, and waits for cloud init to finish and shut it down
[04:45] <davecheney> oooh
[04:45] <davecheney> ohh
[04:45] <davecheney> maybe
[04:45] <thumper> then it just clones to create machines
[04:45] <thumper> using aufs
[04:45] <davecheney>   "1":
[04:45] <davecheney>     agent-state: pending
[04:45] <davecheney>     instance-id: ubuntu-local-machine-1
[04:45] <davecheney>     series: trusty
[04:45] <davecheney>     hardware: arch=ppc64
[04:46] <axw> ooh :)
[04:46] <thumper> davecheney: ok, it is trying :)
[04:46] <davecheney> http://paste.ubuntu.com/7088333/
[04:46] <davecheney> getting very close
[04:48] <davecheney> thumper: do the agent states move to started in lxc ?
[04:48] <thumper> yes
[04:49] <davecheney> ok, so it isn't working then ...
[04:49] <thumper> when they are running and talking to the api server
[04:49] <thumper> it will take some time
[04:49] <davecheney> nope, no agents, http://paste.ubuntu.com/7088341/
[04:49] <thumper> you can watch progress by looking in /var/lib/juju/containers/ubuntu-local-machine-1
[04:49] <thumper> and look at the console.log
[04:50] <davecheney> OH NO
[04:50] <davecheney> i know what it is
[04:50] <thumper> davecheney: cloud-init may not have finished
[04:50] <davecheney> it's finsihed
[04:50] <thumper> wat?
[04:50] <davecheney> no running processes
[04:50] <davecheney> gccgo binaries need a library installed
[04:50] <axw> take a look in /var/log/cloud-init-output.log
[04:50] <axw> ugh
[04:50] <davecheney> libgo5.so
[04:50] <thumper> ugh
[04:51] <thumper> davecheney: hmm...
[04:51] <axw> environs/cloudinit/cloudinit.go is gonna need another AddPackage
[04:51] <thumper> davecheney: checking a few tests, juju-core/container passes on amd64 with both cgo and gccgo
[04:51] <thumper> fails on ppc ggcgo
[04:51] <davecheney> let me get somet details
[04:52] <davecheney> is there a simple way to go into an lxc console ?
[04:52] <davecheney> lxc-enter or something ?
[04:52] <thumper> yes...
[04:52] <thumper> ssh
[04:52] <axw> davecheney: you should be able to ssh into it
[04:52] <davecheney> oh
[04:52] <davecheney> too easy
[04:52] <thumper> :)
[04:52] <thumper> ssh into it,
[04:52] <thumper> install package
[04:52] <thumper> reboot container
[04:52] <davecheney> $ juju ssh ubuntu/0
[04:52] <davecheney> ERROR unit "ubuntu/0" has no public address
[04:52] <davecheney> bzzzzzzzzzzzzt
[04:52] <axw> try the machine
[04:53] <thumper> lxc-ls --fancy
[04:53] <davecheney> yeah, that works
[04:53] <davecheney> actually no
[04:53] <davecheney> $ juju ssh 1
[04:53] <davecheney> ERROR machine "1" has no public address
[04:53] <thumper> no unit agent to set it
[04:53] <davecheney> yup
[04:53] <thumper> lxc-ls --fancy
[04:53] <davecheney> catch 22
[04:53] <thumper> get the ip address
[04:53] <thumper> ssh ubuntu@10.0.3.x
[04:53] <davecheney> lxc-ls --fancy
[04:53] <davecheney> NAME  STATE  IPV4  IPV6  AUTOSTART
[04:53] <davecheney> ----------------------------------
[04:53] <davecheney> zip
[04:53] <thumper> ah...
[04:54] <thumper> wat
[04:54] <thumper> sounds like lxc-create failed
[04:54] <davecheney> thumper: what is your ssh key ?
[04:54] <thumper> on lp, elwood
[04:54] <axw> try as sudo
[04:55] <axw> davecheney: ^^
[04:55] <thumper> axw: yeah...
[04:55] <thumper> otherwise it is just the user space lxc
[04:55] <thumper> sorry didn't specify
[04:55] <davecheney> ahh, that works
[04:55] <davecheney> FUK<
[04:55] <davecheney> key errors now
[04:55] <davecheney> screw this
[04:55] <davecheney> i'll just chroot
[04:55] <thumper> key errors?
[04:55] <thumper> really?
[04:56] <thumper> that should have worked
[04:56] <thumper> ah...
[04:56] <thumper> if you don't have a local ssh there
[04:56] <thumper> it will be using the one it generated
[04:56] <thumper> axw: how does he specify?
[04:56] <thumper> -i
[04:56] <thumper> ?
[04:56] <axw> davecheney: use "-i ~/.juju/ssh/juju_id_rsa"
[04:56] <axw> I think that's what it's called
[04:56] <davecheney> axw: ahh yeah
[04:56] <axw> yep
[04:56] <davecheney> man, all this stuff juju ssh does for you
[04:56] <davecheney> made me soft
[04:57] <axw> maybe we should allow "juju ssh" to take an IP for this scenario
[04:57] <thumper> yeah...
[04:57] <axw> :q
[04:57] <axw> oops
[04:58] <davecheney> $ /var/lib/juju/tools/machine-1/jujud
[04:58] <davecheney> /var/lib/juju/tools/machine-1/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory
[04:58]  * thumper is waiting...
[04:58] <davecheney> got it
[04:58] <davecheney> yup
[04:58] <davecheney> that was what I though
[04:58] <davecheney> axw: maybe
[04:58] <thumper> fuck yeah!
[04:58] <davecheney> the local provider is a bit of a special case
[04:58] <thumper> closer...
[04:59] <thumper> axw: so... how do we conditionally install the libgo package?
[04:59] <axw> thumper: probably just test the arch MachineConfig.Tools
[04:59] <thumper> hmm...
[05:01] <axw> thumper: otherwise I guess we'd need to encode the toolchain in the version string
[05:01] <axw> which isn't really practical
[05:01] <thumper> no...
[05:01] <thumper> unless...
[05:01] <thumper> what about making a meta-package
[05:02] <thumper> called 'juju-deps'
[05:02] <thumper> then on ppc that includes libgo
[05:02] <thumper> and on others it doesn't
[05:02] <axw> I suppose so
[05:02] <thumper> we could then just install the meta-package
[05:02] <axw> also arm64
[05:02] <thumper> and not worry about specifics
[05:02] <thumper> right
[05:02] <thumper> possible at least
[05:03] <thumper> davecheney: what do you think?
[05:03] <thumper> worth raising with jamespage?
[05:03] <davecheney> thumper: it's sort of worse than that
[05:03] <davecheney> there is no libgo package
[05:04] <davecheney> libgo.so.5 comes from gccgo itself, the compiler package
[05:04] <davecheney> which pulls in a tonne more
[05:04] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1292353
[05:04] <thumper> ouch
[05:04] <_mup_> Bug #1292353: juju must install the libgo.so.5 library when required <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1292353>
[05:04] <davecheney> probably need to include more project here
[05:04] <axw> davecheney: should we just distribute it with jujud?
[05:05] <thumper> axw: we'd need to update the LD_LIBRARY_PATH too right?
[05:05] <davecheney> axw: IMO that will make a bad problem worse
[05:05] <axw> yeah
[05:05] <davecheney> like thumper says
[05:06] <davecheney> we'd get into the LD_LIBRARY_PATH business
[05:06] <axw> or rpath shenanigans, but that's not any better
[05:06] <davecheney> you can do elfedit fuckery
[05:06] <thumper> davecheney: we have to work out something...
[05:06] <thumper> nah don't edit things
[05:06] <thumper> that's terrible
[05:06] <davecheney> lemmie raise a bug on gccgo
[05:06] <davecheney> probably not a big job to get it split out into a runtime pkg
[05:06] <davecheney> thumper
[05:06] <thumper> we need libgo.so in a different package
[05:06] <davecheney> if I do apt-get install X y z
[05:06] <davecheney> and z doesn't exist
[05:06] <davecheney> what does apt do ?
[05:07] <thumper> I think it fails
[05:07] <thumper> but not entirely sure
[05:07] <davecheney> thumper: you can see where I'm going with this ?
[05:07] <thumper> no
[05:07] <davecheney> axw: the good news is we'll get a libgccgo package
[05:07] <davecheney> which will be a meta for libgccgo-4.9
[05:07] <axw> cool
[05:07] <davecheney> just like gccgo suggests gccgo-4.9
[05:07] <davecheney> so we don't need to get too worked up on versions
[05:08] <thumper> aye
[05:08] <davecheney> thumper: I was thinking of always installing libgccgo [sic]
[05:08] <davecheney> andignoring any errror
[05:08] <davecheney> if it's hard to sniff the target series/arch
[05:08] <axw> well it does mean we've got a new binary compatibility issue to deal with
[05:08] <davecheney> axw: many, many
[05:08] <davecheney> axw: i did raise this with many people 6 months ago
[05:08] <davecheney> we're backing into a massive testing matrix
[05:09] <axw> davecheney: it's not hard to tell the target arch
[05:09] <axw> we can get that when we generate the cloud-init script
[05:13]  * thumper is EOWing
[05:13] <thumper> later peeps
[05:15] <davecheney> https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1292355
[05:15] <_mup_> Bug #1292355: gccgo needs a runtime package <ppc64el> <gccgo-4.9 (Ubuntu):New> <https://launchpad.net/bugs/1292355>
[05:15] <davecheney> o/ TheMue
[05:15] <davecheney> thumper
[05:17] <marcoceppi> welp, compiled core from trunk, but got a weird error
[05:17] <marcoceppi> .go/src/launchpad.net/juju-core/provider/azure/environ.go:539: cannot use []gwacl.ConfigurationSet literal (type []gwacl.ConfigurationSet) as type *gwacl.OSVirtualHardDisk in function argument
[05:17] <marcoceppi> so, no testing local provider for me, you guys are on your own
[05:18] <axw> marcoceppi: you need to update gwacl
[05:18]  * axw gets the rev
[05:19] <axw> marcoceppi: bzr update -r 231
[05:19] <axw> (in launchpad.net/gwacl)
[05:20] <marcoceppi> OH haha
[05:20] <marcoceppi> I did that in juju-core
[05:20] <marcoceppi> it was not happy
[05:20] <axw> that would be quite old :)
[05:21] <marcoceppi> haha, yeah
[05:22] <davecheney> such wrong channel
[05:23] <davecheney> if this works, i'm going to the pub
[05:24] <davecheney> if this doesn't work, i'll probably go to the pub
[05:24] <davecheney> win/win
[05:25] <davecheney> WORKED!
[05:25] <axw> winner :)
[05:25] <davecheney> http://paste.ubuntu.com/7088436/
[05:25] <davecheney> marcoceppi: http://paste.ubuntu.com/7088436/
[05:26] <marcoceppi> we have trusty!
[05:27] <davecheney> marcoceppi: a whole one charm
[05:27] <davecheney> i told you we didn't to test it
[05:27] <davecheney> that charm is a charm
[05:27] <davecheney> 100% success rate
[05:27] <marcoceppi> that charm sure is a charm
[05:27] <marcoceppi> just like all the other charms
[05:27] <davecheney> it's a perl
[05:27] <marcoceppi> but it's defintely more charmy
[05:29] <marcoceppi> yay, it still didnt' compile
[05:29] <marcoceppi> bunch of signal killed errors
[05:29] <marcoceppi> oh well, I'll just wait for 1.17.5
[05:29] <davecheney> compilation is for loosers
[05:29] <davecheney> winners write in binary
[05:30] <marcoceppi> I use magnets and write directly to tapes
[05:30] <davecheney> i use a hammer and a punch and write them directly onto roms
[05:30]  * marcoceppi drops the AIX and walks away
[05:30]  * davecheney bows to marcoceppi 
[07:35] <rogpeppe> mornin' all
[07:53] <wallyworld_> axw: i ended up having to reformat / since first install complained packages were corrupt :-( now i need to set up stuff again. sigh
[07:53] <axw> oh shit :(
[07:53] <wallyworld_> at least i have a clean install now :-)
[07:53] <axw> that is true. I did consider doing it myself, but cbf at the time
[07:53] <wallyworld_> and i backed up stuff first from command line
[07:54] <wallyworld_> so no data loss, jut time
[07:54] <axw> bit delayed, but morning rogpeppe
[07:54] <rogpeppe> axw: hiya
[07:57] <rogpeppe> axw: i've been meaning to create a bug for this, but i should mention it to you: when bootstrap in the local provider fails, the error is often not very informative these days - it's just "rc: 1"
[07:57] <axw> rogpeppe: #1279710
[07:57] <_mup_> Bug #1279710: failed bootstrap discards stderr <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1279710>
[07:57] <axw> that's because local provider now uses the script stuff, like everything else
[07:58] <rogpeppe> axw: ah, good - you're aware of it
[07:58] <axw> I am, just don't have a good solution yet
[07:58] <axw> I intend to fix it before 2.0 though for sure
[07:58] <rogpeppe> axw: yeah, i didn't see any solution that jumped out at me, though i didn't look for that long
[07:59] <rogpeppe> axw: cool - it made things quite hard to debug at times
[08:04] <axw> rogpeppe: what caused local bootstrap to fail anyway?
[08:04] <axw> or you don't know? :)
[08:04]  * rogpeppe tries to remember
[08:05] <rogpeppe> axw: sorry, can't remember - some bug in the branch that was being tested, ISTR
[08:06] <axw> rogpeppe: no worries
[08:16]  * rogpeppe is an idiot
[08:20] <rogpeppe> vladk: good morning!
[08:20] <vladk> rogpeppe: good morning!
[08:53]  * rogpeppe struggles to work out how to submit a git pull request
[08:57] <vladk> rogpeppe: I had questionable experience with github pull request
[08:57] <rogpeppe> vladk: :-)
[08:57] <rogpeppe> vladk: so many concepts
[08:59] <vladk> you may PR the whole branch, but it will be merge completely if you add smth after PR
[08:59] <vladk> if you create a PR between two commit, it may produce unpredictable merge
[09:02] <vladk> and always head of PR should be on master branch
[09:02] <rogpeppe> vladk: i've been trying to do something like this: http://paste.ubuntu.com/7089049/
[09:02] <vladk> I would not use MERGE button on PR and do manual commits
[09:03] <rogpeppe> vladk: but when i go to create the pull request on github, it says there's no difference between my branch and master
[09:03] <vladk> you should push before
[09:04] <rogpeppe> vladk: before pushing the changes?
[09:05] <vladk> rogpeppe: you create PR on github, so you should push your commits to github before
[09:05] <rogpeppe> vladk: before creating the pull request?
[09:05] <rogpeppe> vladk: i did do that, i think
[09:05] <vladk> rogpeppe: may I look your repo on github?
[09:06] <rogpeppe> vladk: (i haven't been able to create a pull request yet)
[09:06] <rogpeppe> vladk: sure
[09:06] <rogpeppe> vladk: this is what i'm looking at currently: https://github.com/go-yaml/yaml/compare/master...rename-imports
[09:06] <rogpeppe> vladk: the  branch i want to merge is rename-imports
[09:07] <rogpeppe> vladk: and i want to create a pull request into github.com/go-yaml/yaml
[09:08] <vladk> rogpeppe: I don't see any changes in remote-imports
[09:09] <rogpeppe> vladk: ah!
[09:09] <vladk> try 'git push origit' w/o branch name
[09:10] <rogpeppe> vladk: i think my "git branch foo" created a new branch but didn't switch to it
[09:11] <rogpeppe> vladk: hmm, but i still committed something, so i'd have expected that to push
[09:11] <rogpeppe> vladk: i'm worried that if i do that, then i'll push directly to the master
[09:14] <vladk> rogpeppe: it's quite easy to delete recent commits from github, so try, don't worry
[09:14] <rogpeppe> vladk: after reading the push docs, i *think* i see what's going on now
[09:15] <vladk> rogpeppe: you should 'git checkout' after 'git branch'
[09:15] <vladk> rogpeppe: of 'get checkout -b my-branch-name'
[09:16] <rogpeppe> vladk: yes, that's the conclusion i've come to
[09:16] <rogpeppe> vladk: and i should do git push origin :remote-branch-name
[09:16] <rogpeppe> vladk: (i think)
[09:16] <rogpeppe> vladk: i was missing the colon
[09:16] <rogpeppe> vladk: which meant that i was naming a local branch
[09:18] <vladk> rogpeppe: probably 'git push origin :remote-branch-name' push change in one specific branch, while 'git push origin' push commits for all branch, but I always used 'git push origin'
[09:21] <rogpeppe> vladk: i eventually succeeded with "git push --set-upstream origin rename-imports"
[09:35]  * fwereade said yesterday that he thought he'd escaped the flu... yeah, not so much
[09:35]  * fwereade will try to be around off and on but his brain isn't really working very well
[09:39] <TheMue> fwereade: today is the first day I get better after fighting for three days with the flu too
[09:41] <axw> fwereade: hey, I have availability sets working in my sandbox :)
[09:41] <fwereade> axw, awesome news!
[09:41] <axw> add-machine and placement both disabled
[09:41] <axw> with a mode to make it like the other providers
[09:42] <axw> just need to do the SSH tunnelling business
[09:42] <fwereade> axw, and auto-load-balancing for everything in azure mode, old-style one-service-per-machine in normal mode?
[09:42] <fwereade> axw, cool
[09:42] <axw> fwereade: yup
[09:43] <fwereade> axw, fantastic
[09:43] <fwereade> axw, how did the environ interfaces end up? because the fact that other providers don't zone-balance is now a bug, and we should get some time scheduled to bring them up to speed :)
[09:44] <axw> fwereade: I sent a couple of CLs to you to take a look at, to see if the implementation isn't horrible
[09:44] <axw> heh
[09:45] <axw> fwereade: so the way I've done it at the moment is I tell StartInstance what the principal units are - that's all Azure needs. For ec2/etc., we'll need an additional callback to get a mapping of units->instance.Id for the services of the principals
[09:46] <axw> then it can spread units by hand
[09:46] <fwereade> axw, I don't quite follow, but I'm not sure my input filters are functioning correctly -- I'll look at the CLs
[09:46] <axw> no worries, it can wait till you're feeling better anyway
[09:47] <axw> not going to land this until 1.18 is out
[10:10] <rogpeppe> large but totally trivial review anyone? https://codereview.appspot.com/75970043/
[10:10] <axw> looking
[10:13] <axw> rogpeppe: why the gocheck rev bump?
[10:13] <rogpeppe> axw: because i couldn't be bothered to make a new CL for it
[10:13] <axw> fair enough :)
[10:13] <axw> sorry didn't see the comment in the description
[10:13] <rogpeppe> axw: it fixes a bug in gocheck
[10:13] <axw> just making sure it was intentional
[10:13] <rogpeppe> axw: np
[10:15] <axw> rogpeppe: done
[10:15] <rogpeppe> axw: ta
[10:15] <axw> it would be nice if we could review gofix modules, rather than the output
[10:16]  * axw puts it on the end of a too long list of things to do one day
[10:19] <rogpeppe> axw: i didn't actually use a gofix module per se
[10:19] <rogpeppe> axw: i used two tools and did one manual change
[10:20] <rogpeppe> mgz_: does the bot automatically fetch dependencies now?
[10:20] <axw> rogpeppe: sure, but you get what I mean - review a small script (or two), rather than a load of files with the same change in each
[10:21] <rogpeppe> axw: yeah, i do get what you mean, but i'm not convinced that one would actually want to trust that the script works without actually looking at the changes it made
[10:22] <axw> yeah, some level of trust would be necessary
[10:22] <rogpeppe> axw: when reviewing a change that's made entirely automatically, i'll hope that the command used is in the CL description, and i'll look at a sample of the output and take the rest on trust
[10:23] <rogpeppe> axw: that's how i remember similar changes being reviewed in the go source
[10:23] <rogpeppe> axw: for example when we moved from os.Error to error
[10:23] <axw> yeah ok, same outcome and level of trust
[10:24] <axw> and no need for sandboxing and all that
[10:24] <rogpeppe> axw: i could have included the sam command that i used to make the edit, but noone apart from me understands structural regexps :-)
[10:25]  * axw is intrigued
[10:26] <axw> and yet, the dishes won't wash themselves
[10:27] <rogpeppe> axw: http://plan9.bell-labs.com/magic/man2html/1/sam
[10:27] <axw> thanks, I'll take a look a bit later
[10:27] <rogpeppe> axw: you need a dishwasher mate :-)
[10:27] <adeuring> could somebody please have a look here: https://codereview.appspot.com/75980043 ?
[10:27] <axw> yeah :(
[10:27] <axw> I was always told I am the dish washer
[10:27] <rogpeppe> adeuring: looking
[10:32] <voidspace> So I got Ubuntu installed on my machine last night. And now I have horrible, horrible problems on both machines. :-)
[10:32] <rogpeppe> adeuring: LGTM, but i'm surprised that the old code "escaped" a double-underscore to a single one.
[10:32] <voidspace> My Mac is dying in sympathy
[10:32] <voidspace> So trying to get *something working
[10:32] <rogpeppe> voidspace: good luck!
[10:32] <rogpeppe> adeuring: as it looks as if all underscores were deleted
[10:33] <rogpeppe> adeuring: which leaves me wondering if there's something we're missing here
[10:33] <adeuring> rogpeppe: I do not understand this as well... I'll ask thedac (who reported the bug) for more details.
[10:33] <adeuring> I tried to use the double underscores -- no luck at all
[10:34] <rogpeppe> adeuring: with the old version?
[10:34] <rogpeppe> adeuring: maybe that's just spurious
[10:34] <adeuring> rogpeppe: I tried on saucy with the recent source code, and on precise with the deb package from the stable PPA
[10:35] <rogpeppe> adeuring: and you didn't see the "escaping" behaviour?
[10:35] <adeuring> rogpeppe: no -- double underscores were stripped the same way a single underscores
[10:35] <rogpeppe> adeuring: right, that's what i'd expect
[10:37] <rogpeppe> adeuring: BTW we're just moving to using gopkg.in/v1/yaml, so you'll need to send a pull request there
[10:38] <adeuring> rogpeppe: ah, ok...
[10:39] <rogpeppe> adeuring: the actual repo is at github.com/go-yaml/yaml
[10:45] <axw> rogpeppe: when you have a moment please, https://codereview.appspot.com/75990043/
[10:46] <rogpeppe> axw: will do
[10:51] <natefinch> fwereade: standup
[10:55] <mgz_> dammit internet
[11:03] <mgz_> gah!
[11:17] <voidspace> rogpeppe: I'm going to try and get things working here and I'll ping you when I'm ready to do anything actually useful
[11:17] <voidspace> rogpeppe: if that's ok
[11:17] <wwitzel3> brb (hopefully), restart
[11:17] <rogpeppe> voidspace: sgtm
[11:18] <voidspace> rogpeppe: and if you could get the ratelimiter installed for the bot so I can land my branch that would be awesome
[11:18] <rogpeppe> voidspace: just doing that
[11:18] <voidspace> *great*
[11:27] <natefinch> wwitzel3: what hours do you normally work?  I tend to get little done between 7 & 9am because I have my younger daughter sleeping either in my arms or (if I'm lucky) next to me.
[11:28] <wwitzel3> natefinch: I usually try to get started at about 5:45 so I can go through email and bootstrap my memory of what I did yesterday before standup.
[11:29] <natefinch> wwitzel3: I usually do that 10 minutes before the standup ;)
[11:29] <wwitzel3> natefinch: and then I "stop" around 3 .. but all that means is I stop feeling bad about walking away .. I never actually get off my computer :P
[11:29] <natefinch> wwitzel3: haha
[11:29] <natefinch> that's cool
[11:30] <wwitzel3> natefinch: or it means I'm hear, but I'll just pretend like I don't see someone pinging me :D
[11:30] <wwitzel3> here
[11:31] <wwitzel3> mixed thoughts, was going to say pretend I don't hear them, then switched ping, and then grammatical error .. dumb
[11:31] <natefinch> wwitzel3: ok.  I'll try to free up by 9 this morning so we can pair.
[11:31] <natefinch> wwitzel3: haha I've done that
[11:32] <wwitzel3> natefinch: sure, I have plenty to keep me busy .. there are some code reviews I'm going to peak at and i have some HR stuff I've been neglecting
[11:33] <natefinch> wwitzel3: cool, if you ever find yourself with nothing to do, take a look at the bugs
[11:33] <wwitzel3> natefinch: also after your praise of how smooth your upgrade went, I'm running that process now too
[11:34] <natefinch> wwitzel3: good luck :)
[11:36] <voidspace> ooh, I might have unity back
[12:11] <rogpeppe> axw: reviewed
[12:14] <rogpeppe> mgz_: how do you get your juju client talking to the gobot juju server? presumably you use chinstrap somehow.
[12:14] <mgz_> rogpeppe: yeah, you just want some ssh config like
[12:15] <rogpeppe> mgz_: how does that help, given that juju doesn't use ssh to talk to the server?
[12:15] <mgz_> well, you probably know that bit
[12:15] <mgz_> then use sshuttle through either the bootstrap node or chinstrap
[12:16]  * rogpeppe reads sshuttle(8)
[12:16] <wwitzel3> natefinch: well, it seemed to go well (the upgrade)
[12:17] <natefinch> wwitzel3: sweet.   lots of good stuff in Trusty
[12:17] <mgz_> eg: `sshuttle -vr rogpeppe@chinstrap.canonical.com 10.55.61.0/16 >~/sshuttle.log 2>&1 &`
[12:17] <wwitzel3> natefinch: it also just seems a bit more performant .. and my fan isn't kicking on as much as I do things
[12:17] <rogpeppe> mgz_: thanks. i would have taken a while to come up with that
[12:18] <natefinch> wwitzel3: yeah, I'd heard some people had fan troubles in Saucy. I still get a fan going in hangouts sometimes, but I think that's just hangouts
[12:19] <rogpeppe> mgz_: ha, that doesn't work because it tries to run sudo
[12:20] <mgz_> wat
[12:20]  * rogpeppe doesn't background it
[12:20] <rogpeppe> mgz_: ah, i'm rog@chinstrap
[12:21] <mgz_> that'll be it
[12:21] <rogpeppe> mgz_: success, thanks
[12:26] <rogpeppe> mgz_: why does it do the bzr binds *after* running godeps -u ?
[12:26] <mgz_> sound't really matter?
[12:26] <mgz_> *shouldn't
[12:26] <mgz_> wait, ti does
[12:26] <rogpeppe> mgz_: don't the binds change the code?
[12:27] <mgz_> but that's the right way around
[12:27]  * rogpeppe never used bzr bind
[12:27] <mgz_> bind makes that branch a checkout of a remote branch
[12:27] <rogpeppe> mgz_: so it doesn't actually change any files in the branch?
[12:28] <mgz_> if you did that, then updated *that* bound branch, you'd change the rev the remote branch was on
[12:28] <mgz_> we don't actually do this
[12:28] <mgz_> because godeps doesn't change juju-core, which is what we bind
[12:28] <mgz_> but would be a bit of a bear trap
[12:29] <rogpeppe> mgz_: what are the binds doing?
[12:29] <mgz_> the bind is basically so the bot doesn't need to push after committing a successful merge, because that's what tarmac expects
[12:29] <mgz_> it means acttions on the local branch are reflected on the remote branch
[12:30] <rogpeppe> mgz_: i guess i don't understand why we want to perform actions on, goose, say
[12:30] <mgz_> the bot also controls goose landings
[12:30] <mgz_> but yes, this is now very dodgy
[12:30] <rogpeppe> mgz_: ah
[12:30] <mgz_> I'll need to split out goose to a seperate tree set
[12:30] <rogpeppe> and gwacl, presumably
[12:30] <mgz_> gwacl already is
[12:31] <rogpeppe> so no actual need to bind gwacl?
[12:31] <mgz_> no bind is fine, but it's a bind under ~tarmac/gwacl-trees
[12:31] <rogpeppe> ah, it's in a separate tree, yes
[12:31] <mgz_> which is not a shared location with out juju-core ~tarmac/trees location, unlike goos
[12:38] <sinzui> does anyone know the state of bug 1291400? Is there a branch in review?
[12:38] <_mup_> Bug #1291400: migrate 1.16 agent config to 1.18 properly (DataDir, Jobs, LogDir) <regression> <upgrade-juju> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1291400>
[12:40] <axw> rogpeppe: thanks, will pick it back up on monday
[12:48] <adeuring> rogpeppe: a github MP: https://github.com/go-yaml/yaml/pull/3
[12:50] <rogpeppe> adeuring: LGTM
[13:19] <sinzui> rogpeppe, mgz_ jam, natefinch  : I want to release 1.17.5. There are two bugs not fixed. Is it *bad* if we land those fixes for 1.18.0?
[13:19] <rogpeppe> sinzui: which are the bugs?
[13:19] <sinzui> rogpeppe, bug 1271144 and bug 1291400
[13:19] <_mup_> Bug #1271144: br0 not brought up by cloud-init script with MAAS provider <cloud-installer> <landscape> <local-provider> <lxc> <maas> <regression> <juju-core:In Progress by rogpeppe> <https://launchpad.net/bugs/1271144>
[13:19] <_mup_> Bug #1291400: migrate 1.16 agent config to 1.18 properly (DataDir, Jobs, LogDir) <regression> <upgrade-juju> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1291400>
[13:20] <rogpeppe> sinzui: i'm just about to land the fix to the first one
[13:20] <sinzui> I will wait for that, thanks rogpeppe
[13:21] <sinzui> I may need to beat the azure tests. the cloud has been misbehaving and failing the revision tests
[13:36] <adeuring> thedac: while i would cliam that i have a fix for bug 1243827, seen from the bugfix it absolutely unclear how using double underscores could avoid the bug. can you tell me which versions of juju-core and juju-deployer you are using?
[13:36] <_mup_> Bug #1243827: juju is stripping underscore from options <canonical-webops> <config> <goyaml:Fix Released by adeuring> <juju-core:Invalid by adeuring> <juju-deployer:Invalid by hazmat> <https://launchpad.net/bugs/1243827>
[13:43] <rogpeppe> mgz_: another thing i don't quite understand from that tarmac script: where is the actual branch to be tested downloaded?
[13:44] <rogpeppe> mgz_: does it happen before the config-changed-script is run?
[13:44] <mgz_> it's merged into the branch in trees
[13:45] <mgz_> it's independant, in a cron job that uses tarmac, and the tarmac config (seperate config item) manages
[13:47] <rogpeppe> mgz_: so we don't run godeps -u on every branch?
[13:47] <rogpeppe> mgz_: how are we supposed to add a new dependency then?
[13:47] <mgz_> no, because that's actually insufficient, we'd also need to go get
[13:47] <rogpeppe> mgz_: (given that go get launchpad.net/juju-core won't get the new dependency)
[13:47] <rogpeppe> mgz_: yeah
[13:48] <mgz_> rogpeppe: modify the config to pull that specific dep in advance, trigger the config-changed hook, then the next cron run will have what it needs
[13:48] <rogpeppe> mgz_: so add an explicit go get to the config?
[13:48] <mgz_> ie, add a `bzr branch lp:new-dep trees/launchpad.net/new-dep` line or similar
[13:48] <rogpeppe> mgz_: then remove it after the relevant branch has merged?
[13:49] <rogpeppe> mgz_: yeah, same difference
[13:49] <mgz_> yup
[13:49]  * rogpeppe tries not to be distracted by adding pull support to godeps
[13:52] <mgz_> sinzui: do you need any more help for the release?
[13:53] <mgz_> I think we'll have to kick dimiter's bug from 1.17.5 for now
[13:53] <sinzui> mgz_, I am fine. Azure is not, but since we know azure is not fine, I wont let that damn rogpeppe's branch when it lands
[13:54] <rogpeppe> sinzui: it's approved and should land in the next 16 years
[13:55] <rogpeppe> sinzui: ^h^h^h^h^h^hminutes
[13:55] <sinzui> fab. CI is idle and ready to take it
[13:55] <mgz_> rogpeppe: text conflict
[13:55] <rogpeppe> bollocks
[13:58] <rogpeppe> reapproved
[13:59] <natefinch> wwitzel3: sorry for the delay, you want to do some pairing?
[14:01]  * Makyo is back (gone 13:44:06)
[14:01] <natefinch> jb.go
[14:01] <natefinch> gah, stupid focus follows mouse
[14:08] <wwitzel3_> natefinch: hey
[14:17] <mattyw> not exactly a juju-core question - but is there a way to use the testing/mgo.go stuff to setup a mongo database with a password?
[14:17] <rogpeppe> mattyw: using juju-core/state?
[14:18] <rogpeppe> mattyw: or independent of juju?
[14:18] <mattyw> rogpeppe, totally independant of juju
[14:19] <rogpeppe> mattyw: have a look at SetAdminMongoPassword in the state package
[14:21] <rogpeppe> i just grabbed github.com/go-juju BTW, as a placeholder in case we decide to use gopkg.in at some point in the future
[14:29] <rogpeppe> sinzui: that branch has merged
[14:30] <sinzui> rogpeppe, CI has already built it, is running unit tests and publishing the test tools for the next round of tests. I think I am 1h from starting the release
[14:30] <rogpeppe> sinzui: brilliant
[14:44] <natefinch> rogpeppe, mgz_: any ideas as to why juju would keep telling me it's already bootstrapped amazon when there's definitely no jenv around?
[14:44] <rogpeppe> natefinch: what's the output of bootstrap --debug ?
[14:44] <natefinch> 2014-03-14 14:40:52 DEBUG juju.environs.configstore disk.go:64 Making /home/nate/.juju/environments
[14:44] <natefinch> 2014-03-14 14:40:52 INFO juju.provider.ec2 ec2.go:207 opening environment "amazon"
[14:44] <natefinch> 2014-03-14 14:40:53 ERROR juju.cmd supercommand.go:296 environment is already bootstrapped
[14:45] <natefinch> not terribly useful
[14:45] <rogpeppe> natefinch: what does your amazon environment entry look like in environments.yaml
[14:45] <rogpeppe> ?
[14:46] <natefinch>   amazon:
[14:46] <natefinch>     type: ec2
[14:46] <natefinch>     admin-secret: 36c59e8a199197b4b3c0950ab844dec4
[14:46] <natefinch>     # globally unique S3 bucket name
[14:46] <natefinch>     control-bucket: juju-c2feecf0b1cd9ef0d4ea241dd90e10c3
[14:46] <natefinch>     # override if your workstation is running a different series to which you are deploying
[14:46] <natefinch>     # default-series: precise
[14:46] <natefinch>     bootstrap-timeout: 3600
[14:46] <natefinch>     # region defaults to us-east-1, override if required
[14:46] <natefinch>     # region: us-east-1
[14:46] <natefinch>     # Usually set via the env variable AWS_ACCESS_KEY_ID, but can be specified here
[14:46] <natefinch>     # access-key: <secret>
[14:46] <natefinch>     # Usually set via the env variable AWS_SECRET_ACCESS_KEY, but can be specified here
[14:46] <natefinch>     # secret-key: <secret>
[14:46] <rogpeppe> natefinch: i bet it works if you delete the control-bucket entry
[14:46] <natefinch> hmm
[14:46] <rogpeppe> natefinch: are you sure you have no currently running instances?
[14:47] <rogpeppe> natefinch: you can delete admin-secret too
[14:47] <natefinch> rogpeppe: I did manually kill a bootstrap node last night
[14:47] <rogpeppe> natefinch: well, that'll be the reason
[14:47] <rogpeppe> natefinch: there's more to an environment than just the jenv file
[14:47] <natefinch> destroy-environment --force should put us back in a reasonable position, though, and it doesn't
[14:48] <rogpeppe> natefinch: i don't think so
[14:48] <rogpeppe> natefinch: in your particular case, perhaps
[14:48] <rogpeppe> natefinch: but in general we don't know where the environment is if you've deleted the .jenv file
[14:48] <natefinch> there should never be a time when, after doing destroy-environment --force that juju bootstrap tells me it's still bootstrapped
[14:49] <natefinch> that's what --force is for
[14:49] <natefinch> it's the "just fucking do it" flag
[14:49] <natefinch> anyway....
[14:51] <rogpeppe> natefinch: it's awkward, because in this case only you'd need to ignore the .jenv file and use info from environments.yaml
[14:51] <thedac> adeuring: wrt bug#1243827 we were using juju core 1.14.x and juju-deployer 0.2.3+bzr115-0~26~precise1ubuntu1~0 at the time. AFAIK, the problem still remains with 1.16.x and 0.3.0-0ubuntu2. I'll see if I can test that theory today. But the bug has the exact example of the failure.
[14:51] <_mup_> Bug #1243827: juju is stripping underscore from options <canonical-webops> <config> <goyaml:Fix Released by adeuring> <juju-core:Invalid by adeuring> <juju-deployer:Invalid by hazmat> <https://launchpad.net/bugs/1243827>
[14:51] <rogpeppe> natefinch: well, i suppose if the .jenv file doesn't exist, we should perhaps create a new Environ and then destroy it
[14:51] <natefinch> rogpeppe: there's no jenv, that's the thing.  Maybe it's just a matter of the fact that the environments.yaml is an anti-feature
[14:51] <rogpeppe> natefinch: there *was* a jenv
[14:52] <natefinch> rogpeppe: yeah
[14:52] <rogpeppe> natefinch: until you deleted it (probably manually, or perhaps with destroy-environment --force)
[14:52] <rogpeppe> natefinch: i think it's that control-bucket is an anti-feature
[14:53] <natefinch> rogpeppe: could be yeah
[14:53] <rogpeppe> natefinch: without that, you'll get a new env each time
[14:53] <rogpeppe> natefinch: you can still leak environments though (and you probably would have in this case)
[14:53] <adeuring> thedac: thanks for the version info. and right, the problem still exists in recent versions -- but I did not test juju 1.14.
[14:54] <natefinch> rogpeppe: ahh, yeah, good point.
[14:55] <natefinch> rogpeppe: taking out the control bucket worked
[14:55] <natefinch> rogpeppe: I'll probably have to go clean up the original bucket
[15:30] <sinzui> juju devs, r2422 is blessed. I will release it as 1.17.5
[15:48] <rogpeppe> small review anyone? https://codereview.appspot.com/76120043/
[15:48] <rogpeppe> natefinch: ^
[15:49] <natefinch> rogpeppe: pairing with wayne right now, may get to it in a little bit once we figure out what's wrong with my code
[15:49] <rogpeppe> natefinch: ok
[15:59] <lazyPower> anyone have a moment to help a user that's having issues getting the cloudimg deployed with juju? I'm baffled as to why juju isn't fetching and deploying the cloudimg tarball for him.
[15:59] <lazyPower> this is extending past my knowledge of how juju-core works
[16:05] <sinzui> jamespage, 1.17.5 tarball is released. I am going to make the source packages for the ppas now. While you could make the packages with the current SPB, I changed the testing branch to install the bash completions file in the juju tree. https://launchpad.net/juju-core/+milestone/1.17.5
[16:06] <jamespage> * Juju support for juju-mongodb is temporally removed. The feature
[16:06] <jamespage>   will be restored when it is more complete.
[16:06] <sinzui> jamespage, ~juju-packaging/+archive/devel has the source package now
[16:06]  * jamespage crys a bit
[16:06] <sinzui> jamespage, yeah. I hoped it would be put back before today
[16:07]  * bodie_ offers jamespage a slightly disheveled hankie
[16:07] <natefinch> rogpeppe, mgz_: any idea why mongo would be running, but jujud wouldn't be able to connect to it?  I can connect to it using the mongo command line, but jujud just says connection refused
[16:08] <rogpeppe> natefinch: what does (ps alxw | grep mongo) tell you?
[16:09] <rogpeppe> natefinch: is this in a testing context?
[16:09] <bodie_> I'm having a hard time understanding some of the "tribal knowledge" around how to actually run and test things
[16:09] <natefinch> rogpeppe: unfortunately the instance got killed, even with a ridiculously long timeout in my environments.yaml
[16:09] <bodie_> is there an ideal dev workflow here?
[16:09] <bodie_> like, my tests were breaking yesterday and I had no idea why -- I assume juju is running without full green lights?
[16:09] <rogpeppe> natefinch: i need more context
[16:09] <bodie_> I was going on the assumption that I'd get greens, make changes, see what breaks, fix it, etc
[16:10] <rogpeppe> lazyPower: i don't think i understand your question
[16:10] <natefinch> rogpeppe: ok, I'll retry it after lunch
[16:10] <rogpeppe> lazyPower: what's "cloudimg" ?
[16:10] <natefinch> bodie_: all the tests should pass... there are a few  that are flaky
[16:11] <lazyPower> rogpeppe: there's a user outside the us (not sure if this is a cause) - that wasn't able to bootstrap a local environment. The cloudimg tarball was failing to download. He managed to fetch the tarball manually but i didn't know where to tell him to put it
[16:11] <lazyPower> marcoceppi joined in and clued us in that it lives in /var/cache
[16:12] <rogpeppe> lazyPower: ah, local environment - i'm afraid i've never looked into it in that much detail so i won't be much help, sorry
[16:12] <jcw4> natefinch do folks usuall run go test juju-core/... ?
[16:12] <natefinch> rogpeppe: it looks like the bootstrap-timeout in environments.yaml isn't actually working... at least, my instances are still getting killed way before the timeout I set there
[16:12] <natefinch> jcw4: yep.   And in fact, code can't land unless that passes
[16:13] <jcw4> natefinch interesting so if they fail locally somethings wrong on *our* environment?
[16:13] <natefinch> jcw4: however, those tests take a long time, so generally you want to run a subset during iterative development, and only run the full thing when you're pretty sure your code is right
[16:13] <jcw4> natefinch I'll grep the docs, but is there a CI link for juju-core?
[16:14] <natefinch> jcw4: there are tests under juju-core/replicaset that are unfortunately flaky, if it's those that are failing, it's not just you... it's an ongoing problem
[16:14] <jcw4> also providers/azure
[16:14] <jcw4> well actually compile failures there
[16:16] <natefinch> jcw4: make sure you update your dependencies, they may have changed (like the azure provider, I think some changes landed recently to that)
[16:16] <jcw4> natefinch will do, thx
[16:17] <natefinch> jcw4: if you do go get launchpad.net/godeps  you'll have a godeps executable, that you can then use from the root juju-core folder  doing godeps -u dependencies.tsv and it'll tell you if anything is out of date
[16:17] <natefinch> jcw4: you'll have to update the out of date stuff manually, but at least you'll know what needs doing
[16:17] <jcw4> natefinch excellent much better than manually finding outdated stuff
[16:34] <bodie_> ok, I'm getting a bunch of test fails with a freshly checked out copy of everything
[16:34] <bodie_> not too sure what's up
[16:34] <bodie_> is that normal?
[16:35] <bodie_> running go test ./... in $GOPATH/src/juju-core
[17:11] <natefinch> bodie_: can you paste the test output to pastebin.ubuntu.com - that would help figure things out
[17:12] <bodie_> sure
[17:14] <bodie_> it's pretty huge though
[17:14] <bodie_> I think the initial database connection is failing, so pretty much everything else barfs too
[17:15] <bodie_> but I recompiled Mongo with SSL enabled and all that, and it works fine
[17:19] <natefinch> bodie_: yeah, I know the test output is huge...  it's something I've wanted to be able to turn on and off for a while, it just hasn't been at the top of the priority list.
[17:20] <bodie_> lol, from man watch
[17:21] <bodie_> "you can watch for your administrator to install the latest kernel with watch uname -r (just kidding)"
[17:21] <bodie_> oh, the "just kidding" isn't in my version of the manpage
[17:28] <rogpeppe> natefinch: that branch i pointed you towards earlier makes it easier to make test output more or less verbose
[17:28] <natefinch> rogpeppe: hey, that's cool.
[17:28] <rogpeppe> natefinch: i'm still swithering about whether it's better as an environment variable or as a flag
[17:29] <natefinch> rogpeppe: yeah, that's tricky. both would be nice, so you could set it in the environment the way you like the default, and then override with the flag as necessary
[17:30] <rogpeppe> natefinch: i'm not a big fan of both. i prefer one way for most things.
[17:31] <rogpeppe> natefinch: i went with the flag because i think that people might be able to break tests that test log output by setting the level to ERROR
[17:31] <natefinch> rogpeppe: if I had to pick one or the other, I guess the environment variable, since then it's sticky, and I'm guessing there are people who are going to want the default to be one thing or the other
[17:31] <natefinch> rogpeppe: I think tests that depend on the log output are broken to begin with
[17:31] <rogpeppe> natefinch: that's not necessarily true
[17:31] <rogpeppe> natefinch: some tests are specifically testing that something is logged
[17:32] <natefinch> rogpeppe: I suppose that's valid, though I'd prefer if they were able to hook into the logging system to see that something would have been logged rather than checking the output to see what is actually output
[17:33] <rogpeppe> natefinch: they are generally doing that
[17:33] <rogpeppe> natefinch: but the logging system is influenced by the global logging config
[17:33] <rogpeppe> natefinch: such tests should probably reconfigure the logging system as desired
[17:34] <rogpeppe> natefinch: but i didn't want to go through making that change everywhere
[17:34] <natefinch> rogpeppe: yeah, that was my thought, though then that kind of defeats the purpose of being able to adjust how much is logged
[17:34] <rogpeppe> natefinch: only for those (very few) tests.
[17:34] <bodie_> natefinch, here's my test output...
[17:34] <bodie_> http://paste.ubuntu.com/7091353/
[17:35] <bodie_> but, I totally built mongo with SSL
[17:35] <natefinch> rogpeppe: ideally there would be two different loggers, one that respects the log level and does the real logging, and one that ignores it that is used for tests.  But I don't know anything about how loggo works to know if that's feasible
[17:35] <rogpeppe> natefinch: there are many different log levels
[17:35] <rogpeppe> natefinch: it's hierarchical actually
[17:36] <bodie_> oh, now it's over 1300 lines
[17:36] <bodie_> ok.
[17:37] <rogpeppe> bodie_: that's small :-)
[17:37] <rogpeppe> bodie_: i had a 500k line output from a test yesterday
[17:37] <bodie_> lol
[17:37] <bodie_> that's silly
[17:37] <bodie_> ain't nobody got time fo dat
[17:37] <natefinch> bodie_: that's definitely mongo not having ssl, still: mongod: Error parsing command line: unknown option sslOnNormalPorts
[17:37] <rogpeppe> bodie_: darn straight
[17:37] <natefinch> bodie_: as for azure....  what branch are you building?
[17:37] <bodie_> seriously, though.  there really ought to be a fakey backend or something
[17:38] <rogpeppe> bodie_: yeah.
[17:38] <rogpeppe> bodie_: choosing the right level for it is the difficult thing
[17:38] <bodie_> right...
[17:38] <rogpeppe> bodie_: i've wondered about faking up an in-memory mongo
[17:38] <bodie_> env variable to define backend testing level?
[17:39] <bodie_> FAKE_BACKEND=true?
[17:39] <rogpeppe> bodie_: yeah, but someone's got to implement it
[17:39] <bodie_> right, heh
[17:39] <natefinch> rogpeppe: my point is not about having levels or not, my point is about having different log targets.  So you can log like debug+ to the debug log over there and log info+ to stdout and have a testing output that always logs everything.
[17:39] <rogpeppe> natefinch: you can do that too
[17:40] <bodie_> this is just the freshly checked out trunk
[17:40] <rogpeppe> natefinch: except that the global config chokes log messages at source
[17:40] <natefinch> rogpeppe: well, see, that's the problem :)
[17:40] <rogpeppe> natefinch: honestly, it's not actually a problem
[17:41] <bodie_> grrhh...  I wiped out the old mongo installation though
[17:41] <bodie_> I double-checked just now that mongo and mongod are the copies I built yesterday
[17:41] <natefinch> bodie_: if you do mongod --help do you see a section of flags labelled SSL?
[17:42] <bodie_> ugh
[17:42] <bodie_> no
[17:42] <natefinch> bodie_: there's your problem
[17:43] <natefinch> brb
[17:43] <bodie_> oh I know why
[17:49] <rogpeppe> natefinch, mgz_: still looking for a review of https://codereview.appspot.com/76120043 if poss
[17:51] <natefinch> rogpeppe: looking
[17:52] <natefinch> wwitzel3: you around?
[18:00] <natefinch> rogpeppe: lgtm'd
[18:00] <bodie_> alright
[18:00] <rogpeppe> natefinch: ta
[18:00] <bodie_> successfully built mongo with ssl
[18:00] <bodie_> the instructions are screwy
[18:01] <natefinch> bodie_: I told you
[18:01] <natefinch> bodie_:  I have a write up somewhere with actually good instructions, but I can't figure out where they went.
[18:01] <bodie_> when you do scons install, you have to use the --ssl flag both times
[18:01] <bodie_> simple
[18:02] <bodie_> i assumed it was something like ... build locally into a ./build folder with SSL...
[18:02] <bodie_> then scons install uses that
[18:02] <bodie_> BUT NO
[18:03] <natefinch> yeah
[18:06] <sinzui> natefinch, do you have a few minutes to review the branch that updates trunk to 1.17.6?   test-release-hp:
[18:06] <sinzui>     # juju --show-log bootstrap -e test-release-hp
[18:06] <sinzui>     type: openstack
[18:06] <sinzui>     test-mode: true
[18:06] <sinzui>     use-floating-ip: false
[18:06] <sinzui>     admin-secret: 1717-burgers-hotdogs-potato-salad-baked-beans
[18:06] <sinzui>     control-bucket: juju-pavlova-snags--chiko-roll-meat-pie-pasty-sauce-2013-10-10
[18:06] <sinzui>     default-series: precise
[18:06] <sinzui>     auth-url: https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/
[18:06] <sinzui>     authorized-keys: |
[18:06] <sinzui>       ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDyEdd8eDyy2WA6Q+W4GV2NqKX+yfkkW5ogSu3/7DjlqjED7dCNkevq2qpdR1AMkbKTouihWdyc8QKl9lzuwn0zoocXJUVgIOPV+KFxSAhj1djGvryHDjYUwdrLYUMu3CUFeIsRao2cn7EgZs0w1Y1quqr9c8cEg7XsAs0ZMN9YksEjG000VupOIZJNtk+5EYJm/6vNFI83IOn7ctWfjXymBuh7XM8d8vszyYDRdeDXY5Q9VLqHOP7/CFteIvcdHnSC1ObQuKzXRWz+m9thgQnRQjvirdwvDUXhjjQk9MNJZj84EukB8HyAVSN863MfuVGoCsNn7iEdtT6W2nKTWyL3 abentley@speedy
[18:06] <sinzui>     tools-url: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910/juju-dist/testing/tools
[18:06] <sinzui>     auth-mode: userpass
[18:06] <sinzui>     username: "sinzui"
[18:06] <sinzui>     password: "MyPineappleCalls4uInTheNight"
[18:06] <sinzui>     tenant-name: "juju-scale-test"
[18:06] <sinzui>     region: az-3.region-a.geo-1
[18:06] <sinzui> well not
[18:06] <sinzui> not that crack
[18:06] <sinzui> natefinch, https://codereview.appspot.com/76170043
[18:07] <natefinch> sinzui: you have the best passwords and secrets I've ever seen :)
[18:07] <sinzui> natefinch, yeah :( I am pretty said to see that go
[18:08] <natefinch> sinzui: lgtm.... wish we could do the versions some other way than changing sourcecode, though
[18:16] <mramm> sinzui: our upgrade compatability policy includes 1.18 clients tested against a 1.16 server right?
[18:17] <sinzui> Yes mramm
[18:17] <mramm> ok
[18:17] <mramm> thought so, thanks sinzui
[18:20] <bodie_> ... Panic: not authorized on admin to execute command { listDatabases: 1 } (PC=0x414386)
[18:20] <bodie_> that doesn't seem right
[18:20] <bodie_> unless tests aren't running as my user?
[18:20] <natefinch> bodie_: I haven't seen that one
[18:21] <natefinch> bodie_: they run as you
[18:21] <bodie_> http://paste.ubuntu.com/7091566/
[18:22] <bodie_> O_o
[18:22] <natefinch> bodie_: the azure stuff has to be launchpad.net/gwacl being out of sync somehow
[18:23] <natefinch> bodie_: not sure about the mongo problem....
[18:24] <bodie_> http://paste.ubuntu.com/7091591/
[18:24] <bodie_> :S
[18:24] <rogpeppe> oh bugger, looks like the last time i claimed aws expenses was exactly a year ago
[18:24] <bodie_> I thought we confirmed the azure provider wasn't working right now
[18:24] <natefinch> rogpeppe: haha
[18:24] <rogpeppe> well, i can only try
[18:33] <bodie_> so uh... the azure provider is working for other people?
[18:33] <bodie_> like, if you go test, you don't get the error with azure?
[18:34] <natefinch> bodie_: lemme try
[18:34] <bodie_> it's right at the top, if you do get it
[18:38] <natefinch> bodie_: totally broken, you're right
[18:39] <bodie_> ah
[18:39] <bodie_> ok
[18:39] <bodie_> so just disregard or how do I pass tests in order to submit revisions?
[18:40] <natefinch> bodie_: you won't be able to get code landed with those tests broken like that....  O
[18:40] <natefinch> bodie_: I'll see if I can fix it
[18:41] <bodie_> nice!  can I help anyhow?
[18:41] <bodie_> I'm looking for a place to start digging
[18:41] <natefinch> bodie_: I'm sure it's just a matter of gwacl getting changed without juju getting corresponding changes in the tests
[18:44] <rogpeppe> total $1759.26
[18:44] <natefinch> bodie_: it's a problem with dependencies outside juju-core... I'm sure the gwacl tests pass just fine, it's just that gwacl can't know you also need to fix juju-core (and there's still a chicken and egg problem where you have to check one in first, and that breaks either itself or the other one)
[18:45] <natefinch> rogpeppe: for 12 months that's not terrible.  Seems a bit high, though.  Did you have some unusually big months for some reason?  mine are usually $30-50 a month
[18:45] <rogpeppe> natefinch: biggest was $323.39
[18:46] <natefinch> rogpeppe: that's pretty big
[18:46] <rogpeppe> natefinch: i was probably doing a lot of live tests then
[18:47] <natefinch> rogpeppe: btw, looks like the azure tests are broken... probably gwacl changes landing without corresponding juju-core tests.  Is that something the guys down under are working on?
[18:48] <bodie_> natefinch, I really appreciate all the assistance getting up to speed here.  it's pretty daunting
[18:48] <natefinch> bodie_: it really is pretty daunting.  We should write up a getting started document. It was hard for me getting up to speed too (I started ~9 months ago)
[19:02] <natefinch> bodie_: yeah, looks like the signature of one of the functions in gwacl changed a couple days ago, and no one noticed it broke the juju-core tests
[19:14] <bodie_> ah, good stuff
[19:14] <bodie_> I feel useful.. sorta
[19:17] <bodie_> is there a specific version of mongo we should be using?
[19:17] <bodie_> I just built the latest master, which I think is 2.4
[19:17] <bodie_> I'm getting an error "not authorized for upsert" which apparently others are also seeing
[19:18] <bodie_> if anyone is running 2.4 and not seeing that error, would like to know :)
[19:21] <natefinch> bodie_: I'm running 2.4 and not getting that error... I believe we support 2.2 and above.
[19:23] <bodie_> oh, i'm on 2.7-pre
[19:23] <bodie_> O_o
[19:24] <bodie_> I thought I was on the stable...
[19:24] <rogpeppe> i am done for the day
[19:25] <rogpeppe> well past it actually
[19:25] <wwitzel3> rogpeppe: have a good weekend :)
[19:25] <rogpeppe> wwitzel3: and you!
[19:38] <bodie_> fyi: https://svn.boost.org/trac/boost/ticket/7242
[19:39] <bodie_> ugh, maybe this isn't what I need after all
[20:34] <bodie_> Panic: not authorized on admin to execute command { listDatabases: 1 } (PC=0x414386)
[20:34] <bodie_> any thoughts?
[20:34] <bodie_> using Trusty packaged mongo
[20:34] <bodie_> this from the test suits
[20:34] <bodie_> suite*
[20:36] <natefinch> bodie_: the trusty packaged mongo may not have SSL either.  I haven't seen that particular error before, unfortunately
[20:36] <natefinch> unfortunately, it's end of day for me here
[20:38] <bodie_> alrighty :)
[20:38] <bodie_> gustavo said it has ssl and i'm no longer getting the SSL related error... not sure what this one's about, though
[20:38] <natefinch> good luck, and if you don't figure it out, there's always \Mmonday :)
[20:39] <bodie_> farewell and have an excellent weekend
[20:39] <natefinch> you too
[20:39] <niemeyer> bodie_: This looks like plain lack of login
[20:39] <niemeyer> bodie_: and this is not about SSL
[20:40] <niemeyer> bodie_: Or at least not in an obvious way
[20:40] <niemeyer> bodie_: It wouldn't get to the point of issuing a listDatabase command and getting "auth denied" if the SSL communication was corrupted
[20:41] <niemeyer> bodie_: Are you able to run the test in isolation?:
[20:42] <bodie_> negative
[20:42] <bodie_> PANIC: mgo_test.go:42: mgoSuite.TearDownTest
[20:43] <bodie_>   in resetAdminPasswordAndFetchDBNames
[20:43] <bodie_> hm, that didn't paste properly
[20:43] <bodie_> home/bodie/go/src/launchpad.net/juju-core/testing/mgo.go:366
[20:43] <bodie_>   in resetAdminPasswordAndFetchDBNames
[20:43] <bodie_> obviously /home
[20:44] <bodie_> http://paste.ubuntu.com/7092264/
[20:45] <bodie_> I feel like this one should be obvious
[20:45] <bodie_> but I'm not quite seeing it
[21:07] <niemeyer> bodie_: Hmm
[21:07] <niemeyer> bodie_: I'd check how isUnauthorized is implemented
[21:07] <niemeyer> bodie_: The error apparently *is* a lack of authorization one
[21:08] <niemeyer> bodie_: It may be doing a string check against the error, and that string may have changed across MongoDB releases
[21:16] <bodie_> okie doke
[21:16] <bodie_> howdy thumper
[21:17] <thumper> o/
[21:17] <thumper> just passing through
[23:36] <hazmat> thumper, do we have no-proxy support in our proxy bits?
[23:38] <hazmat> oh.. that passthrough was a while ago