[00:03] wallyworld: i don't see the value of pr 495 [00:03] i would not have approved it [00:03] CI already tests godeps works [00:03] me either [00:03] we don't need to run it locally [00:04] +1 for reverting it for more review [00:04] well, i'll talk to nate first [00:04] davecheney: wallyworld I think that was casuing CI some issues. They had issues with it today [00:04] wallyworld: that's +2 for revcerting it [00:04] that is a carrying margin [00:05] nate can always repropose it [00:05] nothing is lost [00:05] rick_h__: what issues do you know? [00:05] wallyworld: it was down and not functional for a bit. I know sinzui and he were chasing down things and trying to get something with deps right [00:05] wallyworld: sorry, only idly watched irc as I wasn't directly effected [00:05] np [00:05] wallyworld: I can check my logs for more info [00:05] wallyworld: but then this is logged right? [00:06] what is? CI output? [00:06] wallyworld: IRC [00:06] yes [00:06] i can search [00:07] davecheney: let's discuss real soon in juju meeting, then we can revert if needed [00:08] * thumper sighs [00:08] I wish our code wasn't so shit [00:08] * thumper thinks hard about hooking this up [00:34] thumper, I think I see a race in PR 555 (the downgrade one). Fixing it now. This also makes the code clearer around the bit that confused you. [00:34] ok, cool [00:45] natefinch: what happens if you run "ls -l /usr/lib/go/src/pkg/archive/zip" is there a .hg in there? [00:48] menn0: are you going to fix bug 1359435 ? [00:48] Bug #1359435: Next version selection for upgrades is no longer correct

