[00:30] <thumper> wallyworld: ta
[00:30] <wallyworld> np
[00:31] <wallyworld> thumper: one other thing i was going to do but too late probably
[00:32] <thumper> yeah?
[00:32] <wallyworld> the fmt.Sprintf() thing could be wrapped around the entire arg string
[00:32] <wallyworld> not just the one param
[00:32] <wallyworld> saves string concat etc
[00:32] <wallyworld> a bit neater maybe
[00:32] <thumper> not easily...
[00:32] <thumper> and I'm not sure it'd end up being neater
[00:32] <thumper> but not a big deal
[00:32] <wallyworld> or even just the chubks
[00:32] <wallyworld> chunks
[00:33] <wallyworld> yeah, not a big deal
[00:33] <thumper> hazinhell: still in hell?
[00:33] <thumper> hazinhell: keen to come to Dunedin?
[00:33] <hazinhell> thumper, yes and hell yes ;-)
[00:33]  * thumper nods
[00:33] <hazinhell> thumper, i've got some family thing i'm trying to work out that's got some minor overlap, but shouldn't be an issue
[00:33] <thumper> ok
[00:41] <davecheney> sinzui still around ?
[01:09] <axw> thumper: https://bugs.launchpad.net/juju-core/+bug/1258132
[01:09] <_mup_> Bug #1258132: [manual] bootstrap fails due to juju-db not starting <juju-core:Triaged> <https://launchpad.net/bugs/1258132>
[01:10] <axw> did you know about the reload-config option? consider it for local provider?
[01:10] <thumper> axw: yeah...
[01:10] <thumper> no, what is it?
[01:10] <axw> tells upstart to reload config from /etc/init
[01:11] <axw> I'm not sure if that's actually solving it, or just ading enough of a delay
[01:11] <axw> i.e. is it synchronous, or is it just scheduling another update that'll race
[01:11] <axw> anyway, was just wondering if you knew
[01:15] <thumper> axw: well, there is some race there that I've not solved yet
[01:15] <thumper> would be great if this did solve it
[01:16] <thumper> abently has a machine that fails about 50% of the tiem
[01:16] <thumper> so we could always use him as a tester :)
[01:16]  * thumper fixes another test isolation failure
[01:17] <thumper> GAH, WTF
[01:18] <thumper> hitting so many weird test failures
[01:18] <thumper> intermittent ones
[01:18] <thumper> this one in manual provider
[01:18] <thumper> environ_test.go:121:
[01:18] <thumper>     c.Assert(err, gc.ErrorMatches, "exit code 99")
[01:18] <thumper> ... error string = "failed to write input: write |1: broken pipe (output: \"JUJU-RC: 99\")"
[01:18] <thumper> ... regex string = "exit code 99"
[01:18] <thumper> huh?
[01:19] <thumper> and getting the provisioner not always making machines
[01:19] <thumper> two different tests failed due to that
[01:19] <thumper> in different places
[01:19] <axw> what the
[01:20] <axw> thumper: I'm changing some code in that vicinity, will look into it later today
[01:21] <thumper> kk
[01:22] <axw> thumper: my hypothesis is that upstart is seeing the file half-way through writing it (in place)
[01:22] <axw> gonna see if I can force reproduce it
[01:23] <thumper> axw: sounds possible
[01:23] <axw> in that case a touch would be sufficient
[01:23] <axw> reload-configuration would reload everything
[01:29] <davecheney> ummm
[01:29] <davecheney> % juju deploy cs:precise/haproxy-67
[01:29] <davecheney> ERROR cannot get charm: charm not found: cs:precise/haproxy-67
[01:30] <davecheney> ^ what has happened here
[01:30] <davecheney> this revision absolutely does exist
[01:30] <thumper> your syntax is wrong
[01:30] <thumper> surely
[01:30] <thumper> haproxy-67 isn't the name of a charm
[01:31] <davecheney> In all cases, a versioned charm URL will be expanded as expected (for example,
[01:31] <davecheney> mysql-33 becomes cs:precise/mysql-33).
[01:31] <davecheney> do I need to leave off the cs:precise ?
[01:31] <davecheney> % juju deploy haproxy-67
[01:31] <davecheney> ERROR cannot get charm: charm not found: cs:precise/haproxy-67
[01:32] <davecheney> thumper: this is sort os serious
[01:33] <davecheney> cts have hit a bug and need to use an older revision of the charm
[01:34]  * thumper looks
[01:35] <davecheney> oh god
[01:35] <davecheney> this is this fucking revno SHIT
[01:35] <davecheney> thumper: sorry
[01:36] <davecheney> its not a juju problem
[01:36] <davecheney> the charm revision is unrelated to the bzr revision
[01:41] <wallyworld> thumper: got time for a quick hangout?
[01:41] <thumper> wallyworld: ah... yeah
[01:41] <thumper> was just writing an email
[01:41] <wallyworld> ok, ping me when done
[01:41] <thumper> how short?
[01:41] <wallyworld> i can wait
[01:41] <thumper> school run is in 20 min
[01:42] <thumper> can you wait 30 minutes?
[01:42] <wallyworld> ok
[01:42] <thumper> ok
[01:42] <thumper> thanks
[02:00] <wallyworld> fwereade_: wtf are you doing awake?
[02:11] <thumper> wallyworld: https://plus.google.com/hangouts/_/7acpilj94h6vnkfr0qilf02c5k?hl=en
[02:12] <axw> davecheney: isn't the bootstrap error message logged higher up?
[02:26] <davecheney> axw: in a word, no
[02:26] <davecheney> or at least not without -v
[02:26] <davecheney> axw: https://bugs.launchpad.net/juju-core/+bug/1258246
[02:26] <_mup_> Bug #1258246: azure: juju bootstrap aborted for no apparent reason <azure-provider> <bootstrap> <ci> <intermittent-failure> <openstack-provider> <juju-core:In Progress by dave-cheney> <https://launchpad.net/bugs/1258246>
[02:29] <axw> davecheney: and with the additional log, don't you just see another "exit status 1" log message?
[02:29] <davecheney> axw: dunno
[02:29] <davecheney> i don't ahve control over that environemnt
[02:30] <axw> davecheney: I think the problem is that the error message we're showing isn't useful, not that it's not there
[02:30] <axw> but I may be mistaken
[02:30] <axw> ERROR exit status 1
[02:30] <axw> I think is from the ssh process
[02:30] <davecheney> i thnk that is coming from the jenkins builder
[02:30] <davecheney> axw: i'm suspecting the underlying cause is a timeout
[02:37] <wallyworld> bigjools: we need your advice. https://plus.google.com/hangouts/_/7acpilj94h6vnkfr0qilf02c5k?hl=en
[02:37] <wallyworld> btw it's work naked day today
[02:38] <thumper> citation needed
[02:38] <wallyworld> http://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC8QqQIwAA&url=http%3A%2F%2Fwww.news.com.au%2Fbusiness%2Fworklife%2Ffriday-6-december-is-work-in-the-nude-day%2Fstory-e6frfm9r-1226776444086&ei=rDihUuPvMoXskgWp44GQAQ&usg=AFQjCNExndNUWYGv4BBhrcIseRATwSXiJg&bvm=bv.57155469,d.dGI
[02:39] <wallyworld> bah. google sucks http://www.news.com.au/business/worklife/friday-6-december-is-work-in-the-nude-day/story-e6frfm9r-1226776444086
[02:44] <thumper> wallyworld: I'll just go make a coffee to sup while doing your reviews
[02:44] <thumper> axw: do you have any you'd like me to look at too?
[02:44] <wallyworld> ok
[02:44] <axw> thumper: ummm no not right now
[02:44] <axw> thanks
[02:44] <axw> I may do later on
[02:46] <axw> thumper: I'm going to look at fixing https://bugs.launchpad.net/juju-core/+bug/1167616 -- keeps tripping me up in tests
[02:46] <_mup_> Bug #1167616: state.SetEnvironConfig should take old and new config values <config> <state> <juju-core:Triaged> <https://launchpad.net/bugs/1167616>
[02:49] <axw> actually, I'm not even sure what's right there. hrm
[03:23] <wallyworld> thumper: the code doesn't allow 2 keys with the same comment to be added. but i guess they could be added manually. there's no go code for fingerprint that i know of so may have to shell out to get it
[03:24] <thumper> hmm...
[03:24] <thumper> Perhaps we just document the limitation
[03:25] <thumper> for now
[03:25] <wallyworld> i did think about using fingerprint
[03:25] <wallyworld> i'll have another look at the ssh package to see if there's anthing i missed
[03:26] <thumper> kk
[04:41] <jam> hatch: there is a 2.4.6 in the cloud-archive:tools archive (vs the stable ppa)
[04:41] <hatch> jam goodmorning :)
[04:41] <hatch> it's all working now
[04:42] <jam> hatch: so from the traceback, you had a mongod that was serving your .juju/local/db directory
[04:42] <jam> which because of how it got shutdown
[04:42] <jam> wasn't getting stopped by "juju destroy-environment"
[04:42] <jam> "some other thing was"
[04:42] <jam> and then every time you bootstrapped
[04:42] <jam> we would try to start a new one
[04:43] <jam> which was probably failing, but we didn't notice because hey, there is something listening on 37017 for us
[04:43] <jam> hatch: *probably* if you had killed the mongod it would have cleaned things up, too.
[04:43] <jam> as there *shouldn't* be a mongod running if nothing is bootstrapped
[04:43] <jam> hatch: anyway, I'm glad you got it working.
[04:43] <hatch> ahhh - so is this something that we could 'fix' - maybe simply by creating a better error message?
[09:02] <axw_> rogpeppe2: thanks for the review. just replied to your comment; would appreciate another look before I land
[09:02] <rogpeppe2> axw_: ok
[09:03] <rogpeppe2> axw_: the overwrite will come, i think, from the fact that we call Update on *all* the attributes
[09:03] <rogpeppe2> axw_: so "set-environment foo=a" will also update bar to the value that was previously seen
[09:04] <axw_> rogpeppe2: no, because it doesn't change between the load and the store
[09:04] <axw_> wait
[09:04] <axw_> no you're right
[09:04] <axw_> :)
[09:04] <rogpeppe2> axw_: :-)
[09:05] <rogpeppe2> axw_: we could change settings so that it only made the update if things had actually changed, but i think that has more likelihood of leading to problems in practice
[09:06] <axw_> rogpeppe2: I did start down the road of doing reflect.DeepEquals to check if things had changed, but was wary of changing things too much there
[09:06] <rogpeppe2> axw_: i thought about that, don't think it actually helps that much
[09:06] <rogpeppe2> axw_: we can still end up with an invalid config
[09:07] <rogpeppe2> axw_: that's why i think that something like what i suggested is the only decent way forward, as it allows the config to be verified as a whole, while still allowing atomic delta changes
[09:08] <rogpeppe2> axw_: but as i said, i'm ok with what you've done for the time being - it is an improvement, and it unblocks the other CL
[09:08] <axw_> rogpeppe2: and that would need to hook into the provider right? along the lines of the prechecker?
[09:08] <axw_> rogpeppe2: yep thanks, I'll land as is and leave the bug open
[09:09] <rogpeppe2> axw_: yeah - the function would need to call EnvironProvider.Verify
[09:09] <rogpeppe2> axw_: to my shame, i haven't actually looked at the prechecker
[09:10] <axw_> rogpeppe2: that's ok, it's not actually switched on yet :)
[09:10] <axw_> but it does essentially that, for machine/container additions
[10:35] <rogpeppe2> mgz: how close are you to landing the status changes?
[10:37] <rogpeppe> mgz: i find myself wanting better status info in the juju-restore command
[10:46] <dimitern> rogpeppe, mgz, fwereade_, TheMue, wallyworld, standup
[10:55] <dimitern> mgz, ?
[11:26]  * dimitern lunch
[13:13] <dimitern> rogpeppe, you've got a review on https://codereview.appspot.com/37850043/
[13:14] <rogpeppe> dimitern: thanks!
[13:15] <rogpeppe> dimitern: FWIW I aim to remove the current state.AddMachine entirely
[13:15] <rogpeppe> dimitern: it's only ever used in tests
[13:15] <dimitern> rogpeppe, ah, then perhaps rename it to AddTestingMachine? :)
[13:16] <rogpeppe> dimitern: i don't want to do that in this CL because there are hundreds of calls to it
[13:16] <rogpeppe> dimitern: hence i left it alone
[13:17] <dimitern> rogpeppe, so it merits mentioning in the CL description as well then
[13:17] <rogpeppe> dimitern: good point - i'll do that
[15:06] <dimitern> rogpeppe, i'd appreciate if you can take a look at this (still wip, just checking i'm on the right track): (only the file upload part done and tested, no state operations yet) https://codereview.appspot.com/38370043
[15:07] <rogpeppe> dimitern: looking
[15:30] <rogpeppe> dimitern: reviewed
[15:31] <dimitern> rogpeppe, cheers!
[15:50] <dpb1> Is this an old error that is now reapearing?  dpb@helo:trunk$ juju deploy --repository dev/charms local:raring/landscape-devenv
[15:50] <dpb1> ERROR cannot bundle charm: symlink "." links out of charm: "../precise/landscape-devenv/"
[15:52] <dimitern> rogpeppe, i can't see a way to verify the content type of the uploaded file before reading it
[15:53] <dimitern> dpb1, i've never seen this one - is it from juju-core or pyjuju?
[15:54] <dpb1> dimitern: juju-core.  I've seen it before with other types of symlinks in the repository path.  Thing is, I've been launching units like this just fine for multiple weeks on juju-core, and now it just breaks.
[15:55] <dimitern> dpb1, is it a charm dir or an archive?
[15:55] <rogpeppe>  dimitern: it's in Part.Header
[15:56] <dimitern> rogpeppe, i'll try that
[15:56] <dpb1> dimitern: this symlink points to an charm directory.  let me put up a paste
[15:57] <dpb1> dimitern: http://paste.ubuntu.com/6530321/
[15:58] <dimitern> dpb1, can you paste a find . instead in the charms dir please?
[16:00] <dpb1> dimitern: http://paste.ubuntu.com/6530335/
[16:04] <dimitern> dpb1, weird.. the error comes from checkSymlinkTarget in charm/bundle.go and that's been there for quite a while
[16:05] <dpb1> I'm racking my brain to think about what changed.  so far I have nothing.
[16:05] <dimitern> dpb1, maybe the symlinks are somehow strange? i can see // in the targets, instead of / - have you changed that?
[16:05] <dpb1> checking
[16:06] <dpb1> there is a trailing slash, let me try removing that
[16:07] <dpb1> dimitern: no, the trailing slash is there from ls -lF, nm  The symlink looks normal and hasn't changed.
[16:09] <dimitern> dpb1, what's your go version?
[16:10] <dpb1> dimitern: you mean juju-core version?
[16:10] <dpb1> 1.16.4-saucy-amd64
[16:12] <dimitern> dpb1, no, go version
[16:12] <dpb1> go version go1.1.2 linux/amd64
[16:12] <dimitern> dpb1, or you're using the binary and not building from source?
[16:12] <dpb1> binary
[16:12] <dpb1> yes, from the ppa
[16:13] <dimitern> sorry, i don't seem to grok how it did work before.. it shouldn't and you've gotten the same error earlier
[16:21] <dpb1> dimitern: ok  I'll keep digging into it
[16:21] <dimitern> dpb1, sorry i couldn't be more helpful
[16:21] <dpb1> dimitern: thx for the effort.  I'm stumped as well. :)
[17:52] <rogpeppe> does anyone know how to get tip bootstrapping correctly?
[17:52] <rogpeppe> i get "cannot find bootstrap tools: XML syntax error on line 9: element <hr> closed by </body>"
[17:53] <rogpeppe> i thought that would have been fixed a while ago
[17:54] <rogpeppe> this bug says it should have been fixed: https://bugs.launchpad.net/juju-core/+bug/1254401
[17:54] <_mup_> Bug #1254401: error reading from streams.canonical.com <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1254401>
[17:54] <rogpeppe> i guess i'll just have to make do with uploading tools
[17:54] <mgz> you have to upload-tools, yeah
[17:55] <mgz> rogpeppe: I think you can also supply tools-metadata-url
[17:55] <rogpeppe> mgz: you're alive! :-)
[17:55] <mgz> if you've put the tools+config bits in local swift say
[17:56] <mgz> rogpeppe: yeah, sorry I wasn't around earlier
[17:56] <rogpeppe> mgz: ah, do you know what tools-,metadata-url might work?
[17:56] <rogpeppe> mgz: np, just wondered if anything was up
[17:56] <mgz> sec, checking
[18:00] <mgz> rogpeppe: https://swift.canonistack.canonical.com/v1/AUTH_526ad877f3e3464589dc1145dfeaac60/juju-dist/tools may work, checking
[18:01] <rogpeppe> mgz: even from ec2?
[18:01] <mgz> hm, good question
[18:02] <mgz> well, to do tip you'd want to build/sync-tools/juju-metadata regardless, to your own s3/swift bucket
[18:03] <mgz> heh, and generate-tools is borked by the same bug
[18:03] <mgz> so, I guess --upload-tools *is* the only sane option
[18:08] <rogpeppe> mgz: :-(
[18:08] <rogpeppe> mgz: how can we have left tip broken for so long? this is not good.
[18:09]  * rogpeppe is tempted to escalate the bug to Critical
[18:13] <mgz> well, it's mostly that we have testing stuff that doesn't work in a place trunk expects to be sane
[18:24] <rogpeppe> ha, bootstrap is totally broken for me currently
[18:24] <rogpeppe> or for any client where it takes more than 5 seconds to connect to the bootstrap machine
[18:25] <rogpeppe> (it takes me 15 seconds to connect to any ec2 instance because of my horribly broken dns)
[18:32] <rogpeppe> https://bugs.launchpad.net/juju-core/+bug/1258607
[18:32] <_mup_> Bug #1258607: bootstrap doesn't work if Dial takes more than 5 seconds <juju-core:New> <https://launchpad.net/bugs/1258607>
[18:37]  * rogpeppe is done
[18:37] <rogpeppe> happy weekends all
[18:38] <mgz> and have a nice weekend rog
[18:38] <rogpeppe> mgz: you too mate