[00:07] davecheney: 62097950d4677fb8ef6c9c83e3d7555eebf2c653 means that the tests in cmd/jujud/agent now don't run at all [00:07] oops [00:07] will fix [00:07] davecheney: package_test.go is in the agent_test package but all the tests are in the "agent" package [00:08] davecheney: thanks [00:08] well, that was unexpected [00:08] i'll fix asap [00:09] davecheney: i'm currently ripping out the upgrade_test.go tests, which is why I noticed [00:10] menn0: hmm [00:10] tests run on my machine [00:10] the way gocheck tests work [00:10] i think i got away with it [00:10] but it's inconsistent and i'll fix it [00:11] davecheney: if I run "go test ./cmd/jujud/agent -gocheck.f UpgradeSuite" the UpgradeSuite tests don't run but they used to before [00:12] got it [00:12] fix coming asap [00:12] thanks [00:14] menn0: https://github.com/juju/juju/pull/3828 [00:17] davecheney: ship it, with commentary [00:18] lucky(~/src/github.com/juju/juju/cmd/jujud/agent) % go test -v [00:18] === RUN TestPackage [00:18] OK: 107 passed, 3 skipped [00:18] --- PASS: TestPackage (175.62s) [00:18] PASS [00:18] ok github.com/juju/juju/cmd/jujud/agent 175.672s [00:18] lucky(~/src/github.com/juju/juju/cmd/jujud/agent) % go test -v [00:19] === RUN TestPackage [00:19] OK: 107 passed, 3 skipped [00:19] --- PASS: TestPackage (173.66s) [00:19] PASS [00:19] ok github.com/juju/juju/cmd/jujud/agent 173.710s [00:19] before vs after [00:19] not seeing a difference in test runs [00:19] how many tests do you see ? [00:21] menn0: ^^ [00:22] 0 [00:23] but I wasn't in the same directory [00:23] ok [00:23] I did "go test -v ./cmd/jujud/agent -gocheck.v" [00:25] i don't really understand how that matters [00:25] gocheck is a singleton [00:25] so all the tests are registered during init [00:25] then something has to hook them up [00:25] anyway [00:25] it's fixed [00:26] NFI [00:26] davecheney: thank you [00:26] zero ducks [00:52] axw: you're on call review today? https://github.com/juju/juju/pull/3829 [00:52] davecheney: yup. looking [00:54] davecheney: LGTM [01:06] bah humbug [01:06] * thumper wants sinzui [01:06] don't we all [01:15] uggerbay [01:15] I've worked out why my call fails... [01:15] kinda [01:16] what I'm not sure about is how it passed before [01:20] axw: https://github.com/juju/juju/pull/3830 [02:16] oh FFS [02:17] wallyworld: got a minute to talk about a bug? [02:17] sure [02:17] 1:1 hangout [02:41] davecheney, menn0, mwhudson, waigani: going to have to skip the standup tomorrow morning as I'm ferrying kids down to the university for a school trip [02:41] will work from the library down there for the moring [02:41] morning [02:46] mkay [02:46] thumper: ok cool [02:47] thumper: I might see you there if marsh centre is closed [02:48] waigani: kk [02:52] Bug #1519995 changed: Upgrades from 1.20.11 to 1.25.2 fail because of status

[02:55] Bug #1519995 opened: Upgrades from 1.20.11 to 1.25.2 fail because of status

[02:58] Bug #1519995 changed: Upgrades from 1.20.11 to 1.25.2 fail because of status

