[01:10] menn0: https://github.com/juju/retry/pull/2 [01:11] thumper: looking [01:11] cheers [01:11] wallyworld: do you know if the ci bot is even looking at master? [01:11] seems that the bug was fixed by cmars some time ago [01:12] thumper: they can only target one branch at a time, maybe 1.25 has been getting priority [01:12] probably... [01:12] * thumper sighs [01:12] FARK!!! [01:12] peergrouper test [01:12] damnit [01:13] hate it! [01:16] thumper: it _never_ passes for me [01:16] it mostly fails for me too [01:16] saying that, it just passed [01:16] if I run it by itself [01:16] second time it failed [01:31] thumper: review done. I ended up deleting and changing a lot of my initial comments so ignore the notification emails and go with what's on the PR [01:31] thumper: summary is I think MaxWait is a strange parameter to have. MaxDuration seems more intuitive to me. [01:32] thumper: I'd want to be able to say, "keep trying for up to 10 mins", not "keep trying while the sum of the waits between attempts is less than 10 mins" [01:33] thumper: if Func doesn't take long they work out to be about the same but I bet that sometimes Func can take a while making it hard to figure out exactly how long a series of attempts might take === Spads_ is now known as Spads [02:52] menn0: yeah... I did wonder about that bit too [02:52] menn0: whether or not to take into consideration the time taken to call Func [02:53] menn0: although... it makes testing harder :) [02:54] menn0: because we need something to advance the clock... [02:54] thumper: if time is recorded when retry.Call is first called then it's easy to know how long everything has taken so far [02:54] menn0: however with the mock clock, it is um... different [02:54] the test Clock can do that right? [02:54] hmm... [02:54] we can make it do that [02:54] just by keeping track of now [02:55] and advancing now every time we are asked to sleep :) [02:59] menn0: here is a mind fcukingly boring review: https://github.com/juju/juju/pull/3605 [03:02] ugh... [03:03] master CI failed due to deploying a local charm failing [03:03] WTF? [03:21] thumper: was otp, looking now [03:25] thumper: review done... super exciting that one [03:25] :) [04:52] Bug #1510787 opened: juju upgrade-charm errors when it shouldn't === ashipika1 is now known as ashipika [08:22] Bug #1509747 opened: Intermittent lxc failures on wily, juju-template-restart.service race condition

[08:25] Bug #1509747 changed: Intermittent lxc failures on wily, juju-template-restart.service race condition

[08:34] Bug #1509747 opened: Intermittent lxc failures on wily, juju-template-restart.service race condition

[08:37] Bug #1509747 changed: Intermittent lxc failures on wily, juju-template-restart.service race condition

[08:43] Bug #1509747 opened: Intermittent lxc failures on wily, juju-template-restart.service race condition

[09:29] dimitern: ping [09:29] dimitern: do you know how I can reproduce a situation where "ignore-machine-addresses" is *required*? [09:29] dimitern: (i.e. reproduce the bug it fixes) [09:32] frobware: ping [09:32] dooferlad, omw [09:37] voidspace, I can think of an example [09:38] voidspace, how about: bootstrap, juju ssh 0, add a virtual NIC with an address like 10.0.0.2, watch the logs to see it gets picked up and set among the API host ports [09:39] voidspace, it won't work just by installing the lxc package outside of juju, as we're detecting the presence of /etc/default/lxc-net and parsing it to find the LXC bridge device name, then filter any addresses on it [09:40] dimitern: ok, I'll try that [09:40] voidspace, however, you can try: sudo apt-get install lxc -y after bootstrapping, then rm /etc/default/lxc-net, and reboot the node [09:40] dimitern: our proposed fix from yesterday won't work - it's what we're already doing! [09:40] (or just reboot jujud) [09:41] dimitern: I think the fix might have to be that we prefer a *fallback address* from the provider list in favour of an exact scope match from machine [09:41] dimitern: better would be to filter the addresses we send from the machine, so we don't send unusable addresses [09:42] voidspace, we do that for lxcbr0 addresses, if we can detect them [09:42] right [09:43] better, we should ignore machine addresses by default and understand the circumstances where we actually need them [09:43] (and use them only where we need them) [09:43] * dimitern is thinking whether a fallback match from the provider addresses can always be preferred to an exact machine address match [09:43] dimitern: we can topic it in standup again [09:43] voidspace, ok [09:44] * voidspace is going to get coffee [09:53] voidspace, hey, do you remember that change to "devices new" API that needed type=container in the arguments in order to show up in the UI? [09:56] dimitern: I remember, but that isn't quite right [09:56] dimitern: they have removed devices with a parent from the ui and last I saw they hadn't got round to putting them back [09:56] dimitern: they're going to put them on the node detail pages [09:56] dimitern: they decided not to use "type=container" afaik [09:56] dimitern: so we don't need to do anything [09:57] dimitern: but *currently* devices with a parent don't show in the ui at all [09:57] which sucks [09:57] voidspace, right, ok - as I couldn't find a reference to the type=container argument in maas src (1.8 or trunk) [09:58] dimitern: if you find the maas bug (I can't recall it) they changed the title to remove the reference to type=container [09:58] dimitern: they changed the title to "remove devices with a parent from the devices page" [09:58] dimitern: and they have a new, not-yet-fixed bug, to add them to the node details page [09:59] wallyworld: ping [09:59] voidspace, I see, well - as long as the device is registered and maas can clean it up with its parent, I don't care so much it's not visible in the UI [10:00] dimitern: I think it's a shame [10:00] dimitern: I liked the visibility [10:00] but ah well [10:00] voidspace, it is a shame, but not quite ours ;) [10:02] TheMue, jam, standup? [10:02] brt === akhavr1 is now known as akhavr [10:37] dooferlad: I assume you checked those USB ethernet adaptors work with Ubuntu... ? [10:37] voidspace: reports say yes. [10:37] dooferlad: cool, thanks [10:39] dooferlad: and *not* the 4x SATA SSD - one disk is sufficient? [10:39] voidspace: we have been told to just go msata and the charm will be updated to use one disk [10:40] dooferlad: ok [10:40] dooferlad: those msata disks look funky [10:40] voidspace: overnighting a disk later if needed is a tradeoff we seem to be OK with. [10:40] cool [10:40] voidspace: just plugged in one of those USB3 adapters. Shows up as enx00e060001127 on my desktop in the output of ifconfig [10:41] dooferlad: great [10:47] Bug #1510875 opened: unable to interrupt 'juju boostrap' on MAAS before the node is running