[00:49] wallyworld, I just noticed that today incidentally while reviewing a PR from thumper [00:49] wallyworld, I had no intention of looking at it today [00:49] ok, ta [00:49] wallyworld, I'm unlikely to get to it this week and I'm off next week. [00:50] happy to look at it when I get back though [00:50] (if it's not fixed by then) [00:50] np, we'll get it sorted, i want to be able to release 1.20.6 early next week [00:53] coffee time... [00:54] wallyworld: how will we know if ci is happy with the windows build? [00:54] wallyworld: and when can we land the pending stuff? [00:54] thumper: i *think* it detects that the bug is fix committed [00:54] hence i marked it as such [00:55] but i'm not sure [00:55] regardless, there's still one critical bug open [00:56] one other [01:00] what is the other? [01:02] https://bugs.launchpad.net/bugs/1359170 [01:02] Bug #1359170: arguments no longer passed to plugins if you don't have an environment set

[01:03] * thumper digs [01:03] I had a look at john's fix for that [01:03] but disagreed with it [01:03] * thumper looks again [01:06] wallyworld: this isn't a critical regression though [01:06] wallyworld: this has been this way for quite some time [01:06] at least since someone change the env command to be the wrapper as it is now [01:06] thumper: i didn't mark it as a regression. i guess we can unmark it [01:06] * thumper removes the tag [01:07] * thumper marks it high, but not regression [01:07] and works on it [01:24] wallyworld: I'm getting the godeps errors now I've pull trunk too [01:24] \o/ [01:34] wallyworld: thumper see my reply to the mail thread [01:34] you already know my solution ... [01:35] seems reasonable to me :-) [01:37] me too :-) [01:44] wallyworld: thanks for the review. will make those doc updates and test again after rebasing [01:44] lots of changes from the windows PR... [01:44] sure, np [01:44] axw: i reverted it [01:44] wallyworld: oh? [01:44] one of the windows ones [01:44] the userdata one? [01:44] yep [01:45] it caused a regression [01:45] bugger :( [01:45] gabriel will be sad [01:45] my comment is in the revert [01:45] I'll take a look, thanks [01:45] axw: well, he MUST learn to test his stuff [01:45] i mean, you develop for windows, you test your stuff on windows before landuing surely? [01:51] minutes for handout in 10 mins are https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit [01:51] please add items to discuss [02:14] wallyworld: I'm asking ben howard for access to Azure China for testing - is there anyone else who should have access? [02:15] axw: we're all in the juju core meeting :-) [02:15] oops [02:15] * davecheney insert paddling [02:27] https://github.com/juju/juju/pull/567 === Ursinha is now known as Ursinha-afk [02:46] wallyworld: Internet is scheduled for connection today, btw [02:46] could be up to 48h before it's active tho [02:47] axw: let's hope they do it on time :-) [02:47] does anyone know if its possible to ssh from a state server to an agent? (meaning, do we have a private key in place that is allowed on the agents?) [02:52] axw or wallyworld : any chance you can have a look at this? https://github.com/juju/juju/pull/566 [02:52] sure [02:53] perrito666: yes, i believe so, that's how juju run works, right thumper ? [02:53] * thumper looks up [02:53] wat? [02:53] perrito666, yep, there's an identity file that you can use [02:54] right [02:54] yes [02:54] I think it is in /var/lib/juju/identity [02:54] use with "ssh -i ..." === Ursinha-afk is now known as Ursinha [03:00] anyone? https://github.com/juju/juju/pull/568 [03:01] wallyworld, thanks [03:02] np [03:02] looking [03:05] wallyworld: inlining now... [03:06] ta [03:06] wallyworld: can you kill http://juju-ci.vapour.ws:8080/job/github-merge-juju/364/console [03:06] it's not going to pass [03:06] sure [03:07] ta [03:22] look at that merge queue... it's a thing of beauty :) [03:33] where is the merge queue? [03:33] menn0: ? [03:35] thumper, I mean all the jobs queued up here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/ [03:35] it was longer before [03:47] wallyworld, the 1.20 backport of what you just reviewed for me: https://github.com/juju/juju/pull/569 [03:47] can you pls have a look? [03:48] \o/ [03:48] yep [03:49] menn0: 1.20 is a lot different isn't it [03:50] wallyworld, yeah the upgrade code has changed a lot so the backports are non-trivial [03:50] wallyworld, I don't see much more upgrade stuff being backported to 1.20 now though [03:50] this PR might be the last one (wishful thinking anyway) [03:50] menn0: my only concern is that maybe there is a test or two missing that may be needed in the backport? [03:51] wallyworld, the other tests that were in trunk don't make sense in 1.20 [03:51] b/c upgradeWorkerContext doesn't exist in 1.20 [03:51] rightio [03:51] done, thanks for fixing \o/ [03:51] the higher level test that I did include does cover the change though [03:52] wallyworld, well I made the problem too so don't thank me too much :) [03:52] ok, thanks for nothing then :-) [03:53] menn0, that's more like it :) [03:53] wallyworld, even.... tiiiirrred [03:53] lol [03:53] menn0: the first sign of insanity is talking to yourself [03:54] wallyworld tells wallyworld that all the time [03:54] LOL [04:21] menn0: i thought the definition of insanity was trying to submit a pull request over and over again and expecting differnt results [04:21] davecheney, if that' the case then we're all a little bit insane [04:32] * thumper is done for the day (until meetings tonight) [04:32] * thumper afk until 10pm local === thumper is now known as thumper-afk [04:33] wallyworld: thumper-afk axw https://github.com/juju/juju/pull/571 [04:33] ^ this PR tries to peal off the most dangerous parts of 556 [04:33] i'd like to submit tihs today and see if CI burps overnight [04:34] then push 556 tomorrow [05:15] davecheney: commented [05:23] axw: thanks, good suggestion [05:23] give me a few minutes [05:24] sure, ping me and I'll take another look [05:39] axw: PTAL [05:41] davecheney: LGTM [05:41] axw: thanks, lets see if this asplodes ci overnight [05:45] morning all [06:19] axw: can you take a peek at this one for me? https://github.com/juju/juju/pull/574 [06:19] sure [06:29] thanks axw [06:30] wallyworld: hmm, should we be throwing away non-public addresses if they have the same IP address component? [06:30] wallyworld: I think we may only want to throw away if it's public... [06:30] otherwise that changes the internal address selection [06:30] hmmmm [06:31] when could there be two addresses, same IP, but one marked public, one marked private? [06:31] wallyworld: if the floating IP returns the same as a private address range? [06:31] un moment [06:32] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1348287/comments/4 [06:32] it won't do that - floating ip addresses are public [06:32] Bug #1348287: Juju status returns private IP in 'public-ip' field.

