[02:34] omg i submitted a PR to juju! [02:34] https://github.com/juju/juju/pull/3958 [02:43] mwhudson: whoa! [02:43] :) === ashipika1 is now known as ashipika [09:07] voidspace, dooferlad, frobware, o/ morning [09:07] dimitern, morning [09:11] dimitern: frobware: dooferlad: o/ morning [09:11] dimitern: dooferlad: welcome back :-) [09:11] cheers :) [09:12] dooferlad, I was looking at your WIP branch - you should get all 3 endpoints bound - 1 explicitly, 2 implicitly to @default [09:12] dooferlad, I suspect there's something around adding the charm (and/or metadata) [09:13] there are other examples in the same test package - have you tried using s.UploadCharm ?\ [09:13] dimitern, can we chat about /e/n/i after standup? [09:13] frobware, sure [09:15] frobware, I've realized some time after I sent the last mail to you, that we can use the interfaces list of the node, right after creating it (or even earlier, if there are bindings passed to acquire) to get which NICs are active and create bridges for them only, eliminating the guesswork [09:16] hmm [09:16] dimitern, I had some concerns about our bridge the world approach. [09:17] dimitern, isn't it too late by then though? this is happening in cloud init [09:17] frobware, hmm. that's right [09:18] frobware, but at the time acquire returns (maybe with verbose=1 as well), we should get all the information we need about the interfaces maas knows about that node [10:02] dimitern: stdup [10:03] voidspace, omw [10:03] dimitern: cool [11:39] Bug #1525868 opened: Uniter state file empty after node crash [13:52] dimitern, can we have a quick HO re: address allocation [13:53] frobware, sure, just give me ~10m to finish this test? [13:53] dimitern, ok; ping when convenient. [13:53] dimitern, which can be longer than 10m ... :) [13:56] frobware, will do, sorry I've *almost* nailed the critical bug - finishing the last unit & live tests, so I can get over with it [13:56] dimitern, sure - don't rush. [14:17] frobware, ok, HO? [14:20] frobware, I'm in the standup one - join when you can [14:22] dimitern, omw [14:22] virtuous-lettuce-juju-machine-0-kvm-2.maas-19 is better than juju-machine-0-kvm-2-00249376-2c6a-4243-8c39-7d88008ee3c8.maas-19 [15:42] Bug #1525959 opened: juju 1.25 Alpha2 deploy fails with our existing bundles [16:18] dimitern, ping - you still about? [16:19] frobware, yep [16:19] dimitern, should aliases, whose underlying device is now bridged be "juju-br-eth0:1" or remain as "eth0:1"? [16:20] dimitern, it's really a naming issue only [16:22] frobware, I think it should be fine to leave them alone [16:22] dimitern, http://pastebin.ubuntu.com/14007098/ [16:22] they don't work very well with curtin anyway - I don't think we need to care about aliases now [16:23] frobware, that looks good to me [16:24] dimitern, you sure? That's what we currently do but I think we should drop the alias [16:24] dimitern: ERROR juju.worker runner.go:226 exited "discoverspaces": unknown object type "DiscoverSpaces" [16:24] dimitern, drop the "juju-br" prefix from the alias [16:24] dimitern: this looks to me like the DiscoverSpaces facade is not registered properly [16:24] frobware, so long you have it already and if it works (after the 120s cloud-init-nonet delay..) let's keep them [16:24] unfortunately I tore down the environment before properly looking at the logs [16:24] re-bootstrapping *grrr* [16:24] voidspace, heh, yeah - check init() funcs in apiserver - that's where it happens usually [16:25] dimitern: yeah, init is there [16:26] voidspace, hmm.. is the version v0 or v1 ? [16:26] dimitern: it was 0, I just bumped it to 1 but not pushed yet [16:26] would that make a difference? [16:26] it should be 1 for a new facade, right? [16:27] frobware, I don't mind the prefix, the important thing is whether it works :) [16:27] voidspace, all new facades should be v1 when introduced [16:27] yeah, I doubt that's the problem though... [16:27] voidspace, that was decided at some point, but might be irrelevant [16:30] Bug #1525959 changed: juju 1.26 Alpha2 deploy fails with our existing bundles [16:31] logs don't have any more useful information, will have to actually work out the problem... [16:32] voidspace, check if the api/ side is calling the correct method and facade name [16:33] facade name is correct [16:33] will add more logging in the worker [16:33] voidspace, alternatively, might be a permission thing? [16:35] dimitern: could be, although I would expect (hope?) for a different error message [16:35] adding logging to see [16:39] Bug #1525959 opened: juju 1.26 Alpha2 deploy fails with our existing bundles [16:42] Bug #1525959 changed: juju 1.26 Alpha2 deploy fails with our existing bundles [18:16] Bug #1526003 opened: Data race in undertaker [21:19] Bug #1526063 opened: TestNoContextWithLock === blahdeblah_ is now known as blahdeblah [21:58] Bug #1526072 opened: Juju-deployer 0.6.0 and juju-core 1.25 - Build doesn't time out and keeps running until aborted [22:04] Bug #1526072 changed: Juju-deployer 0.6.0 and juju-core 1.25 - Build doesn't time out and keeps running until aborted [22:07] Bug #1526072 opened: Juju-deployer 0.6.0 and juju-core 1.25 - Build doesn't time out and keeps running until aborted