[00:03] SGTM [00:08] davecheney: does lbox submit also send pending comments? [00:09] yes [00:09] * thumper pulls fwereade_'s latest commit and will rerun the tests before submitting [00:10] thumper, ah, sorry [00:10] fwereade_: np [00:11] fwereade_: it is only a few minutes... [00:14] hey fwereade_ did you get anywhere with the review on the maas branch? [00:14] thumper, I have endured worse test times than this... I've endured build times worse than these test times [00:15] fwereade_: so have I [00:15] I remember one bank I was at where the compile time was two hours [00:16] bigjools, I have been most remiss there -- it all looks essentially fine, but I have yet to step up and convince myself it all fits together [00:16] bigjools, I will do another pass [00:16] * bigjools had a 4 hour build once [00:16] ah wat? [00:16] * thumper sighs [00:16] lbox submit expects the prereq to be committed first [00:17] fwereade_: ok we're still making some changes to it, some as requested in the initial pass and others to actually make it work. I deployed a charm on my microservers yesterday! [00:17] half the point of a prereq is to get work reviewed independently of landing [00:17] thumper: of course [00:17] that's bollocks [00:17] bigjools, sweet! [00:17] * thumper goes to follow lbox's rules [00:17] thumper: lbox expects quite a few things that are unreasonable IMO [00:17] if you propose the chain A -> B -> C [00:18] i don't think it is unresonable to expect A to land beore B, etc [00:18] I think it is unreasonable [00:18] if C has B and A, then C will implicitly land them [00:18] what if A isn't complete? [00:18] or doesn't make sense without B? [00:18] then that isn't a prereq in the sense that lbox undestands [00:18] in which case lbox is dumb [00:19] * davecheney is not fucking arguing about the tools today [00:19] :) [00:19] careful thumper, you don't want to be accused of bitching [00:19] :P [00:20] * thumper merges before heading into town for lunch and errands [00:23] thumper: Tools: newSimpleTools("1.2.3-linux-amd64"), [00:23] this will make you mad [00:23] what series are these tools ? [00:23] no wait, they are the linux series [00:23] linux of course [00:23] :) [00:23] larakin linux [00:24] * davecheney fixes that shit [00:24] * thumper waits for lbox to do its slow merge [00:24] * thumper bitches [00:24] and done [00:24] * thumper heads to lunch === thumper is now known as thumper-afk [01:03] bigjools, ok, I think I've finished the review [01:03] bigjools, I whine about lots of things but basically I want it to land [01:05] davecheney, I don't suppose you're just putting the last finishing touches to a https://codereview.appspot.com/8545043/ review? :) [01:08] fwereade_: sorry, i was not [01:08] it looked really large [01:08] so I was selfishly noodling with my own brach [01:08] branch [01:09] davecheney, no worries -- but it's a bit less bad than it looks, honest :) [01:09] fwereade_: you -> sleep, will review after lunch [01:09] * davecheney goes back to fighting with the cloudinit checkers [01:09] map[interface{}]interface{} can bite me [01:09] * fwereade_ goes off to sleep :) [01:10] * fwereade_ solemnly advocates killing it with fire [01:22] fwereade_: thanks [01:25] not sure I will ever get used to "if" preconditions [01:25] pre-statements even [01:28] constraints_test.go:283: // A failure here indicates that goyaml bug lp:1132537 is fixed; please // delete this test and uncomment the flagged constraintsRoundtripTests. c.Assert(val.Hello, IsNil) [01:28] ... value *string = (*string)(0xc20006b4d0) [01:28] whut ? [01:29] I guess I need to merge to trunk [01:29] are there plans to introduce library versioning into Go at any point? === thumper-afk is now known as thumper [01:30] bigjools: nothing has been discussed on the list [01:30] davecheney: there was a list thread about pulling the latest goyaml [01:31] yeah, i did that [01:31] but the failure above sounds like the opposite [01:31] i've just merged trunk [01:31] i think that has fixed it [01:32] cool [01:54] juju debug-log is awesome [01:55] i can watch everything happening in an environment [02:03] shit [02:03] Proposal: https://code.launchpad.net/~dave-cheney/juju-core/113-juju-bootstrap-raring-cloudinit-II/+merge/158263 [02:03] error: Failed to send patch set to codereview: can't upload base of environs/mongo.go: ERROR: Checksum mismatch. [02:04] ^ i deleted them added this file during the branch [02:04] now it is really upset [02:04] any suggestions [02:04] huh? [02:04] you removed a file? [02:04] and it is complaining? [02:04] then I added it back [02:04] as in copied it from another branch [02:05] oh... [02:05] not so good [02:05] fuckit [02:05] it will complain about file-ids [02:05] can't you just do a reverse merge of the revision that deleted it? [02:05] and discard everything else? [02:06] i'll figure it out [02:13] screw it, just importde the diff into a new branch [02:21] davecheney: you can delete merge poposals in LP [02:21] instead of rejecting them, (if you like) [02:22] thumper: too late now [03:48] davecheney: hey... gotta sec? [03:48] having an hp problem 'error: cannot log in to admin database: auth fails' [03:50] status -v (http://paste.ubuntu.com/5697341/) shows I'm connecting, but... [04:29] m_3: sorry that environment is stillborn [04:30] grab /var/log/cloud-init-output.log from the first machine [04:30] then destroy the environment [04:30] davecheney: ok, lemme look [04:32] davecheney: that log looks normal [04:32] davecheney: and I can ssh to the box [04:33] davecheney: ubuntu@15.185.162.247... your keys are there [04:34] if you have a sec to help, I'm trying to set up a scale-test environment [04:47] nm, I'm just using that instance to test from there [05:01] davecheney: what would your first thought be if I said I wanted "environment: whatever" as the first line of `juju status` ? [05:02] personally I think it is crazy we don't have this in status somewhere [05:02] yeah, it's not even in there huh [05:07] hmm... [05:07] * thumper takes it to the list [05:07] I would just do it [05:07] but it seems that some people get hung up with backward compatability [05:07] but it would be nice to see something while it waits for bootstrap to finish... [05:08] Ha! ok, that's funny, I figured for sure that'd be in the juju-0.6 status [05:08] most of the time you're sort of filtering status output anyways [05:09] the machine ids up top are just noise normally [05:09] but yes, it absolutely needs the current JUJU_ENV imo [05:10] m_3: feel free to comment on my email message then :) [05:16] m_3: checking [05:17] m_3: 2013/04/11 04:09:32 JUJU jujud machine command failed: state entity name not found in configuration [05:17] error: state entity name not found in configuration [05:17] ok, this broke because there is no 1.9.13 tools for hp [05:18] davecheney: np... I think I worked around it [05:44] jam gz: caused by: https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/17031369947864/servers%!(EXTRA string=Resource limit exeeded at URL %s., string=https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/17031369947864/servers) [05:44] ^ is there a bug about this format string snaffu ? [05:46] * thumper off swimming, back for the meeting === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: | Bugs: 0 Critical, 52 High - https://bugs.launchpad.net/juju-core/ [05:55] mornin' all [05:56] rogpeppe: moning [05:56] morning [05:56] davecheney: yo! [05:56] davecheney: how's tricks? [05:56] good! [05:57] davecheney: i could do with another review on https://codereview.appspot.com/8626044/ if you fancy it [05:57] wrap your peepers around this, https://codereview.appspot.com/8648043/ [05:57] davecheney: swap ya! [05:57] * davecheney looks [06:06] davecheney: nice! reviewed. [06:07] rogpeppe: and to explain myself in my review of your code [06:07] i'm concerned about the magic strings [06:07] "machine-password" [06:07] not becuse they are secrets [06:07] just appear to be test warts [06:07] davecheney: they're only magic in tests [06:07] as you said on the other CL yesterday [06:08] so why not change SetPassword(string) to be ResetPassword() -> string, error [06:08] then it tells you what the password is [06:08] and we don't have to add even more fixtures [06:08] davecheney: are you talking about state.User.SetPassword there? [06:08] yes [06:09] davecheney: no can do [06:09] why not [06:09] davecheney: the whole point is that we're setting the password from the admin-secret in the environment config [06:09] ok fine [06:10] objection withdrawn [06:10] davecheney: cool [06:11] davecheney: your point about possibly leaving a blank password on the admin user is a good one, i think, *because* we don't abort the bootstrap init process if juju bootstrap-state fails [06:11] davecheney: i think we should [06:11] davecheney: i've thought for a while now that we should do "set -e" at the start of the cloudinit script [06:11] davecheney: what do you think? [06:11] if you just did AddUser("admin", $random) that would solve the problem [06:11] the user is created, but nobody knows the password [06:11] would that work ? [06:12] davecheney: i'd prefer to solve the deeper problem [06:12] davecheney: why are we even running the machine agent if the initial set up has failed? [06:12] sounds like a reasonable question [06:12] none of those cloud init steps are optional [06:12] davecheney: exactly [06:14] davecheney: i might change cloudinit to make each command do foo || error foo failed >&2 [06:14] davecheney: that way you won't have to infer the failure in the logs from the command's stderr output [06:15] doesn't cloudinit send &1 and &2 to /var/log/cloud-init-output ? [06:17] davecheney: yeah, the &2 is probably unnecessary, just habit [06:18] davecheney: maybe just set -ex actually [06:23] davecheney: does that sound reasonable to you? [06:24] niemeyer: hiya! bit early for you, ain't it? [06:24] rogpeppe: Nope.. it's actually very late :) [06:24] niemeyer: :-) [06:24] niemeyer: squalling bairn? [06:25] rogpeppe: Have been cooking a release of mgo fixing a cluster resync bug, and spent some hours on it [06:25] niemeyer: cool [06:25] Just about done now [06:25] niemeyer: the resync code is quite subtle, i thought [06:28] rogpeppe: Yeah, real world is not so friendly [06:29] rogpeppe: Servers popping in and out with their own ideas of what they should be doing is fun [06:29] niemeyer: while you're about it, it would be nice to have the redial interval configurable. we're hacking around it currently by sleeping in Dial) but i think the right place is in mgo. [06:30] rogpeppe: What's the issue? [06:30] niemeyer: by default, mongo dials about 10 times a second. [06:31] niemeyer: that's not great when you're waiting for a server to come up. [06:32] rogpeppe: Where does it do that again? [06:32] niemeyer: the logic is scattered [06:33] niemeyer: the emergent behaviour is that it dials 3 (5?) times then sleeps for a bit (0.5s ?) then repeats [06:33] rogpeppe: Ah, right [06:33] niemeyer: i've been through the logic and understood it a few times, but i always forget immediately afterwards :-) [06:34] rogpeppe: It's that retry that I always forget to count [06:34] rogpeppe: I think we could just take that out.. [06:34] rogpeppe: But, not today [06:35] niemeyer: indeed [06:35] niemeyer: our hack works ok for the time being [06:35] rogpeppe: Will keep that in mind [06:35] niemeyer: some time, an bounded exponential backoff would probably be good. [06:35] niemeyer: so we don't suffer too badly from the herd effect after a network outage. [06:38] rogpeppe: This will probably never happen [06:38] niemeyer: ok. too hard? or just not the right thing to do? [06:38] rogpeppe: A database driver is something you want connected as soon as the network is bac [06:38] k [06:39] rogpeppe: But more reasonable timings is a good idea [06:39] niemeyer: if the max bound was only a small number of seconds, it would still be ok. [06:39] rogpeppe: Sure, but it would also be fairly irrelevant I suppose [06:40] niemeyer: i'm not sure. if the network goes down, we don't really want all the clients dialling in synchrony [06:40] niemeyer: the exponential backoff (with a random element) can allow a good spread over time, i think. [06:40] rogpeppe: Perhaps.. it depends on the scale and on the application behavior [06:41] niemeyer: indeed [06:41] rogpeppe: The random element is somewhat unnecessary as well.. they're not wall-clock synchronized [06:42] rogpeppe: This would only be really effective if we allowed the backoff to actually backoff [06:42] niemeyer: if they all see the net go down at the same moment, they all redial immediately and they're all sleeping for the same amount of time, i suspect they'll keep reasonably clustered. [06:42] rogpeppe: Like, spanning through several tens of seconds [06:42] niemeyer: the only random element i'd add would be the first sleep interval. [06:43] 2013/04/11 06:43:16 ERROR JUJU:jujud:machine cmd/jujud: upgrader loaded invalid initial environment configuration: required environment variable not set for credentials attribute: User [06:43] any ideas ? [06:44] rogpeppe: I guess I could put something intelligent based on the number of clients [06:44] rogpeppe: and have the backoff take that into account [06:44] niemeyer: that sounds like a great idea if you have that info [06:44] rogpeppe: Yeah, I think it's around in the server [06:45] davecheney: interesting [06:45] Either way, that's the kind of bug I'd love to get someone complaining about :-) [06:45] niemeyer: lol [06:45] rogpeppe: environment still appears to work [06:45] this is in HP [06:45] we don't need that attr in ec2 [06:45] davecheney: ah. [06:45] davecheney: yeah, i wondered [06:45] Most people that use mgo heavily do so on the basis of a few machines [06:45] millions of requests a days, but just a few servers [06:45] i wonder if this is part of our 'don't upload the secrets' logic [06:46] niemeyer: well, we are going to move in that direction [06:46] davecheney: Heya [06:46] davecheney: it's possible. is this with the openstack driver? [06:46] * davecheney waves [06:46] rogpeppe: Yeah, I have my fingers crossed to have a Critical filed! ;) [06:47] niemeyer: so far the API seems to be working quite well [06:47] niemeyer: although none of the agents are using yet [06:47] Alright, I really need to sleep now, or I won't wake up in time for the meeting in a few hours [06:47] it yet [06:47] niemeyer: sleeeeeeep.... [06:47] have a good Beginning Of Day folks [06:47] niemeyer: you too [06:47] niemeyer: well, a good sleep anyway :-) [06:47] Thanks :) [06:48] https://bugs.launchpad.net/juju-core/+bug/1167723 [06:48] <_mup_> Bug #1167723: environs/openstack: error relating to upgrader on bootstrap node < https://launchpad.net/bugs/1167723 > [07:38] jeeze, i'm not surprised some of the live tests fail. having started an instance, it didn't see that instance when asking for it, even when waiting a whole 10 seconds later. [07:38] how the f*!@# can we make this stuff really reliable? [07:41] rogpeppe: increase timeouts and wait more? [07:41] dimitern: i'm just trying with a 20s timeout [07:41] dimitern: but really, if 20s why not 5 minutes? [07:41] rogpeppe: :) seriously? [07:41] dimitern: i've no idea [07:42] dimitern: i don't know what's happening inside amazon [07:42] rogpeppe: would it affect local live/other tests? [07:42] dimitern: yeah. [07:43] rogpeppe: btw a short and quick review? https://codereview.appspot.com/8630043/ [07:43] dimitern: any time you're expecting an error, you'd need to time out the max amount [07:43] dimitern: looking [07:46] dimitern: i just saw the same thing happen even when waiting for 20 seconds [07:47] dimitern: i guess i should check our logic again. although it succeeds sometimes, it's possible we're getting something wrong somehow. [07:51] rogpeppe: is there any way to log the communication between the client and ec2? [07:51] rogpeppe: sgtm [07:51] TheMue: yeah, we can do that [07:53] rogpeppe: fine, maybe we just interpret the feedback wrong (or they changed a tiny bit in the protocol that's now fools our logic). [07:53] TheMue: it's possible, but slightly unlikely, as our logic does work... some of the time! [07:55] rogpeppe: that's what i meant, the difference between "working" and "done" if you only look at "done" but never interpret "working" (w/o knowing the protocol) [07:56] rogpeppe: me knowing the protocol [07:56] TheMue: i'm pretty sure it's sending exactly the same request each time [07:56] TheMue: (i'm just checking that) [07:57] rogpeppe: the client is sending the request, but i'm more interested in ec2s answer [07:57] TheMue: yeah [07:58] can someone send me the g+ link for the meeting? [07:58] https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.gdt9rkp5uspih9n3db6b95kccc [08:02] ha! found the bug! [08:02] TheMue: our own logic *was* screwed [08:08] mramm, ping [08:08] mramm: bleep bleep bleep :-) === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: - | Bugs: 0 Critical, 53 High - https://bugs.launchpad.net/juju-core/ [08:23] rogpeppe: I have an issue with m.SetAgentAlive() - returns no error, I can see the pinger starting in the log, but pwatcher.Alive(m.globalKey()) returns false (that's what m.AgentAlive() returns), even after a timeout of 5s or using m.WaitAgentAlive(), still fails - any clues? [08:23] dimitern: you'll have to debug it i'm afraid [08:24] rogpeppe: bugger.. ok, I though I might be missing something obvious [08:24] dimitern: check out the pinger tests [08:48] rogpeppe: i'm getting this every time I run the machiner tests: [LOG] 20.79113 NOTICE juju: authorization error while connecting to state server; retrying [08:48] rogpeppe: and then it reconnects and continues [08:48] rogpeppe: could it be an indication why the pwatcher is not working right? [08:53] rogpeppe: I found it! so adding mr.st.StartSync() in the MA code (not tests) after calling SetAgentAlive() the tests pass [09:05] why did i ever have to call this? i though it was for tests only [09:10] hello all [09:10] I am very sorry I missed the meeting! [09:12] mramm: hiya [09:13] mramm: it went well, we even took notes: https://docs.google.com/a/canonical.com/document/d/1tKtAcrz9ADGF-o6lQtmGKYRf2ZHIR7lb-WctXvcLnfg/edit [09:13] I had the alarm set for the meeting, but it was set an hour late! [09:13] I am reading the notes now. [09:21] dimitern, it the machiner using the same *State as the tests? [09:22] dimitern, you shouldn't have to call StartSync usually, I don't think [09:22] fwereade_: probably not, because the tests use the jujuConn one [09:22] fwereade_: I had StartSync in both, but adding it the MA code and removing it from the test didn't cause failures, so I left it at that and submitted [09:23] dimitern, sorry, I don;t think that's ok [09:23] fwereade_: i'm open to suggestions [09:24] fwereade_: why do you think that? [09:24] dimitern, ok, does SetAgentAlive work in practice? it when you do juju status against a live environment, does it work? [09:25] dimitern, because Sync and StartSync are purely for the convenience of tests AFAI am aware [09:25] fwereade_: in order to test this, I need to finish the status CL, then I'll test it live [09:26] dimitern, hmm, is this the tests for the actual machiner, or for the machine agent? [09:26] fwereade_: machiner [09:27] So, from the notes it seems to me like we ought to call this next release 1.10.0 and that we should try to do a release as soon as it is possible to do the python+go thing [09:27] it will have some bugs, which we should focus on fixing for the next few days, and release 1.10.1 early next week [09:28] mramm, +1 [09:28] fwereade_: sorry, I keep mixing "task" and "agent", even though now I know the difference :) [09:28] dimitern, don't worry it still bugs me [09:28] dimitern, but ok I think I know what the problem is, just a mo [09:29] this weekend should be the aim for python+go release testing [09:30] the python code is in review for including in raring, and the go part should be ready to go after that [09:30] My long term proposal would be that we do a "stable" release at the end of the month every month, and then switch to an unstable number for dev versions for weekly releases within that month. [09:31] mgz: that sounds reasonable [09:31] mramm: +1 [09:32] we should then try to come up with some good ways to test that the 1.10.x to 1.12.x release goes smoothly. [09:33] dimitern, ok, the problem is that StartSync needs to be called after SetAgentAlive to get a timely response, but that the test doesn't have an obvious way of knowing when that's happened [09:33] From the notes: "John: It will be parallel installable and easy to remove; they can’t easily bootstrap" [09:33] what's the second part mean? [09:34] Also, can't we do this for them: "We need to make it clear that they need to set up a completely fresh directory structure for juju2" [09:34] dimitern, I think the right thing to do is to SS in the test every 50ms while waiting for WaitAgentAlive in another goroutine and sending the result out into the same select you're using for the SSs [09:37] fwereade_: I tried that as well, didn't work [09:38] fwereade_: oh, wait - I didn't try a separate goroutine [09:39] fwereade_: let me just finish the status CL and I'll test it live as is first [09:41] dimitern, ok cool [09:41] * dimitern machine needs a restart I think, bbiab [09:58] fwereade_: progressing steadily with our provider feature branch — thanks again for the reviews. We have some things that are unclear though. Could you comment on https://code.launchpad.net/~maas-maintainers/juju-core/maas-provider-skeleton/+merge/157025 and specifically the latest comments by Raphaël? [09:58] jtv, sure [09:58] Thanks [10:14] jtv, I think I've covered it, let me know if I missed something [10:14] jtv, awesome that you got a deploy working :) [10:15] fwereade_: thanks for your reviews. [10:15] fwereade_: looking now... Thank rvba for getting the deployment running! [10:15] rvba, thanks for the deployment! [10:15] ;) [10:16] rvba, let me know if anything needs clarification [10:16] interesting, i just saw a real-world failure caused by a temporary provisioning failure: [10:16] 2013/04/11 09:54:08 ERROR JUJU:jujud:machine worker/provisioner: cannot start instance for machine "1": cannot run instances: The service is unavailable. Please try again shortly. (Unavailable) [10:17] * rogpeppe has finally submitted those ec2 expenses [10:17] * rogpeppe hopes it's not too late [10:18] f@$%! time zone issues with both g calendar and thunderbird [10:19] fwereade_: so the problem is not only with tests [10:20] rogpeppe, cool [10:20] dimitern, oh yes? [10:20] fwereade_: w/o SS in M's loop(), I'm not even getting AgentAlive() -> true, nil right after calling SetAgentAlive() with no error [10:20] dimitern, that's expected [10:21] dimitern, the MA doesn't need to detect it's made itself alive [10:21] fwereade_: or, after using WaitAgentAlive for 5s [10:21] fwereade_: i'm confused now [10:21] fwereade_: i think that just having the pinger around should cause AgentAlive to return true, no? [10:21] dimitern, are you sure about the presence timeout being 5s? [10:22] rogpeppe, hmm, ok, that is an interesting point [10:22] fwereade_: I gave it 5s [10:22] dimitern, but where are you asking AgentAlive()? [10:22] dimitern, sorry, I mean the underlying pwatcher refresh frequency [10:23] fwereade_: I had the following (all combinations tried): SAA() -> no error, WAA(5s) -> timeout, AA() -> false, nil (after SAA()) - that's all without SS after SSA() [10:23] dimitern, when and where are you making these calls, in response to what? :) [10:23] fwereade_: with SSA() + SS() all works [10:23] dimitern, maybe we should g+ [10:24] * fwereade_ starts one [10:24] fwereade_: in the beginning of the loop,before settings status [10:24] fwereade_: sure [10:30] dimitern: if what you're saying is true, surely the presence tests would fail? [10:34] rogpeppe: I got it working, just a sec [10:47] davecheney: oh, almost missed it. happy birthday. [10:49] TheMue: thanks mate [10:51] davecheney: yw, 3h left. and hey, you should party, not being here online ;) [10:53] TheMue: party on the weekend [10:54] davecheney: i would like to join, sadly got no time. *cough* *cough* [10:57] * TheMue steps out for lunch, biab [11:03] fwereade_: while i'm on to this, how about doing the same with the "down" state for units: "status: info" (regardless of the status, not only on error, and include info only when != "")? [11:04] fwereade_: agent-state-info, that is [11:24] fwereade_: anyway, PTAL https://codereview.appspot.com/8561046/ [11:25] dimitern: what was the problem BTW? [11:25] rogpeppe: not really sure, but the difference between state.Sync() and StartSync() made the difference [11:25] rogpeppe: that a look, if you want ^^ [11:28] dimitern: are you saying it worked with StartSync but not with Sync? [11:31] rogpeppe: i'm saying the other way around [11:31] dimitern: but in the CL you're using StartSync, no? [11:32] mgz: poke for standup [11:32] dimitern: it shouldn't make any difference, given that you're doing WaitAgentAlive anyway [11:32] rogpeppe: in the machiner CL yes, but now in the one above I changed it to how it should be (not to use StartSync() in the code, just call Sync() in the test, and it passed) [11:33] dimitern: oh, you were calling Sync in the *code*... i see [11:33] rogpeppe: :) yeah [11:33] rogpeppe: i'm testing it live on ec2 now and it seems to work fine [11:33] dimitern: but i was just looking at the one above, and it calls StartSync not Sync [11:34] dimitern: but that's fine - it shouldn't make a difference [11:34] allenap: is mgz with you? [11:34] rogpeppe: are you sure you're looking at the right one? https://codereview.appspot.com/8561046/diff/11001/worker/machiner/machiner_test.go [11:35] dimitern: ah, i was looking at status_test [11:35] dimitern, LGTM [11:36] fwereade_: cheers, I'll make the changes and submit it soon [11:36] fwereade_: and then i'll need some direction on the deuglifying the logs [11:37] dimitern, it's in the card [11:37] dimitern, drop the JUJU: badge throughout, and drop all package name prefixes from "main" packages (leave others intact) [11:37] fwereade_: ah, ok - so only main packages [11:37] dimitern: so when you used StartSync in the machiner test, it failed? [11:37] fwereade_: I though it was to generally reduce the JUJU strings [11:38] rogpeppe: yeah [11:38] dimitern: hmm, that seems fragile. [11:38] dimitern, this gives us reasonably sensible output as feedback without sacrificing logging clarity, I think [11:38] rogpeppe, I forget why but AgentAlive tests all seem to use sync [11:38] rogpeppe: I reckon because Sync() is synchronous, while StartSync() is not [11:39] rogpeppe, possibly I never knew why, IIRC gustavo did the whole presence system [11:39] dimitern: i know that, but even synchronous just means "delivered *somewhere*" [11:39] dimitern: not necessarily acted on [11:39] dimitern: so if it was racy with StartSync, it's probably racy with Sync [11:40] dimitern: i'll have a quick check in the presence code [11:40] rogpeppe: cheers [11:44]