[06:33] the problem was that their public and private ip address ranges were both 10.x.x.x [06:33] so juju couldn't guess which one was public [06:33] but there will never be 2 addresses with the same IP, that doesn't make sense [06:34] well the auto-detection logic will classify it as private [06:34] because it's in the 10. range [06:34] but... [06:34] I think the floating IPs will always come from a separate pool [06:34] yes, which is why we mark it as public [06:34] so that's ok [06:35] ie the provider knows that a 10.a.b.c address is public if it is the floating ip address which was assigned [06:35] wallyworld: the point I'm trying to make is that we shouldn't disqualify that address from use in internal communications [06:35] sure, but juju will guess that it is private when it is not [06:36] i do think that if it is known to be a floating ip address, it should be marked as public and nothing else [06:36] public/private are relative. they may be the same thing depending on where you are. anyway, it doesn't matter because they'll be separate address ranges still [06:37] what worries me is that would could have in juju status both public and private be the same address [06:37] because the floating one was guessed as private and so was picked [06:38] and hences masks the true private address [06:44] axw: do you agree with my statement above? [06:45] wallyworld: sounds sane [06:45] righto [06:45] thanks [07:13] axw: i killed your job because it was going to fail [07:13] trusty vs precise test failure [07:13] wallyworld: yeah, I noticed, but doesn't killing it orphan the ec2 instance? [07:13] hmmm, yeah maybe [07:14] i'll ping curtis later to clean up [07:14] gotta run to soccer, back later for meetings \o/ [07:14] wallyworld: actually looks like it may have run the terminate script [07:14] adios [07:18] wallyworld: o/ [07:18] axw: morning [07:18] voidspace: howdy [07:19] any news on where the october sprint will be? [07:19] I'm in India until October 5th [07:19] sprint starts on the 6th... [07:20] voidspace: I have not had an official answer [07:21] voidspace: i heard brusssles [07:21] axw: I haven't heard anything either [07:21] but that was not confirmed [07:21] davecheney: that would be cool [07:21] davecheney: I mean, literally cool [07:21] Brussells in October [07:21] hmm, neither of us can spell Brussels it seems [07:21] I'm still not convinced I've got it right [07:21] Bruxelles [07:22] :p [07:22] yet we can still communicate our intentions perfectly [07:22] :-) [07:22] if only computers worked like that... [07:22] \o/ evolution [07:25] hello, could anyone have a look at #1325946 for Landscape? it should be a no-brainer backport to 1.20.x [07:25] Bug #1325946: Can't start named MAAS instances if environment is named kvm or lxc

