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