[10:50] Bug #1510875 changed: unable to interrupt 'juju boostrap' on MAAS before the node is running

[10:56] Bug #1510875 opened: unable to interrupt 'juju boostrap' on MAAS before the node is running

[11:01] dooferlad: and those nucs will be fine with my existing PDU [11:02] voidspace, AMT based NUCs, correct? [11:03] frobware: non-AMT I believe [11:03] frobware: they are AMT [11:03] hah [11:03] frobware: believe dooferlad and not me... [11:03] voidspace, ok, just checking as if they're AMT based they can be shared... [11:04] voidspace, with other rigs should priorities change, et al. [11:05] frobware, hw ordered; doc updated with actual prices (with exp. delivery to BG it turned out a bit more than 100 GBP cheaper!) [11:05] dimitern, great [11:05] I mean, not due to the delivery, just price changes I guess [11:06] dimitern, dooferlad, voidspace: I suspect there's some surge pricing for those components going on in some amazon spreadsheet... :) [11:06] frobware: Amazon ran out of NUCs [11:06] :D [11:06] frobware: so now they are £327 instead of £220 [11:06] dooferlad, wow [11:07] frobware: now sold from Kikatek for that delightful mark up [11:07] dooferlad, what I ordered is a bare bones kit - no ram, ssd [11:07] dimitern, which is pretty much the default, no? [11:07] dimitern: yes, that is what I got [11:08] frobware, it is as offered from intel, but some vendors spice it up [11:08] http://www.intel.com/content/www/us/en/nuc/nuc-kit-dc53427hye-board-d53427rke.html [11:12] dammit, I had some in my basket from amazon [11:12] but too late to hit the button [11:12] so I should probably cancel that order - unless I order the NUCs elsewhere at the higher price [11:12] or just wait for amazon to get new stock [11:13] voidspace: amazon stock is due in weeks, right? [11:13] dooferlad: allegedly [11:13] dooferlad: I'm happy to wait, so long as they actually arrive [11:14] voidspace, I'm hoping we can make some progress with vMAAS and a smaller bundle to begin with [11:17] frobware: yep, that would be good === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [13:59] Bug #1510132 changed: redefinition of ‘noMethods$MarshalYAML$hash’

[13:59] Bug #1510944 opened: Only state-server upgrades from 1.20

[14:09] cherylj: there is a regression in 1.22 https://bugs.launchpad.net/juju-core/+bug/1510952 [14:09] Bug #1510952: Upgrades broken in 1.22 tip

[14:23] sinzui: thanks for the heads up [14:24] sinzui: has that test run on 1.24 yet? [14:25] cherylj: no, it hasn't [14:25] It will test next I think [14:26] ok, thanks [14:32] Bug #1510951 opened: Upgrades broken in 1.22 tip

[14:33] Bug #1510952 opened: Upgrades broken in 1.22 tip