[07:32] free: I will have some spare cycles shortly and will see if I can get to it [07:32] free: unless someone else beats me to it... [07:32] voidspace: thanks! [07:32] voidspace: is there already a target date for the next 1.20.x release? [07:32] free: that I don't know, it would depend on sinzui [07:33] free: but we seem to do them fairly regularly, he's pretty efficient [07:33] voidspace: alright, would be great to have this little backport in the next one [07:33] free: understood [07:33] free: I can see the motivation from the bug report :-) [07:33] voidspace: he :) [07:34] free: for the record, we're actively working on "multi-tenant state servers" [07:34] free: which means that api calls won't automatically be scoped against a specific environment [07:34] voidspace: gotcha [07:35] voidspace: we're fine passing the UUID (as opposed to the name) [07:35] free: yep, understood - and we need to be aware of that constraint [07:39] morning [07:39] TheMue: morning [07:43] TheMue: so the issue is that if you back out your fix, the test doesn't fail, does it? [07:43] because we are essentially testing that set.Help() == set.Help() [07:43] and *not* testing that the contents of setDoc are the contents of set.Help() [07:44] So for checking "is set registered" it works fine, but for testing whether the actual content is sane, it doesn't quite cover it. [07:44] jam: morning o/ [07:44] coffee [07:44] brb [07:44] morning voidspace [07:44] jam: hmm, than I took to test of the deploy help wrong [07:45] TheMue: so there is 2 things that are good to test, (a) that "juju set" exists as a command, and (b) that the content of "juju set --help" contains what we want it to. [07:45] Some people like to have tests like: c.Assert(helpText(), gc.Equals, `The content of the help text`) others feel like you shouldn't repeat yourself, as it means you have to update too many tests when something changes. [07:46] TheMue: However, the test you added *wouldn't* have caught that changing setDoc doesn't change the output of "juju set --help" [07:46] because it is effectively testing that [07:46] c.Assert(set.helpText(), gc.Equals, registeredHelpText("set")) [07:46] The "deploy" help has the same problem [07:47] jam: IC [07:47] as does sync-tools help [07:47] jam: you said you added a good test. could you point me to it? [07:47] TheMue: I can understand that people feel "the help text is com [07:47] combined from 3 different places, and it is clumsy to just report it [07:47] " [07:48] TheMue: I believe I added the sync-tools one, but it suffers from what I just observed. [07:48] I had written that test to check for (a) [07:48] but I realize now that (b) would be useful to have [07:48] and we don't [07:49] TheMue: actually, when I wrote the test, I think I actually did: c.Assert(registeredHelpText("sync-tools"), gc.Equals, syncToolsDocString) [07:49] TheMue: but now that we have stuff like EnvironCommandWrapper [07:49] the *actual* help text is a bit obscured from just the raw string we have somewhere. [07:50] So I'm wondering if we would benefit from splitting the test we have into actual concrete comparisons [07:50] jam: OK, so a good test would be, for each command, to retrieve the help by executing the command and compare it to a variable where the help text is stored (like setDec) [07:50] TheMue: or whether people would complain too much about having to update a test when they tweak the help content. (I happen to like the safety-net of tests) [07:50] TheMue: actually, my preferred is to compare it to a local string [07:51] TheMue: so in the table, "out: " would contain the actual help text string [07:51] jam: *iiirks* [07:51] jam: TheMue: for similar tests in the past I've just done a "contains test" [07:52] jam: but then we would have to do it for args and purpose too, just to be consistent [07:52] jam: TheMue: i.e. not duplicating the full text in the test, but asserting that it contains "some relevant part that we require it to contain" [07:52] * TheMue is reminded of UI tests in unit tests [07:52] which is less clumsy to maintain and still tests (somewhat) that the output is being generated correctly [07:52] TheMue: voidspace: so some of it is "the output of juju set --help is something that I'd actually like to read" [07:53] and having it all in one place rather than just "contains" helps with that. [07:53] voidspace: that wouldn’t work if we for example add some content [07:53] TheMue: well, it wouldn't *fail* [07:53] TheMue: voidspace: I don't think people today (core developers for example) are actually running "juju help $COMMAND" and reading all of it to actually know if it makes sense. [07:53] jam: yes but it's still horrible [07:53] voidspace: if you don’t change the test it won’t fail [07:53] TheMue: but is "adding some text" something you want to test [07:54] TheMue: and if it is it's easy to test [07:54] TheMue: you can have several contains tests if there are several important parts [07:54] voidspace: it might be good to know that you *didn't* add "and you're all a bunch of a$$hats" to every command :) [07:54] jam: and copying and pasting output into a test doesn't actually test readability at all [07:54] jam: inside the tests we have access to setDoc and co. so I would like the convention that doc never is set directly, but always via a variable and we compare the output to that variable [07:55] TheMue: I'm reasonably ok with that as a compromise. [07:55] TheMue: I think juju core could benefit from someone actually spending time reading the various help texts and how they reference eachother, etc. and actually make that a nice experience for users. [07:55] that doesn't have to be done via the test suite, though. [07:55] jam: so I could add a TestAllHelps and change the code to fit this convention. it’s good for a table driven test. :) [07:55] * voidspace really goes to get coffee [07:56] jam: when refactoring the code this way I would spend some time in reviewing the help texts [07:57] jam: the quality can’t be tested, but at least it’s a good opportunity to do so [07:58] TheMue: my idea in having the full content there (after all generation steps) is that when auditing a change, you can see what the actual final outputs are. Though I realize that then when "-e" gets slightly different wording, it ends up changing 50 different commands' help content. [07:58] though that is, honestly, just a search and replace, right? [08:01] jam: for later changes I’m with you, it’s no problem. I only have my troubles with the duplication of all output [08:01] jam: but hey, it’s not double in the binary, it’s only in the test [08:01] jam: so it’s ok [08:01] TheMue: there is the concept of Dont Repeat Yourself [08:02] and I want to be tasteful here [08:02] and people certainly have different opinions in this. [08:02] I'm just putting forth a thought. [08:02] That maybe nobody actually knows what all the help texts say because we hide it in all of our layers and wrappers, etc. [08:03] Yeah, there’s a lot of indirection. [08:03] TheMue: and we have stuff where "global" help settings don't show up in the default "juju set --help" [08:04] From a quality point of view it definitely would be better to ensure a correct output (but not the quality of the output). [08:04] TheMue: "juju help global-options" shows you options that are available but aren't shown in "juju help" or "juju help set" [08:04] But having all texts repeated in one file would make it easier to look for a consistent help and wording [08:04] and "juju help set" doesn't *tell* you about "juju help global-options" you have to find it from "juju help topics" [08:05] We hide features, not good. :/ [08:06] TheMue: I'm pretty sure thumper did it intentionally to avoid cluttering the short help, but I *think* we at least want a one-line reference so it can be discovered. [08:06] So a change like this would have to goals: 1. ensure that the shown help is the correct one but even more important 2. that it has a good quality, is consistent and complete [08:16] wallyworld: ping [08:17] or anyone that has installed Go from a PPA - i'd like to try find out why godeps is failing in that case [08:46] rogpeppe1: mine is just from the archive, I think, and it is failing [08:46] rogpeppe1: https://bugs.launchpad.net/bugs/1359573 [08:46] Bug #1359573: API inconsistency: machine tag vs id

