[02:19] wallyworld_: I forgot to grab that example before leaving the standup. Can I grab it again please? [02:19] for loop starts at line 548 in state.go [02:23] wallyworld_: cheers [02:23] np [02:33] wallyworld_: you did a fix to the unit upgrader... did it fix https://bugs.launchpad.net/juju-core/+bug/1284502? [02:33] <_mup_> Bug #1284502: upgrader: cannot read tools metadata (in unit agent) [02:36] axw: i think so [02:36] yes [02:36] that branch is in the queue to land [02:37] ok [02:41] thumper: so i can't push to lp:~go-bot/juju-core/trunk. says it's read only [02:41] ah... [02:41] * thumper thinks [02:42] wallyworld_: you need to do this: [02:42] bzr push bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk [02:42] your ssh key is loaded against the go-bot user [02:42] ah ffs. i tried that but forgot the go-bot@ bit [02:43] :) [02:43] wallyworld_: are you setting the author on the merge? [02:43] what's the way to do that? [02:43] when you have a merge [02:43] run the tests [02:43] yep [02:44] bzr commit -m "blah blah" --author "Firsrt Last " [02:44] ah --author, ok [02:49] thumper: https://codereview.appspot.com/67870045/ -- the change in AddScripts fixes the log dir permissions. Did this as a drive-by in a larger fix [02:50] ok [02:51] hmm... [02:52] axw: actually I ment to ask you earlier today [02:52] how the juju-db upstart job was getting removed [02:55] thumper: the machine agent removes it on tear down [02:55] pkill -SIGABRT kills the machine agent, which stops and removes the jobs [02:56] axw: so the machine agent also brings down the mongo job? [02:56] thumper: yep, that bit is now shared between local and manual providers. [02:57] thumper: see uninstallAgent in cmd/jujud/machine.go if you care to see where [02:58] ok [03:11] wallyworld_: I don't want to see the asserts removed [03:11] wallyworld_: just moved to an explicit test [03:11] thumper: but it's part of the setup [03:12] not prt of what is being tested [03:12] wallyworld_: if something from setup is tested in one test, you don't need to do it in every test [03:12] I disagree [03:12] the setup it the setup [03:12] the test checks the setup did it right [03:12] what you have [03:12] it is to ensure the setup does what we think [03:12] is the test that it worked every time done every time [03:12] IMO this is overkill [03:12] i've seen tests before where setup was faulty and we didn't know it [03:12] just what I was brought up with, blame mwhudson [03:13] wallyworld_: I'm not saying don't test that setup did it right [03:13] what I am saying is don't do that assertion *in* setup [03:13] so you want a TestSetuptest() [03:13] have a test for the purpose of making sure that setup did it right [03:14] FFS, do what you like [03:14] * thumper gives up [03:14] no, it's ok, i'll change it [03:14] just trying to understand yout pov [03:14] I don't know the context, but that sounds like a recipe for difficult to debug test errors when TestSetuptest doesn't run before the other tests [03:14] there isn't a TestSetuptest yet [03:15] i was doing asserts in Setup() to ensure that the test setup was done right [03:15] or more to the point, did what we thought it did so that subsequent tests could be assured of testing the right thing [03:16] but i can add an explicit test to check the behaviour of SetUp() [03:16] * wallyworld_ -> lunch [03:16] I guess this is why having lots of setup in setup is not good [03:17] wallyworld_: look, the overhead of running it every time is insignificant [03:17] hmm, I don't see the need for the assertions at all really. this is testing that SetEnvironConfig does its job [03:17] just keep them in setup [03:17] that should be done in state [03:17] * axw shrugs [03:31] axw: what was the failure here: https://code.launchpad.net/~axwalk/juju-core/local-prereq-rsyslog-gnutls/+merge/208545 [03:31] intermittant? [03:31] thumper: pretty sure it's because the bot was in a bad way [03:32] * thumper nods === edamato is now known as edu-afk [03:49] thumper: wat [03:55] axw: the assertions were not to check that SetEnvironConfig did it's job, but that there weren't typos in hgow it was invoked such the the expected config attrs were set, since the test checks for their removal [03:56] wallyworld_: if you're making assertions about how the tests work, then when do you stop? [03:56] i only do it for selected cases [03:56] on a subjectively as needed basis where there's some risk [04:02] mwhudson: oh hai [04:02] mwhudson: just taking your name in vain [04:02] thumper: cool [04:02] :) [04:02] mwhudson: for teaching me about tests [04:03] in a good way [04:05] waigani: tests on your branch fail so i can't land it for you: policy-based-config-validation [04:05] wallyworld_: doh [04:05] okay, I'll check [04:06] ok, ta [04:13] axw: i get test failures in ~axwalk/juju-core/local-prereq-rsyslog-gnutls [04:13] ah [04:14] cause i don't have syslog-gnutls installed [04:14] let me install that and retry [04:19] right, that's much better [04:24] wallyworld_: hrm, that's actually a problem :) [04:24] tests shouldn't rely on the package being there [04:24] i guess we need to add it to the packaging stuff [04:24] i think it's reasonable the deps are expected [04:24] eg tests will fail if no mongo [04:25] true [04:25] i'd send an email to the list to let people know they need to install it [04:25] wallyworld_: I actually thought I had isolated this one, so I'll see if it's easy to fix... otherwise I will email the list [04:25] and let curtis know so he can get the ppa sorted [04:26] juju-local should be updated tho, there's a bug for that [04:26] regardless for the next release the packaging needs to be changed [04:27] wallyworld_: what do you mean by the packaging? [04:27] that fact that juju-core depends on this new package [04:27] wallyworld_: the client doesn't need rsyslog-gnutls, and it will be installed by bootstrap [04:27] no, only local requires it to be pre-existing [04:27] oh ok [04:27] but that's still juju-core [04:28] there's a meta package for the prereqs [04:28] so if one installs juju-core, it should pull down this new dep [04:28] sure, the dependencies need to be updated [04:28] yep, there's a bug for it against 1.18 [04:29] ok, that's great [04:29] just wanted to double check [04:46] wallyworld_: when you have a moment, can you please review https://codereview.appspot.com/71050043? [04:46] sure [04:47] just landing the rsyslog port branch [05:03] axw: all approved mps landed \o/ [05:03] thanks wallyworld_ :) [05:03] i'm pleased too [09:41] hazmat: re install.sh, sure, I didn't exec it, but it was useful as a crib sheet for set up steps [09:54] mgz, rogpeppe, dimitern: o/ [09:55] natefinch, morning! [09:55] dimitern: morning :) [09:57] natefinch: we're getting wwitzel3 to g+ you now for the hangout [09:57] mgz: cool [10:48] jam: https://plus.google.com/hangouts/_/76cpirbanp35boic60gobgfltc?authuser=1&hl=en [10:51] http://en.wikipedia.org/wiki/Shrove_Tuesday [10:54] mgz: I didn't know they had a whole week of this stuff. [10:59] the feasting bit is only today, the following period is fasting [11:08] mgz: from what i can tell, juju trunk canonistack don't like each other because port 17070 can't get routed via chinstrap like port 22 can for ssh [11:09] or am i missing something? [11:09] i was hoping to try and get the landing bot running [11:09] but i ended up testing a bunch of branches and landing manually [11:10] at least the backlog of approved mps is now in trunk [11:33] wallyworld_: you can always route via sshuttle to the bootstrap node, but I think going via chinstrap should be fine [11:33] wallyworld_: I saw you'd landed a bunch of branches, thanks [11:33] mgz: i tried using shuttle, no good [11:33] i must have been doing it wrong [11:33] the main issue is lcy02 is just hosed, but I will probably try bring up a new bot on lcy01 [11:34] ok [11:34] or fall back to ec2 if needed [11:34] previously lyc02 was better [11:34] LXC is now fixed on trusty for me - local provider works again! \o/ [11:34] dimitern: yeah, i landed a fix today [11:35] it was broken for trusty host and precise charms [11:35] but worked if host and charms were the same [11:35] well, the upgrader bounced anyway [11:37] wallyworld_: huh, that explains this mornings issues, thanks :) [11:37] bloodearnest: ah, sorry about that. fixed now :-) a fix for one problem broken something else so needed a second fix :-/ [11:39] wallyworld_: no worries, seems good now. I thought I'd broken things by having 4 active local envs at once [11:40] nah :-) [11:42] I get warnings for shared-storage-port env config - can I just drop that now? [11:43] not sure about that one off hand, let me check [11:45] bloodearnest: i think you can delete that one [11:46] wallyworld_: great - the warnings interfere with my bash auto-completion [12:08] wallyworld_, awesome! 10x [13:17] does anyone know what the hook behavior is when a unit is rebooted? [13:17] I'm seeing that in 1.16.6 the config-changed hook is run, for example. Is that expected? [13:47] dimitern, rogpeppe: I think john dropped out of the hangout btw [13:55] hi guys. Is anyone working on https://bugs.launchpad.net/juju-core/+bug/1284183? It's causing us a lot of pain as we try to deliver some customer work and we've got a big deadline coming up in a couple of weeks [13:55] <_mup_> Bug #1284183: jujuclient.EnvError: [13:57] ev: we're actually triaging bugs today, so we can look at that one and see what's up with it. Roger knows the most about it, but is out to lunch, he should be back shortly, however [13:58] cool, thanks natefinch [14:38] bug 1287147 for the FFE [14:38] <_mup_> Bug #1287147: [FFe] juju-core 1.18/2.0 [14:42] rogpeppe: when you get a chance, I committed fixes for the issues you brought up in the code review: https://codereview.appspot.com/69600043/ [14:43] natefinch: will look in a mo [15:17] rogpeppe: also if you could have a look at bug 1284183 whenever you get a chance, I'd greatly appreciate it. My team at Canonical keeps hitting it and its killing our velocity as we try to deliver a contract over the next two weeks [15:17] <_mup_> Bug #1284183: jujuclient.EnvError: [16:10] jam: https://plus.google.com/hangouts/_/76cpirbanp35boic60gobgfltc?authuser=1&hl=en === jam is now known as Guest22354 === Guest22354 is now known as jam1 [16:38] ev: i've just been looking at that bug with a view to trying to repro it [16:39] rogpeppe: yay! cjohnston can probably help get logs and things if you need them [16:39] ev: the repro instructions don't seem to work for me [16:39] he experiences it quite often [16:39] doanac and urshina as well, who I'll tell to join this channel [16:39] cjohnston: you've got a bare "sshuttle" line there, but sshuttle just gives me a usage message there [16:40] rogpeppe: you will need to do sshuttle for an instance you have.. I couldn't give you the exact command I use because it wont work for you [16:40] cjohnston: a sample command line? (i haven't used sshuttle before) [16:41] cjohnston: (and i'm not sure what you wanted it to do here) [16:41] Ursinha: just reproduced it [16:41] rogpeppe: sshuttle -r ubuntu@10.55.60.216 10.55.0.0/16 [16:41] rogpeppe: when using something like HP cloud you don't need it.. but you need it to use canonistack [16:41] cjohnston: i'm using ec2 [16:41] rogpeppe: we dont use ec2 because of the api [16:41] cjohnston: or the local provider [16:42] cjohnston: which api? [16:42] the ec2 api is different from hp/canonistack [16:43] (openstack API - we use glance and swift) [16:43] ev: it seems I hit the watcher bug every time I try to deploy using a fresh bootstrapped environment [17:14] mgz, jam1, fwereade: is the bot working yet? Just realized I marked stuff for merge, but there may be no bot to merge it [17:29] natefinch: nope [17:29] was going to fix today but have been under the weather [17:30] mgz: ok, no problem, just wanted to know what the plan was. [17:30] you can manually land things if needed urgently [17:31] ahasenack, no config-changed hook was being executed gratitiously.. there's a bug against that, i think its fixed in trunk [17:31] er. 1.17 [17:31] mgz: nothing's terribly urgent, it just would be nice, since I have other stuff that depends on it. [17:31] bloodearnest, the other crib sheet item is using the lxc stable ppa if not on trusty for aufs [17:34] hazmat: yeah, am on trusty so skipped [17:35] bloodearnest, so it worked out for you? [17:35] hazmat: I needed jujuclient 0.17 from PyPI (0.15 in trusty seems to have bug) [17:36] hazmat: and I could jlxc-add machines, buit the didn't come up properly - I think I may have encountered an issue in trust with local provider that was fixed today [17:36] hazmat: I will try again tomorrow sometime [17:36] bloodearnest, this doesn't use local provider [17:37] bloodearnest, jlxc that is [17:37] hazmat: good point, not sure why it didn't work then [17:37] bloodearnest, probably missing packages in your base snapshot [17:38] bloodearnest, needs git, cpu-checker at min [17:38] hazmat: it highlighted a bug in our charm anyway, someone rebooted a node and config-changed ran and highlighted an issue [17:38] same thing happens with a juju set, just turns out a reboot triggered it :) [17:39] fuzz testing [17:52] http://godoc.org/github.com/loggo/loggo#Formatter [18:09] hazmat - makes sense - will try again later [18:15] half of all open bugs marked high [18:15] hmm [18:24] hazmat: if they weren't important bugs, they wouldn't have bothered to log them [18:24] hazmat: I wonder what portion of the non-high bugs were created as high [18:29] natefinch, almost zero [18:29] sinzui, https://bugs.launchpad.net/juju-core/+bug/1219441 is fix committed or released (dev version) afaik [18:29] <_mup_> Bug #1219441: juju cli should cache api endpoint, saves up to 75% of run time [18:29] * hazmat goes bug weeding [18:30] hazmat, thank you very much! I too and looking for fixed or now wint fix bugs [18:31] sinzui, re high philosophy. are you abiding by lp severity help/description guidelines? or something else [18:31] ie. high for next release? [18:31] high is fix in the next 6 months [18:31] hazmat, If we want it fixed for 14.04, we should target to 2.0 [18:32] does juju work on rackspace? I can't find any documentation for it [18:32] or are my options HP and AWS [18:32] ev no [18:32] ev or digitalocean ;-) .. ie manual provider works everywhere. [18:33] hazmat: we need openstack APIs as we use glance and swift as part of this project [18:33] otherwise I'd be all over the AWS goodness [18:33] ev, there are some issues with rackspace and openstack provider due to lack of images, lack of security groups, etc. [18:34] ick, I'll cancel the account then [18:34] I wonder why there are other accounts inside canonical then? [18:34] * hazmat draws blanks [18:34] they gave some freebie accounts for ostack devs [18:35] ^ cjohnston don't bother with rackspace [18:35] ev: I saw [18:36] cool [19:07] wallyworld_: thanks for landing the branches yesterday [20:46] gah [20:48] niemeyer: do you know why this fails? args = append(args, "--", templateArgs...) [20:48] both args and templateArgs are []string [20:48] thumper: The variadic parameter must match the variadic parameter of the function [20:49] I would have thought that would work [20:49] so it isn't unpacking and repacking [20:49] just passing throughj [20:49] thumper: Right [20:49] hmm... [20:49] ok [20:49] thumper: I'm not sure if that's a good thing or not, or if eventually it'll just be more flexible [20:49] thumper: I suspect it's one of these "let's see how it goes" cases [20:50] it is just one of those "I would expect this to work and it doesn't" moments [20:50] thumper: I agree [21:03] * thumper falls foul of the fix bug and try again without rebuilding issue [21:15] ok, that isn't too crazy [22:30] thumper: go newbie question? [22:31] shoot [22:31] http://paste.ubuntu.com/7035472/ I'm getting the error: newConfig declared and not used on line 16 [22:31] At first, I thought block scope was stopping me from conditionally setting the variable. [22:31] But as long as I declare the var in the parent scope, it should work. I did a simple test in the playground: http://play.golang.org/p/rhxBZjqexA [22:31] So I'm stumped. [22:32] * thumper thinks he knows without looking [22:32] but looks anyway [22:32] right [22:32] you hit the same issue as wallyworld yesterday [22:32] newConfig should be used on line 38? [22:32] since you are using := it creates a new one [22:32] in that scope [22:32] you need to use = [22:32] aahhh [22:32] which may mean you need to declare [22:32] thanks [22:32] var err error [22:33] yep [22:33] cheers [22:33] np === thumper is now known as thumper-gym [23:16] wallyworld: I'm getting the following test failure: [23:17] # launchpad.net/juju-core/worker/rsyslog [23:17] worker/rsyslog/worker.go:19: import ...go/pkg/linux_amd64/launchpad.net/juju-core/log/syslog.a: object is [linux amd64 go1.1.2 X:none] expected [linux amd64 go1.2 X:none] [23:17] yet go version returns: go version go1.2 linux/amd64 [23:17] Any hints, off the top of your head? [23:18] try deleting your pkg directory to force it to recompile everything. i think you must have upgraded your go version and have old compiled artefacts hanging around [23:18] wallyworld: will do, thanks [23:34] wallyworld: 5min hangout? [23:35] waigani: i'm sitting in the tyre shop getting some tyres fitted. so i can't really do it now sorry [23:35] np [23:35] hopefully it will be finished soon [23:35] so I rm -rf pkg [23:35] it's quite an open office so i can't reslly talk [23:36] sure [23:36] now when I make check I get a LOT of those wrong go version errors [23:36] which pkg dir did you remove [23:37] ~/go/pkg [23:37] so your juju src lives under ~/go/src [23:37] yep [23:38] and if you go build ./... it fails? [23:38] did you recently install a new version of go [23:38] yes [23:38] well, a few weeks ago [23:38] this is the first time I've seen this error though [23:39] hmmm. it should have shown up immediately so there's something else at play [23:39] what else has changed? [23:39] hmmm... [23:41] wallyworld: go build ./... throws a whole bunch of the same errors [23:41] http://pastebin.ubuntu.com/7035788/ [23:42] a path problem maybe? [23:42] i.e. two different go excs running? [23:42] seems like it what does "which go" say [23:43] /home/jesse/go/src/code.google.com/p/go/bin/go [23:43] and that's where you installed go 1.2 to? [23:43] i think so, go I'll retrace my steps [23:44] what version does that report? [23:44] 1.2 [23:44] cause there will also be a /usr/bin/go [23:44] ah [23:45] why didn't you install to /usr/bin? [23:45] /usr/bin/go = 1.1.2 [23:45] wallyworld: good question! [23:45] there should be a ubuntu package for it [23:45] I'll do that now and see if it fixes it [23:45] there's something hppening i don't fully understand [23:46] but yeah, try and get only one version installed and see if tha helps [23:46] "go build -a" could also be tried [23:47] what does that do? [23:47] it just returned without output [23:49] you still need to tell it what to build [23:50] i was just saying use the -a param to force a rebuild of everything even if it thinks it's not out of date [23:50] iow go build -a ./...