=== wedgwood is now known as wedgwood_away [00:10] * thumper is back [00:12] davecheney: I have an idea, but it is a little icky [00:12] shoot [00:12] davecheney: I'll see if I can make it owrk [00:12] parameterise from above [00:12] if I can't use a dynamic way of getting the param, pass it in [00:14] * thumper bangs on the keyboard for a bit [00:24] * thumper sighs [00:27] tests in cmd depend on classes in ../worker [00:28] seems wrong IMO [00:28] test helpers ? [00:28] cards on the table [00:28] i'm here to help make Juju better in any way that you think it should be [00:29] but I can't change the language [00:29] it isn't object oriented in the way that most of the textbooks say [00:29] so some things just won't work [00:29] davecheney: more just testing other parts [00:29] I've got it working [00:29] isn't as fugly as some methods [00:29] :) [00:33] davecheney: ok, question time... [00:34] shoot [00:34] if I have a composed element, and I want to provide specialised implementation of a function also defined by the composed element [00:34] and I want the derived function to call the composed function [00:34] what is the way to do it? [00:34] * davecheney translates [00:34] two secs, lemmie do a paste [00:38] thumper: is this of any use ? http://play.golang.org/p/NbcP2zklaj [00:38] * thumper clicks [00:39] b.A.Get() [00:39] yes [00:39] so, embedding A into B allows you to call B.A.Get as B.Get [00:39] the compiler doesn't actually create a forwarding method [00:40] ie, there isn't a synthetic method on B called Get that returns B.A.Get() [00:40] * thumper nods [00:40] _but_ if you want to interpose in that [00:40] just convenience [00:40] you can [00:40] sweet sweet sugar [00:40] and sometimes it is necessary if you embed two types that have the same method sig [00:40] you need to break the deadlock [00:41] TBH, go's application of syntactic sugar is inconsistent [00:41] * thumper nods [00:41] automatic pointer deferending for method dispatch +1 [00:41] no obvious type converstions -1 [00:41] there is a reason for all of it [00:41] but the reason is generally 'this is my opinion, - rob pike' [00:43] :) [00:43] as long as you can make peace with that fact, life can be good [00:44] thumper: i am going to put the completion of commands back on the agenda for tonight [00:44] i (personally) do not feel I understand the work that is remaining [00:44] as in "which need to be done?" [00:45] * thumper nods [00:45] and, without disrepect to your gap analysis, we now have yet another 80% complete document that doesn't capture actionable work [00:47] paying my strata fees 3 days early, like a boss [00:50] strata? [00:50] what we call the rates for the apartment block [00:50] pays for the common area, power, cleaning , that shit [00:50] ah [00:50] * thumper nods [00:50] every time I feel like I have a good grip on this, the stick becomes a slippery eel [00:51] the commands work ? [00:52] making help work nicely [00:52] oh [00:52] ok [00:53] because ideally: juju deploy --help [00:53] should be the same as: juju help deploy [00:53] yes [00:53] but the mechanism for getting there are differrent === _thumper_ is now known as thumper [01:17] davecheney: ok, I think I almost have this working properly now [01:17] just some tests to fix, tests to write etc [01:18] sweet [01:18] nearly lunch time here (i can hear my SO stiring in the next room) [01:18] davecheney: do you think people would complain that I've changed help output from stderr to stdout? [01:18] no idea about the others, but I would no object [01:19] not [01:19] ok, lets see :) [01:19] I think it makes more sense to have help output on stdout [01:19] not stderr [01:19] as it isn't an error [01:19] thumper: can you describe your views on stdout/stderr ? [01:19] call me pedantic [01:19] davecheney: sure... [01:19] (to see if they mesh with mine) [01:20] expected output should go to stdout, which is "normal" [01:20] exceptional or error text should to to stderr [01:20] and if you ask for help, you should expect it on stdout [01:20] makes sense [01:20] thumper: what about verbose or debug information ? stdout as well ? [01:20] there are occasions where you want different information streams on stdout vs stderr, but they should really be rationalised [01:21] verbose output should go to stdout [01:21] because you asked for verbose [01:21] and it is output [01:21] SGTM [01:21] debug info is a fluffy situation [01:21] normally I'd say stdout [01:21] unless you've configured your logging to go to stderr [01:21] one reason for the prediliction to stderr is, by default the Go log package sends everything to stderr [01:21] which should always be an option [01:21] so that default tends to drive other decisions [01:22] command output isn't logging [01:22] sending logging to stderr by default can be argued to allow 2>some_file [01:22] i guess it depends on what your program does [01:22] if it is piping data, that limits your options [01:23] but if it commincates on other fd's, ie, networking [01:23] then you have more choice [01:23] sure, but we're not [01:30] davecheney: oh, don't suppose you want to add me to ~juju ? [01:30] davecheney: you are an admin [01:33] davecheney: one thing I'd like to change is "bufferString(ctx.Stdout)" -> "testing.Stdout(ctx)" [01:33] davecheney: what do you think? [01:33] davecheney: I think it reads a little better [01:33] obviously another one for "testing.Stderr(ctx)" [01:34] and then delete both instances of bufferString [01:35] thumper: are you still not in that group [01:35] two secs [01:35] davecheney: not that one [01:35] added to the gophers [01:35] thumper: which group are you missing ? [01:35] ~juju [01:35] https://launchpad.net/~juju [01:36] thumper: done [01:36] re: "bufferString(ctx.Stdout)" -> "testing.Stdout(ctx)" [01:36] sure [01:36] ta [01:36] maybe do it as a separate branch [01:36] smaller branches == less latency [01:36] yep, agreed [01:36] I think i had a change that did exactly that [01:36] but it was blocked on a stack of prereqs that went nowhere [01:37] i tried to remerge it yesterday [01:37] but gave up as it was fucked [01:40] :( [01:40] interesting that we think along very similar lines [01:41] * thumper does the relocation dance [02:59] davecheney: ping [03:38] well that's dumb [04:15] anyone know how/where to configure the mongo admin password so that juju state works after a bootstrap? [04:19] wallyworld_: i have no idea how any of that works [04:19] i know it's a bit fragile [04:19] thanks anyway, i'll look into it [04:20] i think all agents share a password, but they use a per client certificate [04:20] all i did was "juju bootstrap" and then "jujustatus" and the status failed [04:20] paste [04:20] ? [04:20] that is seroius [04:21] what does the log on the bootstrap node say ? [04:21] i had to hack the stupid error code to get real info out of it [04:21] i haven't logged into the bootstrap node [04:21] i guess i can just ssh in [04:22] but on my client, i get a screenfull of this [04:22] 2013/02/26 14:01:16 JUJU state: opening state; mongo addresses: ["15.185.100.10:37017"]; entity "" [04:22] 2013/02/26 14:01:16 JUJU state: connecting to 15.185.100.10:37017 [04:22] 2013/02/26 14:01:17 JUJU state: connection established [04:22] 2013/02/26 14:01:17 JUJU state: opening state; mongo addresses: ["15.185.100.10:37017"]; entity "" [04:22] 2013/02/26 14:01:17 JUJU state: connecting to 15.185.100.10:37017 [04:22] 2013/02/26 14:01:18 JUJU state: connection established [04:22] 2013/02/26 14:01:19 JUJU juju status command failed: cannot log in to admin database: auth fails [04:22] error: cannot log in to admin database: auth fails [04:22] it finally ends with an error [04:22] what about on the bootstrap node ? [04:22] /var/log/juju/*log [04:22] or /var/log/cloudinit-output.log [04:22] before it just used to say "unauthorized access" without telling me what [04:23] * wallyworld_ looks [04:24] hmmm. nova list returns a few servers. i think some were running already before i did the juju bootstrap [04:24] i wonder if it picked up the wrong bootstrap node [04:25] is "juju-hpcloud-machine-0" supposed to be the bootstrap node? [04:25] there's also "juju hpcloud instance 0" [04:25] i'll try and log into them [04:26] wallyworld_: not sure, i've only been able to bootstrap ec2 nodes [04:26] so i'm used to their line noise names [04:26] except ssh fails [04:26] maybe the machine is fucked [04:26] boot'd the wrong ami [04:27] maybe i'll just kill them all and try again [04:28] except it's a shared account so maybe not [04:28] meh, blow em away [04:29] and say it was a bug :) [04:29] wcpgw [04:47] davecheney: got ssh access finally. but nothing i can see in the juju log nor the clound-init log. will keep poking around [04:48] ps aux [04:48] is jujud running ? [04:48] sounds like it was stillborn [04:49] jujud running [04:50] i'll try it all again. i'd love to know where the admin password comes from [04:53] from what I understand it is generated on bootstrap and is essentially opaque [04:53] i'm not quite sure why we use both a password and tls client certs [04:54] i have no idea either [04:54] i realised one issue - i'm running Q and the image is i specified was for P. so perhaps there's an issue there [04:55] that will be a big problem [04:55] cause i specified --upload-tools and so the tools would be wrong [04:55] if you use upload tools, it will always use the series of your machine [04:55] that was a battle I was unable to win [04:55] wallyworld_: maybe add your question to the agenda, https://docs.google.com/a/canonical.com/document/d/19bpZCZNWDYuRMVGvq66YcPThpirQAz1MRYnOMV6QHxo/edit#heading=h.3hs0dshzcf8k [04:55] but it calls them "..qantal....tar.gz" doesn't it [04:55] and so findToold would fail [04:56] findTools [04:56] yeah, pass --debug or -v for the gorey details [04:56] doesn't explain why mongo login fail though [04:58] i think the ssl cert provides the tunnel, but you still need a username/password [04:58] for mongo [04:58] the debug data should be on the bootstrap node in /var/log/juju/ [05:08] davecheney: yeah, -v or logs unhelpful, just lots of this [05:08] 2013/02/26 15:01:50 JUJU state: opening state; mongo addresses: ["15.185.101.250:37017"]; entity "" [05:08] 2013/02/26 15:01:50 JUJU state: connecting to 15.185.101.250:37017 [05:08] 2013/02/26 15:01:50 JUJU state: connection established [05:08] 2013/02/26 15:01:51 JUJU juju status command failed: cannot log in to admin database: auth fails [05:08] error: cannot log in to admin database: auth fails [05:08] i'll dig further and see what i can find [05:08] ok, that is fatal [05:08] once that happens [05:09] nobody has the password [05:09] and it's game over [05:10] hmmm. the password ran away then. sneaky [07:16] mornin' lal [07:16] "all" even! [07:50] rogpeppe: I just found something even more interesting for the bootstrap case. It would appear that we are calling 'putFakeTools' which actually only uploads 1-2bytes of garbage data, but we *still* call go install to build jujud, even though we aren't actually uploading it. At least, that is what I get if I understand how to 'Tell()' on a file. [07:50] jam: putFakeTools only works for some cases [07:51] rogpeppe: so for 'go test -gocheck.f BootstrapMultiple' it spends 5s in 'building stuff', and the .tgz is 2 bytes long [07:52] jam: putFakeTools won't work if someone calls Bootstrap with uploadTools=true [07:52] rogpeppe: so I'm not sure if it is putFake or not, it doesn't really matter. The point is that it spends 2+s to end up with 2 bytes in a .tgz [07:53] Though the fact that we are spending time in flate means I could be wrong, and I'm trying to sort those things out. [07:53] jam: actually, it ends up with all the tools in a tgz too [07:53] jam: the fake tools are put into the public bucket AFAIR [07:54] rogpeppe: I'm just putting print statements into "buildTools" and see it takes 2.1s, however, statting the file shows far more space than 'Seek(1, 0)' did, because I had the order of parameters wrong [07:54] I needed Seek(0, 1) [07:54] anyway, there is more content, which at least means we have content. [07:54] so that part is good [07:54] We aren't compiling and then not actually using it. [07:55] jam: you can use os.SEEK_END, BTW [07:55] jam: right [07:56] jam: well, we *aren't* actually using it, 'cos we never actually call the executable for real (actually, we do, in PutTools, but that's just a sanity check) [07:56] rogpeppe: sure, but Seek takes ints, so you can do Seek(os.SEEK_END, 0) just as easily as Seek(2, )) [07:57] jam: nope. [07:57] jam: (try it) [07:58] rogpeppe: interesting, I was thinking int was the typeless const, but I see it is the typed value. Is there a way to get untyped or you just have to use "const Foo = 1234" [07:58] ? [07:58] jam: yeah, an unadorned constant is untyped [07:59] jam: it still has some type-like information though (floats are different from ints are different from strings) [08:03] dimitern, mramm: meeting? [08:03] mgz doesn't seem to be here yet, though he mentioned he had to run on Chromebook which doesn't have an arm binary for Hangouts? So we probably shouldn't wait for him. [08:14] https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoQnpJ43nBkJdEFIZVg0dnN0SXNNREpTMTd6X1FMS1E#gid=1 [08:42] FAIL: current_test.go:56: CurrentSuite.TestCurrentSeries [08:42] current_test.go:65: [08:42] // If the command fails (for instance if we're running on some other [08:42] // platform) then CurrentSeries should be unknown. [08:42] c.Assert(s, Equals, "n/a") [08:42] ... obtained string = [08:43] ---------------------------------------------------------------------- [08:43] FAIL: current_test.go:56: CurrentSuite.TestCurrentSeries [08:43] current_test.go:65: [08:43] // If the command fails (for instance if we're running on some other [08:43] // platform) then CurrentSeries should be unknown. [08:43] c.Assert(s, Equals, "n/a") [08:43] ... obtained string = "quantal" [08:43] ... expected string = "n/a" [08:43] OOPS: 6 passed, 1 FAILED [08:45] wallyworld_: what does "lsb_release" do, and "lsb_release -c" ? [08:46] wallyworld_: it looks like the command 'lsb_release' is failing for you, but /etc/lsb-release has the right content so Juju knows what release it should be, and the test is faulty. [08:46] jam: [08:46] ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ lsb_release [08:46] Traceback (most recent call last): [08:46] File "/usr/bin/lsb_release", line 26, in [08:46] import lsb_release [08:46] EOFError: EOF read where not expected [08:46] so my system is screwed somehow [08:47] wallyworld_: right, so that is why the test is failing (lsb_release is failing incorrectly), I don't know yet why 'import lsb_release' is failing [08:47] ok, np. [08:47] wallyworld_: ls /usr/lib/python2.7/dist-packages/lsb_release.py [08:48] ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ ls -l /usr/lib/python2.7/dist-packages/lsb_release.py [08:48] lrwxrwxrwx 1 root root 38 Oct 24 10:34 /usr/lib/python2.7/dist-packages/lsb_release.py -> ../../../share/pyshared/lsb_release.py [08:48] ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ [08:49] jam: [08:49] ian@wallyworld:~/juju/go/src/launchpad.net/juju-core$ python /usr/share/pyshared/lsb_release.py [08:49] {'RELEASE': '12.10', 'CODENAME': 'quantal', 'ID': 'Ubuntu', 'DESCRIPTION': 'Ubuntu 12.10'} [08:49] ['core-2.0-amd64', 'core-2.0-noarch', 'core-3.0-amd64', 'core-3.0-noarch', 'core-3.1-amd64', 'core-3.1-noarch', 'core-3.2-amd64', 'core-3.2-noarch', 'core-4.0-amd64', 'core-4.0-noarch'] [08:49] so it sort of works [08:49] i'm hungry and it's way past dinner time here, so let's chat later about it [08:49] wallyworld_: np [08:51] morning mgz [08:51] hey jam [08:52] mgz: so did you take the opportunity of not having G+ to sleep in, or were you outside feeding the chix? [08:52] both :D [08:52] four eggs this morning [08:53] that sounds small, but I don't know how many chix they have [08:54] five, so only one was slacking [08:55] though if you think about it, having a body that produces a whole egg that often is pretty crazy [08:58] bbiab, popping over to dimiter's [09:15] hey, fwereade is here, if anyone needs him [09:17] give the guy an internet connection dimitern :) [11:00] thanks for the review rogpeppe [11:01] bac: np. i should go back and look at the ones that happened when i was away. from my mobile phone they looked fine :-) [11:10] dimitern: if fwereade's with you, perhaps you could mention that it'd be much appreciated if he passed his canny eye over https://codereview.appspot.com/7398050/ [11:11] or reviews anyone else for that matter - it's a later-comer prereq for another CL [11:15] rogpeppe: i've made the changes you requested. [11:15] bac: thanks [11:15] * bac out for 1.5 hours or so [11:18] bac: replied [11:19] * TheMue is at lunch [11:20] * rogpeppe passes TheMue some slices of delicious ham. [11:35] mgz: we can hear you type, but not you talk [11:39] jam, mgz, TheMue, wallyworld_, thumper, rogpeppe, fwereade, dimitern: Sorry I missed the meeting. My laptop met an untimely end yesterday due to close contact with some coffee. [11:40] mramm, we heard... bad luck :( [11:40] jam, mgz, TheMue, wallyworld_, thumper, rogpeppe, fwereade, dimitern: After which I spent about 8 hours getting things restored to an old machine, and then it was an hour before the meeting and I was going to stay up [11:40] it could at least have been alcohol [11:40] mramm: lol, that's bad [11:40] wallyworld_: well, no wasted booze at any rate. there's a silver lining to every cloud. [11:41] true :-) [11:41] rogpeppe: wallyworld_: very true [11:41] mramm: That sound hard. Coffee as pure energy for the developer is still bad for computers.Something's wrong here. ;) [11:41] yea [11:43] rogpeppe: Thx for the ham, had put it on my flatbread. [11:43] so, I have my old mac working, and while I don't have dual boot on it yet I do at least have ubuntu on it in a VM with *almost* all my settings and documents back from git repo's [11:43] but it made me realize that my backup strategy on ubuntu was a bit of manual kludgery [11:44] but it worked mostly [11:46] mramm: Not everything in the cloud? ;) [11:47] well, it there was a bit of stuff in the cloud, a bit of stuff in git repositories, and then a "copy the home folder" to an external drive bit [11:47] all of which provided some "backup" [11:47] and all of which actually worked out fine [11:47] but there were a lot of manual steps to restore [11:48] Yep [11:49] anyway, I'm back. [11:50] my intention was to get everything fixed before the meeting and have no work related downtime because of the laptop death [11:50] but my intention was foiled by a comfy chair in my office! [11:51] * TheMue just tries to imagine this picture [11:56] fairly trivial CL if anyone wants to take a look: https://codereview.appspot.com/7391051 [11:56] also, i'm still looking for another review of https://codereview.appspot.com/7398050/ so i can propose the branch that uses it as a prereq [11:57] rogpeppe: Will take a look at both. [11:57] TheMue: thanks [12:02] rogpeppe: First review done, now the next. [12:06] mgz, ping [12:06] rogpeppe: 2nd one done too. [12:06] TheMue: tyvm [12:07] mgz, am I right in thinking that the openstack metadata service does not expose instance-id until version 2012-08-10 ? [12:15] fwereade: folsom or later [12:15] so yup. [12:25] mgz, this seems to suggest otherwise: http://docs.openstack.org/essex/openstack-compute/install/apt/content/running-an-instance.html [12:25] mgz: cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id [12:25] mgz, I guess that's just a lie? :) [12:26] fwereade: that gives you the i-0000000 form, which is no good to man nor beast [12:27] (in the context of trying to do openstack operations) [12:27] * dimitern lunch [12:28] mgz, wait, what's wrong with that? is that form not used in the API? [12:28] there's no correlation between the uuid you need to do operations via the openstack api, and the integer id used the in ec2 compat api, and there's no api call to map between them, it's all hidden in the backend db [12:28] mgz, oh ffs [12:28] mgz, ok, thanks [12:28] folsom adds openstack specific data to the metadata service, which we can use [12:28] mgz, so we currently can't work pre-folsom regardless? [12:30] * fwereade lunches, thanks mgz [12:31] fwereade: Enjoy. [13:10] can someone other than me have a look at this CL please, so that Brad can submit: https://codereview.appspot.com/7384058/ [13:13] m_3: hi, I have a small branch charmhelpers branch up for review; I hear you are the guy to see about that: https://code.launchpad.net/~benji/charm-tools/bug-1130793-add-log-option-escaping/+merge/150442 [13:18] rogpeppe: Done [13:18] TheMue: thanks [13:54] Yo! [13:59] fwereade: whoops, missed the last question. so, gojuju doesn't work on pre-folsom currently, as the pyjuju code predates folsom, it has a cunning workaround, that gojuju could also adopt as needed (it stashes the uuid in storage) [14:11] niemeyer: hiya! [14:11] niemeyer: i've just run across a couple of weirdnesses in goyaml - i wonder if you can tell me if they're expected behaviour or bugs === wedgwood_away is now known as wedgwood [14:55] a fairly small review anyone? https://codereview.appspot.com/7399054 [14:56] fwereade: it contains two things that should please you [14:59] rogpeppe, cool, need to kanban too [14:59] fwereade: just going there [15:00] mramm: kanban meeting? [15:05] m_3: ping [15:07] benji: pong [15:07] m_3: hi, I have a small branch charmhelpers branch up for review; I hear you are the guy to see about that: https://code.launchpad.net/~benji/charm-tools/bug-1130793-add-log-option-escaping/+merge/150442 [15:07] rogpeppe: reviewed [15:10] rogpeppe: Sure [15:11] benji: yikes... tomorrow's first chance for me (see juju-gui)... I'm prepping for two talks later today [15:11] m_3: apparently you and Gary are discussing this in juju-gui, so nevermind [15:15] benji: ack.... ping me tomorrow if you haven't gotten it through [15:16] m_3: Way to go [15:17] m_3: The amount of activity around charms is looking great, btw [15:17] niemeyer: i filed a bug report (that may or may not be spurious) https://bugs.launchpad.net/goyaml/+bug/1133337 [15:17] <_mup_> Bug #1133337: unmarshalling map into *string has odd behaviour < https://launchpad.net/bugs/1133337 > [15:17] rogpeppe: Thanks! [15:19] niemeyer: thanks! we're doing a lot of talking :)... still need to do more charm cleaning though [15:20] niemeyer: i encountered these issues when trying to deal with service configuration in a moderately sane way, BTW. [15:25] rogpeppe: Cool [15:26] rogpeppe: I'll put that in the queue and see what would be a reasonable answer [15:26] niemeyer: thanks. for the time being, i'm just treating null as the string "null" [15:26] rogpeppe: What does that mean? [15:27] rogpeppe: This is certainly wrong, if it means what I think it menas [15:27] rogpeppe: People should be able to set a configuration value to the string "null" [15:28] niemeyer: they can do that. they can't use null as to delete an attribute though. [15:28] rogpeppe: That's fine.. we don't have that semantic defined yet [15:29] niemeyer: yeah. we chatted about it though, so i was considering doing it. [15:29] niemeyer: i'm not sure what user expectations are tbh [15:31] rogpeppe: Sure, and I hope we can implement it [15:31] rogpeppe: I don't think that's a typical case people think about [15:31] rogpeppe: So much so that the whole fixup didn't come from a user request [15:31] niemeyer: yeah. i suspect that deleting a attribute is a pretty rare operation, so i'm not too concerned [15:34] niemeyer: ha, perhaps you were talking about goyaml semantics. [15:38] rogpeppe: No, the former [15:55] TheMue: any chance of that promised review? https://codereview.appspot.com/7399054/ [15:55] rogpeppe: Will be in in a few seconds. Mostly LGTM, only one "feeling". ;) [15:58] rogpeppe: It's in. [15:59] TheMue: thanks! [15:59] rogpeppe: yw === otubo1 is now known as otubo === teknico is now known as teknico_mobile === teknico is now known as teknico_mobile [17:56] a small review anyone? https://codereview.appspot.com/7405049 [18:07] dimitern: looking [18:13] rogpeppe: cheers [18:15] dimitern: reviewed [18:15] i'm seeing an error running go test ./... on state/statecmd/ServiceGet [18:15] rogpeppe: tyvm [18:16] that's the error I'm getting - running on just pulled trunk: https://codereview.appspot.com/7405049 [18:17] oops - this is it - http://paste.ubuntu.com/5568327/ [18:28] so william proposed CLs which are a direct result of pair programming to need one LGTM [18:28] what do you think about it? [18:40] dimitern: hmm, that looks bad. might be my fault, but i'm already running really late and have to go. [18:41] rogpeppe: no worries [18:41] dimitern: it's a trivial fix if you wanna do it [18:41] rogpeppe: sure? [18:41] dimitern: (in the test only, i think) [18:41] rogpeppe: ok, I'll propose it later [18:41]