[00:22] it is strange [00:23] i've seen more piture of HRH in NZ that I have in Au [01:25] Bug #1588636 changed: mgo: Panic: Test left sockets in a dirty state (PC=0x46257C)

[01:27] spot the bug if err != nil && err == mgo.ErrNotFound { [01:27] return errors.Trace(err) [01:27] } [01:28] aside form the err != nil being extraneous? [01:28] errors.Cause? [01:29] if errors.Cause(err) == mgo.ErrNotFound { return errors.Trace(err) } [01:29] yeah, it's eaither [01:30] err != nil && err != mgo.ErrNotFound [01:30] or err == mgo.ErroNotFound [01:30] but the latter would mean ignoreing any error other than mgo.ErrNotFound [01:31] well, yes.. it depends on the rest of the error stack to figure out which one they meant [01:31] er s/error stack/context of the code [01:32] I kinda hate errors.Trace. It just adds so much noise to the code. If we had the stacktrace on the error, I don't think I'd ever use trace. [01:33] https://github.com/juju/juju/commit/93d52ed7 [01:33] fix some log messages ... and add an entire state/presence package [01:33] no biggie [01:34] natefinch: that's why my errors package captures the full stacktrace at the point of creatin [01:34] it has some drawbacks [01:34] but compared to errors.Trace turds everywhere [01:34] it's paid for itself [01:36] davecheney: that commit is pretty funny... I presume the presence stuff was intended to be committed separately [01:36] davecheney: also, whoowee that is some old code [01:37] yeah, that line is older than some of your kids [01:37] davecheney: this is true. [01:47] wallyworld: I spent Friday looking at the logs, but I can't see any differences between the setaddress calls that work and those that fail. I'm printing out the entire list of operations... and the ones that work look identical to the ones that fail.. and the ones that fail, the ops don't change from attempt to attempt, as they should if things were actually changing. [01:47] natefinch: https://github.com/juju/juju/pull/5537 if you feel so inclined [01:49] natefinch: maybe we need to log what is actually in the db [01:50] wallyworld: yeah, I had that in there and then must have deleted it while debugging why I wasn't getting any log output. Sigh. [01:54] davecheney: wow, totally messed up error handling for 4 years... [01:55] admcleod_: i guess mgo doesn't often return errors other than not found [01:55] whoops [01:55] davecheney: that was for you, of course [01:55] stupid fingers [01:56] davecheney: I'd ask for a unit test to verify it, but... uh.. yeah. LGTM [01:56] natefinch: didn't fail before : didn't fail afterwards :) [01:57] what I wouldn't give for separate persistence layer [01:58] you had me at separate layer [03:06] https://bugs.launchpad.net/juju-core/+bug/1589339 [03:06] Bug #1589339: environs/manual: test failure if host does not have a valid reverse dns record [03:06] nice [03:06] lol [03:08] solution: hack /etc/hosts [03:09] test isolation, how does it work? [03:10] Bug #1589339 opened: environs/manual: test failure if host does not have a valid reverse dns record [03:13] Bug #1589339 changed: environs/manual: test failure if host does not have a valid reverse dns record [03:22] Bug #1589339 opened: environs/manual: test failure if host does not have a valid reverse dns record [03:24] davecheney: wow, I just noticed from an offhand comment on golang-nuts that builds are now deterministic... that's amazing [03:25] natefinch: cool [03:25] i hope it lasts [03:25] googlers don't care about byte for byte comparisons [03:25] and there is no test for it [03:25] davecheney: gah, there should be a test for it [03:25] davecheney: it's SOOOO useful [03:38] axw: here's part 1. next I can introduce a get-controller-config CLI and make get-model-config only show the model specific bits; we can also pass in config from cloud.yaml as controller config at bootstrap time [03:38] http://reviews.vapour.ws/r/4983/ [03:38] wallyworld: thanks, just saw. just from reading the summary: why in the "controllers" collection rather than the settings collection? [03:39] axw: collection needs to be global [03:39] so all models can always read the controller config [03:39] wallyworld: ok [03:40] axw: i started out in settings and it all went to shit with different hosted models [03:40] we now use that controllers collection for a few things it seems [03:42] axw: once this gets a +1 or whatever, let me know where you're at so we can decide what bit i should do next - the CLI or controller config from clouds.yaml. also, i think we need to handle the case for things like resource-tags where the model values don't overwrite but merge [03:43] wallyworld: sure. merging config sounds like something we don't need to do right away [03:44] yeah [03:44] axw: i should have said in the PR, but a bunch of the green is model config stuff moved from state.go to its own modelconfig.go file [03:45] wallyworld: yep, thanks [03:45] and i found some old code to delete also [03:52] Bug #1589350 opened: apiserver/provisioner: tests do not pass with go 1.7 beta 1 [04:07] Bug #1589350 changed: apiserver/provisioner: tests do not pass with go 1.7 beta 1 [04:10] Bug #1589350 opened: apiserver/provisioner: tests do not pass with go 1.7 beta 1 [04:10] Bug #1589351 opened: provider/azure: test failure during stress test [04:16] https://launchpad.net/bugs/1589353 what a shitshow [04:16] Bug #1589353: apiserver/annotations: test failure during setup [04:40] Bug #1534757 changed: Attempting to run charm before unit provisioned, 1.26 <2.0-count>

