[00:30] wallyworld: ta [00:30] np [00:31] thumper: one other thing i was going to do but too late probably [00:32] yeah? [00:32] the fmt.Sprintf() thing could be wrapped around the entire arg string [00:32] not just the one param [00:32] saves string concat etc [00:32] a bit neater maybe [00:32] not easily... [00:32] and I'm not sure it'd end up being neater [00:32] but not a big deal [00:32] or even just the chubks [00:32] chunks [00:33] yeah, not a big deal [00:33] hazinhell: still in hell? [00:33] hazinhell: keen to come to Dunedin? [00:33] thumper, yes and hell yes ;-) [00:33] * thumper nods [00:33] 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] ok [00:41] sinzui still around ? [01:09] thumper: https://bugs.launchpad.net/juju-core/+bug/1258132 [01:09] <_mup_> Bug #1258132: [manual] bootstrap fails due to juju-db not starting [01:10] did you know about the reload-config option? consider it for local provider? [01:10] axw: yeah... [01:10] no, what is it? [01:10] tells upstart to reload config from /etc/init [01:11] I'm not sure if that's actually solving it, or just ading enough of a delay [01:11] i.e. is it synchronous, or is it just scheduling another update that'll race [01:11] anyway, was just wondering if you knew [01:15] axw: well, there is some race there that I've not solved yet [01:15] would be great if this did solve it [01:16] abently has a machine that fails about 50% of the tiem [01:16] so we could always use him as a tester :) [01:16] * thumper fixes another test isolation failure [01:17] GAH, WTF [01:18] hitting so many weird test failures [01:18] intermittent ones [01:18] this one in manual provider [01:18] environ_test.go:121: [01:18] c.Assert(err, gc.ErrorMatches, "exit code 99") [01:18] ... error string = "failed to write input: write |1: broken pipe (output: \"JUJU-RC: 99\")" [01:18] ... regex string = "exit code 99" [01:18] huh? [01:19] and getting the provisioner not always making machines [01:19] two different tests failed due to that [01:19] in different places [01:19] what the [01:20] thumper: I'm changing some code in that vicinity, will look into it later today [01:21] kk [01:22] thumper: my hypothesis is that upstart is seeing the file half-way through writing it (in place) [01:22] gonna see if I can force reproduce it [01:23] axw: sounds possible [01:23] in that case a touch would be sufficient [01:23] reload-configuration would reload everything [01:29] ummm [01:29] % juju deploy cs:precise/haproxy-67 [01:29] ERROR cannot get charm: charm not found: cs:precise/haproxy-67 [01:30] ^ what has happened here [01:30] this revision absolutely does exist [01:30] your syntax is wrong [01:30] surely [01:30] haproxy-67 isn't the name of a charm [01:31] In all cases, a versioned charm URL will be expanded as expected (for example, [01:31] mysql-33 becomes cs:precise/mysql-33). [01:31] do I need to leave off the cs:precise ? [01:31] % juju deploy haproxy-67 [01:31] ERROR cannot get charm: charm not found: cs:precise/haproxy-67 [01:32] thumper: this is sort os serious [01:33] cts have hit a bug and need to use an older revision of the charm [01:34] * thumper looks [01:35] oh god [01:35] this is this fucking revno SHIT [01:35] thumper: sorry [01:36] its not a juju problem [01:36] the charm revision is unrelated to the bzr revision [01:41] thumper: got time for a quick hangout? [01:41] wallyworld: ah... yeah [01:41] was just writing an email [01:41] ok, ping me when done [01:41] how short? [01:41] i can wait [01:41] school run is in 20 min [01:42] can you wait 30 minutes? [01:42] ok [01:42] ok [01:42] thanks [02:00] fwereade_: wtf are you doing awake? [02:11] wallyworld: https://plus.google.com/hangouts/_/7acpilj94h6vnkfr0qilf02c5k?hl=en [02:12] davecheney: isn't the bootstrap error message logged higher up? [02:26] axw: in a word, no [02:26] or at least not without -v [02:26] axw: https://bugs.launchpad.net/juju-core/+bug/1258246 [02:26] <_mup_> Bug #1258246: azure: juju bootstrap aborted for no apparent reason

