[00:13] thumper: do you know how to kick tarmac in the balls to reset it? [00:13] wallyworld: sorry, no [00:14] ok. ta. ffs it seems i can never just land a branch without hassle [00:17] poos [00:18] I want the opposite of updateSecrets [00:18] I want to get some settings from the EnvironConfig [00:18] and put it into the local config [00:18] * thumper thinks [00:20] * thumper resolves to just use default hard coded port numbers [00:20] and allow people to override them in the config [00:20] too hard to be dynamic here [01:04] * thumper does a little dance [01:05] wallyworld: http://paste.ubuntu.com/5879343/ [01:06] thumper: \o/ [01:06] as Borat would say, niiiiiiiice [01:08] wallyworld: now... to break it up, land it and have some tests... [01:08] it has been super hacky so far [01:08] davecheney: local provider is working [01:08] it runs, who needs tests :-P [01:08] wallyworld: it is actually pretty hard to test some of this [01:09] as it requries root [01:09] yeah :-( [01:09] so test around the edges where you can [01:09] and have some form of live tests [01:12] * thumper goes to make lunch for the minions [02:41] wallyworld: didn't you write a function somewhere to get the container type from a machine id? [02:41] sorry, what's the context? [02:42] i've worked on 5 branches today [02:43] s'ok, found it [02:43] ContainerTypeFromId [02:43] cool [02:47] thumper: i'm dumb. i read your question as "why didn't you write...." and was thinking that i thought i had. clearly my brain is dying [02:48] heh [02:48] you had already [02:49] * thumper enfixorates the ensure lxc bit [02:50] * thumper starts teasing apart the threads of the local provider work to land bits independently [02:51] hmm 7 pipes unlanded already [02:52] is that all? :-P [02:52] go on, try for 10 [02:52] wallyworld: it probably will be by the time I've done the teasing [02:52] wallyworld: but IT WORKS!!!! [02:52] so far [02:53] thumper: so you sorted out th addrssing for local? [02:53] * thumper wonders how to stress test it [02:53] what do you mean? [02:53] i thought you had to tell the containers what ip address thy could use [02:54] or make the containers to look methods not yt existing on state.machine [02:55] wallyworld: no, not for the local provider [02:55] wallyworld: the default lxc settings work fine [02:55] wallyworld: the problem is having the user, on the outside of the containers getting the ip addresses of the containers [02:55] ah ok. so they all just use the localhost address? [02:56] wallyworld: instead of fucking around with lxc to get it from the outside [02:56] wallyworld: I want to fix it in state [02:56] wallyworld: no, they use a 10.0.3.0/24 address [02:56] wallyworld: which is routed through 10.0.3.1 bridge [02:56] ok [02:57] hence my email that I sent a few minutes ago [02:57] * wallyworld hits refresh [03:18] * thumper waits while lbox does its thing [03:18] this thing that lp does too [03:20] bit 1: https://codereview.appspot.com/11321043 [03:28] bit 2: https://codereview.appspot.com/11319044 === tasdomas_afk is now known as tasdomas [03:51] bit 3: https://codereview.appspot.com/11325043 [03:51] thumper: but lbox does it synchronously and less accurately. (though you do know when it has actually finished, vs async in lp) [03:52] hi jam [03:52] when are you off for holidays? [03:53] thumper: my flight is tomorrow evening. [03:53] so I'll be working some tomorrow, but maybe not a full day [03:54] * thumper nods [03:54] * thumper goes to make coffee and take a break [03:54] will submit bit 4 RSN [04:02] jam: hi, tarmac is fooked and i don't know how to kick it in the guts [04:02] wallyworld: can you point me to context? [04:03] jam: i approved a mp and nothing happened. the tarmac log says there was a bzr error merging (from memory, can't recall exactly), and now it appears to not ven be trying to look at any new approvals to process [04:04] i at least wanted just to kick start it again [04:08] wallyworld: it is running, but it just keeps failing on your proposal: http://paste.ubuntu.com/5879636/ [04:08] jam: that timestamp is hours old [04:09] wallyworld: UTC? [04:09] it only failed once and then stopped processing [04:09] 4 ohurs [04:09] i think it was about 4 hours ago from memory [04:10] jam: and it was the 2nd try because the first run failed some tests [04:11] wallyworld: yeah, date says 4 hrs ago [04:11] I don't see anything running, which is strange, cron should still be firing off tarmac every minute [04:11] yes it is weird [04:12] wallyworld: we use "flock ...." as a way to avoid having 2 tarmac processes running concurrently (you can use crontab -l to see it). I did a lot of searching, but I didn't see any processes running flock or python. [04:12] So I just deleted the lock file [04:12] and it is running now. [04:12] It is going for ~jtv's code [04:12] hmm. ok. i didn't realise that's what we did [04:12] maks sense [04:12] so the error handling needs improving [04:13] to always release the lock [04:13] wallyworld: it is the "flock" process outside of tarmac [04:13] I didn't think we could get that wrong [04:13] as it starts a process, and when that process dies it unlocks [04:14] wallyworld: http://paste.ubuntu.com/5879648/ [04:14] from man flock [04:14] makes me think it might have left a mongo or something running. [04:15] yeah, wouldn't be surprised [04:15] wallyworld: --wait 3600 maybe? (so we auto-drop flock after 1 hour) not sure on that one. [04:16] an hour sounds reasonable, maybe even less [04:16] hopefully this won't happen too often [04:16] wallyworld: so the test suite should only take 15min or so, but we might run multiple [04:16] and I don't think flock actually kills the subprocess. [04:16] it would just stop locking [04:19] wallyworld: any ideas what would be non-ascii with what you submitted? [04:19] ISTR there were also nonascii patches because gcc was outputing Unicode sequences. [04:20] jam: no, that's just the thing. it worked first time, some tests failed, and i just re-approved [04:20] https://bugs.launchpad.net/tarmac/+bug/750930 [04:20] <_mup_> Bug #750930: breaks on non-ascii characters in verify_command output on failure [04:20] that is my patch, which appears to still not have landed... [04:20] ah, i did push up a small change [04:20] i'll check the logs [04:23] jam: is was a one line fix to add "jc." in front of IsTrue cause a trunk change while the branch was in review broke my test [04:23] so i don't see any non-ascii in there [04:24] wallyworld: I have a feeling it could be a gcc sort of issue (gcc uses fancy quotes if your terminal is marked UTF-8) [04:24] so maybe something with gwacl or something [04:24] anyway, I have the patch, not sure what the issue is, unfortunately. [04:24] I'm putting together a branch for us [04:24] because lp:tarmac is owned by rockstar only [04:25] I already have a couple local-only patches, and I don't want to make that worse. [04:25] the local patches are just logging changes [04:25] jam: ah, there was a gofmt change in code i didn't touch. the diff in loggerhead shows "nothing" changed, so it could have been a tab [04:26] or something [04:26] wallyworld: well a tab is still ascii [04:26] it sounds like a build that failed [04:26] true [04:26] bit 4: https://codereview.appspot.com/11326043 [04:29] wallyworld: note that the code that failed indicated it was trying to mark the proposal as failed [04:29] hmm. ok. i'll rerun the tests [04:53] jam: just got an email - it ran and merged ok that time [04:53] i didn't change anything [05:10] bit 5: https://codereview.appspot.com/11327043 [05:16] bit 6: https://codereview.appspot.com/11327044 === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas [06:27] bit 7: https://codereview.appspot.com/11330043 [06:28] jam: tarmac hates me. this time it appears to be stuck on my branch because i did the prereq myself. so i guess i have to repropose against trunk and adjust all the downstream branches? [06:34] bit 8: https://codereview.appspot.com/11333043 [06:35] and that last one enables the local provider [06:35] * thumper is done for the day [06:35] plz review nicely :) [06:35] laters... [06:43] is anyone able to bootstrap on ec2 ? [06:43] i'm seeing bootstrap nodes stillborn === tasdomas is now known as tasdomas_afk [06:56] davecheney: i did earlier today [06:56] just sits there waiting for the mgo server to come up [06:56] can't see to the instance either [06:57] hmmm. not sure sorry :-( [07:04] wallyworld: you can just propose the prereq and manually mark it merged. [07:05] davecheney: I was bootstrapping a lot yesterday, but I have not tried it today. [07:34] jam: wallyworld i cannot bootstrap in ap-southeast-2 [07:34] ap-southeast-1 works [07:35] -2 results in an aninstance that is running but does not repond at all on the netwokr [07:35] no ssh no nothing [07:35] davecheney: can you get the boot information from ec2? [07:37] oh, and it looks like destroy-environment doens't work either [07:37] davecheney: well if you can't read the s3 bucket, you can't destroy stuff, I think. [07:38] It *sounds* like an ec2 side issue, but I could certainly be wrong. [07:38] jam: get system log looks fine [07:38] jam: if it was a bucket issue, --upload-tools would have failed [07:38] they are the same bucket [07:38] true enough [07:42] hang on, my ap-southeast-1 is set to raring [07:42] ... i wonder if I set it to precise [07:42] ... === tasdomas_afk is now known as tasdomas [07:48] sigh - no [07:49] it's just ap-southeast-2 is busted today [07:50] davecheney: hiya [07:50] mornin' all [07:51] rogpeppe: howdy [07:53] davecheney: just wondering: if you needed to reinstall your laptop ubuntu, what would you use for backup and restore? just tar? [07:55] davecheney: my laptop is in a bad state since upgrading to 13.04 and it's possible that reinstalling might fix things [07:55] rogpeppe: i just tar up ~ [07:55] but really you want to avoid all the dot files shit in ~ [07:56] davecheney: i'm just concerned that i'll lose all the stuff outside $HOME that i've accumulated over the years. [07:56] rogpeppe: ahh, i don't ever step outside $HOME for that reason [07:56] davecheney: i'm thinking mostly of apt-get stuff [07:57] davecheney: but i guess i can just stumble along until i find something missing, then apt-get it [07:57] dpkg -l | grep ^ii [07:58] davecheney: ah, cool. what's the significance of "ii" ? [07:59] ii == installed [07:59] lots of other stuff in there as turds [07:59] davecheney: and do you know of any way i can ask for only those packages which aren't depended on by others [07:59] ? [08:00] no, but jam or tim will know [08:00] davecheney: something which could produce output suitable for tsort might work [08:01] google says debtree [08:01] morning [08:01] I know you can ask for rdepends I believe, but I don't know a specific way to say "give me the list of packages explicitly installed ignoring their dependencies". I know it is possible, because when you "apt-get remove" it can tell you "these packages are no longer required" [08:01] I just don't know it. [08:10] hmm, the solution here looks plausible (though i'm sure i haven't explicitly installed *all* the 2080 packages i get when applying the first answer) [08:10] http://unix.stackexchange.com/questions/3595/ubuntu-list-explicitly-installed-packages/3624#3624 === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 6 Critical, 79 High - https://bugs.launchpad.net/juju-core/ [08:11] rogpeppe: what problem do you have? is your system in trouble? [08:12] TheMue: yeah, various pieces of the system are broken in weird ways [08:12] TheMue: it's possible that it's a hardware issue [08:12] TheMue: but i have to try a fresh install first [08:13] rogpeppe: iiirgks, that really doesn't sound good [08:13] rogpeppe: i had to cleanup my package list after 13.04 upgrade [09:02] davecheney, trying your no-strip suggestion now [09:16] guys, is juju-core 1.11.2 behavior stable today? [09:18] pavel: what do you mean exactly? [09:19] I mean that I have weird errors all day [09:19] pastebin? [09:19] if there are no any common issue, then it's on my side [09:20] yeah, as far as I know we've not broken the published tools or anything of late [09:20] ok, thanks [09:56] wallyworld: when you're back, I figured out how flock works. It opens a file flocks it, then execs into the child process which means that all spawned processes hold open that flock until they all exit. And there was a 'mongo' running that meant the lock was permanently held. [09:57] hah [09:58] o_cloexec plz [10:50] Anybody up for a second review? Nothing big — just discarding an unneeded complication: https://codereview.appspot.com/11322043 [10:51] jtv: looking [10:51] Thanks! [10:57] jtv: out of interest, what does gwacl stand for? [10:59] jtv: you've got a +1 [10:59] hey guys I need a review on the last bit of the deployer API stuff (client-side): https://codereview.appspot.com/11342043 [10:59] rogpeppe: i assume go windows azure cloud library (or client library) [11:00] dimitern: *click* [11:00] TheMue: ah, sounds plausible. i reckon it could do with a package doc comment... [11:02] rogpeppe: yes, sounds reasonable. didn't look if there exists one [11:05] mgz: well you need it for the first process, and you can set a flag as to 'don't inherit' but I don't know what it kills when. [11:06] jtv: reviewed [11:07] jam: the other option is specifically when spawning mongo, to do the post-exec go through and close all file handles hack [11:07] mgz: what's the issue? [11:07] mgz: or not have the test suite crash without cleaning itself up? :) [11:08] that too :) [11:08] fwereade: ping [11:08] rogpeppe: flock persisting when a child process spawns with an fd open [11:08] mgz: http://linux.die.net/man/1/flock [11:09] I would consider --close, but that seems to negate the point of using flock in the first place ( [11:09] (don't let 2 tarmac processes run concurrently) [11:09] mgz: 5&- ? [11:09] mgz: if 5 is your fd [11:10] rogpeppe: earlier today we had a submission go haywire and the bot was hung unable to process new requests for 4+ hours. [11:10] mgz: sorry, >5&- [11:10] It would appear because mongod was spawned by a test case, and was not stopped when the 'go test' executable exited [11:11] jam: hmm, interesting - it *should* be stopped at the end of the test [11:11] rogpeppe: sure, but given the test suite failed via some sort of crash, some resource was not properly cleaned up [11:11] in this case a mongo, which then had a file descriptor it inherited still open [11:11] so while --close sounds like it might work (we want to hold open the handle for tarmac, but not for children) [11:12] it sounds like it closes too early. [11:12] jam: could we use process groups or sessions or something related, and kill the session after go test finishes? [11:14] jam: it sounds like it might be a mistake to make gotest/mongo not hold the lock, because presumably we don't want multiple garbage mongod's accumulating [11:18] rogpeppe: we don't, but I also don't mind *a* garbage mongod preventing us from landing anything until I come online, especially since I'm gone for 2+ weeks (2 vacation, 1 for Isle of Man) [11:18] I guess I can just tell Martin and Wallyworld they have to deal with it :) [11:19] jam: presumably it might end up as an arbitrary number of mongods if the same issue reoccurs. [11:19] rogpeppe: it is slightly harder to discover, but easier to diagnose when it does happen. :) [11:19] jam: in which case just {go test 200>&-} should do the job [11:20] * rogpeppe hasn't done fd manipulation in sh for a while, it seems :-) [11:20] rogpeppe: the piece that knows what verify_command to run needs to know what handle flock opend. And you can force the flock handle, but it isn't like 200 is the default. [11:20] rogpeppe: thanks — I think it was Go Windows Azure Client Library. [11:21] And thanks TheMue too. :) [11:21] jam: aren't we writing both bits? [11:22] rogpeppe: we do control both bits, they are spread far apart in terms of configuration, so if we find we have to have it we can, but I would avoid it [11:22] jam: $FLOCK_HANDLE ? [11:33] rogpeppe: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 standup [11:58] mramm: I'm in the 1:1 whenever you're ready [11:58] ok [11:58] answering questions for dimitern quickly [11:58] there in a min or two [12:01] np [12:20] dimitern: you've got a review [12:21] TheMue: tyvm [12:21] dimitern: yw [12:22] * TheMue => lunchtime [12:25] fwereade: when you can, PTAL https://codereview.appspot.com/11342043/ [12:27] * rogpeppe goes to lunch [12:30] fwereade: you disappeared. i think we had sort of finished anyway [12:38] wallyworld__, others: fwereade just texted me that his connection was gone haywire and he's going to lunch now [12:38] ok [12:47] jam, before I go, about the api addresses -- would it be that awful to connect to state and get api addresses from there? we should be able to assume sane/valid state info, right? [12:48] fwereade: we have a state connection, though it is hidden behind the state.Machine we have in the code. [12:48] we need it to SetPassword [12:48] so we will have a state conn [12:48] but I'm not sure how to get it passed in. [12:48] I can investigate [12:49] jam, I feel like it ought to be possible but, yeah, I guess all the entity stuff is a little tangly, maybe it's not worth it [12:49] jam, have a little look but if it's going to be costly I guess we're fine without it [12:50] jam, I'm just a bit worried about what'll happen if that code lives longer than we expect it to ;) [12:53] rogpeppe, bug fix LGTM, thanks [12:54] rogpeppe, that was *not* how I expected that Format to work though :) [12:54] (evidently ;p) [13:04] fwereade: that isn't how anyone who doesn't read the docs closely thinks it works [13:04] given it is the first time I've seen a strftime that *wasn't* %H:%M:%S based [13:05] jam, yeah, and there's even mention of those %H~s etc in the docs iirc [13:05] fwereade: thanks for the review [13:06] http://golang.org/pkg/time/#Time.Format doesn't actually mention the % versions that I can see [13:06] and http://code.google.com/p/go/issues/detail?id=444 clearly indicates it doesn't want strftime [13:07] fwereade: Given the issue, is 2006 actually better? [13:07] which is 1 [13:07] what is 2 [13:07] IMO you still need the docs to figure out what to pass [13:08] maybe if you did it enough you'd remember the magic date better [13:09] jam, ha, clearly my crack consumption was much higher than usual that day... I could swear I remembered looking it up [13:09] jam, maybe I was an idiot and looked up strftime instead [13:09] jam, that's probably it [13:10] fwereade: right, it must use strftime syntax, I'll go track it down and use it [13:10] jam, yeah, indeed [13:11] jam, there's something quite neat about what they do there but it's a touch astonishing too [13:14] fwereade: i think it's only astonishing if you're used to strftime. i just wish they'd chosen a more memorable date - the y/m/d ordering is quite parochial [13:26] fwereade: so.. s.State.APIAddresses() is actually wrong in the test suite (because it does the same "give me the default port on all these things") s.APIInfo(c).Addrs has the correct value... [13:26] It doesn't matter for real world case [13:26] but it is true that we aren't recording in State the *actual* API Info [13:26] (addresses) [13:30] * rogpeppe wishes there was an easy way of traversing forwards through a pipeline of merge proposals [13:31] rogpeppe: pump ? [13:31] jam: when reviewing [13:31] or you mean web browse would link them [13:31] LP links them together [13:31] well, only towards the prereq maybe [13:31] jam: does it? perhaps i've missed that. [13:32] jam: exactly (and even then it only points to the branch, not the MP, i think) [13:32] rogpeppe: so if you go to the MP page, it has links to the branch itself, and the prerequisite branch, if you click on the branch itself, it says "1 branch depending on this one" [13:32] which you can click to [13:32] and then get to the MP from there [13:32] so the links are there [13:32] but not direct [13:33] hmmm.. the "1 branch dependent on this one" takes you to the page which has the list of merges to that branch [13:33] which *doesn't* include the MPs that depend on the branch [13:33] I wonder if it was intended to do so [13:33] rogpeppe: poke tim :) [13:34] jam: yeah, i just saw that. [13:34] jam: it looks wrong. [13:37] jam: verrrrry longstanding bug. [13:41] abentley: :) [13:41] fwereade: https://codereview.appspot.com/11137044/ has been updated with a state.State.APIAddresses call. I wish that actually did the right thing in the test suite. [13:42] (We don't record the API Addresses in the DB, so APIAddresses infers them from the State.Addresses that *are* recorded) [14:03] wallyworld__: something is wrong with your branch. I'm getting: Running test command: go fmt ./... && go build ./... && go test ./... [14:03] Command appears to be hung. There has been no output for 900 seconds. Sending SIGTERM. [14:03] It is trying again right now, but other branches have been able to land I believe. [14:08] jam: ah, i see now why mongo wasn't shut down [15:12] hmm, my laptop seems to have stopped talking to its wired ethernet :( [16:04] fwereade, dimitern: ping about some recent timeouts on go-bot [16:04] jam, oh yes? [16:04] we've had several failures like this one: https://code.launchpad.net/~dimitern/juju-core/070-deployer-client-facade/+merge/174973 [16:05] Where it appears deployer tests are getting a 500ms timeout [16:05] jam: yeah, i noticed [16:05] I have the feeling Canonistack is overloaded, and go-bot is running slowly [16:05] but I noticed the deployer code wakes up every 50ms, but doesn't do anything like StartSync in the inner loop [16:06] fwereade: we have s.State.StartSync() at the beginning, but not in the inner loops [16:06] this doesn't fix everything, but I think when tests are failing they aren't cleaning up cleanly, so we have a bunch of follow on failure. [16:07] jam, yeah, those all do look like timeouts while the SUT is actually doing what it should, but slowly [16:07] fwereade: right, it is getting some of them done (like svc 0 but not svc 1) [16:08] jam, StartSync in inner loops is only necessary when there's no way to tell when a triggering action has actually taken place [16:09] note stuff like: ok launchpad.net/juju-core/worker/uniter 365.596s [16:09] which is one of the slower tests [16:09] but 370s is super long [16:10] tarmac was running the whole test suite in 15min [16:10] fwereade: so I'm considering just bumping up the global LongWait (and changing the deployer code to use that value). [16:10] But I figured I'd bring it up for discussion. [16:11] jam, yeah, I'm +1 on that -- in normal circumstances these tests pass relatively fast, but in unhappy circumstances we still want them to work [16:11] oof, yeah, I did not see that one [16:12] fwereade: and long timeout is supposed to be the "waiting this long is a failure" not the "sleep a bit to let things progress" [16:12] jam, yeah, indeed [16:21] jam, rogpeppe1: how might we be getting an "unauthorized" error out of machiner? [16:21] fwereade: context? [16:21] rogpeppe1, deploying to saucy on azure: http://paste.ubuntu.com/5880671/ [16:21] fwereade: is machiner using the API now? [16:21] fwereade: (i'm presuming not) [16:21] rogpeppe1, no, I don't think it actually is, which is what's baffling [16:21] fwereade: might line 22 etc be significant here? [16:22] fwereade: hmm, no [16:22] fwereade: that's expected [16:22] rogpeppe1, I think that's normal, yeah [16:24] fwereade: this only happened deploying to saucy on azure? [16:24] s/happened/happens/ [16:24] rogpeppe1, I have only seen it reported there [16:25] rogpeppe1, but I have not deployed today [16:26] fwereade: and this is on the bootstrap machine too, right? that's very odd. [16:27] rogpeppe1: this is only on the bootstrap machine. I can't deploy nodes. [16:28] rvba: what happens when you run juju status? === tasdomas is now known as tasdomas_afk [16:28] rogpeppe1: http://paste.ubuntu.com/5881387/ [16:29] rvba: is it possible could you give me ssh access to the bootrap machine? [16:29] rogpeppe1: nothing is listening on the API port: http://paste.ubuntu.com/5881394/ [16:30] rogpeppe1: sure, just one sec. [16:30] rogpeppe1: launchpad id? [16:31] rvba: that's not surprising [16:31] k [16:31] rogpeppe1: ssh ubuntu@juju-azure-saucyy7xrrjl4h9zemnvvbaqpfqtelpm2jzjjzu375hmczp20ldz.cloudapp.net [16:32] rvba: as the machine agent is failing to start [16:32] rvba: and that's what runs the API [16:33] rvba: my ssh public key is: [16:33] ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDOjaOjVRHchF2RFCKQdgBqrIA5nOoqSprLK47l2th5I675jw+QYMIihXQaITss3hjrh3+5ITyBO41PS5rHLNGtlYUHX78p9CHNZsJqHl/z1Ub1tuMe+/5SY2MkDYzgfPtQtVsLasAIiht/5g78AMMXH3HeCKb9V9cP6/lPPq6mCMvg8TDLrPp/P2vlyukAsJYUvVgoaPDUBpedHbkMj07pDJqe4D7c0yEJ8hQo/6nS+3bh9Q1NvmVNsB1pbtk3RKONIiTAXYcjclmOljxxJnl1O50F5sOIi38vyl7Q63f6a3bXMvJEf1lnPNJKAxspIfEu8gRasny3FEsbHfrxEwVj rog@rog-x220 [16:33] rvba: rogpeppe [16:33] rvba: (i think - perhaps it's rogpeppe@gmail.com; i never know what launchpad expects) [16:34] rogpeppe1: you should be able to login now, I've imported the key you put on lp. [16:34] rvba: am logged in, thanks [16:34] remember you can just do `ssh-import-id rogpeppe` [16:34] That's precisely what I did. [16:39] hmm, the agent config file looks ok, but mongo auth as that agent fails. http://paste.ubuntu.com/5881424/ [16:39] and the log seems to indicate that the password for the MA was created correctly http://paste.ubuntu.com/5881429/ [16:42] rvba: are you using tip? [16:42] rogpeppe1: yes [16:43] rvba: revno 1464? [16:44] rogpeppe1: yes [16:48] rvba: i'll just check to see if it works under ec2 [16:49] hmm, looks like trunk is broken against the latest version of gwacl [16:50] rogpeppe1: yes, we're fixing this, use gwacl's revision number 182. [16:50] rvba: thanks. using that. [17:15] rvba: hmm, seems to work ok under ec2. can you reproduce the azure behaviour? [17:16] rogpeppe1: yes, I've tested it ~3 times this afternoon. [17:20] rogpeppe1: I'll try with a raring image right now. [17:20] rvba: please. i'm just trying ec2 with a saucy image (assuming it can find one) [17:22] oh bugger, forgot to use --upload-tools. discard as unverified all my previous assertions of okayness [17:23] darn, "no "saucy" images in us-east-1 " [17:24] i've reached eod and have to stop [17:24] rvba: please let me know how you get on with raring [17:24] rogpeppe1: will do… talk to you tomorrow! Thanks for your help. [17:24] rvba: no help as yet, i'm afraid [17:25] rvba: g'night all [17:26] nn rogpeppe1 === andreas__ is now known as ahasenack [17:53] rogpeppe1: works ok on raring. === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk [21:06] good morning [21:19] fark... bikeshed much? [21:43] thumper, heh, sorry, is that my reviews to which you refer? [21:44] fwereade: no [21:44]