[03:01] Bug #1519403 changed: 1.24 upgrade does not set environ-uuid [03:04] Bug #1519403 opened: 1.24 upgrade does not set environ-uuid [03:07] Bug #1519403 changed: 1.24 upgrade does not set environ-uuid === mwenning is now known as mwenning-afk [03:10] Bug #1519403 opened: 1.24 upgrade does not set environ-uuid [03:12] wow mup is confused [03:16] Bug #1519403 changed: 1.24 upgrade does not set environ-uuid [03:19] Bug #1519403 opened: 1.24 upgrade does not set environ-uuid [03:22] Bug #1519403 changed: 1.24 upgrade does not set environ-uuid [03:47] thumper: do you think it would be reasonable to reject upgrading to 2.0 if the env has no UUID? [03:48] thumper: ... or is there always a UUID now? [03:48] axw: ummm.... can you explain more? [03:48] you mean cached locally? [03:48] thumper: in environs/config there's a "ok bool" on UUID that says if the config has a UUID or not [03:48] ah... [03:48] ok [03:48] thumper: is it only the client that might not have one? [03:48] config that comes from the environments.yaml will not have a UUID [03:49] it is expected that all servers will have one [03:49] as of 1.20, it is cached in response to API connections [03:50] as of 1.24 or 1.25, it is written to the cache as part of bootstrap rather than the first connect after bootstrap [03:50] thumper: ok, cool. it would be nice if 99% of callers didn't have to use the (UUID, bool) call [03:50] agreed [03:50] as of 2.0, there is no environments.yaml [03:50] leading to confusing me :) [03:51] so this should no longer be an issue [03:51] more cleanup [03:51] thumper: excellent [03:51] thanks [03:51] np [03:57] axw: we do need to pass the series to the backend. if the user overrides the series, we can't put that into the charm url and just pass that as we do now, because the modified charm url will not be resolvable in the store as it doesn't exist [03:57] so we need to record the true charm url and user specified series separately [03:58] this applies when the user forces a series not supported by the charm [03:58] wallyworld: why do we resolve the URL in the backend? [03:58] wallyworld: or try to fetch it on the backend [03:58] i'd have to check the code again but we do [03:58] we call repo.Resolve() server side [03:59] to add the charm to state [03:59] from emmory [03:59] wallyworld: ok [03:59] axw: i had the same thought as you originally but ran into these issues [03:59] when i tested live with series override [04:09] wallyworld: what exactly is hte issue with revision in the URL? you've taken out the revision in the bundle tests, but surely we still need to be able to specify revision somehow [04:10] axw: you can only specify revision if a series is in the url, so name-42 is not allowed but trusty/name-42 is. these changes are upstream charmstore changes [04:10] since in a multi-series world they reckon name-42 is ambiguous [04:10] not sure i agree tbh [04:11] wallyworld: yeah, likewise. in any case, you removed revision from trusty/wordpress and wordpress both [04:11] works either way, i can add it back to the trusty case [04:11] must have been a typo [04:30] wallyworld: for a new charm with series in metadata, can you resolve a URL with series if the series is supported? [04:30] yes [04:31] wallyworld: ok, good. so it's just unsupported series that you can't resolve. makes sense [04:31] yep [04:49] wallyworld: axw mgz can someone trigger a run of this job please http://juju-ci.vapour.ws:8080/job/run-unit-tests-race/ [04:49] davecheney: sure, if I can work out how [04:50] davecheney: what revision_build? [04:50] was about to ask [04:51] i'm not sure what to type in there [04:51] wallyworld: axw [04:51] i have no idea [04:51] its supposed to be automatic [04:51] i've tried feeding it a revisoin and it barfs [04:51] davecheney: I think it's dependent on the build-revision job, which hasn't run for ToT yet [04:51] there is some extrenal process that kicks off the job [04:51] but i don't know what it is [04:51] tot ? [04:52] top of tree [04:52] sorry [04:52] worst alias for master, ever [04:52] yes, that one [04:52] working in LLVM has messed with my brain [04:53] seek professional counciling [04:53] is it possible to bump the build-revision job ? [04:53] oh, my other gripe about the race job [04:53] if you stop the job [04:54] becuase it's testing a branch that you know won't pass [04:54] something resubmits that job [04:54] davecheney: trying a new build-revision now [04:54] thanks! [05:03] davecheney: race job is running now [06:14] axw: lts and model series are validated now [06:15] wallyworld: ta, looking [06:38] thanks axw, have to wait to land after charmstore is cut over === Makyo is now known as Guest70426 === meetingology` is now known as meetingology === JoseeAntonioR is now known as jose === JoseeAntonioR is now known as jose === marlinc_ is now known as marlinc [08:13] Bug #1519527 changed: MAAS 1.9b2+ with juju 1.25.1: lxc units all have the same IP address === wgrant is now known as Guest42266 === tasdomas` is now known as tasdomas [09:16] dimitern_, ping [09:17] frobware, pong [09:19] dooferlad: just to let you know I'm blocked on the fixed range stuff [09:20] voidspace: OK, I should be on that soon. [09:20] voidspace: just juggling multiple tasks :-( === mup_ is now known as mup === MmikeM is now known as Mmike [10:00] voidspace, jam, fwereade, standup? === dimitern_ is now known as dimitern [10:03] dimitern: omw [10:11] frobware: if you are trying to hangout in Firefox and having sound problems then try Chrome - I had a similar issue. === akhavr1 is now known as akhavr [10:36] dooferlad: sorry, I brainfarted - of course it should be possible for the keepalive goroutine to be reentered. re-reviewing that bit now [10:36] axw: no problem [10:36] axw: thanks for taking another look. [10:37] dooferlad, voidspace, dimitern: looks like most folks have either declined or maybe'd the OS call today - I propose we cancel unless there are some agenda items [10:38] frobware: +1 [10:39] frobware, sgtm [10:46] voidspace: AddFixedAddressRange change just pushed [10:46] voidspace: making SetNodeNetworkLink nicer now. [10:52] voidspace: and now the SetNodeNetworkLink update you asked for is done. [11:45] dooferlad: awesome, thanks [11:52] dooferlad: hmmm... setting the range with the new api doesn't *seem* to work [11:52] dooferlad: digging in (will check the test code to see if I'm doing it right) [11:52] var ar AddressRange [11:52] ar.Start = "192.168.1.100" [11:52] ar.End = "192.168.1.200" [11:52] ar.Purpose = []string{"dynamic"} [11:52] ts.AddFixedAddressRange(subnet.ID, ar) [11:52] dooferlad: and also I still get nil back instead of an empty array when there are no ranges [11:52] where ts is the test server [11:52] dooferlad: suite.testMAASObject.TestServer [11:53] oh [11:53] misunderstood [11:53] dooferlad: that's *exactly* what I'm doing [11:53] and reserved_ip_ranges for that subnet returns null [11:54] voidspace: http://pastebin.ubuntu.com/13513986/ is my little live test server [11:55] Clearly you need to have something to run it... [11:55] http://pastebin.ubuntu.com/13513993/ for example [11:56] from http://localhost:6776/api/1.0/subnets/1/?op=reserved_ip_ranges I get http://pastebin.ubuntu.com/13513997/ [11:57] dooferlad: try it without the call to NewIPAddress [11:57] I have a hunch [11:57] still hacking my code to try it [11:57] voidspace: good hunch [11:57] dooferlad: early short circuit in your code [11:58] dooferlad: ok, so my code now runs [11:58] dooferlad: however the tests pass, which is bad - they should fail because now the allocatable range should be different [11:58] dooferlad: but that's probably a bug in my code :-) [11:59] dooferlad: I can remove the adding of the extra IPAddress once that's fixed [12:00] voidspace: fixed and pushed. [12:00] dooferlad: that was quick :-) [12:03] voidspace: oh hang on. Fscked up. Wrong repo. [12:03] voidspace: try now [12:04] dooferlad: I have a suspicion my Purpose may be being overwritten [12:04] that may not be true [12:05] but I'm not seeing the range with the right Purpose yet [12:06] dooferlad: hah no, typo in my code [12:13] dooferlad: and it's found another bug in my code :-) [12:14] I was using net.IP(..) not net.ParseIP(...) [12:14] voidspace: success! [12:14] dooferlad: and now it's done [12:14] dooferlad: yep, mine is ready to land [12:14] dooferlad: (or at least ready for review) [12:14] dooferlad: is your branch proposed? [12:14] voidspace: sweet! I will propose my branch now. [12:16] voidspace: https://code.launchpad.net/~dooferlad/gomaasapi/subnets/+merge/278342 [12:16] dooferlad: great [12:18] dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3252/ [12:19] voidspace, looking [12:32] Bug #1520199 opened: provider/maas: better handling of devices claim-sticky-ip-address failures and absence of reserved IP address

