[00:53] wallyworld_: ping [00:54] otp, sec [01:01] thumper: hi [01:01] wallyworld_: hey [01:01] wallyworld_: how are things with you today? [01:01] not too bad. doing some refactoring as per code review comments. but main issue is a failing test i have no farking idea what's wrontg [01:04] wallyworld_: want to hangout? or are you focused? [01:04] i can do a call [01:04] you have a url handy?\ [01:06] nope, will start one [01:06] https://plus.google.com/hangouts/_/871ae6be4b5cd1f19de181069ba7255665b21443?hl=en [01:28] thumper: https://codereview.appspot.com/9886045 [02:16] * fwereade__ is up way past his bedtime, and has just proposed a reasonably monstrous pipeline, and would be ever so happy if he woke up tomorrow to some reviews from thumper and/or wallyworld_ [02:16] * fwereade__ will probably be late in tomorrow [02:16] fwereade__: hi there [02:16] fwereade__: sure [02:16] fwereade__: saw them incomming [02:16] cheers [02:16] gn :) [02:16] night [02:17] fwereade__: i'll ping you tomorrow if i can't get my stupid test to pass [02:17] talk later [02:17] wallyworld_, sorry, never got round to that -- definitely let me know tomorrow [02:17] will do. good night [02:38] thumper: found why the two tests were giving different results - stupid typo. now to fix the failure [02:38] haha [02:39] fo [02:48] wallyworld_: I have something for you [02:48] yeees? [02:48] wallyworld_: what does a container instance of a *state.Machine give for the result of a Tag() call ? [02:48] does it special case anything? [02:49] not that i have implemented [02:49] wallyworld_: you'll need to tweak it [02:49] i haven't changed the Tag() method [02:49] wallyworld_: as the result of Tag() should be something that works for a filename [02:49] machine-0/lxc/1 isn't good [02:49] replace('/', '-' [02:49] i had ":" as the separator [02:49] yeah, I know [02:49] we can blame fwereade__ for that [02:50] ok, will tweak the Tag() method, thanks for letting me know [02:50] wallyworld_: can I count on you fixing that for me? [02:50] np [02:50] yep [02:50] wallyworld_: I'm getting my head around all this cloudinit stuff [02:50] now that I realise that the user-data is the yaml file, things are easier [02:50] I was trying to find the missing step [02:50] yeah [02:51] i knew that much not not too much extra [02:51] but not [02:51] * thumper nods [02:51] I'm starting to feel more comfortable about implementing this lxc-broker now [02:52] I feel I know more about WTF is going on [02:52] cool [03:31] wallyworld_: do you know how to use the api? [03:31] wallyworld_: I want to start using that instead of *state.State [03:31] if possible [03:32] we should have something that returns me a *state.Machine right? [03:32] thumper: not really. i've not written code that uses it. perhaps look at the tests to see what is done? [03:32] or should I not bother yet [03:32] I have too many other things to worry about just now [03:32] will leave a TODO for now [03:32] sure. let's make sure we fix that one soon though [03:40] wallyworld_: yes, agreed === tasdomas_afk is now known as tasdomas [04:48] * thumper stops hacking to do some reviews for fwereade__ [05:23] fwereade__: left the last two as an exercise for some europeans :) [05:23] * thumper is done for today === danilos_ is now known as danilos [07:57] morning danilos [07:57] jam: morning [08:07] mornin' all [08:08] morning [08:08] somehow my provider dislikes me this morning *hmpf* === TheRealMue is now known as TheMue [08:57] fwereade__: ping [08:59] danilos: do you have a hardware switch on your mic [08:59] jam: no [08:59] jam: it just died [08:59] fwereade__: oh, technician rings at the door, bbiab [08:59] jam: it's not showing in the "vumeter" [08:59] TheMue, heyhey [09:01] jam: it seems something got messed up in the USB stack, my mouse stopped working now [09:02] danilos: uh-oh, sounds like reboot is in order [09:02] jam: yeah :/ brb [09:03] I'll grab a snack, be back in a sec [09:09] danilos: welcome back [09:10] rogpeppe1, jam, TheMue: https://codereview.appspot.com/10083047/ and https://codereview.appspot.com/10166044/ are sizeable but important [09:10] fwereade__: so, back again, will take a look [09:10] fwereade__: thx for your review [09:11] TheMue, and what can I do for you? you pinged :) [09:11] fwereade__: yes, the first note "Should just be a straight rename of JobServeAPI to JobManageState." is not clear for me in that context. [09:14] TheMue, jobs are somewhat fluid and casual groupings of tasks; in the current intended model, the ManageState tasks include API-serving and txn-resuming (by necessity) and cleaning (by convenience/similarity of use case) [09:18] fwereade__: ah, so only JobManageState shall exisit in future and start all the according tasks. am i right? [09:19] TheMue, JobManageState should just be a direct replacement of JobServeAPI at this point [09:19] fwereade__: ok [09:20] TheMue, fwiw if you were to fix the watcher and just repropose the worker, I would be happy -- integration (and thus the jobs change) doesn't have to come in in this CL [09:20] TheMue, smaller, simpler, quicker to review, I think [09:20] TheMue, (and I'm sorry for dropping the ball on the watcher impl review) [09:21] fwereade__: it's ok. i had it this way earlier but changed it after a hint of dimiter. will now change it back again. [09:25] fwereade__, is it worth me raising a bug about $HOME not being set when hooks get run, or is it fair to say it's not there for a reason? [09:25] fwereade__: "Clients are expected to parse their own damn data ..." *hehe* [09:26] mattyw, I would *prefer* to only guarantee the existence of the env vars we produce ourselves [09:27] mattyw, let me just poke in and see if I can see what happened to it, though, just a sec [09:28] fwereade__, it's possible it might not have ever been there, It looked to me like it wasn't set in pyjuju either [09:30] mattyw, ok, it looks like it never was there [09:31] fwereade__, ok thanks [09:32] mattyw, I *might* be conviced that we should pass the whole shell environment down rather than constructing it from scratch (apart from $PATH, which we do copy down (with additions)), but I'd need a reasonably significant use case [09:33] mattyw, feels somewhat nicer to run in as controlled an environment as possible though [09:35] Makyo, ping -- I would appreciate your eyes on https://codereview.appspot.com/10166044/ -- it includes the stuff we discussed yesterday [09:37] fwereade__: i think we should pass the whole shell environment down === tasdomas is now known as tasdomas_afk [10:12] jam, all: heya, how do I run the live tests? I had it written down somewhere, but can't find it now [10:13] danilos: you go to each provider, cd environs/openstack; go test -live; cd environs/ec2; go test -amazon [10:13] you need to source your credentials into the environment first [10:13] jam: it's fine to keep it in ~/.juju/environments.yaml or do I really need to put them into environment variables? [10:13] danilos: I don't think the test suite looks at environments.yaml [10:14] jam: ack, thanks === tasdomas_afk is now known as tasdomas [10:31] * TheMue is at lunch [10:33] jam: I am trying with ec2 first, but "go test -amazon" doesn't work (it seems AWS_SECRET_ACCESS_KEY is being unset somewhere where it shouldn't be, since setting both through EC2 envvars makes it go past that point, but then tests fail which expect access keys to be wrong) [10:35] jam: fwiw, this is what I had: http://pastebin.ubuntu.com/5754428/ [10:35] danilos: if you are running the ec2 tests, I know you'll need to also do '-test.timeout=7200' or something like that, as the test suite is quite slow. [10:36] that isn't your specific problem [10:36] but you'll run into that in 5 min [10:36] (the default timeout for the test suite) [10:36] jam: right [10:37] danilos: so I just sourced my ec2creds which only sets "AWS_ACCESS_KEY_ID" and "AWS_SECRET_ACCESS_KEY" and go test is happy [10:40] danilos: you might want to check the spelling of your env variables, as the above ones aren't very obvious for me. [10:40] laptop just crashed for the 4th time in two days [10:40] and lost another couple of hours' work dammit [10:42] jam: I did, I'd hope copy-pasting from goamz/aws/aws.go should do it as a check :) [10:42] right [10:42] rogpeppe: just in your editor buffer? wouldn't it at least be on disk? [10:43] jam: i hadn't saved, stupidly [10:43] * rogpeppe goes to change the editor so that this doesn't happen again [10:43] danilos: I can confirm your bootstrap-verify branch (as when we started) is passing the test suite. "BootstrapAndDeploy" takes 421s to complete, though. [10:43] rogpeppe, hey, emacs auto-saves stuff for you [10:44] eheh, stop trying to convert people to your religion [10:44] jam: I am having the same problem with trunk [10:44] mgz_, just sayin' :P [10:44] mgz_: /wave [10:44] danilos: yeah. this should too - there's a Dump function that saves the current working state, but it's not called automatically [10:44] danilos: well, I do a pretty heavy cycle of running the test suite, which requires saving often [10:45] jam: me too, I even commit with each new test/function added ;) [10:46] danilos: yeah, I'm often the same [10:47] jam: any ideas if I am doing something blatantly wrong: http://pastebin.ubuntu.com/5754461/? [10:49] danilos: my goamz was a bit older, I just updated and will see if that breaks my stuff [10:49] jam: thanks [10:50] nooo, the drilling on the floor up returns [10:50] danilos: I get a lot of failures just running 'go test ./...' in goamz, does it pass for you? [10:50] TestMultiComplete fails for me. [10:51] a lot of "SpecifiedBucketDoesNotExist" log messages. [10:51] jam: yeah, for me as well with r37: http://pastebin.ubuntu.com/5754474/ [10:59] danilos: on the plus side, it has been failing for a while :) [10:59] r35 also fails for me [11:01] danilos: I see the same failure you had until I source my credentials. [11:01] Are you sure you exported them correctyl? [11:09] danilos: when I source my creds again, it starts passing, even if goamz doesn't work. [11:13] jam: http://pastebin.ubuntu.com/5754519/ [11:13] jam: I am not sharing my keys with you, but even echoing $... does show them [11:13] danilos: sure 'set' sees it, but are they exported? [11:14] I don't know if you are using bash [11:14] but you can do: [11:14] FOO=xxyy [11:14] but you need to do [11:14] export FOO [11:14] for child processes to see it [11:16] jam: that was it :/ ta [11:16] danilos: I'm glad it helped [11:16] jam: I thought I tried with passing them right before the "go test", when it's passed down [11:17] danilos: AWS_XXX=YYYY go test ? [11:17] I think that should wok [11:17] work [11:17] jam: it was confusing that it actually failed on ACCESS_SECRET_KEY, but not on ACCESS_KEY_ID which was checked for first [11:17] jam: yeah, I know [11:30] danilos: hangout time? [11:30] you can at least join to listen in [11:54] jam: [11:54] state_test.go:1107: [11:54] c.Errorf("mgo.Dial only paused for %v, expected at least %v", t1, 3*retryDelay) [11:54] ... Error: mgo.Dial only paused for 500.800787ms, expected at least 1.5s [11:59] hm, environs/azure seems to break the build? [11:59] fwereade__: ^am I missing something or should this get pulled out for now? [12:00] one question about the live tests: if I interrupt the test run with C-c, does that mean I might have instances that keep on running? [12:01] mramm: are you awake yet? :) [12:01] danilos: potentially, tests should be capable of not leaking resources, but do you trust them to be robust like that? :) [12:01] mgz_, fwereade__: I'm pretty sure we need to roll back the azure change because it breaks 'go build' [12:01] mgz_, tbh, no :) [12:02] you'll want the eucatools stuff or similar to inspect left over instances/secgroups etc [12:02] jam: yep, I'm here [12:02] wallyworld__: I should probably have posted to the mailing list when I updated for the newer mgo, I had run into it the other way (updated mgo, the *other* tests were failing) [12:02] mramm: I'm here: https://plus.google.com/hangouts/_/e6b23e6c7391c8641a3b6660495f8fe7055e1884 [12:02] danilos: yes, and in fact, I've seen unclean shutdowns without killing the test suite. [12:03] So generally, check if you have instances running [12:03] jam: no problem. i wonder why the version (v2) stayed the same even though the changes were not backwards compatible semantically [12:03] wallyworld__: technically the APIs are stable, it just added a Sleep internally [12:03] tests that depend on time.Now are a bit broken anyway [12:04] IMO [12:04] but the behaviour changed [12:13] jam: ok, the tests pass with canonistack as well; now, I wonder if anybody knows how to choose lcy02 for https://dashboard.canonistack.canonical.com/ [12:13] mgz_: ^^ ? [12:14] people use dashboard? :) [12:16] mgz_, huh, was that not a change in response to an mgo change? are you definitely up to date there? [12:16] danilos: so, no, not sure, you can ask in the internal support channel, or use python-novaclient commandline tools which pay attention to the env variables you set [12:17] jam, mgz_: grar, I did specifically lgtm it with a "make sure it builds" [12:17] mgz_, heh, I was taking a look and noticed that none of my instances showed up in there [12:17] there may be another endpoint for lcy02 [12:18] fwereade__: yep, I saw that [12:18] and I was surprised [12:18] jam, if no more tan I have seen has happened, yes, please revert it [12:18] fwereade__: sorry, probably crossing converstions here [12:19] fwereade__: ian's test failure was a mgo thing, trunk not building is the azure stub [12:19] mgz_, ok, we should indeed revert the azure stub if it doesn't build [12:21] mgz_, the wiki page talks about choosing a different region in the drop down when logging in, a shame there is no such dropdown :) [12:21] :D [12:21] fwereade__: all reviewed i think [12:21] mgz_, ah, there's also a "lcy01 is the only available region in the dashboard" [12:21] now back to try and remember the code i wrote this morning :-( [12:22] rogpeppe, lovely, ty [12:22] rogpeppe, nothing more joyous than having to rewrite the code from memory (it is still fast, but very annoying) [12:22] mgz_, jam, has anyone proposed a revert? [12:23] fwereade__: proposed [12:23] danilos: yeah. it's the comments in particular i find annoying, when you've spent a while thinking of a good turn of phrase and it's all gone [12:23] mgz_, approved on trust that it does what you say it does ;p [12:24] https://codereview.appspot.com/9714046/ [12:27] mgz_: LGTM trivial [12:28] mgz_: just make sure you poke jtv so he knows its happened [12:29] Argh. I forgot to compile before landing. And now I can't propose a fix because something else is broken. [12:29] rogpeppe, sorry, but you seem to have reviewed all the things that already had 2 LGTMs and skipped the one's that didn't [12:29] I thought I'd built it, and I didn't. *bash* *bash* [12:29] rogpeppe, good comments, appreciated very much [12:30] fwereade__: orly? i thought i'd gone through all the ones in activereviews [12:30] fwereade__: which ones have i missed? [12:31] fwereade__: (it's really not easy to work forward through reviews in a consistent way - i should have kept notes about which ones i'd done) [12:31] Does anybody know what the logger.Logf errors are about? [12:31] rogpeppe, https://codereview.appspot.com/10083047/ and https://codereview.appspot.com/10166044/ [12:31] rogpeppe, it is not impossible that you were looking at the "approved" section ;p [12:31] jtv, update launchpad.net/loggo [12:31] fwereade__: ah, i was indeed [12:32] fwereade__: doh [12:32] argh thanks [12:32] fwereade__: and one of them i'd even started and had a pending comment for [12:33] fwereade__: i started on that one and then realised i needed to go through the rest of the pipeline to get context [12:37] Will have a build fix up shortly. [12:38] mramm, are you ready for a random GUI person to descend upon the juju core daily yet, or should we wait another day? [12:39] sure [12:39] thanks [12:44] rogpeppe, no worries [12:47] Review needed for build fix: https://codereview.appspot.com/10184043 [12:47] Anybody available? [12:49] fwereade__: while changing test just one question. by coalescing events you mean multiple cleanups transaction lead to only one event? === teknico1 is now known as tekNico === wedgwood_away is now known as wedgwood [13:39] TheMue, yes I do, sorry [13:41] fwereade__: hmm, so outlined loop (I already used it before that way) does not coalescing events. [13:42] fwereade__: it simply fires each time. [13:45] fwereade__: e.g. I have two destroys w/o cleanup. here I get two events. [13:47] TheMue, that's fine if the first event was notified before the second occurred [13:47] TheMue, but if two events happen and then the client is notified, he should not be notified again [13:47] TheMue, I think the structure I showed you is pretty common among the watchers, isn't it? [13:48] TheMue, and apart from anything else [13:48] fwereade__: yes, that's why I used it first too. [13:48] fwereade__: but there is more effort e.g. when collecting and merging document ids [13:48] TheMue, if you don't read from channels you register with state/watcher, you block *all* watchers [13:49] TheMue, except that there is no effort in this case [13:49] TheMue, any change, flip the send bit on; any send, flip it off [13:51] fwereade__: dunno if I got you right.but let me propose the newest version so i can show you where i'm stumbling. [13:52] TheMue, sure, sgtm [13:56] fwereade__: https://codereview.appspot.com/10148045 is in, i removed the job integration too === teknico1 is now known as tekNico [13:57] fwereade__: in state_test.go line 1342ff I do the two Destroy() and then get two change events. [14:02] fwereade__, rogpeppe, mramm : hangout? [14:02] fwereade__, ack, looking. [14:37] TheMue, I don't think you can depend on getting exactly 2 events there; a correct implementation in combination with suitably pathological scheduling decisions could lead to the watcher read only completing once both the add and the remove are processed [14:38] fwereade__: hmm, could you please rephrase [14:41] TheMue, there are really 2 events happening, it is true [14:42] TheMue, and almost always, because they are somewhat separated in time and the machine is probably not working too hard on these tests, the watcher's client will have the opportunity to read those 2 events independently [14:42] TheMue, hmm, a thought [14:43] TheMue, how many do you get if you Sync first, rather than StartSync? [14:43] fwereade__: i'm listening ... [14:43] fwereade__: will test, one sec [14:46] fwereade__: yep, then it's only one [14:46] TheMue, ok, and that *could* happen with StartSync, it's just less likely [14:48] fwereade__: ah, now I understand, thanks. now I only have to see how to improve the testing for it. [14:52] TheMue, put a couple of notes on https://codereview.appspot.com/10148045/ [14:52] fwereade__: thank you === tasdomas is now known as tasdomas_afk [15:27] gaah, errors.NotFoundf appends " not found" to its message [15:28] this is not consistent with actual usage in general [15:30] NotFoundNamef("unit %q", unit) -> `unit "foo/2" not found` [15:30] NotFoundf("ping pong %q blah", unit) -> `ping pong "foo/2" blah` [15:31] would both be used [15:31] rogpeppe, do those names seem ok to you? [15:32] rogpeppe, errors.NounPhraseNotFoundf [15:32] ;p [15:32] fwereade__: i'd just have the latter. the " not found" suffix was only ever a convenience and i think it's no longer so convenient. [15:32] rogpeppe, an awful lot of places include that explicitly [15:33] rogpeppe, and they're either not tested properly or the tests are dumb because they're not catching "foo not found not found" [15:33] rogpeppe, actually that all collapses to "not tested properly" doesn't it [15:34] TheMue, mgz_, jam, danilos: any opinions on the above? [15:34] fwereade__: i see only three places that use NotFoundf("xxx not found") [15:34] fwereade__: and they all look like copypasta of the same code [15:35] fwereade__: i suspect i was probably responsible originally :-) [15:35] rogpeppe, heh, I saw 3 in the first dozen I looked at [15:35] rogpeppe, clearly my data set was too small :) [15:36] fwereade__: http://paste.ubuntu.com/5755219/ [15:36] rogpeppe, the other aspect is charm.NotFoundError [15:36] rogpeppe, they have custom messages that are quite nice [15:36] rogpeppe, and I'd quite like to keep them [15:37] rogpeppe, but the current NotFoundf seems like a good common case so it can should probably keep its name [15:37] rogpeppe, errors.NotFoundMessagef()? [15:37] rogpeppe, for the custom cases? [15:38] fwereade__: errors.NotFoundError{msg} ? [15:38] rogpeppe, the f is useful there too [15:38] rogpeppe, ah sorry mistook you [15:38] fwereade__: BTW there's an error field in NotFoundError which is never used [15:39] rogpeppe, ha [15:39] rogpeppe, best drop it then [15:39] fwereade__: same with unauthorized error [15:39] fwereade__: i think it's a hangover from its goose origins [15:39] rogpeppe, ok, I'll strip those too then, thanks [15:40] fwereade__: perhaps: have only one NotFoundf helper, same as current. but if you want to create a "not found" error with a custom message, do so. [15:41] rogpeppe, seems reasonable [15:41] fwereade__: some time i'll have some more time to work up my new errors package. it was going in quite a nice direction, i think. [15:42] fwereade__: i found that rather than error codes, a useful concept was a "diagnosis" [15:42] rogpeppe, sounds interesting [15:42] rogpeppe, there's definitely a lot of room for advancement in that whole field :) [15:43] fwereade__: so an error could change but its diagnosis might remain the same. and in particular, a diagnosis could be an error itself. so to find out if something's a not-found error, you might do errors.Diagnosis(err) == somepkg.ErrNotFound [16:00] rogpeppe, or indeed somepkg.ErrorHasSomeObscureProperty(errors.Diagnosis(err)) [16:00] rogpeppe, ofc the really hard part will be resisting the temptation to s/err/murder/ [16:01] rogpeppe, btw, another thing is really bugging me here [16:01] rogpeppe, NotFound vs Unauthorized [16:02] rogpeppe, can you think of any major consequences to s/Unauthorized/NotAuthorized/? [16:08] rogpeppe1, hey, UnauthorizedError *does* use the error field, but not in a very sane way [16:09] fwereade__: ah, i didn't notice [16:09] rogpeppe1, it's in state/open.go [16:09] rogpeppe1, ISTM that the first usage is clear gibberish [16:09] rogpeppe1, and the second one has no reason to keep the error lying around [16:11] fwereade__: yeah, they both look dodgy to me [16:12] rogpeppe1, ok, it's used so little I'm going to make it consistent, if you have no objection to "not authorized" supplanting "unauthorized" [16:12] rogpeppe1, the second one looks like it has a purpose tbh [16:12] fwereade__: yeah, i was just thinking that [16:13] fwereade__: but perhaps it should be: "cannot log in to juju database: not authorized: %v" [16:13] rogpeppe1, NotAuthorizedf("foo %q", "bar") -> `foo "bar" not authorized` [16:13] rogpeppe1, maybeUnauthorized(err error, action string) [16:13] rogpeppe1, NotAuthorizedf(action) [16:13] fwereade__: we should use either Unauthorized or NotAuthorized consistently at least [16:14] rogpeppe1, Errorf("%s failed: %v", action, err) [16:14] rogpeppe1, sure, that was just a thinko [16:14] fwereade__: i *think* i prefer Unauthorized, for the function names at least [16:14] fwereade__: in a sentence, i'm happy to use "not authorized" when it reads better [16:14] rogpeppe1, even considering that Unfound would be an abomination unto the lord? [16:15] fwereade__: sure [16:15] fwereade__: they don't have to be the same [16:15] rogpeppe1, no, but there's definitely some degree of value in consistency too [16:16] fwereade__: i'm not sure there's any particular virtue in that particular consistency. the moment i find myself typing "NotAuthorizedError" by accident, i'll concede though :-) [16:16] rogpeppe1, " not found", " not authorized" both seem to read just fine to me [16:17] rogpeppe1, that's a matter of personal habit alone, surely [16:17] rogpeppe1, consistency is in itself a virtue [16:17] fwereade__: "not authorized" doesn't work so well as an adjective tho [16:18] fwereade__: although it's unavoidable with "not found" [16:18] rogpeppe1, it's just harder to appreciate the value of imposing consistency when it's code you already know [16:18] fwereade__: if you feel strongly about NotAuthorizedError, go for it [16:19] rogpeppe1, strongly enough, yeah -- thanks :) [16:19] fwereade__: though while you're about it, errors.NotAuthorized might be better when errors.NotAuthorizedError [16:19] s/when/than [16:19] rogpeppe1, then NotAuthorizedf and NotFoundf echo one another [16:19] rogpeppe1, foo not bar [16:37] rogpeppe1, oh and finally: errors.NotAuthorizedError vs errors.NotAuthorized; errors.IsNotAuthorizedError vs errors.IsNotAuthorized [16:37] rogpeppe1, any point keeping the stuttering? [16:37] fwereade__: i don't think so [16:38] rogpeppe1, cool [16:38] fwereade__: i thought about mentioning it but i didn't want to add yet more negativity... [16:38] rogpeppe1, funny how a liitle "this isn't quite consistent, let's just fix that one bit" can balloon [16:39] fwereade__: oh yes [16:49] * TheMue is not happy about the cleaner test yet. it needs about 6 seconds. [17:18] Anyone up for a second review of my branch? It's just some forgotten imports added to the azure skeleton, and some unqualified class names qualified with their package name: https://codereview.appspot.com/10184043/ [17:20] jtv, it would seem resaonable to carry over one of the earlier +1s and submit [17:20] Can I do that? [17:21] or get fwereade__ to rubberstamp [17:21] Just the sort of thing I was hoping to accomplish here, really. :) [17:23] Oh never mind. I'll just submit as-is then. [17:28] I wonder what this error output from lbox means... [17:28] error: use of closed network connection [17:28] Rietveld: https://codereview.appspot.com/10184043 [17:28] The lbox command still returns success (i.e. zero), but I think it just always does that, regardless. [17:30] g'night all [17:30] rogpeppe1: n8 [17:31] fwereade__: still available? [17:32] nn robbiew [17:32] I mean, rogpeppe1 [17:32] Damn over-eager tab completion... [17:32] ;-) [17:32] Sorry! :) [17:33] np [17:33] jtv: not seen that error before myself [17:34] I've noticed that relatively often, given how rarely I've used lbox: weird errors, different every time, and if you keep retrying it succeeds eventually — but you can't ever really tell because it doesn't report errors properly. [17:45] FWIW it does look as if lbox failed there, it just doesn't seem to have checked for the error condition. When I retried, it succeeded. [17:58] jtv: Are you using precise? That looks like the error I used to get when compiling with go 1.0 (updating to go 1.0.3 from ppa:gophers/go [17:58] fixed it) [18:00] jam: no, I'm on Raring. [18:00] Go version is go1.0.2. [18:00] Do I need to update to 1.0.3? [18:16] jtv: I think danilos is using your same configuration successfully, but I'm not sure [19:02] hi guys, has anyone seen this error before? It's from the bootstrap node: http://pastebin.ubuntu.com/5755877/ [19:02] on aws, using juju-core trunk [19:03] juju bootstrap worked, one instance running, then I did a bunch of deploys [19:03] juju status says they are all pending, but ec2-describe-instances still only sees the bootstrap instance, no word on the others [19:03] I didn't bootstrap with --upload-tools, I wonder if that oculd be it [19:23] andreas__, I suspect you're using trunk but not running --upload-tools [19:23] andreas__, ha, yes [19:24] ok, I destroyed the env and bootstrapped again with --upload-tools, it's working now === makyo_ is now known as Makyo [20:55] morning [21:46] fwereade__: I have some questions around the provisioner change [21:47]