[04:40] Bug #1589353 opened: apiserver/annotations: test failure during setup [04:41] axw: wallyworld https://github.com/juju/testing/pull/101 [04:41] here is a simple one [04:41] ok [04:43] davecheney: ty, nice to see that fixed [04:43] wallyworld: it's one of those bugs that doesn't stay fixed [04:44] wallyworld: i've been trying to repro https://bugs.launchpad.net/juju-core/+bug/1588574 [04:44] Bug #1588574: Session already closed in state/presence

[04:44] but all i've acomplished so far today is raising 4 extra bugs [04:44] yeah, the presence stuff sucks [04:45] axw: we'll need to get to the inheritance stuff pretty quickly to allow config from clouds.yaml to be handled. i guess we should keep controller only config like api port totally separate from anything that can be inherited [04:47] wallyworld: unless it's going to be a huge amount of rework (didn't look like it), I'd feel more confident reviewing them separately. [04:48] ok [04:49] davecheney: did u try to remove omitempty as per my suggestion? [04:50] anastasiamac: no i did not i'm sorry [04:50] i'm still trying to reproduce the error locally [04:50] anastasiamac: why will changing the json part of a struct fix the bug ? [04:50] davecheney: it does not cause probs for me except at landing :D [04:51] davecheney: every attemp at landing came up with the error messaage u r chasing "session closed" [04:51] davecheney: possibly unrelated and was just this PR's luck :-P [04:52] anastasiamac: yeah, i cannot reprodyce the bug locally either [04:52] i'm trying to build an environment in ec2 that matches CI [04:52] but i keep hitting flakey tests [04:52] davecheney: \o/ [04:52] i've raised 4 bugs already today and haven't managed to run all the tests successfully [04:53] davecheney: it's sad but even that makes a productive day :-P [04:54] if I fix all 4 bugs I raised, then I'm back to square one, so that's something [04:55] :D [05:06] spoiler alert: i'm probably not goig to fix all four today [05:13] funny and here I was looking forward to watching it all being fixed today :D [05:14] axw: bbiab, almost got a revised branch ready, but school pickup [05:52] Bug #1589372 opened: state: state test failure during stress test [07:02] Bug #1589385 opened: leftover eth0.cfg in /etc/network/interfaces.d <4010> [07:11] mongodb is such a pile of crap === admcleod_ is now known as admcleod [07:19] I _finally_ got the bug to trigger locally [07:22] davecheney: \o/ how? [07:22] anastasiamac: persistance [07:22] just need enough load [07:22] in the right way [07:23] well done! ;-P [07:32] https://github.com/juju/testing/pull/102 === jamespag` is now known as jamespage [08:44] axw: would you yave time to look at http://reviews.vapour.ws/r/4972/ ? it needs to merge into the feature branch === gnuoy` is now known as gnuoy [09:01] voidspace, fwereade: standup? [09:01] dooferlad: ^^ [09:05] dimitern: sorry, omw [09:05] got distracted [09:34] fwereade: how does the advice to return concrete errors (e.g. ErrFooFailed) align with "no global variables" ? [09:35] (as I suspect global consts are fine) [10:06] fwereade: https://github.com/juju/juju/pull/5543 [10:06] if you have the time [10:25] dimitern, ha :) good point, possibly error types are safer? I have been bitten a couple of times by people assigning to stuff that's "obviously" a global "constant" variable [10:25] dimitern, but types don't quite feel like they pay for themselves? [10:26] fwereade: yeah, I suspect so [10:26] fwereade: it's nice to use if errors.Cause(err) == ErrMyFooFailed [10:28] fwereade: well, I guess if we define type SimpleError string and func (s SimpleError) Error() { return s }, we can define all such concrete errors as const ErrFooFailed SimpleError = "foo failed" [10:28] and get both the const guarantee and no global vars [10:29] davecheney, LGTM [10:30] dimitern, mm, I think I like that [10:30] dimitern, neat [10:32] fwereade: it even works: https://play.golang.org/p/jbCEra4_xi [10:33] (and it should be almost the same using Cause()) [10:37] fwereade: re tests isolation, while treating tests and production code the same: given a ctor NewFooForSeries(series string) (Foo, error); and Foo being an interface with concrete (unexported) implementations per series [10:39] fwereade: how to properly isolate this for tests (assuming e.g. Foo.GetFoo() returns different results based on what's there on the local machine)? One option is to allow "dummy" as series and construct a no-op Foo, that has extra methods tests can use to set a pre-canned result from GetFoo().. [10:50] dimitern, I *think* that if they differ interestingly enough to be different types they deserve different ctors for direct testing? then you can have a wrapper around a map[series]ctor with shims as necessary and test that as much as it needs -- but it's much closer to being purely data-driven [10:52] dimitern, and then if NewXenialFoo returns an exported *XenialFoo it seems sane/good to check the underlying types that come out of a Foo factory [10:53] fwereade: I was thinking something like this might work: https://play.golang.org/p/bW-TI4l8yI [10:53] dimitern, or rather checking that some series return a *UpstartFoo and others a *SystemdFoo [10:54] fwereade: and the dummyRouteSource there is perfectly valid at run-time, but will be mostly used by tests; no special treatment [10:56] fwereade_: hey, did you get the last link? [10:56] dimitern, I think I'd rather see a *WindowsRouteSource and a *LinuxRouteSource [10:56] dimitern, don't think so [10:57] dimitern, (both the above could be unit tested everywhere, I think?) [10:57] fwereade_: here:https://play.golang.org/p/bW-TI4l8yI [10:57] ah I did see that one [10:58] dimitern, or rather checking that some series return a *UpstartFoo and others a *SystemdFoo [10:58] dimitern, is anything in there so platform-specific it needs build tags? [10:58] fwereade_: my point is NewRouteSource() will be called somewhere early as part of a lot of tests, and by default it can use the dummyRouteSource [10:58] fwereade_: it needs to use different sources (usually execute different tools and parse different outputs) [10:58] dimitern, I was thinking I'd rather have an explicit NewFakeRootSource() for tests? [10:59] fwereade_: that's cleaner perhaps [10:59] dimitern, and, yeah, but you don't want to hit the actual OS with those calls in unit tests [10:59] fwereade_: and the Fake one can implement e.g. SetRoutes() in addition to GetRoutes() from RouteSource [11:00] dimitern, yeah, that sounds good, or you could just pass them in in the ctor [11:00] dimitern, harder for people to induce races ;p [11:01] fwereade_: I really don't want to repeat earlier mistakes, e.g. patching the package tests for GetRoutes() to use faked ones, but providing no easy way to do the same outside the package [11:01] dimitern, quite so, it feels to me like it's a foo/footest.NewRouteSource(...) situation [11:01] fwereade_: routes as Fake ctor args is nice! will do that [11:02] dimitern, where do we need to thread the routes through to, by the way? [11:03] fwereade_: and having specific ctor's (NewWindowsRouteSource) rather than a switch-sorta-factory feels better - NewWindowsRouteSource can still be there but it's impl. can be in a +build windows - guarded file [11:04] dimitern, why hide it away? just makes it easier to break when you're not running on windows [11:04] fwereade_: atm I need to implement and parse "get default route", and then use it as part of the container provisioing step [11:04] dimitern, unless it's guarding actual syscalls I'd rather steer clear of +build where possible [11:05] fwereade_: fair point [11:05] fwereade_: it's more about guarding against the lack of a windows-specific tool [11:05] dimitern, ok, but we don't want to *actually* call the tool in the unit tests, regardless of system [11:09] fwereade_: nope, only in the package tests [11:09] fwereade_: we'll call a patched executable for the tool [11:10] fwereade_: I was thinking of using natefinch's PatchExec that uses jujud as the binary to call [11:10] fwereade_: and outside of the package, the NewDummyRouteSource() will be used in all tests [11:15] fwereade_: how does that sound? [11:18] dimitern, do we have to PatchExec or can we supply, e.g., a `func RunCommand(string, ...string) (notsurewhattoreturn, error)` [11:18] fwereade_: https://github.com/juju/testing/blob/master/cmd.go#L203 [11:19] it's essentially what it does - patching exec.RunCommand [11:20] fwereade_: "patching" is incorrect here, as nothing is actually patched [11:20] fwereade_: AIUI we're using GetExecCommand when needed in the suite, rather than using PatchValue() [11:21] wallyworld: I gave that PR a LGTM on GitHub already [11:22] axw: oh great ty. just about to push up a new revision of the other. found a bug where we were setting up cfg with controller uuid and then initialising state with something else [11:22] wallyworld: cool. I probably won't be able to review till the morning tho, sorry [11:22] and then there were inconsistencies. may have just been tests [11:22] that's fine [11:24] dimitern, I think it *does* still depend on some magic patching, from having to embed that suite, and I think it smells a bit maybe? -- but it *does* still give you a real *exec.Cmd, which *is* pretty cool [11:25] dimitern, so that sounds reasonable to me [11:25] fwereade_: ah, sorry - PatchValue can be used after all (e.g. environs/tools/build_test.go:TestGetVersionFromJujud), but isn't necessary (e.g. cmd/juju/commands/main_test.go:TestFirstRun2xFrom1xNotUbuntu - we can just run the patched command directly with CaptureOutput) [11:26] I quite like that approach :) [11:26] s/that/that second/ [11:26] fwereade_: ok, cheers [11:26] dimitern, right, ok, but what's writing to os.Stderr/out in the first place? doesn't having to capture those imply broken isolation? [11:27] * fwereade_ may well be missing something [11:27] fwereade_: I think it's still isolated, see: CaptureOutput creates both stderr and stdout in isolation [11:28] https://github.com/juju/testing/blob/master/cmd.go#L307 [11:28] dimitern, yeah, that's what's bothering me -- what is causing stuff to be written to os.Std* that we need to patch it out in :317? [11:29] fwereade_: exec.Cmd.Run() does [11:30] dimitern, this feels like a sign that the (string, ...string) shortcut is maybe the source of the problem [11:30] dimitern, only if you don't set the command up properly ;p [11:33] dimitern, utils/exec doesn't seem that great for replacing either, though, what with RunParams actually being stateful [11:33] fwereade_: so you're saying rather than embedding PatchExecHelper, then using GetExecCommand() and CaptureOutput, use a ctor e.g. NewWindowsRouteCmd() that sets it up to run "route print", and NewLinuxRouteCmd() doing "ip route ..", and a NewFakeRouteCmd() taking args and output? [11:35] by "sets it up to run" I mean &exec.Cmd{Args: .., Path: .., Stdin: inBuf.Reader(), ..} [11:35] dimitern, I don't *think* so? if we need the types we need the routes, I presume -- clients will just want to accept a `Routes`, right? [11:35] s/I mean/I mean return/ [11:36] fwereade_: Routes like []RouteInfo argument to the OS-specific RouteSource ctor? [11:37] dimitern, no, just a type encapsulating the routes, already created [11:38] * dimitern steps out for ~30m [12:02] dooferlad: ping [12:04] frobware: pong [12:14] dooferlad: for the reboot cloud-init stanzas - did that work for all of precise, trusty and xenial? [12:17] frobware: IIRC, yes [12:20] Bug #1589471 opened: Mongo cannot resume transaction