[14:40] fwereade: I added setting of unit statuses in the last changes to the unit assigner review: http://reviews.vapour.ws/r/2814/ [14:42] natefinch, awesome, thanks [14:42] er, in the last two changes, that is. [15:02] dimitern, ping [15:02] alexisb, oh, sorry - omw [15:05] * fwereade needs to stop early, will be back this evening to talk to NZ [15:16] dooferlad, having just spoken with cherylj we should look at 1.24 first for #1510651 [15:16] Bug #1510651: Agents are "lost" after terminating a state server in an HA env

[15:16] frobware: thanks, spotted the bug update === akhavr1 is now known as akhavr [16:42] wwitzel3: I know you're there, I can hear you typing [16:56] ericsnow: you around? [16:56] natefinch: yep [16:57] ericsnow: the lxd remote config value - I presume that should be an IP address or domain name? [16:57] natefinch: yep [16:57] natefinch: I'll make that more clear [16:58] perrito666: got a sec? [17:01] ericsnow: I'm adding an isLocal() function to the environ, since we're checking that in a couple places [17:01] natefinch: k [17:01] ericsnow: (the logic is simple, but I don't want remote() == "" getting tossed around the codebase everywhere [17:01] natefinch: fine with me [17:01] natefinch: method on environConfig? [17:03] ericsnow: on the environ. I don't want to have to know to look at the config to determine if it's local. There's some law about not doing foo.bar.baz()... forget now what it's called. Just expose it at the higher level. The config itself doesn't need to know about local or not, I don't think. [17:05] natefinch: you're doing foo.bar. either way and the config is what identifies the remote as local or not [17:06] Bug #1507771 changed: Juju deploy fails when template container cannot be started

[17:07] ericsnow: if you're calling it on the environ, then only environ needs to know that it's getting information from the config. Everywher else just calls the function on the environ. And the environ is the thing that is interpreting the config. The config is just holding the data. Adding isLocal to the config is putting environ-level logic in the data bag that is the config [17:08] natefinch: k [17:08] natefinch: not a big deal to me either way :) [17:08] natefinch: the method is useful regardless [17:09] ericsnow: agreed :) [17:10] ericsnow: fwiw, I started with it on the config and then decided it was probably more appropriate on the environ... but yeah, it's not a huge deal either way [17:12] Bug #1507771 opened: Juju deploy fails when template container cannot be started

[17:15] Bug #1507771 changed: Juju deploy fails when template container cannot be started

