[02:28] thumper: is this likely to be fallout from your series changes? http://pastebin.ubuntu.com/5691125/ [02:29] I am trying to work out if it's a bug in the core or in the maas provider [02:29] * thumper looks [02:30] bigjools: yes, you want --fake-series=precise [02:30] thumper: on the bootstrap command line? [02:30] aye [02:30] ok cheers [02:30] as you are uploading tools [02:30] and by default, it makes tools for your series [02:30] but the machine you are booting says precise [02:31] it worked \o/ [02:31] although you should have public tools for 1.9.13 now [02:32] thumper: public? [02:32] as in, ec2 public bucket [02:32] thumper: I am not using ec2 [02:32] this is maas [02:32] * thumper nods, ok [02:33] anyway, bootstrap "completed" so thanks :) [04:36] is there a local placement option in juju-core like there was in Python? [04:36] there is one under review right now [04:37] ok ta [04:37] bigjools: it will function similarly to deploy-to but be called force-machine [04:37] discussion on the mailing list about it is ongoing [04:37] markramm: I don't know much about this - is deploy-to a cmd line option? [04:39] bigjools: no, that isn't an option at the moment [04:41] bigjools: it was a jitsu feature in python [04:41] that took a machine ID and installed a service on that particular machine [04:42] ah ok, no wonder I hadn't heard of it [04:42] thanks both [04:42] I just now realize that I'm not sure what you meant by "local placement" [04:42] so perhaps I got it wrong [04:43] markramm: "placement: local" in the environment config [04:43] juju-core complains if I have that in [04:45] bigjools: yes, we don't understand that key [04:46] davecheney: the error message was a little opaque: error: placement: expected nothing, got "local" [04:46] yeah, that isn't that helpful [04:46] * bigjools files a bug [04:46] bigjools: good idea [04:46] I was actually looking to avoid bringing up another machine in maas and re-using the bootstrap node [04:47] since it's slow - there's no fast installer yet [04:47] but no biggie [05:20] bigjools: https://launchpad.net/ubuntu/raring/+source/mongodb/1:2.2.4-0ubuntu1 [05:21] is it possible to drag this into a PPA targeting precise ? [05:21] it might be, depends if it builds with precise's available deps [05:28] should I try a source build on a Precise vm [05:28] ? [05:42] * thumper goes to make dinner [05:43] davecheney: use pbuilder [05:43] bigjools: speak to me as if I were a child [05:44] well you can use a VM [05:44] davecheney: I've got 4 naughty kids, don't tempt me! [05:44] bigjools: if you want to come to NSW for a spankin' let me know [05:44] i'm happy to arrange [05:45] what, you'd whizz straight past me then [05:45] so you can use a VM, or pbuilder automates an environment for a particular release [05:45] whatever you're comfortable with [05:46] i'll try pbuilder [05:46] i expect to get screwed on permissings [05:46] permissions [05:46] frankly, I fire up a canonistack instance these days [05:47] massively quicker [05:47] * davecheney deployes the ubuntu charm [05:47] just dget the source for raring on a precise instance [05:50] * bigjools afk [06:33] mornin' all! === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 0 Critical, 52 High - https://bugs.launchpad.net/juju-core/ [07:31] moin moin btw [08:11] TheMue: hiya [08:11] TheMue: i believe you are the on-call reviewer today... [08:11] TheMue: i have some reviews for you :-) [08:11] TheMue: https://codereview.appspot.com/8458044/ https://codereview.appspot.com/8487044/ https://codereview.appspot.com/8533044/ https://codereview.appspot.com/8534043/ [08:12] fwereade: if you fancy having a look, another opinion would be nice too [08:12] rogpeppe, cheers, I'll try to get there soon [08:12] fwereade: thanks [08:13] fwereade: that last one gets us back to having unit and machine status for the gui folks [08:20] rogpeppe: will look at them. [08:20] TheMue: thanks! [09:24] rogpeppe: a lot of stuff, but i'm getting forward [09:25] TheMue: thanks a lot. the big changes are pretty much mechanical [09:26] rogpeppe: yes, that helps [09:41] TheMue: thanks for the review. i'm not sure what you're thinking of when you say "exposed constants for the EntityTypes" [09:45] rogpeppe: simple public constants, nothing more. but as i also wrote, today they are needed nowhere, so simply forget it. ;) [09:46] TheMue: sorry, do you mean the entity kinds? i don't see any occurrence of the word EntityType in the source. [09:47] rogpeppe: oh, sorry, yes. where you return strings like "service" etc. [09:47] TheMue: ah, i see. [09:48] TheMue: they are actually compared, but not outside the params package. [09:49] rogpeppe: i haven't seen them as strings elsewhere, only that you fill that one map by reflection. am i right? [09:50] TheMue: look for the string "machine" in state/api/params and you'll see what i mean [09:51] heya, I am getting a bunch of test failures with juju-core trunk on raring: http://pastebin.ubuntu.com/5691888/ [09:51] rogpeppe: ah, ic. so probably constants make sense, but not public ones. [09:52] I did follow README and CONTRIBUTING docs, except that I am using system-installed mongodb [09:52] TheMue: i'm happy just using the strings. test coverage is sufficient that you won't be able to get it wrong. [09:52] (because it's 2.2.4 and 2.2.0 was referenced in the README) [09:52] anyone has any ideas what did I mess up? [09:52] danilos: i think you do need the SSL-capable mongo [09:53] danilos: it looks like you might be using GOPATH wrongly [09:53] danilos: what's the value of your $GOPATH ? [09:53] rogpeppe, it's /home/danilo/.gopkgs [09:54] rogpeppe, I've got a symlink from ~/.gopkgs/src/launchpad.net/juju-core to ~/juju-core, but it behaves the same no matter what directory I am in [09:54] rogpeppe, or maybe not the same, but I've seen a lot of test failures either way [09:55] danilos: symlinks don't work, i'm afraid [09:55] danilos: your juju source must live in /home/danilo/.gopkgs/src/launchpad.net/juju-core [09:55] danilos: you can symlink the other way if you want [09:55] rogpeppe, :/ but originally I tried it like that as well, maybe the non-SSL mongo was to blame [09:56] danilos: you definitely need the SSL-capable mongo [09:56] danilos: were you getting build errors before? [09:57] rogpeppe, no, go build seems to work correctly either way [09:57] danilos: sorry, i'm mean build errors when testing [09:57] danilos: like the errors you pasted above [09:58] danilos: the easiest way to start is to do: "go get launchpad.net/juju-core/..." [09:58] danilos: making sure you remove that symlink first [09:58] rogpeppe, right, that's how I started off then rearranged the trees a bit to follow my branch organization model (which is a shared repo with lightweight checkouts: I like having multiple branches around, especially when starting on a project) [09:58] danilos: that will get you the source into the right place [09:59] go is really picky about placement of things [09:59] danilos: i use cobzr [09:59] danilos: fwereade doesn't but i don't know how he *does* use multiple branches [09:59] rogpeppe, right, I hate the git model of a single working directory and local merge problems when you forget to commit stuff, which is why I tried to avoid it [09:59] jam has a setup like yours, I'll just see if I have what his layout was anywhere [09:59] it certainly can be made to work [10:00] ...I think thumper does as well [10:00] mgz: i think thumper uses native bzr colocation [10:00] * mgz has been using this to test the 2.6 colo stuff [10:01] rogpeppe, it seems there are no build failures when I get the code directly in, argh :/ there're still a bunch of test failures [10:01] danilos: are you using the right version of mongo? [10:02] mgz, rogpeppe: ok, I'll check with them if I don't figure something out, and switch to cobzr model until then [10:02] rogpeppe, not yet, I'll get it downloaded and set up as well [10:02] danilos: all you need to do is download the tar file and put the files somewhere in your $PATH [10:04] rogpeppe, ok [10:08] rogpeppe, so far it seems that was the remaining problem; I'll figure out a tree layout that works for me, thanks for the input [10:08] danilos: cool, np [10:09] I know one thing that works, is having the normal shared-repo+treeless branches in your normal dev location [10:09] then lightweight checkouts in the go-expected locations [10:10] there's a trick then to make switch easy, by doing something in locations.conf I think, but am not sure what it is [10:15] mgz, right, and can probably live with something like that, thanks [10:19] fwereade: i'd really appreciate your comments on this branch before it gets waved through, as it's the technique that's directly impacted by the doc split between unit/machine and status. https://codereview.appspot.com/8534043/ [10:20] rogpeppe, ok, looking now [10:22] fwereade: thanks [10:31] rogpeppe, that one's approved [10:32] rogpeppe, need to grab some lunch, bbiab [10:32] fwereade: thanks! [10:50] fwereade: ping [11:08] rogpeppe, pong [11:09] fwereade: i was just wondering why we don't just use constraints.Value directly as a mongo doc [11:30] mgz: standup? [11:31] I'm there [11:32] mgz, dimitern: https://pastebin.linaro.org/2129/ [11:33] mgz, dimitern: http://pastebin.ubuntu.com/5692068/ [11:37] TheMue: cheers for updating the topic! [11:38] dimitern: yep, seen it as my task as reviewer today. ;) [11:38] rogpeppe, sorry, I left a comment half-types [11:39] rogpeppe, because I'd rather have a dumb but explicit translation layer between the api type and the database representation than to conflate the two [11:39] no critical bugs? how come? [11:39] fwereade: do you think we should do that for all the other types we marshal directly to mongo then? [11:40] fwereade: i'm wondering if we should marshal constraints to mongo as string [11:40] anyone have time for a quick review? https://codereview.appspot.com/8532043 [11:40] rogpeppe, I can't think of many of those... state.Tools, any others? [11:40] fwereade: charm.Meta [11:41] fwereade: (that's a big one) [11:42] rogpeppe, hmm, yeah, in hindsight the pressures maybe feel different now constraints is out of state [11:42] fwereade: charm.Config [11:43] fwereade: i'd quite like a tool that automatically checked for mongo compatibility between versions [11:43] fwereade: but i'm not entirely sure how it would work [11:44] rogpeppe, yeah, I think it'd be tricky [11:46] fwereade: there are two approaches: 1) make some kind of formal description of the schema and check that everything adheres to it 2) write a test that talks to two different versions, each of which looks at the same mongodb, getting one to write and the other to read [11:46] fwereade: (at least) two approaches :-) [11:47] rogpeppe, yeah, it's not going to be fun [11:48] fwereade: maintaining compatibility is crucial though. [11:48] rogpeppe, agreed [11:48] fwereade: there's another possibility actually [11:49] rogpeppe, I'm honestly not sure about external types, but I am starting to feel that from this perspective it's important that we keep a clear eye on just wtf we are storing in mongo [11:49] fwereade: use a tool to tell us exactly what types we're storing in mongo [11:49] fwereade: then we can use a variant of the go compatibility checker to make sure we don't change those types in backwardly incompatible ways. [11:50] fwereade: it won't work for types that know how to marshal themselves, but those are probably not where the problems will occur [11:51] fwereade: because if you change a MarshalBSON method, you'll have a pretty good idea that it might have some impact on mongo storage [11:51] rogpeppe, well, it's the types that know how to marshal themselves I am concerned about tbh -- those changes are going to be easy to make accidentally [11:51] fwereade: i'm more concerned about someone just changing the type of a field [11:52] fwereade: without realising that the type is used in mongo [11:52] rogpeppe, yep, that too [11:52] rogpeppe, agreed that having what you described in place would take one big worry off the table [11:53] rogpeppe, in the meantime I think I *would* prefer to avoid directly storing external types in mongo, but obviously we can't change all that now, we just need to fret and hope :/ [11:54] fwereade: for now, perhaps we should just comment every type that's used in mongo, so that people know it's important not to change it. [11:54] fwereade: it should be straightforward to do [11:54] rogpeppe, that sounds like a good idea to me [11:59] fwereade: i've added a ticket to the kanban [11:59] rogpeppe, cheers [12:11] mgz, dimitern: the other test seems to really be fixed by r39 in goyaml from a week or so ago by gustavo [12:14] rogpeppe, fwereade: next chapter in the nonced provisioning saga: https://codereview.appspot.com/8561044/ [12:15] trivial test fix branch to review: https://codereview.appspot.com/8570043 [12:15] danilos: ^you can practice your reitveld on that too :) [12:16] mgz, I will, that's even easier :) [12:49] I am having some trouble getting lbox to do anything with codereview.appspot.com: I suppose I need to configure something (even if I set my email address for bzr to the one I use to log in to codereview.appspot.com, no review is created [one is created on LP]) [13:22] TheMue: here's a review for you: https://codereview.appspot.com/8568044 [13:22] ah, ok, so if updating the milestone fails (which I don't have permissions for yet), then it borks out and doesn't do a code review submit [13:22] rogpeppe: just doing dimiters, then yours will follow [13:23] TheMue: ta! [13:23] danilos: how did you manage to update a milestone with lbox? :) [13:23] dimitern, I didn't, but it tries to update a bug milestone and I am still not a member of the ~juju team which is the maintainer for the juju-core project [13:24] dimitern, I am only passing the -bug=... parameter to the propose command [13:24] danilos: I see [13:24] danilos: didn't know it touches milestones when you link a bug [13:25] dimitern, yeah, it tries to create a bug if you don't link it (or so it seems) [13:26] now I need Kapil, Gustavo or Dave Cheney to add me to the team [13:26] dimitern, reviewed [13:26] hazmat, hi, can you please add me to the ~juju team? [13:27] fwereade: cheers! [13:28] fwereade: and this is the final step: https://codereview.appspot.com/8561045/ [13:28] dimitern, ta [13:28] danilos, welcome to juju core, and done [13:30] hazmat, thanks! :) [13:31] fwereade: I don't think asserting on both instanceid and nonce being "" will work for replayed transactions [13:32] TheMue, hi, I wouldn't mind getting a review for https://codereview.appspot.com/8572043/ :) [13:33] dimitern, I think replayed transactions leak badly here anyway [13:33] dimitern, but in the actual use cases, we'll never be setting the same instance id anyway, so that specific check actually reduces to "never set" anyway [13:33] danilos: enqueued, just doing rogers ;) [13:33] TheMue, thanks [13:34] mgz, dimitern: I wouldn't mind if one of you gives me a second ack (or nack, depending on your opinion :) on https://codereview.appspot.com/8572043/ [13:34] dimitern, I think it's clearer and simpler and no less correct ;p [13:36] fwereade: it's simpler for sure, just have a nagging feeling I'm missing something, if i don't assert instid should either be "" or "instid" [13:37] fwereade: perhaps you could alleviate my concern - what'll happen when we need to replay a SetProvisioned transaction without asserting "instid", which is already set? [13:37] dimitern, I think there is a general issue wrt txns that need to be synchronized with non-txn state [13:37] dimitern, the short answer is "we're probably screwed", but asserting on the possibility of the same instance id can't actually help, I think [13:38] fwereade: istm asserting only on "" will cause erraborted, which then by the virtue of the machine being still alive will return "already set" [13:39] fwereade: that's the only reason to check for same id in the assert, if you think it's superfluous, I'll drop it [13:41] danilos: you've got a review [13:41] dimitern, essentially a delayed SetProvisioned txn leaves state badly inconsistent with reality until it's completed, and there's no way round that except to do some distracting cleverness re completing machine txns before making provisioning-related decisions [13:42] dimitern, and it's low-impact enough that I plan to just skip it for now [13:43] fwereade: yeah, and hard to induce such an error to test it properly imo [13:43] fwereade: ok, I'll do as you suggest [13:43] dimitern, yeah, indeed [13:47] dimitern, thanks [13:48] dimitern, fwiw, I did test it with both tip revisions and going back one revision of goyaml to confirm it fails expectedly with it [13:54] danilos: cheers [13:55] rogpeppe, danilos: you've got reviews [13:55] TheMue: ta! [13:56] rogpeppe: yw, nice little helpers in the code [13:58] danilos: does go get -u retrieves the fixed goyaml version? [13:58] TheMue, I can try reverting to r38 to see if it does (since I started yesterday, I got the latest version by default: r39 is from April 2nd) [14:00] TheMue, yeah, it does update it for me at least [14:01] danilos: that's good [14:01] TheMue, btw, is "LGTM" a convention of rietveld (i.e. does it interpret it as a positive review and makes the review message green), or just internal juju team convention to give out a shorter "looks good to me"? [14:01] it's for the pretty green [14:02] mgz, for some definition of pretty, yes :) [14:02] * TheMue almost missed hangout [14:03] danilos: it is interpreted by rietveld, and "not lgtm" marks it red [14:03] danilos: and there's the red NOT LGTM for Disapprove [14:03] TheMue, dimitern: ack, thanks [14:05] danilos: not sure if it's case-sensitive, but it definitely catches it as part of the word (like "this is LGTMy"), ymmv [14:07] fwereade: updated https://codereview.appspot.com/8561044/ [14:08] fwereade: and there's the other one as well - https://codereview.appspot.com/8561045/ [14:09] * dimitern lunch [14:10] heh, even later lunch than me [14:12] niemeyer, heya, I've marked a couple of bugs that you've fixed in goyaml with r39 as fix-committed, I hope you don't mind :) [14:36] danilos: Thanks! [14:36] danilos: They're even released already [14:39] niemeyer, even better :) [14:46] danilos: are you Данило Шеган ? [14:47] danilos: 'cos if so, i think you've just earned your first "broken trunk" badge :-) [14:48] rogpeppe: with an updated goyaml? [14:48] TheMue: yes [14:49] rogpeppe: oh, where does it break? [14:50] TheMue: constraints [14:50] danilos: you've done go build ./... and go test ./... in the juju-core directory? [14:50] TheMue, yeah, with latest trunk [14:50] TheMue, are you seeing any problems? [14:51] rogpeppe, btw, I am, what did break for you? [14:51] rogpeppe, got the traceback? [14:51] ha, that would be nice :) [14:52] correct term is "cryptic one-line error" [14:52] danilos: http://paste.ubuntu.com/5692522/ [14:52] rogpeppe, that's exactly what should fail if you don't have fixed goyaml version [14:52] mgz: aww come on, it's a cryptic four-line error, surely?! [14:53] danilos: ah, so i need to pull goyaml? [14:53] rogpeppe, i.e. when I tested it with r38 of goyaml, it failed like that [14:53] danilos: ah, i'm on v36 [14:53] rogpeppe, yes, as per my email (this is goyaml r39 from 2013-04-02 by niemeyer): it was failing for me since I just fetched it yesterday for the first time [14:54] that probably deserves a post to the mailing list then, if everyone needs to update [14:54] ...which you've already done [14:54] mgz, I posted to juju-dev [14:54] danilos: ahhhh, i think gustavo must've moved the goyaml repo [14:54] Hm? [14:54] danilos: because it thinks 36 is the latest version [14:54] rogpeppe: that's why i asked for the goyaml. *phew* [14:55] yeah, need `bzr pull --remember lp:goyaml` [14:55] rogpeppe, what does 'bzr info' say for you in there? [14:55] danilos: http://paste.ubuntu.com/5692535/ [14:55] changed from lp:~gophers/goymal/trunk [14:55] it should be something like bzr+ssh://bazaar.launchpad.net/+branch/goyaml off the top of my head, let me check on disk for me [14:56] niemeyer: i've done "bzr pull" in my goyaml directory and it things 36 is the latest branch, but apparently there's a r39 out there [14:56] rogpeppe: ^see my bzr pull command above [14:56] It's still lp:goyaml.. it's under ~goyaml's trunk now, indeed.. the change was announced when we switched everything out of ~gophers [14:56] rogpeppe, yeah, lp:goyaml points at http://bazaar.launchpad.net/~goyaml/goyaml/trunk/ for me (so not bzr+ssh, guess that's go thingy) [14:57] danilos: Nope [14:57] yeah, go get is... not helpful [14:57] Ah, yes [14:57] niemeyer: ah, presumably i had to do a bzr pull --overwrite --remember lp:goyaml/trunk [14:57] rogpeppe: Hmm.. no.. [14:57] rogpeppe: bzr pull lp:goyaml --remember [14:58] niemeyer, any other reason why it didn't save the "top" URL of lp:goyaml (which I think evaluates to bzr+ssh://bazaar.launchpad.net/+branch/goyaml or similar) [14:58] danilos: I have no idea.. [14:58] niemeyer: ah, ok, done, thanks [14:58] danilos: I'd expect that too [14:59] * rogpeppe wonders what other packages are "frozen" in the same way [14:59] niemeyer, I guess it's not using "lp:" for fetching branches, which would explain it [14:59] yeah, jam proposed a fix for that [14:59] danilos: Maybe.. I'd not expect that to make a difference, though [14:59] danilos: Whatever is fetching branches is still talking about launchpad.net/goyaml [15:00] it may even have landed in go trunk [15:00] danilos: Not ~foo/goyaml/trunk [15:01] niemeyer, maybe it's doing so over http (I had the http ~foo/goyaml/trunk in it after a simple 'go get', and my bzr login is set properly) [15:01] danilos: Maybe, but I'd still consider that a bug in bzr itself [15:01] danilos: If the user asks for lp.net/foo, that's what it should be linked with [15:02] danilos: Even if it fetches from elsewhere [15:02] danilos: We probably won't solve that bug today, though [15:02] niemeyer, yeah, or in Launchpad (I've just double-checked that, if I do a 'bzr pull --remember http://launchpad.net/goyaml', it does the wrong thing) [15:02] still waiting for a review on https://codereview.appspot.com/8561045/ [15:02] niemeyer, indeed :) [15:02] fwereade: sorry, but i'm bugging you again ^^ [15:02] there does seem to be a launchpad forwarding bug [15:03] dimitern, sorry dude [15:03] but... using that http url is... more than a little bogus anyway [15:04] mgz: Hmm.. why? [15:04] mgz, yeah, LP sends permanent redirects for that http url (it's not perfect, but it seems to work and I suppose go get uses it) [15:04] dimitern: started revisioning [15:04] niemeyer, I don't think it's advertised anywhere as the URL to use for fetching branches [15:04] TheMue: thanks [15:04] danilos: Well.. 1) It works; 2) It's extremely user-friendly [15:06] niemeyer, I am not disagreeing, I think there's a LP (or maybe bzr) bug in there [15:06] the branch also has a broken parent reference [15:06] danilos: i can't see your post to juju-dev anywhere. what was the subject line? [15:07] rogpeppe: Update goyaml dependency for juju-core [15:07] niemeyer: ah, just turned up [15:08] niemeyer: can you run this please: `bzr config --scope=branch -d bzr+ssh://bazaar.launchpad.net/+branch/goyaml --remove parent_location` [15:08] rogpeppe, I've posted an update with your experience as well, hope this helps somebody else who hits the same problem [15:09] danilos: thanks [15:09] rogpeppe, and now I see that mgz beat me to it... oh well :) [15:09] : [15:09] ) [15:11] mgz: What does that do? [15:12] removes a broken parent location reference on the trunk branch [15:12] it's trunk, it shouldn't have a parent (and certainly not a ../../ one that goes nowhere) [15:12] dimitern: you've got a review [15:12] TheMue: tyvm [15:12] mgz: Never seen that [15:13] mgz: Neat [15:13] mgz: The command, Imean [15:14] beats editing .bzr/branch/branch.conf, especially when it's a remote branch :) [15:15] phew [15:15] * danilos hands the first "broken trunk" badge back ;) [15:16] okay, I think that probably does fix the launchpad redirect too [15:16] so, go get should now have the right origin [15:16] mgz: Done [15:23] mgz, it does? I just filed https://bugs.launchpad.net/launchpad/+bug/1166854, let me check that :) [15:23] <_mup_> Bug #1166854: bzr http URL stores evaluated URL instead of the link < https://launchpad.net/bugs/1166854 > [15:23] mgz, it doesn't for me, it still stores the evaluated URL instead of the shorter one [15:24] oh, that bxr resolves redirects and stores the dest is a known thing [15:24] mgz, at least 'bzr pull --remember http://launchpad.net/goyaml' does (haven't tried 'go get' itself) [15:24] but launchpad actually had the wrong redirect [15:24] mgz, right; oh, the redirect worked fine for me at least [15:25] mgz, btw, is bzr supposed to store temporary redirects as well? could that be a solution? [15:25] mgz, solution on the LP side, that is [15:25] the launchpad side for this is very messy [15:25] there are two levels, the first of which isn't actually an http redirect at all, but a fake branch that references another location [15:26] mgz, it's starting to sound nice [15:26] mgz, "interesting" is a perfect word, I assume :) [15:28] anyway, enough of that for now, those smarter about code-hosting in LP and bzr can comment on the bug and close it as invalid if needed; it'd still be nice to improve the experience for potential Go Launchpad users [15:29] niemeyer: reviewed [15:29] dimitern: Cheers [15:29] sorry, http->https redirect first... then: [15:29] $ curl https://launchpad.net/goyaml/.bzr/branch/location [15:29] http://bazaar.launchpad.net/~goyaml/goyaml/trunk [15:38] fwereade: Any idea of when we'll make log messages reasonable? [15:39] I am seeing a problem in environs/openstack/config_test.py configTest.check method: it doesn't seem to clean the state properly after a failing test: I expect first test to fail (I am just adding it before adding the code), but the second one shouldn't fail: if I move my new test to the end, second one doesn't fail anymore [15:39] niemeyer, ...damn, I have a draft email proposing a small doable card [15:39] fwereade: Just got a request by dimitern to uglify messages to conform to other ugly messages [15:39] fwereade: I'm doing it, but the output is comical [15:40] 2013/04/09 12:39:56 INFO JUJU:juju:publish cmd/juju: charm published at 2013-04-01T15:53:05Z as cs:~niemeyer/precise/ubuntu-6 [15:40] danilos, that sounds like a problem to me [15:40] niemeyer: i think a consistent source is better than half-baked better solution only at places [15:40] JUJU! JUJU! JUJU! I mean it, JUJU! [15:40] dimitern: I'm doing it.. [15:40] niemeyer: and i agree the format needs to change to cut the bullshit of the logs :) [15:40] dimitern: But I don't have to agree.. :) [15:40] niemeyer, the proposal will eliminate that at least -- thank you for bearing with us re consistency in the meantime, though [15:41] fwereade, http://pastebin.ubuntu.com/5692650/ and my test is in lp:~danilo/juju-core/bug-1135335 [15:42] fwereade: np.. I'm more bothered by presenting people with such obviously bad UX than the fact I have to change it [15:43] fwereade: i though the JUJU: badge was supposed to somehow help the logs integrate better with syslog, but it's kinda crap if it's a requirement - a smart syslog will badge these according to sources [15:43] danilos, omg, that's evil [15:43] danilos, var credentialsTestConfig = configTests[12] [15:44] fwereade, aah [15:44] danilos, I haven't checked your branch, but I bet you inserted a test before that one, thus throwing off the hardcoded magiv number [15:44] yeah, that is good. [15:44] danilos, please kill that technique with fire if you would be so good :) [15:45] fwereade, I'd be delighted to :) any suggestions as to how since I am just getting to grips with go syntax? :) [15:45] fwereade, should I simply split it out into a separate var, and then reference it in the big array after that? [15:45] move it above the block of test definitions as its own thing, then add it in the list [15:45] danilos, easiest way: just stick that test in a var, then stick the var into the []tests [15:45] danilos, but cast an eye over the actual uses of it [15:45] mgz, fwereade: ok, I guess we are all on the same page, thanks :) [15:45] fwereade, of course [15:46] danilos, it may be that it's not worth it in the first place ;) [15:48] fwereade, right, it's used in a single place with a different test.err and a couple of different env vars (just below the declarations): I'll see if I can move that as a separate entry in the configTests array [15:48] today i tried the classic bootstrap+deploy mysql/wordpres+add-unit for both+expose; in ec2 - everything worked with the new provisioning! [15:48] danilos, great, thanks [15:49] * fwereade cheers at dimitern [15:49] * danilos tries to count from 0 to 12 in an array :) [15:49] dimitern, https://codereview.appspot.com/8561044/ LGTM [15:50] dimitern, btw, what's the value of BootstrapNonce? [15:50] dimitern, didn't spot that [15:50] fwereade: "user-admin:bootstrap", as you suggested - it was part of the previous CL [15:50] dimitern, ah, great, thanks [15:51] fwereade: thanks for the review; i really want to finish and land both of these today [15:52] dimitern, what was the thinking behind UUID for nonce? [15:53] dimitern, seems a shame not to have it badged with the provisioning machine [15:54] dimitern, nothing wrong with a UUID in itself, but I'd prefer the nonce to look like "machine-0: