[00:00] wallyworld: it sounds like you have a lot on your plate [00:00] i'll look at testing ec2 and hp deployments today now that RT is closed [00:00] ido [00:00] awesome :-) [00:00] wallyworld: fair warning, there are some remaining tools selectino bugs on ppc [00:00] ok [00:00] mainly because precise/ppc64el is not a thing [00:00] i'll do what I can to resolve them myself [00:01] davecheney: i'm happy to fix also [00:01] wallyworld: lemmie figure out what they are first [00:01] ok [00:01] all I can see at the moment is tests pass with gccgo/amd64 [00:01] and fail with gccgo/ppc64el whinging that no tools are available [00:13] davecheney: is there simplestreams metadata for ppc64el? [00:13] that would be a likely cause [00:34] wallyworld: in the test fixures ? [00:35] sinzui: https://bugs.launchpad.net/juju-core/+bug/1298708 [00:35] <_mup_> Bug #1298708: bzr: bzr unit tests are not properly isolated

[00:35] this is sort of a big failure [00:35] how does this pass in CI ? [00:35] davecheney: i think so. what tests are failing? [00:35] wallyworld: hang on [00:35] talking at cross purpises [00:35] what are you talking about [00:36] the missing ppc64el tools metadata [00:36] wallyworld: in that case I agree [00:36] let me check quickly [00:39] * davecheney flails around a bit [00:40] wallyworld: where in the source are the test fixtures ? [00:40] depends on what tests are filing [00:41] wallyworld: you mentioned that there was sample simples streams data [00:41] where in the source are those fixtures kept ? [00:41] there's several tests with different sources [00:42] sure [00:42] there's some in environs/simplestreams/testing [00:42] but each provider also sets up its own data [00:42] ubuntu@winton-02:~/src/launchpad.net/juju-core/environs/simplestreams/testing$ ls [00:42] testing.go [00:42] ahh, rigth [00:42] now I understand [00:44] afk for a bit [01:36] eu1Ahloo [01:36] eu [01:37] ouch [01:37] :p [01:37] not a bad password, as passwords go.. [01:39] sarnold: nah, altough I think I should definitely not use it for something else than my laptop :) since apparently I can have the screen locker on but the focus on the chat [01:41] perrito666: ah :) https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1292217 [01:41] <_mup_> Bug #1292217: lightdm screen lock has triggered but keyboard is still connected to the main session

[01:41] sarnold: lol === vladk|offline is now known as vladk [03:08] when using goyaml and json is there a way I can tell struct tags to marshal/unmarshal the same for both systems - the syntax in my head is something like `json,yaml:foo-bar` [03:18] mattyw: yes [03:18] the syntax is slightly different [03:18] from memory `yaml:foo-bar,json:foo-bar` [03:18] there might even be some "'s in there as well [03:18] davecheney, I found that `json:"foo" yaml:"foo"` works - but it would be nice not to have to repeat the key [03:19] it would be nice to not need to repeat the key - but I guess that isn't the way the world works [03:19] mattyw: well puyt === vladk is now known as vladk|offline [03:20] davecheney, thanks dave - I'll let you get back to implementing generics [03:20] mattyw: you're welcome [03:20] mattyw: you're welcome [03:38] axw: wallyworld i am looking at this bug [03:38] http://paste.ubuntu.com/7165797/ [03:38] and I am really concerned that public and private addresses are being mixed up [03:38] looking at the code, so far I see they are handled separately [03:39] but I woner if at some point they are mushed into a map, then someone is grabbing the first key from the map and assuming that is the first item pushed into the map [03:39] could be [03:39] wallyworld: it looks liek they are stored in separate fields in the machine/unit document [03:39] sorry it would be the machine document [03:39] i think so yes [03:39] davecheney: they are indeed put into a map [03:40] axw: ORLY [03:40] davecheney: to remove dupes. does order matter here? SelectPublic/SelectInternal should still do the right thing...? [03:40] axw: is that in state, or in instance ? [03:40] it looks just like another map orderin fting [03:41] thing [03:41] wallyworld: the first bug is [03:41] in the test only [03:41] the seconds are a little weirder [03:41] davecheney: they're merged in state.Machine.Addresses [03:41] state/machine.go [03:41] addresses := []instance.Address{ [03:41] instance.NewAddress("127.0.0.1"), [03:41] instance.NewAddress("8.8.8.8"), [03:41] } [03:41] err = machine.SetAddresses(addresses) [03:41] c.Assert(err, gc.IsNil) [03:41] address, ok = s.unit.PublicAddress() [03:42] c.Check(address, gc.Equals, "8.8.8.8") [03:42] this is weird [03:42] what defined the public and private addresses ? [03:42] it feels like the order in which the are added [03:42] the first is always private [03:42] the rest are public [03:42] there's an lgorithm [03:43] internalAddressIndex [03:43] davecheney: addresses have a scope which says whether they're public/private [03:43] i think it's just the test [03:43] wallyworld: the test is failing because s.unit.PublicAddress() returns the priovate address [03:43] davecheney: see NetworkScope in instance/address.go [03:43] the test is inserting 2 addresses into a map without enough info for one to be considered private over another [03:43] the test needs improving i think [03:43] wallyworld: there aren't any maps on that code sample I showed [03:43] i'm concerned that this is a bug in the code [03:44] not the expected in the test [03:44] davecheney: that's not the point [03:44] the code picks an address based on the internalAddressIndex algorithm [03:44] and the addresses in the test don't appear to have enough info for one to be picked over another [03:44] so an arbitary one is chosen [03:45] wallyworld: right, so that is a bug in unit.PublicAddress [03:45] if they're all public or private, I think order matters [03:45] not the test [03:45] that's based on a very quick look at the code [03:45] but that's arbitrary [03:45] it's not a bug [03:45] if more than 1 address matches, it just picks one [03:45] so the test needs to insert addresses with more info [03:46] davecheney: instance.NewAddress just gives you an address of "unknown" type [03:46] so that 1 is definitely private vs public [03:46] the address type needs to be set [03:46] so neither 127.0.0.1 nor 8.8.8.8 in that test are public [03:46] it just happened to be picking 8.8.8.8 before because it was the last in the list [03:46] axw: right, thanks [03:46] axw: wallyworld thanks [03:46] now I understand [03:46] i'll fix it [03:47] * axw hopes nothing actually relies on that [03:47] davecheney: sorry about bad explanation, test is shit [03:47] axw: you'll be surprised :) [04:11] Spot the bug, Holiday [04:11] May 2014 07/05/2014 - 07/03/2014 Awaiting Sign Off [04:21] axw: wallyworld instance.NewAddresses would appear to be a footgun [04:22] davecheney: yeah, it should probably be in a testing package, if that [04:22] it doesn't really set the scope does it [04:22] it's only used by tests [04:24] axw: should I delete it ? [04:24] it never sets the scope [04:25] so its value would be ... dubiois [04:25] instance.Address{Value: "x.y.z.q"} does the same thing [04:29] hmm, NewAddress does do more that I just said [04:29] but it always sets the scope to unknown [04:36] davecheney: sorry, was making lunch. I don't know, depends on how it makes the tests look. I'd opt for just moving it, so it's not accidentally used in a place where it matters [04:46] axw: moving it out of the instance API and as a helper [04:46] that would certainly reduce it's lethality [04:49] let's see what breaks [05:04] axw: http://paste.ubuntu.com/7166620/ line 174 [05:04] i wonder if this related to the last issue [05:10] * axw looks [05:11] davecheney: broken test; it's setting the wrong scope on the "public" address [05:18] axw: yet it passed up until now .... [05:18] davecheney: yes, by implicitly relying on map ordering [05:19] it just happened to pick the internal address previously [05:19] waaaaaaaaaaaaaah [05:19] ok, will fix [05:20] wallyworld: i don't think i'm going to get to adding simple streams data for ppc64el [05:20] i'll log a but [05:20] bug [05:20] but I know you have better things to do [05:20] ok [05:20] i'm finishing the joyent provider [05:20] i'll try and get to it real soon now [05:21] wallyworld: no no [05:21] that is what I am saying [05:21] i need to log a bug for my status report [05:22] but don't think you need to do it [05:22] ok [05:41] axw: OMG [05:41] cloudLocalAddress := instance.NewAddress("cloudlocal") [05:41] cloudLocalAddress.NetworkScope = instance.NetworkCloudLocal [05:41] ^ even other callers of NewAddress don't trust it [05:45] :) [05:45] it's a bit pointless there isn't it [05:45] davecheney: if you do move it, maybe rename it too. NewUnknownAddress [05:51] axw: i'm thinking instead adding a manditory scope parameter instead [05:51] then it can't be misused [05:51] davecheney: sounds sensible [05:51] famous last words [06:02] cummon and land my change you mongrel [06:21] jam1: has the bot crapped itself ? [06:21] or is it just reeeeeeeeeeely slow ? [06:25] axw: instance.NewAddress is barely used, only one case in the whole codebase [06:26] davecheney: apart from tests? yeah, that one can just be changed to create an address struct literal [06:30] yeah, quite a few tests [06:30] i'm going to go with the plan of adding an explict scope argument [06:30] this will probably make people questino the values passed to NewAddress [06:47] axw: git 101 question - i've forked a github branch, cloned locally into the src tree i use for juju-core development, comitted and push some changes. How do i now revert the branch on disk to the original from github? [06:48] i'd use bzr switch [06:48] what's the git equivalent? [06:50] wallyworld: git checkout $BRANCH ? [06:50] davecheney: ok, ta. i'm a total git noob. [06:50] wallyworld: i *may* not have told you the right thing [06:50] there is also git reset --hard [06:51] wallyworld: depends on whether you branched to start with [06:51] but that might be a hammer to crack an egg [06:51] i must say, having created a couple of pull requests on github, bzr + laucnhapd is MUCH nicer :-( [06:51] axw: i just did a go get -u originally [06:52] i guess i could rerun that? [06:52] wallyworld: so, I think what you probably should've done is branched, and pushed the branch to GitHub [06:52] but it's a bit late [06:52] no, your push would've pushed to the master branch [06:52] axw: i forked [06:52] and then cloned [06:53] that's what the online help said to do [06:53] wallyworld: right, but forking on github creates a repo + branch [06:53] branches [06:53] so you've modified the master branch in your fork [06:53] my push went to my copy of the branch [06:53] yes [06:53] yep... now what do you want to do exactly? [06:54] wallyworld: bear in mind I'm a git noob too :) [06:54] revert, on disk, back to what was there before i deleted the go get version and clone my version [06:54] ah, i thought you were a git master :-) [06:54] i used git *for the very first time* just 10 minute ago [06:54] wallyworld: probably better just to create a new branch off the old commit [06:55] wouldn't checkout/clone be better? i wonder what go get does [06:55] i could just rm the dir and run go get again [06:56] you could, but you'll get the same stuff back [06:56] that's what i want for now [06:56] wallyworld: you want the same thing you pushed? [06:56] that's what you'll get back [06:56] i'm just trying to figure out how the do the equivalent of "bzr switch" [06:57] "git checkout " [06:57] and that will overwrite what's there? [06:57] ta, will try that [06:57] that'll change your working tree [06:57] coolio, that's what i want [06:58] it's going to be "fun" switching over [06:59] it's not so bad, just a bit different [06:59] i've read and heard that bzr's model and workflow is *much* nicer, so it will be a pain i think [07:19] wallyworld: jam1 axw, https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 [07:19] still hasn't landed [07:19] can someone kick the bot ? [07:19] sure [07:20] ta much [07:23] Preparing to merge https://code.launchpad.net/~dave-cheney/juju-core/105-fix-lp-1298789 [07:23] tests running [07:24] wallyworld: right [07:24] thanks for checking [07:24] np [07:25] tests take 30 mins on my laptop with one cpu [07:25] i can imagine they are even slower on canonistack [07:25] oh yes [07:32] mornin' all [07:33] rogpeppe: o/ [07:33] while we're waiting for the bot, https://codereview.appspot.com/81330044 [07:34] davecheney: good call - i've been meaning to do that for a while [07:34] rogpeppe: and then I can change SetAddresses to be var arg [07:34] and remove all the use of NewAddresses [07:35] davecheney: that doesn't seem quite right - addresses have more info than is just in the string [07:36] rogpeppe: indeed, that was the subject of todays bug [07:36] NewAddress always creates an address with scope NetworkUnknown [07:36] https://code.launchpad.net/~dave-cheney/juju-core/105-fix-lp-1298789/+merge/213198 [07:36] davecheney: are we using NewAddress in production code? [07:36] https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 [07:36] davecheney: we shouldn't really. [07:36] rogpeppe: i'm going to do two things [07:36] 1. make the caller always specify the scope [07:37] 2. make sure we're only using it in tests [07:38] rogpeppe: actually, if we do 1 then 2 may not be necssary because it will become less dangerous to call that function [07:38] davecheney: that seems ok to me, except that i always presumed that Unknown was there for when a provider genuinely doesn't know the scope of an address [07:39] rogpeppe: unknown can be returned for both a public and private address [07:39] that seems wrong [07:39] davecheney: i'm not sure [07:39] davecheney: we should talk to mgz about this - it's his scheme [07:40] davecheney: the other thing i'd like to do with addresses is drop the explicit type field [07:40] rogpeppe: have a look at the bug attached to this one, https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 [07:41] davecheney: that's not a production code bug, is it? === vladk|offline is now known as vladk [07:42] goog morning [07:42] good morning [07:44] vladk: hiya [07:54] axw: you've got a review: https://codereview.appspot.com/81700043/ [07:55] thanks [07:58] dimitern: morning [07:59] rogpeppe: for client caching addrs, is it reasonable to only do it when using the configstore? and assume that Environ.StateInfo will get updated addresses too? [07:59] morning [07:59] dimitern: hiya [07:59] morning vladk, dimitern [08:00] dimitern: i'd appreciate your thoughts on this: https://codereview.appspot.com/81570043/ [08:00] rogpeppe, looking [08:00] dimitern: (particularly after our chat yesterday...) [08:01] axw: for the former, i think so [08:01] axw: without the configstore, i don't there *is* any way to cache addresses [08:01] axw: didn't you fix this ? http://paste.ubuntu.com/7167180/ [08:01] rogpeppe: hah, good point :) [08:01] axw: i'm not sure what you mean by the latter [08:01] rogpeppe: well actually... [08:02] rogpeppe: we may have the configstore, but it may have out of date info [08:02] rogpeppe: so we try using StateInfo to get addrs from external storage [08:02] davecheney: looking [08:02] axw: nothing should be using StateInfo [08:02] axw: i saw you proposed a fix yesterday [08:02] maybe that hasn't laneded [08:02] i'm pretty sure i'm up to date [08:02] davecheney: I thought so too, but maybe not :( [08:02] axw: because nothing connects directly to mongo [08:03] rogpeppe: I'm talking about environs.Environ.StateInfo, which gets provider-state from storage [08:03] you know, the one we chatted about the other day [08:03] * rogpeppe feels bad about tests depending on map ordering. [08:03] rogpeppe: go 1.3 for the win [08:04] axw: ah yes, i think it's reasonable to assume that the info from StateInfo (actually we'll rename it to APIInfo soon) is maintained [08:05] * rogpeppe will try running tests on tip [08:07] rogpeppe: excellente, thanks [08:08] rogpeppe: you may not have seen my email yet, so: is the APIHostPorts client API still necessary if we return them via Login? [08:08] I would prefer to do it via Login [08:08] axw: i think it does no harm - we can leave it in [08:08] ok [08:08] axw: but i think we should return the results from Login anyway [08:09] rogpeppe: yeah, that's what I am working on right now [08:09] rogpeppe: simpler and more efficient [08:09] axw: <3 [08:20] guys, today may be challenging, cath is away and laura is a bit sick [08:21] upside: she's fairly subdued [08:21] downside: I will be off and on at complete random today [08:21] just flag me in here with reviews you need and I'll get to them as I can [08:25] fwereade, take a look at this https://codereview.appspot.com/81570043/ i'd like to know your thoughts as well [08:28] dimitern: fwereade has already reviewed it (although perhaps not completely) [08:29] rogpeppe, ah, sorry, haven't reached the end [08:39] rogpeppe, i don't really get why do you have a clone method on the configsetteronly? [08:40] rogpeppe, imo once you have configsetteronly, you should've got it from a clone of an existing config [08:40] rogpeppe, what if you forget to call clone? [08:40] dimitern: there's not really any point on having it on the Config, because when you've got a Config, it should be immutable [08:41] dimitern: if you've got a mutable config (ConfigSetter or ConfigSetterWriter) you are responsible for cloning the config to hand out to potentially concurrent clients [08:42] rogpeppe, and you're handing out a clone with a clone method itself? [08:42] dimitern: that's reasonable, i think, because that's the case in only a very small amount of code [08:42] dimitern: ? [08:42] dimitern: Clone returns Config, which doesn't have a clone method [08:43] rogpeppe, oh ok [08:59] rogpeppe, reviewed [09:10] dimitern: thanks a lot [09:11] dimitern: responded [09:13] rogpeppe, will look in a moment [09:15] rogpeppe, i'm confused about upgrades + migrate config [09:15] rogpeppe, istm now we're migrating the config in-memory only and then what? [09:16] dimitern: the caller is responsible for actually writing the config [09:16] rogpeppe, i'm asking about that particular caller [09:16] rogpeppe, the upgrade step [09:17] dimitern: the upgrade step doesn't need to write the config [09:17] rogpeppe, you've changed migrate not to write, but not changed agentconfig upgrade step calling migrate to write after calling migrate [09:17] rogpeppe, that's its only purpose in life [09:17] dimitern: the write happens outside of PerformUpgrade [09:17] rogpeppe, migrate and write the updated config [09:18] dimitern: which is why PerformUpgrade is called in a ChangeConfig-called function [09:18] rogpeppe, have you tested this with an actual live test upgrading 1.16 to 1.18? [09:18] dimitern: not yet [09:19] rogpeppe, please do :) [09:19] dimitern: will do [09:19] dimitern: is there a particular reason you can see why this scheme won't work? [09:20] rogpeppe, i'm not saying it won't work, i'm just concerned not to introduce regressions [09:20] dimitern: ok, that's cool [09:25] rogpeppe: last one, https://codereview.appspot.com/81780043 [09:26] rogpeppe: I'll look at parallel connection in the API client on Monday, unless you have something else more important? [09:26] axw: thankjs [09:26] axw: i'll have a think [09:26] nps [09:29] rogpeppe, lgtm [09:36] hello [09:40] stupid bot, how long is this going to take, https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 [09:42] davecheney: looks like the bot is hung [09:42] davecheney: i'll kick it [09:43] thanks [09:43] otherwise i'll check it tomorrow [09:43] davecheney, hey [09:43] dimitern: hello [09:43] i'm not really here [09:43] davecheney, how do you run juju on ppc btw? [09:43] i have a scotch downstairs which is getting impatient [09:43] dimitern: how do I run it ? [09:43] go build launchpad.net/juju-core/... [09:44] mayube I don't understand the question [09:44] ds [09:44] morning all [09:44] davecheney: bot now going again [09:44] thanks [09:44] this is the changing of the guard [09:44] davecheney: it's got to axw's branch first though, i'm afraid [09:44] rogpeppe: no worries [09:44] not much hurry now [09:44] me -> EOW [09:44] voidspace: hiya [09:44] davecheney, I mean on a vm or what machine [09:45] dimitern: we have ppc hardware available [09:45] davecheney, nice! [09:45] dimitern: do you want a machine [09:45] or are you just curious [09:45] you can have a machine [09:45] they are for the juju team [09:45] davecheney, nah, just curious :) [09:45] but it is a non zero amout of work [09:45] davecheney, i have enough on my plate already [09:46] dimitern: right, yes, we have some ppc machines which are cut up into vms so we can each work without having to negotiate for port 17017 and things [09:46] davecheney, good to know, i assume arm vms as well? [09:46] dimitern: not so much [09:46] these ppc machines are kvm vms [09:46] so they are mostly wire speed [09:46] the arm stuff is all inside the arm fast model simulator [09:47] it uses a lot more cpu power, and produce much less impressive results [09:47]