[02:29] davecheney: and with the additional log, don't you just see another "exit status 1" log message? [02:29] axw: dunno [02:29] i don't ahve control over that environemnt [02:30] davecheney: I think the problem is that the error message we're showing isn't useful, not that it's not there [02:30] but I may be mistaken [02:30] ERROR exit status 1 [02:30] I think is from the ssh process [02:30] i thnk that is coming from the jenkins builder [02:30] axw: i'm suspecting the underlying cause is a timeout [02:37] bigjools: we need your advice. https://plus.google.com/hangouts/_/7acpilj94h6vnkfr0qilf02c5k?hl=en [02:37] btw it's work naked day today [02:38] citation needed [02:38] 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] bah. google sucks http://www.news.com.au/business/worklife/friday-6-december-is-work-in-the-nude-day/story-e6frfm9r-1226776444086 [02:44] wallyworld: I'll just go make a coffee to sup while doing your reviews [02:44] axw: do you have any you'd like me to look at too? [02:44] ok [02:44] thumper: ummm no not right now [02:44] thanks [02:44] I may do later on [02:46] 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

[02:49] actually, I'm not even sure what's right there. hrm [03:23] 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] hmm... [03:24] Perhaps we just document the limitation [03:25] for now [03:25] i did think about using fingerprint [03:25] i'll have another look at the ssh package to see if there's anthing i missed [03:26] kk [04:41] hatch: there is a 2.4.6 in the cloud-archive:tools archive (vs the stable ppa) [04:41] jam goodmorning :) [04:41] it's all working now [04:42] hatch: so from the traceback, you had a mongod that was serving your .juju/local/db directory [04:42] which because of how it got shutdown [04:42] wasn't getting stopped by "juju destroy-environment" [04:42] "some other thing was" [04:42] and then every time you bootstrapped [04:42] we would try to start a new one [04:43] which was probably failing, but we didn't notice because hey, there is something listening on 37017 for us [04:43] hatch: *probably* if you had killed the mongod it would have cleaned things up, too. [04:43] as there *shouldn't* be a mongod running if nothing is bootstrapped [04:43] hatch: anyway, I'm glad you got it working. [04:43] ahhh - so is this something that we could 'fix' - maybe simply by creating a better error message? [09:02] rogpeppe2: thanks for the review. just replied to your comment; would appreciate another look before I land [09:02] axw_: ok [09:03] axw_: the overwrite will come, i think, from the fact that we call Update on *all* the attributes [09:03] axw_: so "set-environment foo=a" will also update bar to the value that was previously seen [09:04] rogpeppe2: no, because it doesn't change between the load and the store [09:04] wait [09:04] no you're right [09:04] :) [09:04] axw_: :-) [09:05] 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] 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] axw_: i thought about that, don't think it actually helps that much [09:06] axw_: we can still end up with an invalid config [09:07] 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] 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] rogpeppe2: and that would need to hook into the provider right? along the lines of the prechecker? [09:08] rogpeppe2: yep thanks, I'll land as is and leave the bug open [09:09] axw_: yeah - the function would need to call EnvironProvider.Verify [09:09] axw_: to my shame, i haven't actually looked at the prechecker [09:10] rogpeppe2: that's ok, it's not actually switched on yet :) [09:10] but it does essentially that, for machine/container additions === mthaddon` is now known as mthaddon === waigani_ is now known as waigani === wedgwood is now known as Guest45906 [10:35] mgz: how close are you to landing the status changes? === rogpeppe2 is now known as rogpeppe [10:37] mgz: i find myself wanting better status info in the juju-restore command [10:46] rogpeppe, mgz, fwereade_, TheMue, wallyworld, standup [10:55] mgz, ? [11:26] * dimitern lunch [13:13] rogpeppe, you've got a review on https://codereview.appspot.com/37850043/ [13:14] dimitern: thanks! [13:15] dimitern: FWIW I aim to remove the current state.AddMachine entirely [13:15] dimitern: it's only ever used in tests [13:15] rogpeppe, ah, then perhaps rename it to AddTestingMachine? :) [13:16] dimitern: i don't want to do that in this CL because there are hundreds of calls to it [13:16] dimitern: hence i left it alone [13:17] rogpeppe, so it merits mentioning in the CL description as well then [13:17] dimitern: good point - i'll do that === sidnei` is now known as sidnei === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [15:06] 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] dimitern: looking [15:30] dimitern: reviewed [15:31] rogpeppe, cheers! [15:50] Is this an old error that is now reapearing? dpb@helo:trunk$ juju deploy --repository dev/charms local:raring/landscape-devenv [15:50] ERROR cannot bundle charm: symlink "." links out of charm: "../precise/landscape-devenv/" [15:52] rogpeppe, i can't see a way to verify the content type of the uploaded file before reading it [15:53] dpb1, i've never seen this one - is it from juju-core or pyjuju? [15:54] 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] dpb1, is it a charm dir or an archive? [15:55] dimitern: it's in Part.Header [15:56] rogpeppe, i'll try that [15:56] dimitern: this symlink points to an charm directory. let me put up a paste [15:57] dimitern: http://paste.ubuntu.com/6530321/ [15:58] dpb1, can you paste a find . instead in the charms dir please? [16:00] dimitern: http://paste.ubuntu.com/6530335/ [16:04] dpb1, weird.. the error comes from checkSymlinkTarget in charm/bundle.go and that's been there for quite a while [16:05] I'm racking my brain to think about what changed. so far I have nothing. [16:05] dpb1, maybe the symlinks are somehow strange? i can see // in the targets, instead of / - have you changed that? [16:05] checking [16:06] there is a trailing slash, let me try removing that [16:07] dimitern: no, the trailing slash is there from ls -lF, nm The symlink looks normal and hasn't changed. [16:09] dpb1, what's your go version? [16:10] dimitern: you mean juju-core version? [16:10] 1.16.4-saucy-amd64 [16:12] dpb1, no, go version [16:12] go version go1.1.2 linux/amd64 [16:12] dpb1, or you're using the binary and not building from source? [16:12] binary [16:12] yes, from the ppa [16:13] 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] dimitern: ok I'll keep digging into it [16:21] dpb1, sorry i couldn't be more helpful [16:21] dimitern: thx for the effort. I'm stumped as well. :) === wedgwood is now known as Guest77125 === Guest77125 is now known as wedgwood [17:52] does anyone know how to get tip bootstrapping correctly? [17:52] i get "cannot find bootstrap tools: XML syntax error on line 9: element

