=== mwenning is now known as mwenning-wfh [14:30] Turns out enabling the openstack kilo ubuntu repository on my maas controller was a mistake, upgrades twisted and hits https://bugs.launchpad.net/maas/+bug/1431741 [14:50] lathiat, 1.7 right? [14:50] yeah [14:50] rvba, why is that only fix committed? did it not go into 1.7? [14:51] lathiat, can you apply that patch live and does it fix the issue? [14:56] kiko: it doesn't seem that fix is in 1.7. But AFAIUI MAAS 1.7 doesn't target platforms with Django 1.7. [15:03] Bug #1464701 opened: Deselected filter left with stray underline [15:55] kiko: well, no, 1.5 from the 14.04 repos. [15:55] probably not the end of the world since i dont actaully need that repo on th emachine [15:55] i did it trying to find cloud-archive:tools for 14.04 which it turns out doesn't exist [16:06] lathiat, yeah -- could you move to 1.7? [16:06] kiko: is there a ppa for it? [16:06] i looked but coldn't find mention in the docs [16:07] lathiat, yes, I think it's mentioned in the topic [16:08] ahh https://launchpad.net/~maas-maintainers/+archive/ubuntu/stable [16:08] yep [16:08] are docs bugs file dinto launchpad? [16:08] the current docs say to use ubuntu-cloud:archive, saying it has the latest lts release support [16:08] yep! [16:08] btu that archive only supports 12.04 [16:08] bugs.launchpad.net/maas [16:08] so that could be updated [16:09] i will try that repo out thanks [16:09] Bug #1464720 opened: commit_within_atomic_block is depreacted [18:06] Bug #1464741 opened: 1.8.0 unable to rename machine [18:09] Bug #1464741 changed: 1.8.0 unable to rename machine [18:21] Bug #1464741 opened: 1.8.0 unable to rename machine === ming is now known as Guest91806 === jfarschman is now known as MilesDenver [21:48] kiko, responded to https://bugs.launchpad.net/maas/+bug/1460151 [21:49] kiko, when I want to remove maas-proxy, everything gets removed (maas, maas-dns, maas-region-controller) [21:50] kiko, btw, re: btrfs - I was using it only for lxc provisioning - got an separate ssd just for lxc, and it was workingok. Then I got another SSD, and did mkfs.btrfs -d raid0 over both of them. Then I started to experience slowdowns after a week or two of usage (btrfs-transactio process was hammering the drives in the background). [21:51] The other day I got another 2 SSDs (so I can have 4 of them in raid0-like config) and that killed btrfs performance completely. The slowdowns were frequent - for instance deploying mongodb charm in lxc took over 20 minutes (mongodb creates large oplog files, and I guess those don't play well with COW filesystem) [21:52] Also, qcow2 images on btrfs is also no-no. raw images work a tad better, but also very very slow. I now reverted to lvm on mdraid0 over those 4 ssds (I actually didn't need mdraid0 as lvm can do that by itself), and the performance is superb. [21:53] fio test gives me over 40MB/sec in troughput in 16job random readwrite test over 8GB file. (On btrfs I had cca 900k/sec) [21:53] kiko, that's all on trusty kernel (3.13)