[12:37] frobware: that branch that did the reboot is gone :-( [12:38] dooferlad: do you recall the name of the branch? [12:38] frobware: no [12:38] dooferlad: I have you as a git remote [12:41] frobware: git reflog to the rescue :-) [12:43] dooferlad: http://pastebin.ubuntu.com/17060265/ [12:43] frobware: yep [12:45] dooferlad: just shows how long we've been futzing with this [12:46] frobware: no wonder we have a bit of a bunker mentality [14:00] dooferlad: ping [14:02] frobware: pong [14:08] dooferlad: please could you capture the output (or perhaps lack of) for the bond/LACP issue and raise a bug. [14:08] dooferlad: asking as you definitively have more NICs.... :) [14:11] frobware: it simply hangs after the bridge script runs. Nothing more to say! [14:13] dooferlad, dimitern, frobware: what do maas 1.9 node-groups correspond to in maas 2? [14:13] babbageclunk: to rack controllers [14:13] dimitern: thanks [14:29] * fwereade_ thinks he just barely resisted the urge to name a type *state.Less [14:34] fwereade_: nice [14:47] hey all, happy monday! [14:48] hey [14:48] alexisb: happy monday [15:08] dimitern: ping? [15:09] babbageclunk: pong [15:12] dimitern: can I pick your brains about this maas spaces demo stuff in the juju-sapphire hangout? [15:12] babbageclunk: yeah, ok - omw [15:12] dimitern: thx! [15:31] hey, does anyone know how to manually log into the controller's mongo instance now? the password in accounts.yaml doesn't seem to work [15:36] katco: if mongo is v3 you need to install mongodb-org ppa and pull the 3.x client [15:36] people at packaging are working to provide the client along with the tools soon [15:36] perrito666: i'm on beta9, so i assume that v3 [15:36] so we dont have to [15:36] katco: it actualy depends on your distro [15:36] xenial? [15:36] perrito666: the machine i have available atm is wily [15:36] your => your machine 0 [15:36] perrito666: host machine [15:37] perrito666: bootstrapped controller is xenial though [15:37] then yes, mongo 3 [15:37] controller is what matters [15:38] * perrito666 is stuck waiting for the plumber and has no food, happy monday [15:38] mramm: thank you for your repro case on lxd [15:38] mramm: on that ip address setting bug [15:39] perrito666: ta. do you have a url for that ppa? [15:40] katco: https://docs.mongodb.com/v3.0/tutorial/install-mongodb-on-ubuntu/ sorry not a ppa, old style debline [15:40] perrito666: ah ok [15:41] perrito666: ta for your help [15:41] np, ask if you need anything else [15:42] my computer is not so happy about having a 13 machine LXD environment deployed :) [15:43] obv time for a bigger machine [15:45] natefinch: openstack bundle? [15:52] perrito666: just a couple random bundles, HA/big data stuff [15:53] natefinch: yea, I just built a desktop machine with 64 gig ram because juju deploying so much stuff broke my (relatively powerful) laptop [15:54] yep, lots of ram and lots of ssd :) [15:55] yep, two different SSD's on two different SATA channels, one for the system and one for the lxd filesystem [15:55] yep... my laptop is quad core i7 with 16GB of RAM... I'm glad they started offering 32GB on new XPS 15s. But I keep thinking that I should really just get a desktop and keep this laptop just for sprints. for the amount I spent on this laptop I could get a ridiculous desktop [15:56] go desktop, is the way [15:56] I have done that and use the laptop for whenever I cant work at home [15:56] plus it would be fun to build a desktop from scratch again... haven't done that in like a decade [16:07] brb reboot [16:09] Bug #1589385 changed: leftover eth0.cfg in /etc/network/interfaces.d <4010> [16:11] bbl, errands [16:19] I too had to throw together a more capacitive desktop for deploying lxd in my home lab [16:19] behold her beauty [16:20] http://imghub.org/image/UMUX [16:20] :-) :-) [16:20] http://imghub.org/image/UrGu [16:21] one more, http://imghub.org/image/UxWY [16:24] to be honest, I built her a few yrs ago ... she serves as my lxd lab now though [16:24] nice cooling rig [16:24] Bug #1589581 opened: Consistant basic use of debug-log between 1.25 and 2.0 [16:25] how many NICs are in there? looks like you have 4 ethernet cords plugged into it? [16:27] natefinch, yea .... things are arranged slightly different now, but I use to have to make up for not having 10G network infra [16:27] bdx: ha. yeah, must be hard roughing it on single gigabit ethernet [16:29] I would create iscsi extents and share them to different servers over different interfaces/networks to try to mitigate stomping the 1G [16:29] lol [16:33] now she has 10G, so I can share her fast zfs arrays to other servers more better [16:35] I use to be heavily into the gpu modding game ... those 660's in there are modded to grid k2's [16:37] they no longer exist tho [16:38] she is gpu-less nowadays [17:34] cherylj, ping [17:56] alexisb: pong [17:56] heya cherylj [17:56] welcome back [17:59] thanks :) [18:40] Bug #1588911 changed: Juju does not support 2.0-beta9