[12:34] voidspace, looking [13:04] is anyone around today? [13:07] voidspace, reviewed [13:30] dimitern: thanks [13:31] dimitern: I didn't make dummy provider configurable because it's not needed as part of this PR [13:31] dimitern: it can be made configurable when it's needed [13:32] dimitern: and I don't think you're right about the space name transforming code [13:32] dimitern: we store juju name and provider name and we need to be able to convert between them [13:33] dimitern: so it shouldn't return an error [13:34] dimitern: and yet again I disagree with your comments about nesting structs in tests [13:34] dimitern: I think it makes them much harder to read [13:34] dimitern: whitespace is good! [13:36] voidspace, too much whitespace can kill you know :D [13:36] dimitern: that's propaganda, there are no known cases [13:36] dimitern: I think collapsing them will make them uglier [13:37] voidspace, I disagree about the space names not needing to validate the juju name [13:37] dimitern: I can wrap them in a helper as per one of your other sessions [13:37] dimitern: we do validate - that's what my code does [13:37] dimitern: it transforms into a valid namme [13:37] dimitern: so it can't return an error [13:37] voidspace, how about tests where you get a space [13:37] voidspace, like "#$^#$^" from maas? [13:38] dimitern: what do you want to do with them? [13:38] dimitern: we haven't defined that behaviour yet - so just changing the name of the existing function won't help that case [13:38] voidspace, report an error, rather than pass it happily back to the apiserver and fail on import [13:39] dimitern: what error? [13:39] dimitern: you haven't defined the error cases [13:39] dimitern: and we *still* need a transform [13:39] dimitern: why shouldn't we use #$^ as a space name [13:39] voidspace, ok, can we then at least replace not just " " -> "-", but also any invalid chars for a juju space name to "_" [13:40] voidspace, because that would be unusable in constraints or anywhere pretty much [13:40] dimitern: where are the valid characters defined [13:41] dimitern: can't you use strings for constraints - no escaping? [13:41] voidspace, check names.IsValidSpace [13:41] (as in use quotes) [13:41] dimitern: ok, thanks [13:41] dimitern: I still think you need therapy for your anti-whitespace prejudice [13:42] dimitern: I good course of Python should help [13:43] voidspace, I like whitespace, in general, but having 3 levels of mostly empty lines (except for "{") nested moves the EOL too much for my taste when reading the code, but I guess that's just me [13:45] voidspace, and the same goes for too long lines that can be wrapped nicely, instead of arbitrarily according to various editor settings [13:45] dimitern: well, the edit you're suggesting would result in *massively* long and completely unreadable lines [13:45] whereas as it is I can just glance at it and understand it [13:46] the whitespace shows up the structure as well as making the contents easier to read (single member per line) [13:46] voidspace, with the risk of wasting a couple more minutes on an issue with hardly any consequence, what's unreadable? [13:46] so I genuinely disagree and don't see the problem [13:46] collapsing all the whitespace into a single line [13:46] as you suggest [13:47] []network.SpaceInfo{{ .. }, { .. }} [13:47] that would be one line of about three hundred chars [13:47] or more [13:47] 800 maybe [13:48] and just breaking the line, instead of using whitespace for structure, means you have to pick along it to work out where members are [13:48] there's a reason that all json pretty printers use whitespace to show structure [13:48] because it makes data structures easy to read [13:48] voidspace, I'm not saying use v := []map[string]string{map[string]string{"foo":"bar","one":"two"},map[string]string{"bar":"baz", "four":"five"}} [13:48] it makes the vertically verbose but easy to scan [13:48] dimitern: well, that's *specifically* what you say [13:49] voidspace, I'm not saying use v := []map[string]string{ \n \t map[string]string{"foo":"bar","one":"two"}, \n \t map[string]string{"bar":"baz", "four":"five"}}\n [13:50] dimitern: I still think the SubnetInfo as single lines would be too long and harder to read [13:50] voidspace, oops anyway - I meant multi-line, but some braces together on the same line, rather than having "{\n" followed by "{\n" etc [13:50] dimitern: ok, I'll see how that looks [13:50] that maybe fine to me and would lose a level of indentation [13:51] fair enough [13:51] I should've pasted a formatted snippet rather than being lazy and trying to express what I meant on one line [13:51] :-) [14:05] Bug #1520247 opened: TestContainerProvisionerStarted fails due to unknown container type: lxd