[08:46] sorry [08:46] ii golang-go 2:1.2.1-2ubunt amd64 Go programming language compiler [08:46] ii golang-go 2:1.2.1-2ubunt amd64 Go programming language compiler [08:46] $ godeps -t ./... [08:46] godeps: no version control system found for "/usr/lib/go/src/pkg/go/build" [08:46] godeps: no version control system found for "/usr/lib/go/src/pkg/bufio" [08:46] jam: what does this program print for you? http://paste.ubuntu.com/8104597/ [08:47] jam: and what's the exact output you get from "godeps -t ./..." ? [08:47] rogpeppe1: http://paste.ubuntu.com/8104605/ for the latter [08:48] rogpeppe1: $ ./goroot [08:48] /usr/lib/go [08:48] jam: and does godeps actually produce a non-zero exit code? [08:49] rogpeppe1: $ godeps -t ./... 2>/dev/null ; echo $? [08:49] 1 [08:49] yeah [08:49] exit 1 [08:49] jam: i think i know what's going on now, thanks. the fix should hopefully not be hard. [08:50] rogpeppe1: I'm around if you need me to poke at stuff [08:50] jam: thanks - i may well ask you to try an updated version. [09:01] wallyworld, around? [09:02] wallyworld, https://code.launchpad.net/~lutostag/gomaasapi/fix_nonce_generation/+merge/231638 [09:02] that seems like a hack to me and not a proper fix [09:02] aren't we just changing the odds that we'll hit that bug again rather than properly preventing it? [09:21] wallyworld, nevermind [09:25] who is OCR today? [09:27] and the title is incorrect as neither of those two bugs are critical and open [09:27] doesn't look like I'm allowed to change the title though [09:28] voidspace: it can be changed via mup [09:28] TheMue: ah, ok [09:29] voidspace: but have to remember the syntax myself :) [09:29] TheMue: do you know the magic incantation? [09:29] heh [09:29] voidspace: and btw, even without being ocr I just reviewed your PR [09:29] TheMue: ah, cool - thanks [09:30] voidspace: today Nate and Menno are OCRs [09:30] TheMue: thanks [09:30] I was just looking for the doc [09:30] not sure if I have it starred [09:30] I should do [09:31] yeah, simplifies the quick access [09:31] it's slow to calculate [09:31] I have it starred now [09:32] TheMue: the one I really need reviewing is this one: https://github.com/juju/juju/pull/561 [09:32] TheMue: the other one was reviewed to death already ;-) [09:33] voidspace: *lol* [09:33] voidspace: OK, will take a look [09:33] TheMue: I don't understand your comment "why two asserts?" [09:34] TheMue: I don't see two [09:34] TheMue: maybe I'm being dense [09:34] TheMue: and I have a philosophical objection to testing that we don't do things [09:34] even where it is something we used to do [09:34] because such tests build up and don't really test anything useful anymore [09:36] voidspace: provider/openstack/live_test.go lines 183 and 184 [09:36] TheMue: ah, 184 isn't shown in the snippet [09:36] I'll look [09:37] TheMue: the answer maybe, "you'll have to ask the person who originally wrote the test" - but I'll look :-D [09:37] voidspace: yeah, I won’t test it too, but in this case you do a change. something that has been open before is now closed. the test would document it. [09:37] TheMue: the test would document something that doesn't happen [09:37] TheMue: there are an infinity of things that don't happen we could document [09:37] voidspace: I know it hasn’t been done by you, I only seen it [09:37] it just becomes a historical note [09:37] TheMue: sure I'll look [09:38] TheMue: the test makes sense at the time you write it, but not after that [09:38] voidspace: yes, a documentation of the change, not of what doesn’t happen [09:38] TheMue: as I said, I object... [09:38] I don't think our tests should be a historical archive [09:38] they should document what we do, not what we used to do [09:39]