[00:04] menn0: do we have any friends at mongodb inc or who really know mongo details inside out? [00:05] mwhudson: I think niemeyer might know some people there, not sure otherwise [00:06] menn0: ok [00:11] to by now what is by now a general lack of surprised, switching to the mmapv1 storage engine makes the test much faster [00:12] mwhudson: doh ... so maybe wiredtiger sucks [00:12] yeah it's a bit odd [00:12] or maybe it's something about the way we use it [00:12] i wonder if there's some tuneable [00:12] this is why i would like to talk to someone who really knows their shit [00:14] mwhudson: start with niemeyer I guess [00:14] niemeyer: hello hello [00:15] huh i wonder about using https://docs.mongodb.org/manual/core/inmemory/ for tests one day [00:15] oh, enterprise only [00:31] * mwhudson is now reading spinlock code in wiredtiger... [00:38] until tomorrow juju-dev === redir is now known as redir_eod [00:47] hee hee [00:47] After this operation, 1,356 MB of additional disk space will be used. [00:47] (installing juju-mongodb3.2-dbgsym) [00:56] mwhudson: heya [00:57] I'm on my phone so apologies in advance if the communication breaks up [01:09] niemeyer: ok, just wondering if you know a good person to poke at mongo inc [01:10] niemeyer: we have an issue where index creation with wiredtiger takes ~100ms vs ~1ms with mmapv1, makes some tests veeeerrrry slow [01:12] niemeyer: also it's 100ms of wall clock time but <<100ms of cpu time so i suspect it's waiting on a lock or something [01:16] mwhudson: Let me find a bug #.. Just a sec [01:18] mwhudson: https://jira.mongodb.org/browse/SERVER-21198 [01:19] mwhudson: Very unfortunate indeed, and I could not find much support to actually fix the underlying problem [01:20] mwhudson: I haven't yet finished testing with libeatmydata [01:21] niemeyer: huh, let's try turning --nojournal off [01:21] mwhudson: You can't if --config is used, but you probably don't need that [01:22] (mgo does as it needs to ensure replicas work well too) [01:22] hm seems to help [01:23] of course i have so much debugging crud patched into my tree that its hard to tell [01:25] mwhudson: If you find something interesting please do let me know.. I'm struggling with the same issue.. Still using mmapv1 on CI due to that [01:26] niemeyer: will do [01:26] i should actually read the whole ticket too... [01:27] thumper: why should a non-controller-administrator model owner not be allowed to grant access to their model to someone else? [01:28] axw_: this is what I'm fixing [01:28] thumper: didn't you change it to that tho? was that temporary? [01:28] axw_: no, it was done that way when grant/revoke were added [01:28] in error [01:29] thumper: ah ok, I'm looking at the wrong function [01:29] thumper: so what will it be? only model owners can share? [01:30] anyone with write access to the model can share [01:30] and admins [01:30] thumper: hmm ok. I guess if you give someone write access, then it makes sense that they can delegate that to someone else. ok, thanks [01:30] thumper: just clarifying some docs [01:31] np [01:33] niemeyer: blah, 3.2 is still a LOT slower even without --nojournal [01:34] but it certainly does help [01:35] 3.2/nojournal: 20s 3.2/no-nojournal: 6.5s 2.4/nojournal: 0.3s 2.4/no-nojournal: 0.8s [01:40] and 3.2 with mmapv1 is ~the same as 2.4, this is mmapv1 vs WT, nothing else afaict [01:45] huh mongod doesn't start with eatmydata for some reason [02:17] menn0: btw i also filed https://bugs.launchpad.net/juju-core/+bug/1573286 [02:17] Bug #1573286: juju/mongo: oplog tests fail with mongod 3.2 [02:18] mwhudson: yep I saw that [02:18] mwhudson: thanks [02:18] mwhudson: I'll jump on that once this SSH host key work is done [02:18] cool [03:00] axw_: do you happen to know off the top of your head what happens with "juju ssh" and windows machines? [03:00] do we explicitly block it or will it just fail because there's no SSH server? [03:00] menn0: windows client? [03:00] windows workload machine [03:01] menn0: I'm pretty sure it'll still try to connect [03:01] (and fail) [03:01] axw_: ok thanks [03:01] menn0: I'm bootstrapping azure, I can try it if you like [03:02] axw_: it's ok, it doesn't matter too much, more curious than anything [03:03] okey dokey [03:10] Bug #1571687 changed: Azure-arm leaves machine-0 from the admin model behind [03:19] Bug #1573365 opened: Can't bootstrap --upload-tools on trusty [03:49] Bug #1573365 changed: Can't bootstrap --upload-tools on trusty === urulama|____ is now known as urulama [04:25] Bug #1573382 opened: only one user can create local users [04:57] * thumper goes for a wander [05:46] * menn0 is done [06:01] Bug #1572707 changed: 2.0b5: panic when running juju register [06:01] Bug #1573407 opened: juju show-user/list-users do not check authorisation [06:52] Bug #1573410 opened: trusty juju 1.25.5 having issues deploying xenial lxc containers [07:31] perrito666: i do now :) === rogpeppe2 is now known as rogpeppe [08:15] I figured out how to trick the unit tests into thinking trusty is still the latest lts :) [08:17] mv /usr/bin/distro-info /usr/bin/distro-info-org && ln -s /usr/bin/fake-distro-info /usr/bin/distro-info [08:18] fake-distro-info is just `#!/bin/bash\necho trusty` [08:23] and make check passed for the first time since yesterday, just like on a good ol' trusty machine \o/ [08:41] babbageclunk: morning [08:41] babbageclunk: any luck with the maas upgrade yesterday? [08:44] dimitern: morning! [08:45] dimitern: Well, it came back up when I restarted the vm this morning, but it's still reporting the wrong version. [08:45] babbageclunk: via the CLI ? [08:45] I'm doing the update/dist-upgrade dance now. [08:45] yup [08:46] I got a bit confused by the fact that apt doesn't have a dist-upgrade command, so I just did an upgrade (which definitely mentioned maas packages). [08:46] babbageclunk: the vm where the maas contoller runs is xenial, right? [08:46] do I still need to do a apt-get dist-upgrade as well? [08:46] dimitern: yes [08:47] babbageclunk: sudo apt dist-upgrade works for me btwq [08:47] btw even [08:48] dimitern: tsk, doesn't appear in the help or the man page! Presumably there for backwards-familiarity? [08:49] babbageclunk: ha! you're correct - it doesn't appear in the help, but bash completion seems to suggest it.. I guess it's aliased to full-upgrade [08:50] dimitern: I don't understand the difference - reading on askubunut [08:50] uhbuntu [08:50] babbageclunk: full-upgrade vs dist-upgrade ? it appears to do the same thing on my machine at least :) [08:51] dimitern: sweet, that's emitting lots of messages about upgrading the maas installation [08:51] dimitern: well, migrating it [08:51] dimitern: It was the difference between upgrade and dist/full-upgrade I didn't grok [08:52] but now I think I do! [08:52] ha, didn't realise maas was django [08:53] heh I still don't get the difference between full- vs dist-upgrade [08:55] dimitern: yay, version is upgraded now - between that and bumping up the ram on the controller everything seems good now. [08:55] dimitern: thanks for the help! [08:56] babbageclunk: awesome! I'm glad it ok, as I was already feeling bad for suggesting it :) [08:56] dimitern: :) would have been straightforward if I was a bit more familiar with all of the tools. [08:57] babbageclunk: well, with my experience maas upgrades are rarely a walk in the park :D although it seems to be improving with each release [08:58] dimitern: ooh, I wonder if that fixes the bug with the power settings getting cleared when the machine gets allocated via the API. [09:00] babbageclunk: hopefully - they've made changes to the power handling, esp. around what's considered 'fatal error' (not to be retried) === dooferlad_ is now known as dooferlad [09:34] babbageclunk: dimitern: frobware: dooferlad: you updated your main machines to xenial yet? [09:34] nope [09:34] voidspace: noooooo [09:34] :-) [09:34] dooferlad: I thought you probably wouldn't have [09:34] voidspace: yeah [09:35] dimitern: hah, cool [09:35] I might wait a few days, I don't generally wait very long [09:35] voidspace: I was eager to try maas2 2 weeks ago so I did [09:35] a trivial change to the lxd provider, review appreciated please: http://reviews.vapour.ws/r/4682/ [09:36] rogpeppe: LGTM [09:37] voidspace: ta! [09:38] rogpeppe: wait a sec please [09:38] voidspace: yes, for about 2 months now [09:38] rogpeppe: why panic? [09:38] dimitern: we've had this conversation before [09:39] rogpeppe: I guess so, but can you remind me? :) [09:39] dimitern: config.Schema is deterministic [09:39] dimitern: and configSchema is a global variable that never changes [09:40] dimitern: and we've run a test that calls environprovider.Schema [09:40] * dimitern has another look [09:40] dimitern: so if config.Schema returns an error, there is some serious problem === urulama is now known as urulama|school === urulama|school is now known as urulama|afk [09:41] dimitern: the interface contract for Schema doesn't return an error (and why should it? a provider should be able to return its own schema without errors) [09:42] rogpeppe: right, got it [09:42] hi, I've experienced some problems with the hostname not being set in /etc/hosts when Juju with LXD as provider [09:42] dimitern: this code is just the same in the other providers [09:42] this is on 2.0 beta4 [09:42] rogpeppe: :) thanks for explaining [09:42] I saw this: https://github.com/lxc/lxd/issues/1759 [09:43] would it be up to Juju to set this up correctly? [09:46] jamespage: did that work OK for you? [09:57] [] [10:01] [11:03] jamespage: I saw that you were involved here: https://bugs.launchpad.net/charms/+source/ceph/+bug/1365671 [11:03] Bug #1365671: juju + maas provider: ceph-mon doesn't listen on localhost and /etc/hosts points fqdn to 127.0.1.1 [11:03] Could you please clarify how this works now in Juju 2.0? [11:04] I'm trying to setup the hbase charm on a local LXD environment but it complains about the hostname not being set in /etc/hosts [11:04] simonklb, tbh I don't know how that would work in a LXD environment - the original bug was with MAAS doing some config it did not need todo. [11:05] jamespage: do you know how cloud-init is configured? Is that something you can do with Juju? [11:06] simonklb, juju manages all of that complexity [11:06] simonklb, this charm? https://jujucharms.com/hbase/ [11:07] jamespage: yes! === rvba` is now known as rvba [11:07] from that bug-thread you were in it said that MAAS was configured with manage_etc_hosts localhost - so is cloud-init configured per provider somehow? [11:08] it seems like manage_etc_hosts is unset with the LXD only setup [11:08] simonklb, its certinaly not the same with every provider... [11:08] cory_fu, hey - do we have a more recent hbase charm than https://jujucharms.com/hbase/ [11:09] I wrote that for 12.04 and I suspect it needs to be removed from the charmstore.... [11:09] its certainly not been tested recently by the looks of things... [11:09] dammit need to stop doing ... [11:09] gnuoy is going to start fining me about that [11:09] I am... [11:10] my fingers do it on auto [11:11] jamespage: a more recent hbase would be even better, but it might be useful to know how to configure cloud-init with Juju (if it's possible) [11:11] simonklb, juju intentionaly abstracts that away from the end user [11:12] there may be configuration knobs per provider that change cloud-init behaviour, but nothing that will allow you to touch it directly... [11:13] jamespage: right, seems wierd that they wouldn't make cloud-init setup /etc/hosts though [11:14] "they" are right here so someone will be able to answer that definatively... [11:14] ;-) [11:16] haha yea, unfortunately the timezones make it so that my work day is almost over when they wake up :) [11:16] atleast the americans === urulama|afk is now known as urulama [11:34] Is the MAAS 2.0 support still wip? [11:35] Just tried a new xenial MAAS setup and it gives me a runtime panic when trying to bootstrap [11:36] Xenial repository seems to use Beta4 [11:42] jamespage: is it possible to run the hbase charm in hbase standalone mode? === babbageclunk is now known as babbageclunk|run [13:06] Bug #1571687 opened: Azure-arm leaves machine-0 from the admin model behind [13:28] dimitern, voidspace, babbageclunk|run, dooferlad: going dark for a bit. need to get back to a working graphical login. my dist-upgrade didn't go so well. [13:28] frobware: ok, best of luck then :) [13:30] I can't get my monitor out of 640x480... :( [13:33] Garyx: latest master bootstrap should work, but containers aren't yet supported [13:33] Garyx: so yes, WIP and you need to set the MAAS2 feature flag [13:33] Garyx: it shouldn't panic though - although older versions did [13:34] Garyx: so it's probably an older version you have (I hope) === babbageclunk|run is now known as babbageclunk [13:52] jamespage: We have https://jujucharms.com/u/bigdata-dev/apache-hbase/ which is a bit newer... [13:52] But I don't think it's really been tested much... [13:53] HBase hasn't been a priority for us... [13:53] cory_fu, probably more than my 4 year old bash version.... [13:53] py-juju tastic... [13:53] :) [13:53] jamespage: I actually got your hbase bash charm working :D [13:54] simonklb, wow === cmars` is now known as cmars [13:54] simonklb, I struggled to remember I actually wrote it until I dropped into the code... [13:55] must remember to leave more bug comments as mental notes for +4 years time... [13:55] 1804 [13:55] golly [13:55] oh no 2004 [13:55] apparenlty I can't add up either... [13:55] haha, I had to modify it a bit to get hbase to work in standalone mode, but its running at least! [13:56] for some reason I have an issue pinging the machine using it's domain name, pinging other machines by hostname works, but not the one running hbase [13:56] the only difference is that the hbase machine is running precise but the other are running trusty [13:56] is this a known problem? [14:02] voidspace: happened on beta5 and beta4 for me :/ [14:02] voidspace: I set the featur flag so that it would try to bootstrap. [14:31] ok, this is getting ridiculous - I'm going to have to spend some time working out why my computer keeps freezing. [14:33] katco: are we having our retrospective or just a normal standup today? [14:33] ericsnow: standup i think... no need for a retro yet. although we should schedule one for resources before too long [14:34] ericsnow: sorry, forgot to take it off the calendar [14:34] katco: np :) [14:45] I checked /var/lib/misc/dnsmasq.lxdbr0.leases and saw that the hostnames are not registered properly [14:45] it's not depending on the series though, scratch that, same problem with machines running trusty [14:46] one machine registered ubuntu * and another just [14:46] * * [14:47] the ones that I'm able to ping obviously registered the hostname correctly, i.e. something like "juju-01f074e8-8788-44d6-87a3-a1861bd1e906-machine-0 *" [14:47] any dnsmasq gurus here? :) [14:51] looks like the machines register themselves with a different hostname first and then try to register again with the real hostname [14:51] is this some kind of race? [14:53] can we not bootstrap remote lxd servers? [14:54] saw this came up years ago as well https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1043121 [14:54] Bug #1043121: deployed node cannot be looked up with dnsmasq on MAAS [14:54] but for MAAS [14:54] I'm hitting this with local LXD [14:59] marcoceppi: we don't support remote LXD currently [15:01] ericsnow: standup time [15:09] Bug #1573659 opened: Panic in when bootstrapping MAAS 2.0 [15:12] frobware, voidspace, dooferlad, babbageclunk: guys, I'd appreciate a review on this: http://reviews.vapour.ws/r/4685/ [15:12] voidspace, dooferlad, dimitern - I think we had this discussion last week, but no Juju-spaces sync meeting anymore? I should delete the appointment. [15:13] babbageclunk: ooh.. I forgot, but yeah I guess no call today as well [15:14] dimitern: oh, but should I keep the appointment in my calendar? [15:14] babbageclunk: delete it, we will likely reschedule anyway once it starts regularly again [15:14] ok [15:17] dimitern: wow, that's a lot of scrolling [15:18] babbageclunk: hopefully not too hard to follow - tried to mostly remove stuff and resist the occasional urge to refactor :) [15:20] dimitern: yeah, it looks like just deletia. (And comment rewrapping.) [15:24] babbageclunk: thanks! === Makyo_ is now known as Makyo [15:27] Bug #1573665 opened: Drop special-casing of precise once we no longer support it. [15:27] Bug #1573668 opened: bootstrap should really be add-controller [15:28] voidspace, dooferlad, frobware: ping [15:30] dimitern: pong [15:30] dooferlad: here it is http://reviews.vapour.ws/r/4685/ :) [15:31] dimitern: will take a look in a moment. [15:31] dooferlad: ta! [15:34] babbageclunk: btw that panic when bootstrapping maas2 seems to be when a machine has at least 1 nic with mode=auto and no subnet [15:37] dimitern: ok - can I reproduce that in vmaas? [15:40] babbageclunk: yeah, should be easy - just add a second nic to a node, recommission it, and try to bootstrap +maas2 ff on and --to my-node-hostname [15:42] babbageclunk: this might help: http://paste.ubuntu.com/15983759/ [15:42] dimitern: thanks - I was still trying to unpack it. +maas2? ff on? [15:42] :) sorry - too concise [15:42] babbageclunk: with the maas2 feature flag enabled [15:43] dimitern: Ha! should have known that. [15:43] fwereade, ping [15:43] dimitern: ok - I'll try to chase it down now. [15:46] babbageclunk: thanks! cherylj filed a bug 1573659 [15:46] Bug #1573659: Panic in when bootstrapping MAAS 2.0 [15:48] babbageclunk: some logs/context here as well - https://github.com/juju/juju/issues/5259#issuecomment-213466954 (telltale sign of a link without subnet - mode=auto, is this log message `interfaces.go:274 interface "eno4" has no address`, just before the panic) === urulama is now known as urulama|afk [16:04] dimitern: another monster review from dimitern [16:04] dimitern: grabbing coffee first [16:04] dimitern: hmm, I added another nic and recommissioned, but now it doesn't show any network for the node. Do I need to add both of them? [16:04] voidspace: it's mostly removals :) [16:05] babbageclunk: doesn't show *any* interfaces after commissioning? [16:05] dimitern: nope [16:06] babbageclunk: can you paste the output of 'maas .. interfaces read ' ? [16:07] anyone else experiencing tests not passing for xenial? [16:07] dimitern: hang on, I tried removing it and recommissioning to see what I saw then. [16:09] perrito666: you're on xenial? [16:10] perrito666: I managed to get them passing by moving /usr/bin/distro-info out of the way and replacing it with a bash script that simply outputs "trusty" [16:10] dimitern: that is..... no, I wont do that, tests need fixing [16:11] perrito666: yeah, I tried that for 2h yesterday and decided I have enough other stuff to do :) [16:11] dimitern: ok, that gives me an idea of the order of magnitude [16:11] but, this is also something that broke recently [16:13] dimitern: should I add the nic on a different network? [16:14] babbageclunk: just leave it unconfigured [16:14] fwereade, I am going to have cherylj hand off the quick fix for bug 1572237 [16:14] Bug #1572237: juju rc1 loses agents during a lxd deploy [16:15] unless you speak now [16:15] we will need to try and get something in today [16:15] dimitern: ah, ok - that's probably what I got wrong. [16:15] ericsnow, katco ping? [16:15] cherylj: hi [16:15] dimitern: (sorry to keep bugging you) [16:16] hey ericsnow, that bug alexisb just mentioned is super critical and we need someone to see if there's a quick fix we can do for it. [16:16] dimitern: how do I leave it unconfigured? [16:16] cherylj: I'll take a look [16:16] ericsnow: want to do a quick HO to see if you would be comfortable taking it? [16:16] babbageclunk: leave both dropdowns (subnet and address) Unconfigured? [16:16] dimitern: just leave out the bridge name? [16:17] babbageclunk: what bridge? [16:17] cherylj: only if you think it would help :) [16:17] dimitern: the dropdowns are network source and device model. [16:18] ericsnow: I looked through the bug again, and fwereade did put in his update about a possible solution, so just let me know if you have questions [16:18] dimitern: hang on - dropdowns in VMM or MAAS ui? I'm talking about the VMM ui [16:18] cherylj: k [16:18] I couldn't remember if he had updated the bug with that info or not [16:19] babbageclunk: ah, sorry [16:19] babbageclunk: in the virt-manager connect both NICs to the same bridge (maas-19-int in my case) [16:23] dimitern: Ok, now I've got two interfaces, one unconfigured. [16:24] dimitern: Does this look right? http://pastebin.ubuntu.com/15984913/ [16:24] cherylj: https://github.com/juju/juju/pull/5262 [16:25] babbageclunk: great, so bootstrapping with --upload-tools --to should (hopefully) reproduce the panic [16:25] as small as it looks, that fixes most of the remaining windows tests [16:25] babbageclunk: yeah - notice how the second (ens9) is mode=link_up only, no subnet [16:28] dimitern: ok, go it! [16:28] dimitern: duh, got [16:29] babbageclunk: nice! [16:29] dimitern: I mean, the panic at least.] [16:31] babbageclunk: passing also --config=logging-config='=TRACE' combined with some additional trace logging (if needed) around maas2Interfaces should show the cause [16:32] perrito666: did you live test on windows? [16:32] dimitern: ok, thanks - I can see where it is, although it's odd - there's a nil check immediately before it. [16:32] dimitern: ok, digging a bit more. [16:32] babbageclunk: thanks for looking into that [16:33] babbageclunk: nil checks on an interface value might be misleading btw [16:33] babbageclunk: the infamous double nil dereference [16:33] dimitern: Ok - that's almost certainly the problem. [16:33] (usually concerns errors only, but..) [16:33] dimitern: I've heard of that but hadn't ever seen it in the wild before! [16:34] cherylj: I did, I actually am fixing those on windows [16:35] perrito666: nice :) [16:36] cherylj: wow sorry i completely missed your ping... did you get what you needed? [16:36] dimitern: hmm. It sounds like the right fix for that is to make the subnet methods handle a nil receiver. [16:36] babbageclunk: here's some info on that if you're interested: http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/index.html#nil_in_nil_in_vals [16:36] katco: yes, thanks :) [16:36] cherylj: k, sorry about that [16:36] ericsnow: ta [16:36] katco: no worries [16:36] dimitern: given that I can't cast to the real underlying type. [16:36] dimitern: since it's private in another package. [16:37] dimitern: and reflection seems like the wrong thing to use here. [16:37] babbageclunk: well, if the gomaasapi.Subnet interface's implementation uses non-pointer receivers (as they just access the data already populated in the unexported fields) [16:37] cherylj: I need to suffer to fix those in order to feel the same that windows feels :p [16:37] haha [16:39] dimitern: no, no value receivers. === redir_eod is now known as redir [16:41] dimitern: that's a lot of code removed! [16:41] dimitern: still reading [16:46] voidspace: :) hopefully more to come soon [16:47] dimitern: were you halfway through a thought? [16:47] dimitern: heh [16:47] dimitern: I'm on page 3 [16:47] of 76 apparently... [16:47] possibly a slight exaggeration [16:47] voidspace: might be easier to look the diff on github instead [16:48] dimitern: Hmm - I could add an IsNil method to gomaasapi.Subnet. Is that idiomatic? [16:48] babbageclunk: I wanted to also remove a few other things, but that would have made it harder to follow [16:48] dimitern: appreciated [16:49] babbageclunk: nope, how about just changing gomaasapi.subnet's methods to use non-pointer receivers? [16:50] dimitern: oh, I see. Does that work? Trying now in the playground. If so I'll do that. [16:52] babbageclunk: for example: http://play.golang.org/p/pAHQEQEunJ [16:56] dimitern: How does that help? They both panic. [16:56] dimitern: oh, hang on - I think I'm misreading [16:57] babbageclunk: that might be a better example actually: http://paste.ubuntu.com/15985771/ [16:57] babbageclunk: it's not quite there yet, but it's a start [16:57] dimitern: not quite analogous - they they're both == nil. [17:00] dimitern: but the problem is that the subnet's nil - do you mean do the same thing to the links? [17:01] babbageclunk: yeah, that's one option [17:02] dimitern: why does that help? you've just changed the point at which the address gets taken - does that change how the interface gets constructed? [17:02] dimitern: sorry if I'm being dense. [17:02] babbageclunk: basically change the whole chain interface->link->subnet->vlan to ensure no dangling pointers [17:02] dimitern: ok, I think I see [17:03] babbageclunk: or, alternatively make sure any method that returns an interface does check the pointer field != nil before [17:04] dimitern: I think it has to be that, right? [17:04] babbageclunk: the crux of the problem is that getters-returning-interfaces should also return either an error or at least a "exists" bool flag [17:04] So interface.Subnet() shouldn't return Subnet(nil), it should return nil [17:05] babbageclunk: that' won't help though [17:05] Oh, but can it do that? It doesn't return a *Subnet. [17:05] babbageclunk: as the compiler will silently wrap the nil in a non-nil interface instance [17:06] dimitern: ok, that's what I thought. [17:06] babbageclunk: e.g. if link.Subnet() returned (Subnet, bool) instead of just Subnet, and use the bool to indicate whether l.subnet == nil.. [17:07] dimitern: Ok, so then I think you're right [17:07] perrito666: can we count on c: always being the root? [17:07] it will be a lot more natural to the caller to check firs the flag and only then try to use the subnet interface [17:07] cherylj: I was clear on "just do this for tests and fake paths" :) [17:07] cherylj: otherwise no, you cant [17:07] cherylj: there is no "root" on windows, or at least is not such a clear concept [17:08] dimitern: Or the other way would be to have IsNil methods on all of those interfaces. But I think you're right, the other way is probably more Go-y. [17:08] perrito666: okay, thanks. :) [17:08] cherylj: ask as much as you like I am really happy to share the windowsness [17:09] dimitern: that's kind of a nasty gotcha. [17:09] babbageclunk: you can check for if subnet != nil, assuming 'subnet' is an interface, coming from a func that returns either the implementation or a plain nil [17:10] babbageclunk: and because this happens a lot with errors, that's why we have jc.ErrorIsNil vs gc.IsNil [17:10] dimitern: LGTM [17:10] voidspace: \o/ tyvm [17:11] dimitern: nice work, thank you [17:11] dooferlad: I'll wait for your review as well - will check back in a hour or so [17:11] dimitern: but there's no way we can change our interface to do that, right? [17:12] voidspace: cheers [17:12] (well - it was a pleasure to see old mistakes go away) === mup_ is now known as mup [17:12] dimitern: If the implementation methods returned (eg) *vlan instead of VLAN would that help? [17:13] babbageclunk: yeah, but that trail has long left :) [17:13] dimitern: because the interfaces would still return VLAN [17:13] babbageclunk: another reason why you should take interface arguments but return concrete (pod) types [17:13] dimitern: *interface methods I mean [17:15] dimitern: hard to do testing with that, though. [17:16] babbageclunk: I need to leave now, but I'm sure you can figure it out [17:16] :) [17:16] dimitern: same! [17:16] dimitern: Thanks for all the help - have a lovely weekend! [17:16] * babbageclunk isn't as sure he can figure it out. [17:16] changing a few methods to return (interface-result, bool-flag) should be easy (and also to test) [17:17] babbageclunk: cheers! likewise ;) [17:17] yup yup [17:43] Bug #1573681 opened: conflict when managing LXD storage with Juju 2.0 [18:35] ericsnow: you wanted to review this WIP? [18:38] redir: sure [18:38] redir: it might be a little while as I'm working on a priority bug [18:38] ericsnow: http://reviews.vapour.ws/r/4689/ [18:38] np [18:39] I'll keep chugging on the other LTS things. [18:39] They need to land all at once. But incremental reviews would make it much easier. [18:39] ericsnow: ^ [18:39] redir: k [18:43] Bug #1573741 opened: 2.0-rc1 cannot deploy in azure [18:43] Bug #1573742 opened: Newly provisioned machines start off at the controller's version. === redir is now known as redir_lunch [20:45] does juju still use zookeeper? === redir_lunch is now known as redir [20:47] redir: it does not [20:48] katco: that was my understanding. Just see comments referencing making sure it is configured to start... [20:48] redir: where is that? [20:49] provider/ec2 tests [20:49] katco: ^ [20:49] redir: if you're nearby, create a small patch to remove those comments [20:50] katco: I am working on that test so I'll do it in the drive by [20:50] redir: nice, good find :) [20:50] redir: and ta [20:50] katco: I think I'll have a qq here in this test. i [20:51] katco: It is testing the cloud-init stuff which will be significantly different in xenial due to the change to systemd [20:51] katco: wondering if we need seperate tests for xenial and pre-xenial [20:53] redir: i didn't want to get into it this morning, but the fact that our tests don't work on different releases is a huge smell to me [20:53] redir: i.e. unit tests really shouldn't be affected by what release you're on [21:03] katco: agreed. [22:56] ericsnow: resubmitted a PR that has all passing tests rebased on master. RB: http://reviews.vapour.ws/r/4691/ [22:56] redir: k [22:59] or if there's anyone else that wants to review that ^^ feel free [22:59] ericsnow is busy [22:59] saving the world [23:01] alexisb: yeah, that's why I said or anyone else. ericsnow has a full plate [23:02] and it is late on friday, so the reviewer pool is shallow [23:03] redir, I would do it for you but I am not an official reviewer so you would need another +1 besides me [23:03] alexisb: understood:) [23:04] * redir goes to look at the board [23:09] ha! [23:09] redir: (looking, btw) [23:10] one of the ec2 local server suite tests actually had 'zookeeper' in a commen [23:10] so not only was it ported verbatim from pyjuju and not corrected, no one looked at it since [23:11] heh [23:14] mgz: tx [23:15] not wild about the way these bundle tests are written, but I guess it's 2 years before we have to edit all these strings again [23:15] the alternative is I guess faking out the series selection stuff at the suite level, [23:16] mgz: you are not alone [23:16] 2.1! [23:16] :) [23:24] redir: and the ec2 bootstrap test is just a fork of the existing one in two, so I won't nitpick it [23:26] mgz yeah that could have been smarter [23:27] redir: review'd [23:29] mgz, thank you especially given it is nearly your saturday [23:29] alexisb: it is totally saturday :) [23:30] mgz, are you UTC or UTC+1 [23:30] In summer time so... +1 atm? [23:30] :) well in that case, dude! go enjoy your weekend [23:32] hey, I've got 9 hours till saturday morning squash [23:33] mgz: here we call this friday night, and spend it drinking [23:36] perrito666: what's the bootstrap wait loop change about in your windows tests pr? [23:36] it looks reasonable, just not sure how it's connected [23:37] a race condition [23:38] perrito666: review'd [23:38] mgz: in go 1.6, in windows, it will sometimes end withouth returning lastErr because of the select having hc.closed firing first [23:38] mgz: why this happens only in windows, beats me [23:39] it should be happening in linux too [23:39] perrito666: some socket implementation detail? I'd expect that to be the case on all platforms. [23:39] mgz: could be [23:39] in any case, the logic was begging for that race to happen [23:40] I wish it was easier to track though :p [23:41] mgz: commented on your comment. [23:43] redir: don't see it? hit publish mabe? [23:43] mmm yup I was muted on RB [23:44] mgz: the tests fail if they don't match up. [23:44] redir: right, I expect that to be the case [23:44] so they can't be unique [23:45] the question is do we care to fix them so the tests actually end up with exactly one image [23:45] or they are unique in export_test [23:45] which they know what it is [23:45] they do end up with one of the images in export_test [23:45] but, if it makese sense in the context of the test, feel free to drip the issue [23:45] depending on what constraints are applied [23:45] OK [23:45] dropping [23:45] or dripping [23:45] as it were [23:45] tx [23:46] perrito666: you win funny find/replace error of the day [23:46] mgz: lol, tx [23:48] perrito666: `git diff 5d2acdb0^..5d2acdb0 -- environs/config/config.go` - spot the funny mistake [23:48] mgz: could you pastebin? I am in an odd repo status [23:48] perrito666: I'll fix and make you review [23:50] aghh logger [23:50] perrito666: :P [23:50] (I had a seccond repo) [23:50] I suck [23:51] oh, are we on next again? [23:51] or is master just closed for a while [23:51] we're not on next [23:52] well yeah we prolly don't want to land that thing you just reviewed [23:53] alexisb: are we keeping master blocked just for eric's fix? [23:53] are the test slaves setup to have distro-info --lts return trusty? [23:53] mgz, it is blocked for the azure bug [23:53] but yeah no other commits atm please [23:54] redir: yeah, we moved our setup in time [23:54] so, we have another month of trusty as the default [23:54] mgz OK because that PR you reviewed is to fix it to work when --lts returns xenial. [23:55] mgz: which means it will prolly break on your time shifted slaves [23:55] redir: we can coordinate that monday [23:55] * redir is unclear on the transition process [23:56] redir: probably just want me or curtis to revert the hack as your branch lands [23:56] hopefully it still merges cleanly and passes then:o [23:56] OK. I'll follow up with whomever is around then. [23:57] Good luck at squash in 8 hours [23:57] I played quite well on two hours sleep last week, though... not generally a good idea [23:58] indeed