closed by " [17:53] i thought that would have been fixed a while ago [17:54] 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

[17:54] i guess i'll just have to make do with uploading tools [17:54] you have to upload-tools, yeah [17:55] rogpeppe: I think you can also supply tools-metadata-url [17:55] mgz: you're alive! :-) [17:55] if you've put the tools+config bits in local swift say [17:56] rogpeppe: yeah, sorry I wasn't around earlier [17:56] mgz: ah, do you know what tools-,metadata-url might work? [17:56] mgz: np, just wondered if anything was up [17:56] sec, checking [18:00] rogpeppe: https://swift.canonistack.canonical.com/v1/AUTH_526ad877f3e3464589dc1145dfeaac60/juju-dist/tools may work, checking [18:01] mgz: even from ec2? [18:01] hm, good question [18:02] well, to do tip you'd want to build/sync-tools/juju-metadata regardless, to your own s3/swift bucket [18:03] heh, and generate-tools is borked by the same bug [18:03] so, I guess --upload-tools *is* the only sane option [18:08] mgz: :-( [18:08] 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] well, it's mostly that we have testing stuff that doesn't work in a place trunk expects to be sane [18:24] ha, bootstrap is totally broken for me currently [18:24] or for any client where it takes more than 5 seconds to connect to the bootstrap machine [18:25] (it takes me 15 seconds to connect to any ec2 instance because of my horribly broken dns) [18:32] https://bugs.launchpad.net/juju-core/+bug/1258607 [18:32] <_mup_> Bug #1258607: bootstrap doesn't work if Dial takes more than 5 seconds [18:37] * rogpeppe is done [18:37] happy weekends all [18:38] and have a nice weekend rog [18:38] mgz: you too mate === gary_poster is now known as gary_poster|away === tiaz_ is now known as tiaz