| mwhudson | menn0: do we have any friends at mongodb inc or who really know mongo details inside out? | 00:04 |
|---|---|---|
| menn0 | mwhudson: I think niemeyer might know some people there, not sure otherwise | 00:05 |
| mwhudson | menn0: ok | 00:06 |
| 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:11 |
| 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:12 |
| menn0 | mwhudson: start with niemeyer I guess | 00:14 |
| mwhudson | niemeyer: hello hello | 00:14 |
| mwhudson | huh i wonder about using https://docs.mongodb.org/manual/core/inmemory/ for tests one day | 00:15 |
| mwhudson | oh, enterprise only | 00:15 |
| * mwhudson is now reading spinlock code in wiredtiger... | 00:31 | |
| redir | until tomorrow juju-dev | 00:38 |
| === redir is now known as redir_eod | ||
| 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:47 |
| niemeyer | mwhudson: heya | 00:56 |
| niemeyer | I'm on my phone so apologies in advance if the communication breaks up | 00:57 |
| mwhudson | niemeyer: ok, just wondering if you know a good person to poke at mongo inc | 01:09 |
| mwhudson | niemeyer: we have an issue where index creation with wiredtiger takes ~100ms vs ~1ms with mmapv1, makes some tests veeeerrrry slow | 01:10 |
| 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:12 |
| niemeyer | mwhudson: Let me find a bug #.. Just a sec | 01:16 |
| niemeyer | mwhudson: https://jira.mongodb.org/browse/SERVER-21198 | 01:18 |
| niemeyer | mwhudson: Very unfortunate indeed, and I could not find much support to actually fix the underlying problem | 01:19 |
| niemeyer | mwhudson: I haven't yet finished testing with libeatmydata | 01:20 |
| 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:21 |
| niemeyer | (mgo does as it needs to ensure replicas work well too) | 01:22 |
| mwhudson | hm seems to help | 01:22 |
| mwhudson | of course i have so much debugging crud patched into my tree that its hard to tell | 01:23 |
| 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:25 |
| mwhudson | niemeyer: will do | 01:26 |
| mwhudson | i should actually read the whole ticket too... | 01:26 |
| axw_ | thumper: why should a non-controller-administrator model owner not be allowed to grant access to their model to someone else? | 01:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| thumper | np | 01:31 |
| mwhudson | niemeyer: blah, 3.2 is still a LOT slower even without --nojournal | 01:33 |
| mwhudson | but it certainly does help | 01:34 |
| mwhudson | 3.2/nojournal: 20s 3.2/no-nojournal: 6.5s 2.4/nojournal: 0.3s 2.4/no-nojournal: 0.8s | 01:35 |
| mwhudson | and 3.2 with mmapv1 is ~the same as 2.4, this is mmapv1 vs WT, nothing else afaict | 01:40 |
| mwhudson | huh mongod doesn't start with eatmydata for some reason | 01:45 |
| 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:17 |
| 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 | 02:18 |
| 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:00 |
| 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:01 |
| menn0 | axw_: it's ok, it doesn't matter too much, more curious than anything | 03:02 |
| axw_ | okey dokey | 03:03 |
| 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:10 |
| mup | Bug #1573365 opened: Can't bootstrap --upload-tools on trusty <juju-core:New> <https://launchpad.net/bugs/1573365> | 03:19 |
| mup | Bug #1573365 changed: Can't bootstrap --upload-tools on trusty <juju-core:New> <https://launchpad.net/bugs/1573365> | 03:49 |
| === urulama|____ is now known as urulama | ||
| mup | Bug #1573382 opened: only one user can create local users <juju-core:In Progress by thumper> <https://launchpad.net/bugs/1573382> | 04:25 |
| * thumper goes for a wander | 04:57 | |
| * menn0 is done | 05:46 | |
| 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:01 |
| 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> | 06:52 |
| rogpeppe2 | perrito666: i do now :) | 07:31 |
| === rogpeppe2 is now known as rogpeppe | ||
| dimitern | I figured out how to trick the unit tests into thinking trusty is still the latest lts :) | 08:15 |
| dimitern | mv /usr/bin/distro-info /usr/bin/distro-info-org && ln -s /usr/bin/fake-distro-info /usr/bin/distro-info | 08:17 |
| dimitern | fake-distro-info is just `#!/bin/bash\necho trusty` | 08:18 |
| dimitern | and make check passed for the first time since yesterday, just like on a good ol' trusty machine \o/ | 08:23 |
| dimitern | babbageclunk: morning | 08:41 |
| dimitern | babbageclunk: any luck with the maas upgrade yesterday? | 08:41 |
| babbageclunk | dimitern: morning! | 08:44 |
| 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:45 |
| 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:46 |
| dimitern | babbageclunk: sudo apt dist-upgrade works for me btwq | 08:47 |
| dimitern | btw even | 08:47 |
| babbageclunk | dimitern: tsk, doesn't appear in the help or the man page! Presumably there for backwards-familiarity? | 08:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| babbageclunk | but now I think I do! | 08:52 |
| babbageclunk | ha, didn't realise maas was django | 08:52 |
| dimitern | heh I still don't get the difference between full- vs dist-upgrade | 08:53 |
| 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:55 |
| 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:56 |
| 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:57 |
| babbageclunk | dimitern: ooh, I wonder if that fixes the bug with the power settings getting cleared when the machine gets allocated via the API. | 08:58 |
| dimitern | babbageclunk: hopefully - they've made changes to the power handling, esp. around what's considered 'fatal error' (not to be retried) | 09:00 |
| === dooferlad_ is now known as dooferlad | ||
| 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:34 |
| 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:35 |
| voidspace | rogpeppe: LGTM | 09:36 |
| rogpeppe | voidspace: ta! | 09:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| === urulama is now known as urulama|school | ||
| === urulama|school is now known as urulama|afk | ||
| 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:41 |
| 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:42 |
| simonklb | would it be up to Juju to set this up correctly? | 09:43 |
| rogpeppe | jamespage: did that work OK for you? | 09:46 |
| voidspace | [] | 09:57 |
| voidspace | 10:01 | |
| 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:03 |
| 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:04 |
| simonklb | jamespage: do you know how cloud-init is configured? Is that something you can do with Juju? | 11:05 |
| jamespage | simonklb, juju manages all of that complexity | 11:06 |
| jamespage | simonklb, this charm? https://jujucharms.com/hbase/ | 11:06 |
| simonklb | jamespage: yes! | 11:07 |
| === rvba` is now known as rvba | ||
| 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:07 |
| 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:08 |
| 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:09 |
| jamespage | my fingers do it on auto | 11:10 |
| 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:11 |
| jamespage | there may be configuration knobs per provider that change cloud-init behaviour, but nothing that will allow you to touch it directly... | 11:12 |
| simonklb | jamespage: right, seems wierd that they wouldn't make cloud-init setup /etc/hosts though | 11:13 |
| jamespage | "they" are right here so someone will be able to answer that definatively... | 11:14 |
| jamespage | ;-) | 11:14 |
| 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:16 |
| === urulama|afk is now known as urulama | ||
| Garyx | Is the MAAS 2.0 support still wip? | 11:34 |
| Garyx | Just tried a new xenial MAAS setup and it gives me a runtime panic when trying to bootstrap | 11:35 |
| Garyx | Xenial repository seems to use Beta4 | 11:36 |
| simonklb | jamespage: is it possible to run the hbase charm in hbase standalone mode? | 11:42 |
| === babbageclunk is now known as babbageclunk|run | ||
| 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:06 |
| 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:28 |
| frobware | I can't get my monitor out of 640x480... :( | 13:30 |
| 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:33 |
| voidspace | Garyx: so it's probably an older version you have (I hope) | 13:34 |
| === babbageclunk|run is now known as babbageclunk | ||
| 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:52 |
| 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:53 |
| jamespage | simonklb, wow | 13:54 |
| === cmars` is now known as cmars | ||
| jamespage | simonklb, I struggled to remember I actually wrote it until I dropped into the code... | 13:54 |
| 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:55 |
| 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? | 13:56 |
| 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:02 |
| babbageclunk | ok, this is getting ridiculous - I'm going to have to spend some time working out why my computer keeps freezing. | 14:31 |
| 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:33 |
| katco | ericsnow: sorry, forgot to take it off the calendar | 14:34 |
| ericsnow | katco: np :) | 14:34 |
| 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:45 |
| simonklb | one machine registered ubuntu * and another just | 14:46 |
| simonklb | * * | 14:46 |
| 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:47 |
| 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:51 |
| marcoceppi | can we not bootstrap remote lxd servers? | 14:53 |
| 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:54 |
| natefinch | marcoceppi: we don't support remote LXD currently | 14:59 |
| katco | ericsnow: standup time | 15:01 |
| mup | Bug #1573659 opened: Panic in when bootstrapping MAAS 2.0 <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1573659> | 15:09 |
| 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:12 |
| dimitern | babbageclunk: ooh.. I forgot, but yeah I guess no call today as well | 15:13 |
| 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:14 |
| babbageclunk | dimitern: wow, that's a lot of scrolling | 15:17 |
| dimitern | babbageclunk: hopefully not too hard to follow - tried to mostly remove stuff and resist the occasional urge to refactor :) | 15:18 |
| babbageclunk | dimitern: yeah, it looks like just deletia. (And comment rewrapping.) | 15:20 |
| dimitern | babbageclunk: thanks! | 15:24 |
| === Makyo_ is now known as Makyo | ||
| 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:27 |
| dimitern | voidspace, dooferlad, frobware: ping | 15:28 |
| dooferlad | dimitern: pong | 15:30 |
| dimitern | dooferlad: here it is http://reviews.vapour.ws/r/4685/ :) | 15:30 |
| dooferlad | dimitern: will take a look in a moment. | 15:31 |
| dimitern | dooferlad: ta! | 15:31 |
| 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:34 |
| babbageclunk | dimitern: ok - can I reproduce that in vmaas? | 15:37 |
| 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:40 |
| 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:42 |
| 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:43 |
| 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:46 |
| 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) | 15:48 |
| === urulama is now known as urulama|afk | ||
| 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:04 |
| dimitern | babbageclunk: doesn't show *any* interfaces after commissioning? | 16:05 |
| babbageclunk | dimitern: nope | 16:05 |
| dimitern | babbageclunk: can you paste the output of 'maas .. interfaces read <node-id>' ? | 16:06 |
| 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:07 |
| dimitern | perrito666: you're on xenial? | 16:09 |
| 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:10 |
| 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:11 |
| babbageclunk | dimitern: should I add the nic on a different network? | 16:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| babbageclunk | dimitern: Ok, now I've got two interfaces, one unconfigured. | 16:23 |
| babbageclunk | dimitern: Does this look right? http://pastebin.ubuntu.com/15984913/ | 16:24 |
| perrito666 | cherylj: https://github.com/juju/juju/pull/5262 | 16:24 |
| 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:25 |
| babbageclunk | dimitern: ok, go it! | 16:28 |
| babbageclunk | dimitern: duh, got | 16:28 |
| dimitern | babbageclunk: nice! | 16:29 |
| babbageclunk | dimitern: I mean, the panic at least.] | 16:29 |
| dimitern | babbageclunk: passing also --config=logging-config='<root>=TRACE' combined with some additional trace logging (if needed) around maas2Interfaces should show the cause | 16:31 |
| 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:32 |
| 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:33 |
| perrito666 | cherylj: I did, I actually am fixing those on windows | 16:34 |
| cherylj | perrito666: nice :) | 16:35 |
| 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:36 |
| 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:37 |
| babbageclunk | dimitern: no, no value receivers. | 16:39 |
| === redir_eod is now known as redir | ||
| voidspace | dimitern: that's a lot of code removed! | 16:41 |
| voidspace | dimitern: still reading | 16:41 |
| dimitern | voidspace: :) hopefully more to come soon | 16:46 |
| 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:47 |
| 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:48 |
| dimitern | babbageclunk: nope, how about just changing gomaasapi.subnet's methods to use non-pointer receivers? | 16:49 |
| babbageclunk | dimitern: oh, I see. Does that work? Trying now in the playground. If so I'll do that. | 16:50 |
| dimitern | babbageclunk: for example: http://play.golang.org/p/pAHQEQEunJ | 16:52 |
| babbageclunk | dimitern: How does that help? They both panic. | 16:56 |
| babbageclunk | dimitern: oh, hang on - I think I'm misreading | 16:56 |
| 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. | 16:57 |
| babbageclunk | dimitern: but the problem is that the subnet's nil - do you mean do the same thing to the links? | 17:00 |
| dimitern | babbageclunk: yeah, that's one option | 17:01 |
| 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:02 |
| dimitern | babbageclunk: or, alternatively make sure any method that returns an interface does check the pointer field != nil before | 17:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| dimitern | voidspace: cheers | 17:12 |
| dimitern | (well - it was a pleasure to see old mistakes go away) | 17:12 |
| === mup_ is now known as mup | ||
| babbageclunk | dimitern: If the implementation methods returned (eg) *vlan instead of VLAN would that help? | 17:12 |
| 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:13 |
| babbageclunk | dimitern: hard to do testing with that, though. | 17:15 |
| 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:16 |
| dimitern | babbageclunk: cheers! likewise ;) | 17:17 |
| babbageclunk | yup yup | 17:17 |
| 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> | 17:43 |
| redir | ericsnow: you wanted to review this WIP? | 18:35 |
| 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:38 |
| 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:39 |
| 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> | 18:43 |
| === redir is now known as redir_lunch | ||
| redir_lunch | does juju still use zookeeper? | 20:45 |
| === redir_lunch is now known as redir | ||
| katco | redir: it does not | 20:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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 | 20:53 |
| redir | katco: agreed. | 21:03 |
| 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:56 |
| 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 | 22:59 |
| redir | alexisb: yeah, that's why I said or anyone else. ericsnow has a full plate | 23:01 |
| redir | and it is late on friday, so the reviewer pool is shallow | 23:02 |
| 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:03 |
| * redir goes to look at the board | 23:04 | |
| mgz | ha! | 23:09 |
| mgz | redir: (looking, btw) | 23:09 |
| 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:10 |
| alexisb | heh | 23:11 |
| redir | mgz: tx | 23:14 |
| 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:15 |
| redir | mgz: you are not alone | 23:16 |
| redir | 2.1! | 23:16 |
| redir | :) | 23:16 |
| mgz | redir: and the ec2 bootstrap test is just a fork of the existing one in two, so I won't nitpick it | 23:24 |
| redir | mgz yeah that could have been smarter | 23:26 |
| mgz | redir: review'd | 23:27 |
| alexisb | mgz, thank you especially given it is nearly your saturday | 23:29 |
| mgz | alexisb: it is totally saturday :) | 23:29 |
| 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:30 |
| mgz | hey, I've got 9 hours till saturday morning squash | 23:32 |
| perrito666 | mgz: here we call this friday night, and spend it drinking | 23:33 |
| 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:36 |
| perrito666 | a race condition | 23:37 |
| 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:38 |
| 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:39 |
| perrito666 | I wish it was easier to track though :p | 23:40 |
| redir | mgz: commented on your comment. | 23:41 |
| mgz | redir: don't see it? hit publish mabe? | 23:43 |
| redir | mmm yup I was muted on RB | 23:43 |
| 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:44 |
| 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:45 |
| mgz | perrito666: you win funny find/replace error of the day | 23:46 |
| perrito666 | mgz: lol, tx | 23:46 |
| 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:48 |
| perrito666 | aghh logger | 23:50 |
| mgz | perrito666: :P | 23:50 |
| perrito666 | (I had a seccond repo) | 23:50 |
| perrito666 | I suck | 23:50 |
| 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:51 |
| redir | well yeah we prolly don't want to land that thing you just reviewed | 23:52 |
| 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:53 |
| 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:54 |
| 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:55 | |
| 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:56 |
| 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:57 |
| redir | indeed | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!