[14:34] version bump review please: http:..reviews.vapour.ws/r/3254/ [15:10] non-americans, rally to the cause! plzreviewplz [15:41] mgz_, done [15:44] dimitern: I totally misunderstood! [15:45] dimitern: where you said "please call IsValidSpace" I misread it as "please call the function" (i.e. rename) IsValidSpace [15:45] dimitern: I agree with you :-) [15:45] frobware: merci [15:46] we may actually not do a 1.26-alpha3 - but I also don't want to handle a major version bump in the code right now [15:54] Bug # changed: 1261780, 1493602, 1496652, 1499277, 1511135, 1513236, 1515736, 1517344 [15:54] Bug #1520292 opened: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: 1.23.3.5 > 1.22.8.1'

[15:59] voidspace, oh :) [16:00] dimitern: yeah, oops... [16:00] voidspace, no worries [16:10] I think we need a basic-of-git session in a couple of weeks [16:25] dimitern: ping [16:26] dimitern: so we have to decide what to do with invalid space names [16:26] dimitern: do you think that converting invalid chars to "_" is the right thing to do? [16:27] dimitern: if we error out instead we either have Spaces/Subnets return an error when they encounter an invalid space name [16:27] dimitern: which would mean you can't use *any* spaces or subnets if one of the space names is invalid [16:27] dimitern: or we just drop the invalid space and its subnets [16:28] dimitern: but if we do multiple character substitutions we risk name clashes (two different MAAS spaces being seen as the same juju space) [16:29] voidspace, I think we need to be consistent [16:30] dimitern: we need to eat too [16:30] dimitern: but that doesn't answer the question either... ;-) [16:30] voidspace, sorry, typing still.. [16:30] I agree we *must* be consistent [16:30] I'm only teasing [16:31] voidspace, if a maas space name cannot be converted to a valid juju space name, we can use a generated name or ask user to provide one [16:31] dimitern: how can we ask the user to provide one? [16:31] voidspace, or both (i.e. use a generated-but-valid when importing, and allow the user to rename it) [16:32] voidspace, if we added them manually, that wouldn't be an issue, as we ask for a name anyway [16:32] dimitern: right [16:33] voidspace, but the problem is with auto importing [16:33] dimitern: however, the provider has no access to state - so that will have to happen a layer above the provider [16:33] dimitern: I'm almost tempted to remove SpaceName from SpaceInfo and SubnetInfo and only use ProviderSpaceId [16:33] voidspace, yeah - so doesn't that imply we shouldn't try to convert them in the provider ?:) [16:33] and let the conversion happen elsewhere [16:33] right [16:33] voidspace, that sounds better than inventing names [16:34] dimitern: well, it doesn't avoid the problem - just moves it... [16:34] but moving it out of *my* code is fine [16:34] ;-) [16:34] voidspace, well, we should talk to the provider with names/ids it understands [16:34] dimitern: yep [16:34] voidspace, but the translation needs to happen in the apiserver I think [16:34] dimitern: I'll leave SpaceName on SpaceInfo but remove it from SubnetInfo [16:35] agreed [16:35] voidspace, we do have a similar case already - with relation tags [16:35] ah right [16:35] voidspace, since "relation-#" is the tag format but can't be converted to the other form "svc1:rel1 svc2:rel2", there's an api call to do that [16:37] voidspace, I had a similar issue to solve with subnetsToZones - so the provisioner apiserver facade does the translation between juju id (cidr) and provider subnet id [16:38] before calling start instance [16:56] if anyone feels like punishing themselves, http://reviews.vapour.ws/r/3255/ is another monster :-/ [16:57]