[01:09] <mscheel> Hi, I'm following http://maas.ubuntu.com/docs/install.html#pkg-install to get the 1.7 maas
[01:09] <mscheel> I have already installed maas 1.5 (the server is Ubuntu 14.04), I'd like to upgrade
[01:10] <mscheel> I do the add-apt-repository cloud-archive:tools but I get:
[01:10] <mscheel> cloud-archive only supported on precise
[01:10] <mscheel> (so for fun I installed a server on precise, but then it only gets maas 1.2)
[01:11] <mscheel> Is there a way to get the 1.6 or 1.7 maas via packages?
[01:12] <mscheel> (thanks in advance)
[03:57] <mwhudson> mscheel: there must be a ppa somewhere
[03:57] <mwhudson> although, is 1.7 out yet?
[03:57] <jtv> Not as such.
[03:58] <mwhudson> mscheel: https://launchpad.net/~maas-maintainers/+archive/ubuntu/dailybuilds ?
[03:58] <jtv> Yeah, that should give you pre-release packages.
[04:29] <rick_h_> mwhudson: I had to get the experimental to get 1.7
[04:30] <rick_h_> vs dailybuilds, but then again I guess 1.7.0 is listed there
[04:30] <rick_h_> https://launchpad.net/~maas-maintainers/+archive/ubuntu/experimental is a few revs ahead it looks like
=== CyberJacob|Away is now known as CyberJacob
=== CyberJacob is now known as CyberJacob|Away
[08:07] <mscheel> mwhudson: thanks!
[08:08] <mscheel> I didn't realize 1.7 wasn't out
[08:09] <mscheel> I need the static IP support, which doesn't appear to be present in the 1.5 UI at least
[08:10] <jtv> Yeah that's 1.7.
[08:10] <jtv> If you upgrade, you'll also want to edit your cluster interface to have separate static & dynamic IP address ranges.
[08:12] <mscheel> yeah we followed http://maas.ubuntu.com/docs/cluster-configuration.html
[08:13] <mscheel> didn't realize that 1.5 was different
[08:13] <mscheel> I don't think we can use daily/experimental/beta maas for the project I'm working on, unfortunately
[08:17] <mscheel> btw, one of the things that tripped me up early in my experiments, was when I configured the cluster controller, I used 127.0.0.1 as the region controller address (or at least that's what I thought I was doing :)  - then when my first node started to come up, it just sits there, on a ci-info screen, never times out or prints that it is failing because it is trying to connect to 127.0.0.1
[08:18] <mscheel> eventually I managed to get a screen shot of the boot process that showed that IP address as the controller it was connecting to, and just had to dpkg-reconfigure the cluster controller
[08:22] <jtv> mscheel: thanks — I'll file a bug on the package, to make the question clearer.
[08:22] <mscheel> thanks - I wasn't really sure where the "bug" was because the error was mine :)
[08:22] <mscheel> I assume there's some reason the client node just sits waiting for a response
[08:23] <jtv> Well if it can't reach the server, there isn't all that much we can make it do.
[08:24] <mscheel> yeah not really
[08:24] <mscheel> an error message would have been helpful, or a statement of what step it was on, maybe
[08:25] <mscheel> "registering with maas cluster controller @ <ip: x.y.z.a>"
[08:25]  * mscheel shrugs
[08:25] <mscheel> if I'm the only one it happened to, not a big deal :)
[08:27] <jtv> Then again, there could be any number of people running into it and not getting back to us.
[08:27] <jtv> I see a small change that could be made: it's not just how the cluster controller reaches the API, it's also the basis for how the nodes reach the API.
[08:28] <mscheel> ah, yeah, that makes sense
[10:11] <jtv> allenap: if you look at lp:~jtv/maas/use-compose-curtin-network-preseed now and run src/maasserver/tests/test_preseed.py, you'll see that RPC failure I mentioned.
[10:11]  * allenap looks
[10:21] <jtv> allenap: found it!  The fake handler for that RPC method was hidden away in a mix-in.
[10:21] <mgz> allenap: where are you?
[10:25] <allenap> jtv: http://paste.ubuntu.com/8478304/ is how I’d start.
[10:25] <allenap> mgz: Gah. I’m at home.
[10:25] <jtv> allenap: thanks — I think I need this to pass by default though, because it affects semi-unrelated tests.
[10:26] <mgz> allenap: :D
[10:26] <allenap> mgz: I’m not going to make it :-(
[10:27] <mgz> allenap: ;_;
[10:28] <mgz> you brussels though?
[10:28] <allenap> mgz: Nope, last minute reprieve. Austin, yes.
[12:01] <jtv> rvba: can you think of an easy way to add the region controller to the DNS mappings?
[12:02] <jtv> So that I can test with a DNS server that resolves a hostname for the region controller in both IPv4 and IPv6?
[12:03] <rvba> jtv: let me have a look at the code…
[12:03] <jtv> Thanks.
[12:07] <rvba> jtv: I don't really see a way other than pass the region ip → hostname info to DNSForwardZoneConfig in src/maasserver/dns/zonegenerator.py, the same way we pass dns_ip.
[12:09] <jtv> rvba: that's probably not so bad, actually.  Thanks!
[12:09] <rvba> np
[12:09] <jtv> (In fact I've been wondering if the region shouldn't just provide a fixed hostname for itself in its own DNS...)
[13:00] <rvba> blake_r: Hi Blake.  It seems src/maasserver/models/tests/test_bootsource.py:TestBootSource.test_calls_cache_boot_sources_on_create is flaky… any idea why (see http://paste.ubuntu.com/8479003/)?
[13:02] <blake_r> rvba: no I will have to look into it
=== jfarschman is now known as MilesDenver
=== roadmr is now known as roadmr_afk
=== jfarschman is now known as MilesDenver
=== roadmr_afk is now known as roadmr
=== slobo_ is now known as slobo
=== CyberJacob|Away is now known as CyberJacob
=== jfarschman is now known as MilesDenver
=== CyberJacob is now known as CyberJacob|Away