[17:30] ericsnow: your dependency injection makes my goto definition useless :/ [17:30] natefinch: you're using a goto? [17:31] ericsnow: yeah, godef [17:31] ericsnow: which will just go to the definition of the interface.. there's no real way around it [17:31] (I think the go oracle has a way to find implementors of an interface, but I haven't been able to get that working) [17:32] natefinch: ah [17:32] natefinch: yeah, bummer [17:32] ericsnow: the downside of interfaces everwhere... figuring out what code is actually getting called is hard [17:40] katco: you have any ideas on a name to use instead of "clientServerMethods"? [17:50] cherylj: I do now [17:51] perrito666: just wanted to follow up on bug 1507867 [17:51] Bug #1507867: juju upgrade failures

[17:51] it looks like there were two pieces: the ignore machine address for containers, and the mongo issues [17:51] I see mfoord took the machine addresses / containers part [17:51] are you still working the mongo side? [17:51] or were you going to hand that off to sapphire? [17:52] indeed, on the mongo issues we are stil waiting some logs that might shed light on the mather sadly the resources of bootstck are a bit scarce right now and they cannot run the test yet, I intended to do the handoff once these logs where in place but I might as well do it now [17:53] perrito666: should we open up a new bug to track just the mongo stuff? [17:53] cherylj: that would be advisable looking again at the current one it is becoming a bit of a mix [17:54] perrito666: okay, I will create one and try to extract the meaningful mongo bits [17:55] * perrito666 is wondering why he came to work to the only coffee shop without internet in town [18:21] ericsnow: well, 3 of them have to do with certificates, so there's a cert struct/interface in there for sure [18:22] ericsnow: the wait and config... perhaps belong in 2 separate interfaces? [18:25] katco: clientServerMethods is just there to help organize the methods better (so the Client methods aren't split across several files) [18:26] katco: in my mind the name communicates that pretty well [18:27] ericsnow: well, first, grouping them into a struct doesn't preclue them being split across files :) [18:28] ericsnow: what do you mean by, "organize the methods"? [18:28] katco: my point is that they were methods of Client before I moved them under their own struct (which Client now embeds) [18:28] katco: grouping the different Client methods [18:28] katco: and splitting them across multiple files [18:29] ericsnow: ok. so i think i'm just asking that you take that to its logical conclusion and group them into types that make sense [18:29] ericsnow: "server" methods is too generic [18:29] katco: I was following the grouping I was already using (see conn_raw.go) [18:31] ericsnow: i think you're grouping in terms of implementation, and it probably makes more sense to group in terms of what the group of methods do [18:32] ericsnow: you even have comments grouping them [18:33] katco: right [18:43] katco: ah, so your concern is with "Server" rather than with the whole name? [18:44] ericsnow: well, the client should take implementations of interface it needs [18:44] ericsnow: so no, the whole thing [18:45] ericsnow: the fact that it's for the client is implicit because the client is embedding the types [18:46] katco: all the client needs is the raw *lxd.Client (as returned by newRawClient()) [18:46] katco: I can change it back so the clientServerMethods methods are methods of Client instead if you like [18:47] katco: that may be less confusing [18:47] katco: (though it splits Client methods across multiple files) [18:47] ericsnow: no i think what you've done is a good thing, you're doing IoC [18:47] ericsnow: i'm just saying split things out to be a little more fine-grained [18:48] katco: but it's not meant to be IOC [18:48] ericsnow: well it is :) and it's a good thing [18:48] katco: IOC here would be providing the raw client as an interface (or multiple) [18:49] ericsnow: that's exactly what i'm saying [18:50] katco: right; that's orthogonal to the clientServerMethods type [18:50] katco: I wasn't planning on doing any IOC yet with the raw client [18:51] ericsnow: you've extracted out the functionality, but haven't encapsulated it in a way that makes sense [18:51] katco: my point is that I haven't extracted out any functionality; it was already there as-is [18:52] ericsnow: you extracted it out into another type, right? [18:52] katco: the only thing I did was move the Client methods in a given file into their own type so that I wouldn't have Client methods spread across mutliple files [18:52] ericsnow: that is extracting the functionality out, isn't it? [18:58] ericsnow: it's fine for now. if you just want to collect them in the same file, leave it on client and put them all in a file together [19:00] katco: hmm, one goal is to avoid massive files like that though [19:00] ericsnow: no i mean, same type, new file [19:00] katco: that's the way I had it in the first place :) [19:01] katco: but having a type split across multiple files is a pain point [19:01] ericsnow: that's better than a new type that isn't encapsulating properly :) [19:01] ericsnow: it is? [19:02] katco: it has been for me [19:11] katco, ericsnow: I definitely highly dislike having a single type split across files [19:13] katco, ericsnow: it makes it harder to understand the type as a whole, and it means you have to go hunting through files to find the method you're interested in. [19:20] perrito666: it looks like there was another bug spun off to track the ignore-machine-addresses with containers. Let's keep bug 1507867 for the mongo issues. [19:20] Bug #1507867: juju upgrade failures

[19:20] sounds fair [19:20] perrito666: I'm going to put in an update that we are waiting on logs from bootstack and assign the bug to you [19:21] once you have a chance to talk with someone from sapphire to do a hand off, please update the bug assignee [19:21] ok, Ill do a handoff as soon as we get these [19:21] awesome, thanks! [19:21] everything is awesome [19:21] * perrito666 sings [19:21] everything is cool when you're part of a team? [19:40] wwitzel3, ping [19:47] Bug #1511090 opened: MAAS documentation on jujucharms.com incorrectly advised disable network management [19:57] alexisb: pong [19:59] heya wwitzel3 I was going to ask you to reach out to adam, but you did [19:59] wwitzel3, also do you have documentation regarding deploying openstack on lxd provider? or is that someone else? [19:59] I heard it now exists [20:01] alexisb: we have an email chain between James Page and myself, but we didn't have any official docs yet since it is a lot tweaking still. [20:05] wwitzel3, ack [20:05] thanks! [20:05] natefinch: ptal: http://reviews.vapour.ws/r/2927/ [20:10] ericsnow: looking [20:11] natefinch: ta [20:29] thumper, waigani, just joined onyx-standup [20:42] Bug #1511103 opened: relation-get error: permission denied [20:48] Bug #1511103 changed: relation-get error: permission denied [20:54] Bug #1511103 opened: relation-get error: permission denied === Icey is now known as IceyEC === IceyEC is now known as Icey [22:24] Bug #1511135 opened: storage: add bundle support [22:27] Bug #1511135 changed: storage: add bundle support === menn0_ is now known as menn0 [22:33] Bug #1511135 opened: storage: add bundle support [22:36] Bug #1511138 opened: Bootstrap with the vSphere provider fails to log into the virtual machine

[22:39] Bug #1511138 changed: Bootstrap with the vSphere provider fails to log into the virtual machine

[22:54] Bug #1511138 opened: Bootstrap with the vSphere provider fails to log into the virtual machine