[00:25] thumper: pingy [00:31] wallyworld_: hey [00:31] thumper: i'd like to be able to land the joyent provider code as i think william wants it in my tomorrow [00:31] i have it working [00:32] http://165.225.148.189/wp-admin/install.php [00:32] but it's a huuuuuuge branch [00:32] since it has been developed all in one go [00:32] * thumper nods [00:32] and i've taken what was there and modified it so it works [00:32] how much outside provider/joyent is there? [00:32] none [00:32] ok, lets do it [00:32] i have another branch i'm doing [00:33] which does outside work [00:33] fixes some other stuff [00:33] ok [00:33] can we land it but not enable for the first cut? [00:33] that way we can still release 1.18 off trunk [00:33] but the code is a least there [00:33] thumper: yes, i want to land https://codereview.appspot.com/82050043/ [00:33] and i will have the other work done today [00:33] * thumper looks [00:33] which will allow the provider to work as per the link i pasted above [00:34] do you want a real review [00:34] or a cursory look? [00:34] the latter :-) [00:34] heh [00:34] i know there's stuff to do [00:34] ok [00:34] but we can iterate [00:34] agreed [00:34] i have clean uop a lot [00:34] but i ran out of steam [00:35] * thumper looks [00:35] a lot of the work is not mine [00:36] i branched off daniel's work and did stuff to get it going [00:36] wallyworld_: thumper i say if it commits cleanly an the bot gives it the green light [00:36] commit it [00:37] davecheney: and it works :-) http://165.225.148.189/wp-admin/install.php [00:37] wallyworld_: LGTM [00:37] lets get it landed [00:37] davecheney: also, i added a comment to the RT cause outgoing ssh did not work for me [00:37] wallyworld_: balls [00:37] i tried from rockne-03 with no luck [00:37] wallyworld_: we might have to put the breaks on that [00:37] arosales: said I should work on local and manual providers [00:38] and I guess maas [00:38] because those are what we would use to demo ppc [00:38] ok, i think ppc will work fine, just want to verify [00:38] wallyworld_: same [00:38] i want to verify as well [00:38] but i've been told a few times now not to proritise it [00:38] so i'm not doing any dev work as such, just testing [00:38] so I sohuld be smart and start listening [00:40] thats what my wife says [00:40] but less politely [00:49] wallyworld_: your wife sounds smart [00:50] she is, but not so smart she didn't marry me [00:50] davecheney: are there bugs filed for the failing power tests? [00:50] thumper: i am raising them as I work on them [00:50] ok, how many failures do we have? [00:50] thumper: i don't have an exact cound [00:51] less than we had last week [00:51] please hold [00:51] doing a test run at the moment === Daviey_ is now known as Daviey [01:19] wallyworld_: in case you haven't seen this already: #1299802 [01:20] <_mup_> Bug #1299802: upgrade-juju 1.16.6 -> 1.18 (tip) fails [01:20] oh :-( hadn't seen that [01:20] looks like an upgrade steps thing, maybe [01:21] could be, i'd have to trawl through the log [01:21] i think if something fails, the desired version remains as it was [01:22] ah ok [01:30] _thumper_: http://paste.ubuntu.com/7182728/ [01:30] current state of play [01:31] _thumper_: https://bugs.launchpad.net/juju-core/+bug/1299958 [01:31] <_mup_> Bug #1299958: worker/peergrouper: test failure