[18:40] Bug #1589628 opened: Unable to bootstrap lxd with juju 2 because of x509 certificate error [18:40] Bug #1589635 opened: github.com/juju/juju/state fails on TestMachinePrincipalUnits with an unexpected name [18:43] Bug #1589628 changed: Unable to bootstrap lxd with juju 2 because of x509 certificate error [18:43] Bug #1589635 changed: github.com/juju/juju/state fails on TestMachinePrincipalUnits with an unexpected name [18:43] Bug #1588911 opened: Juju does not support 2.0-beta9

[18:49] Bug #1588911 changed: Juju does not support 2.0-beta9

[18:49] Bug #1589628 opened: Unable to bootstrap lxd with juju 2 because of x509 certificate error [18:49] Bug #1589635 opened: github.com/juju/juju/state fails on TestMachinePrincipalUnits with an unexpected name [18:56] perrito666: ping [18:57] katco: pong [18:58] perrito666: hey, are api calls currently carrying information about the user who's making it? [18:58] iirc, the info is in the connection only [19:00] perrito666: can you give me a jumping-off point? [19:02] katco: certainly, if I am guession correctly what you are looking for, apisercer/client_auth_root.go is a great place to start, there you know the facade, method and the user all in the same place [19:02] perrito666: awesome, that sounds like a winner, ta [19:03] wow, my typo rate really worsens when my wrist is hurt [19:03] katco: np [19:10] anyone online know anything about the state.address struct? [19:13] Bug #1589641 opened: github.com/juju/juju/state fails on ActionSuite.TestUnitWatchActionNotifications

=== redir is now known as redir_lunch [19:36] natefinch: not I [20:00] voidspace: don't suppose you're working late today? [20:13] Bug #1589670 opened: backups does not implement Backups for non linux OSes [20:15] fwereade_: ping? === redir_lunch is now known as redir [20:33] alexisb: btw, we'll need to hand off this bug. I'll be on later, but I'm not going to figure it out in the next half hour. . [20:43] natefinch, did you provide an update in the bug? [20:43] Bug #1589680 opened: Upgrading to cloud-archive:mitaka breaks lxc creation