[01:31] working on this one now [01:35] _thumper_: the big difference between gccgo/amd64 failures and gccgo/ppc64 failures is there are no test fixtures for ppc64 [01:35] _thumper_: I will raise an issue for this by COB [01:37] * _thumper_ nods === _thumper_ is now known as thumper [01:49] wallyworld_: sorry, what was that branch again? [01:49] axw: lp:~wallyworld/uju-core/remove-provider-addr-methods [01:49] davechen1y: hello, would it be more useful to run juju tests on arm64 from the latest release or bzr tip? [01:50] ta [01:54] davechen1y: also, is the fix for that test linking bug in trusty yet? [01:55] hm seems like it should be [01:56] why am i still seeing linker errors then :( [01:58] davechen1y: just proposing a fix for the bzr test failure [02:01] davechen1y: https://codereview.appspot.com/82250045 [02:06] thumper: /me looks [02:06] mwhudson: make sure you have gccgo-go 1.2.1 [02:06] then you're good [02:07] thumper: +1 [02:07] axw: do you think your logging dir config changes would have fixed this: https://bugs.launchpad.net/juju-core/+bug/1298663 ?? [02:07] <_mup_> Bug #1298663: juju debug-log broken in 1.17.6

[02:07] * axw looks [02:08] thumper: yeah I think so [02:09] thumper: I will find the bug and set as dupe [02:09] $ dpkg-query -W gccgo-go [02:09] gccgo-go 1.2.1-0ubuntu1 [02:10] mwhudson: yup [02:10] there is one package that still fails to link [02:10] it's on my list [02:10] ok [02:10] davechen1y: is your list online somewhere? [02:12] mwhudson: i email it daily to a shittone of people [02:12] davechen1y: feel free to add me to the list :-) [02:12] mwhudson: https://docs.google.com/a/canonical.com/document/d/1aKWR3kDzS5Og6PXxe9m98Xea75ScVrGWIZ95rSQIdTM/edit [02:12] all bugs are tracked in lp [02:12] there is no separate bug list [02:12] the list of bugs tracked in lp is not exhaustive [02:12] thanks [02:13] thumper: https://bugs.launchpad.net/juju-core/+bug/1299969 [02:13] <_mup_> Bug #1299969: launchpad.net/juju-core/provider/manual: ssh tests are not properly isolated

[02:13] looks similar to the bzr bug [02:14] wallyworld_: we should be able to remove public/private address from the unit doc too, right? [02:14] wallyworld_: if we always wait for the machine to have addresses first [02:14] axw: yeah, when we can support schema changes [02:14] wallyworld_: true. we can just ignore it for now I suppose [02:14] though it is already, if the machine has addresses [02:14] yeah, i was going to remove the api first [02:15] sounds good [02:15] the thing i'm up against now - can subordinate units have addresses? [02:15] i'd like to say no [02:15] will make the refactoring simpler, otherwise i'll need to add a bunch of extra code [02:16] wallyworld_: from the docs, "Subordinate units inherit the public/private address of the principal service." [02:16] how that's implemented I don't know [02:17] it uses the provider addresses [02:17] the ones i want to delete [02:17] which is kinda sucky [02:17] I mean how the subordinate inherits from the principal... [02:17] same machine, so it'll just work I guess [02:18] wallyworld_: where's that code? [02:18] yeah, but the current assumption is the provider.PublicAddress() works [02:18] state/unit.go [02:19] wallyworld_: right, but there's nothign special about subordinates there... is there somewhere else? [02:19] wallyworld_: what extra code do you need to land? [02:19] sec [02:22] axw: i think it's in worker/unit/modes.go which calls unit.SetPrivateAddress() which it gets from the provider [02:22] wallyworld_: we may be able to get away without waiting for addresses. you may need to check with fwereade or someone else [02:22] wallyworld_: yeah but what's special about subordinates there? [02:23] wallyworld_: they still live on a machine, and they'll still get their addresses from the machine [02:23] axw: nothing, but that's how subords get the unit doc address set [02:23] that's only used if its machine doesn't have addresses [02:23] axw: the unitDoc for sub ords has machne id = "" [02:23] oh [02:23] right [02:23] so the machineAddresses() bt fails [02:23] so, we need to use its principal's machine rather [02:24] so i need to look up the principal unit [02:24] but the state apis return no error :-( [02:24] no error for what? [02:24] so i have to do it at the api level or chaneg the method [02:24] PrivateAddress() [02:25] so if i want to look up princiap unit, get assigned machine etc, i need to cater for errors [02:25] nor does addressesOfMachine if Machine() errors at the moment [02:25] I don't think this is any worse [02:25] true, still sucks though :-( [02:25] but yeah [02:26] davechen1y: thanks for the for the work on manual [02:26] arosales: http://165.225.148.189/wp-admin/install.php [02:26] wallyworld_: thanks for landing the joyent provider [02:26] 105 of 141 launchpad.net/juju-core/... package tests fail :/ [02:27] wallyworld_: is that off joyent? [02:27] yep :-D [02:27] wallyworld_: woot \o/ [02:27] well done [02:27] wallyworld_: any work arounds in place or can I have folks start testing? [02:27] got a few follow up branches to land to fix juju core stuff [02:27] ah ok [02:27] wallyworld_: good stuff [02:28] arosales: i'll land the stuff by today or tomorrow [02:28] wallyworld_: give me a mail when trunk is ready for general testing [02:28] wallyworld_: thanks [02:28] sure, welcome [02:28] * arosales returns to dinner [02:31] wallyworld_: in addressesOfMachine, you can just use AssignedMachineId instead of u.doc.MachineId [02:31] that'll do the right thing for subordinates [02:32] yeah [02:32] wallyworld_: deployed a charm to azure, it got addresses [02:32] wallyworld_: anything in particular you want me to test? [02:32] axw: nah, just a smoke test, that's great thanks [02:32] lots of code to delete \o/ [02:33] although [02:33] (t-mwhudson)mwhudson@am1:~/juju-core-1.17.7$ date [02:33] Thu May 7 09:01:27 UTC 2150 [02:33] ^ this may be responsible for some of the failures [02:33] wallyworld_: yeah, looks like a nice branch :) [02:33] will get better :-) [02:35] mwhudson: sad trombole [02:35] davechen1y: yay shared porter hardware [02:36] da f [02:36] 2150 [02:36] unix time goes that high ? [02:36] well, I guess an int is 8 bytes big [02:36] on mar64 [02:36] on arm64 [02:36] yeah, i guess it does on arm64? i have no idea what this is about [02:36] hyperactive real time clock [02:39] fixing that makes 30 more packages' tests pass [02:40] hmmf, lots of this: [02:40] panic: runtime error: invalid memory address or nil pointer dereference [recovered] [02:40] panic: runtime error: invalid memory address or nil pointer dereference [02:40] [signal 0xb code=0x1 addr=0xa0] [02:41] which is a bit of a worry [02:43] oh, it's some pointer being null inside mgo [02:43] oh heh, helps to have juju-mongodb installed i imagine [02:45] bah [02:48] thumper: thanks for review. i can land disabled for now but when i propose the followup branch to fix the juju-core address issue i should enable then as 1. i've been asked to get it into trunk so people can test 2. it's ment to go into 1.18 [02:52] hm, where do logger.Debugf messages end up when running tests? [02:54] wallyworld_: ok [02:54] mwhudson: into the gocheck log [02:55] mwhudson: assuming that you are using something that has the LoggingSuite contained [02:55] thumper: which is ... ? [02:55] running with -gocheck.vv doesn't make anything appear [02:55] is it going into some file somewhere? [02:55] no, the log is only shown if a test fails [02:55] well it's panicking? [02:55] does that count? [02:55] mwhudson: hmm... [02:56] * thumper looks at the code [02:59] mwhudson: c.GetTestLog() [02:59] mwhudson: returns a string [03:01] uh [03:01] thumper: thanks [03:01] although i think this is a silly bug [03:02] http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/testing/mgo.go#L112 <- this debugf only makes sense if there was no error right? [03:02] i.e. it should be in an } else { from the preceding test [03:02] because if inst.server is null it goes bang [03:04] err [03:05] oh do i have to put the juju-mongodb binaries on $PATH explicitly? [03:05] ... yes [03:08] yes [03:08] although I think perhaps the test harness should fix that for you IMO [03:09] the failure mode is certainly impressively obscure :) [03:12] ok the tests are taking much longer now, that's a good sign :-) [03:17] down to 20 failures [03:17] much better :-) [03:17] * mwhudson goes home [03:37] axw: do you know if instance polling works as expected for the manual provider? I would assume so [03:38] wallyworld_: it won't do anything for machines other than machine-0, since hte manual provider does not manage instances [03:39] wallyworld_: the machiner will update machine addresses though [03:39] cool, just checking that removing those methods off manual env provider won't brek stuff [03:39] wallyworld_: actually, just a moment. it might. [03:41] wallyworld_: ah no, addresses are recorded at provisioning time too [03:41] so all good? [03:41] wallyworld_: and the hostname is recorded as public [03:41] yeah should be good [03:41] i'm going to test local provider [03:41] i think maas should be ok [03:45] is anyone seeing this error on trunk? http://paste.ubuntu.com/7168714/? [03:46] ^^ I'm guessing not as things seem to be landing - but I've not changed anything in my branch that 'should' have affected this === vladk|offline is now known as vladk === vladk is now known as vladk|offline [04:31] anybody know windows? [04:34] hazmat: "this is unix, I *know* this". but yes, I have some familiarity [04:35] jam, so i've got a user trying to use the digital ocean plugin on windows.. and the path the plugin code thinks juju is at doesn't quite line up .. i'm just using os.path.expanduser("~/.juju") (taking into account JUJU_HOME) [04:36] jam, https://github.com/kapilt/juju-digitalocean/issues/16 and https://github.com/kapilt/juju-digitalocean/issues/15 [04:37] juju is not very go-gettable is it [04:37] jam, going through the juju-core code at the moment trying to see the delta.. ic.. HOMEDRIVE and HOMEPATH.. [04:37] hazmat: I'm pretty sure we don't use $HOME on Windows for our .juju dir, but use the %APPDATA% magic. So probably we need a helper in juju-core that gives you the path to look in [04:37] mischief, it is.. but go dep management needs help.. [04:37] hazmat: juju/osenv/home.go APPDATA [04:37] mischief, you go get.. cat dependencies.tsv.. update the various branches [04:37] yea, i just tried to go get and some package api has changed [04:37] ah [04:38] mischief, there's some tool that will read dependencies.tsv and do it for you [04:38] jam, thanks [04:38] i would like that :) [04:39] mischief, go get launchpad.net/godeps .. see bottom of CONTRIBUTING.txt [04:39] er.. minus the .txt [04:40] hmm.. interesting thats docs on how to generate but now how to use [04:44] jam, so reading through home.go .. its a bit unclear are the functions in in osenv/var_windows.go used.. else it just looks like return os.environ['APPDATA'] but that looks like its some how being setup by magic [04:44] and in this context the plugin is in a separate process.. not clear if its gets it own APPDATA or if it inherits. [04:44] hmm [04:45] hazmat: so Home() != JujuHome() [04:45] hazmat: APPDATA is windows place to put your application stuff [04:45] it is C:\Users\$USER\AppData\Roaming\ [04:45] hazmat: and then we put our own "Juju" under that [04:45] jam, right.. but JujuHome() calls Home() on linux.. but not [04:46] hazmat: right [04:46] on windows [04:46] hazmat: on Windows we don't put it in $HOME [04:46] so osenv.JujuHomeDir() is what you should be using. [04:46] but we have functions to determine Home() on windows from other env vars [04:46] k [04:46] yup.. that should do it [04:46] thanks [04:46] hazmat: we also support $HOME for some other reason [04:52] hmm.. not sure this is going to work.. juju docean depends on an ssh binary [04:53] hazmat: ok finally done [04:53] now i am finally building jujud :) [04:53] i never used godeps before, but it certainly does solve the dependency tracking problem [04:53] there are many tools like it [04:55] mischief, yup.. lack of leadership .. fragemented ecosystem tooling for basic problems.. i think there's roughly a dozen different paradigms and tools for this issue. [05:00] hazmat: well, I have ssh on my windows box [05:00] you can certainly get one [05:00] jam, putty, etc.. but not openssh i presume [05:01] hazmat: both git and cygwin give you openssh [05:01] jam, i recommended they use cygwin.. [05:01] yeah [05:01] and you *can* build it natievly somehow [05:02] fair enough.. but that's not happening (be building it for users) i can't really support that effectively.. and afaics neither does openssh.. http://www.openssh.com/windows.html [05:02] s/be/me [05:03] better would be if i could get digital ocean to support userdata/cloudinit and drop the ssh entirely.. but need them to implement it.. slowly getting more votes on it.. http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3736274-support-cloudinit-instance-metadata [05:18] hazmat: it would still appear there is a problem, after use of godeps -u [05:31] http://sprunge.us/GAAV [05:33] i guess i'll use ubuntu ._. [05:58] As most people do. [06:09] fwereade, jam, i'd appreciate a review on this so i can land it https://codereview.appspot.com/80600044/ [06:12] dimitern: the first thing that comes to mind is that I thought we specified it as "--network/--exclude-networks" for the Juju deploy command line. 'no-networks' being a MaaS API name, but not as user-friendly. [06:13] jam, maas'es is actually not_networks, but fair enough --exclude-networks it is [06:14] jam, and you mean --networks right, not --network for the other one? [06:14] dimitern: well, they should be the same plurality [06:14] *I* like plural form (networks) [06:14] jam, btw is our 1-1 in 15m or in 1h 15m ? [06:14] I think fwereade was asking for singular [06:14] dimitern: 1h15m [06:15] jam, ok [06:15] jam, i don't recall that [06:16] I certainly recall it, because I remember disagree on this case. We have "--constraints" which is a plural for something that might be one but can hold many [06:16] I think --networks fits well in the same vein [06:16] +1 [06:17] thumper: https://codereview.appspot.com/77970043/ [06:19] jam, i found a bug 1299114 in maas when adding networks [06:19] <_mup_> Bug #1299114: 'ValidationError' object has no attribute 'error_dict' when creating a network [06:20] jam, now I'm in the process of exporting and uploading to u1 21GB disk image [06:20] (now my 100mbps fiber will come in handy :) [06:21] jam, re what fwereade said about mocking api requests to test 1.16 compat code path - any ideas? [06:22] dimitern: I did not, I just did manual testing for most of the cross version compat code. [06:24] jam, yeah, me too; i was thinking of trying to mock it, but there are too many levels of indirection to make it cheap to do [06:26] yeap [06:26] If we had it in place before, then I would certainly use it. [06:56] fwereade, rogpeppe1 does one of you have a spare moment to help me out with a test that's failing? [06:57] mattyw: sure [06:57] mornin' all [06:57] rogpeppe1, morning! [06:57] mattyw: how's tricks? [07:07] morning! [07:11] dimitern, jam: sorry, I must have misremembered the mocking -- and I'm fine with --networks/--exclude-networks, I think that was what we agreed? if my preference for singular seems insane to you both then let's go with plural [07:12] fwereade, plural seems more appropriate [07:14] * fwereade has another public holiday, yay malta, and so I have laura at home, and will not be getting much work done [07:14] but fwiw I will be reviewing things flagged in the channel when laura is otherwise occupied [07:15] rogpeppe1: taking it over here [07:15] rogpeppe1: ok, understand doing it at bootstrap-state because peergrouper isn't working. for #2, the only address will be machine--0 right? then the client already has the address...? [07:15] machine-0 rather [07:16] fwereade: this already has a +1 but just in case there's something that raises any red flags, it would be great if you did get to look at https://codereview.appspot.com/82470043/ [07:16] the client already has the address it used to dial, but there might be other addresses too [07:16] axw: ^ [07:16] rogpeppe1: when would you need another address for the same machine? [07:17] axw: perhaps you might want to dial it within the cloud [07:17] axw: and perhaps the public address isn't valid in the cloud [07:17] rogpeppe1: we already have api-addresses for that? [07:18] axw: also, it means we don't need any special casing for the addresses returned by Login [07:18] axw: it just seems right to me that we should ensure from the very start that APIHostPorts is valid [07:19] axw: especially since it's user-visible [07:19] yes, I suppose so [07:19] axw: also, there are other things in the agent that watch it [07:20] axw: and it would be nice not to need to special-case them [07:20] rogpeppe1: ok, I will get back to that one now then. now that we have a fully valid config at bootstrap time, it's straight forward to do without any changes to environs/cloudinit and so on [07:20] axw: yeah [07:21] axw: the code to set up the replica set already needs the address anyway tbh [07:27] wallyworld_, I have not reviewed it but I heartily endorse what you did [07:27] fwereade: i thinks it's all ok, stuff works [07:27] just wanted to be sure i hasn't missed any subtle issues [07:27] i need this to land for the joyent provider to work [07:28] i like all the red in the diff [07:28] jam, i'll be 5m late for 1-1, sorry [07:29] dimitern: np [07:29] wallyworld_, I might review it anyway just to see the red, those CLs do always make me happy [07:29] wallyworld_, but don't wait on me ;) [07:29] * fwereade bbs [07:30] fwereade: sure, np. i have a filing status test to fix anyway [07:30] failing [07:31] fwereade: my main concern is just to check that it is 100% ok to remove the SetAddress calls from the uniter startup in ModeInit(). I'm sure it is but.... [07:37] jam, i've joined === psivaa_ is now known as psivaa [07:47] axw: i'm trying to understand the comment in https://codereview.appspot.com/81780043/diff2/1:20001/juju/apiconn_test.go?column_width=90 [07:48] axw: i'm not sure what you mean by "we can only create the zero value" [07:48] axw: the zero value of what? [07:48] * axw looks [07:49] rogpeppe2: we can only create the zero value of api.State, because all of its members are private [07:50] sorry, not very clear [07:50] rogpeppe2: the point is, without a real call to Login we can't change the result of HostPorts [07:50] wallyworld_, I will be most sad if we are not ready to do that -- they'reonly there as a fallback anyway, we should always be deriving unit addressesfrom machine addresses these days [07:51] axw: ah yes. hmm. i wonder if we should mock out api.State hre [07:51] here [07:51] axw: we're relying on it not crashing when methods are called on its zero value [07:51] axw: that seems a bit wrong to me [07:51] axw: it was kind of ok before because we weren't calling any methods on in [07:51] it [07:52] rogpeppe2: sure, I'll look into doing that [07:53] axw: i think that'll mean you'll have to create an internal version of NewAPIFromStore that returns the possibly-mock api.State, then a thin wrapper that type asserts the returned value back to api.State [07:53] axw: then in tests you can call the internal version [07:54] axw: i suppose another possibility would be to actually create a genuine api.State to return. [07:55] rogpeppe2: that might be less painful :) [07:55] I don't want to create a Mongo test just because though [07:55] axw: i actually don't think doing the mock thing will be that much hassle [07:55] I'll see how hard it is to create an interface here [07:55] axw: thanks [07:56] axw: the test was always slightly dodgy (for which i'm fully responsible) but i think the latest changes push it over the boundary into crackfulness. [07:57] fair enough :) I was being a bit too lazy, I admit [08:18] fwereade: that's what i thought, justed wanted some extra eyes cause of the scope of the change [08:26]