[03:44] <bigjools> jtv: which package were you installing?
[03:44] <jtv> maas-dns
[03:45] <jtv> Actually I was installing lots of packages, but that's where the error happened.
[03:45] <bigjools> jtv: let me re-phrase then.  What package did you ask apt-get to install?
[03:46] <jtv> Pretty much everything that maas-region-controller depends on, but not maas-region-controller itself.
[03:46] <bigjools> jtv: you mean you were manually installing all the dependencies?  What was your exact command line
[03:46] <jtv> And not postgres, which was the original point of what I was doing.
[03:46] <jtv> Yes, I was manually installing all the dependencies.
[03:47] <bigjools> why?
[03:47] <jtv> Because I was reproducing the postgres installation problem, and wanted to minimise noise.
[03:47] <bigjools> ok
[03:48] <bigjools> this is arising because maas-dns invokes some tasks, and in the tasks module it has stuff to talk to seamicro
[03:48] <bigjools> which is annoying
[03:50] <jtv> Make it a lazy import?
[03:50] <jtv> FWIW installing python-seamicro silenced the error, although of course by that time loads of other dependencies had already been installed — they may have similar problems otherwise.
[03:51] <jtv> If it's just seamicro, I say cut the import chain somewhere and do it in a heavily commented function.
[03:51] <bigjools> jtv: move the import inline, perhaps
[03:52] <bigjools> yeah here we go, postinst calls "maas-region-admin set_up_dns"
[07:50] <rvba> jtv: looks like some validation that happens *after* you set self.broadcast_ip expects that address to be a string indeed…
[07:52] <jtv> OK I can do that now
[07:53] <bigjools> getting a lot of errors in celery log
[07:54] <bigjools> [2014-03-31 17:53:03,074: ERROR/MainProcess] consumer: Cannot connect to amqp://maas_workers@10.0.0.9:5672//maas_workers: [Errno 104] Connection reset by peer.
[07:54] <bigjools> restarted celery and boom, a ton of queued jobs went through
[08:02] <bigjools> rvba, jtv, gmb: off to eat.  Call in 28m, and I have some fun news.
[08:04] <jtv> OK
[08:21] <jtv> rvba: https://code.launchpad.net/~jtv/maas/fix-default-broadcast-clean/+merge/213414
[08:21] <rvba> jtv: on it
[08:22] <jtv> Thanks.
[08:22] <rvba> jtv: looks good
[08:25] <jtv> Thanks.
[08:28] <rvba> jtv: bigjools: running another test in the lab with manual fix for the bug jtv is fixing (see above)… so far so good: nodes enlisted okay… commissioning…
[08:28] <rvba> with *a* manual fix.
[08:28] <bigjools> :)
[08:29] <dimitern> perhaps a dumb question, but i'll ask anyway - what are the valid reasons to recommission a node after it becomes ready? hw changes?
[08:29] <bigjools> yes
[08:30] <dimitern> including changing nics ?
[08:30] <rvba> or if you add new commissioning scripts.
[08:30] <dimitern> ah, right
[08:30] <bigjools> changing nics is an interesting one
[08:30] <bigjools> gmb, jtv, rvba: I'm on talky
[08:31] <dimitern> thanks!
[08:31] <bigjools> let's chance our hand
[08:31] <gmb> Wasty.time.
[08:31] <jtv> That's taking a while...
[08:33] <rvba> bigjools: jtv: deploying stuff with juju in the lab…
[08:51] <rvba> bigjools: jtv: test passed
[08:54] <jtv> \o/
[10:43] <Hermes42> hi all, got a question regarding maas node installation: it seems to get it's packages from us.archive.ubuntu.com , whatever I do. I would prefer to use a local apt-cacher. has anyone an idea how to configure that?
[10:57] <jtv> Hermes42: you can configure that on the Settings page.  By default it goes through a caching proxy on the region controller.
[10:57] <jtv> (This also means that you can install nodes without giving them direct internet access)
[10:58] <jtv> You can also select a different archive on that page.
[10:58] <jtv> Click the cogwheel in the upper right of the UI.
[11:09] <Hermes42> i  tried that. unfortunatly, the clients still want to install from external us.archive...
[11:09] <Hermes42> additionally, the connection is direct and not over maas
[11:10] <Hermes42> jtv: i think you talk about <ip>/MAAS/settings ; Ubuntu section
[11:11] <Hermes42> there i have configured http://192.168.100.84:3142/ftp.halifax.rwth-aachen.de/ubuntu/ as the ubuntu archive, still installing from us.archive.ubuntu.com
[11:11] <Hermes42> ...84:3142 is my apt-cacher proxy on the maas server
[11:12] <Hermes42> maybe i have to regenerate some images?
[11:12] <Hermes42> maas-import-ephemerals doesn't seem to do anything anymore...
[11:12] <jtv> We don't generate images, so that's not it...
[11:12] <jtv> No, that script is obsolete.
[11:12] <Hermes42> ok
[11:12] <jtv> The latest package versions don't even have it.
[11:13] <jtv> I wouldn't configure the proxy as the Ubuntu archive, to be honest; I'd just configure a proxy.
[11:13] <jtv> There's a separate "proxy" field on the settings page.
[11:13] <Hermes42> jtv: my maas-server is build on 14.04 with maas 1.5
[11:14] <Hermes42> also tried that, additional to the archive
[11:14] <Hermes42> the traffic still seems to go direct
[11:14] <jtv> That is strange.
[11:14] <Hermes42> rechecking
[11:14] <jtv> If you do nothing at all from a clean install, the nodes should get all their packages from the squid-deb proxy on the region controller.
[11:15] <Hermes42> testing.
[11:15] <Hermes42> changing ubuntu source to http://192.168.100.84:3142
[11:15] <Hermes42> oops
[11:15] <Hermes42> the other half ;)
[11:16] <Hermes42> ftp.halifax.rwth-aachen.de/ubuntu/
[11:16] <jtv> It's supposed to be a full URL.
[11:17] <jtv> As is the proxy, by the way.
[11:17] <Hermes42> http://ftp.halifax....
[11:17] <jtv> OK
[11:17] <Hermes42> proxy is http://192.168.100.84:8000/
[11:17] <jtv> That all looks sensible...
[11:17] <Hermes42> which should be the squid on maas server
[11:18] <Hermes42> i had problems with the apt-cacher before, the clients wouldnt connect to 3142
[11:18] <jtv> This is not apt-cacher though.  It's squid-deb-proxy.
[11:18] <jtv> And if you want to use the built-in proxy, just leave the proxy field blank.
[11:18] <Hermes42> had to change /etc/maas/preseeds/generic
[11:19] <Hermes42> all mirror strings to choose-mirror
[11:19] <jtv> Sounds like it would make a useful bug report.
[11:21] <Hermes42> yep.
[11:22] <Hermes42> the freshly installed client still has /etc/apt/sources.list with us.archive....
[11:23] <Hermes42> i'll restart the maas and reinstall the client node.... brb
[11:31] <Hermes42> strange... now it seems to connect to the squid while commisioning, not us.archive, at least that what the download speeds say
[11:41] <Hermes42> when starting the node it still connects directly  to us.archive...
[11:42] <Hermes42> jtv: where can i configure the mirror for the starting node? I see no traffic on MAAS-Server during client downloading packages (e.g. linux-kernel)
[11:42] <Hermes42> ok can s.o. tell me a working os / maas / juju combination? I currently try trusty beta
[11:43] <Hermes42> with the default packages there /maas 1.5
[11:46] <jtv> Hermes42: from MAAS's point of view there is no difference between your first node and any other ones.
[11:46] <jtv> The kernel is not downloaded as a package; it comes straight from the cluster controller.
[11:47] <jtv> And, if you're getting a fast-path install, the whole boot image comes from there.
[11:52]  * jtv must be off now.  Good night!
[14:21] <perrito666> hello, could someone take a look to https://codereview.appspot.com/82670043/ ?
[14:21] <perrito666> It adds basic support for networks listing to testserver
[15:18] <rvba> dimitern: Hi, I'm having a look at bug 1299114.  Do you recall the parameters you were using when defining the network?
[15:21] <dimitern> rvba, I tried different combos, all failed; in the web ui i could see required fields which were left blank to turn red and report validation errors (ip address and netmask I think)
[15:22] <rvba> dimitern: I'm trying to figure out what caused the error… but having the exact data that you submitted would help me.
[15:23] <rvba> dimitern: so far, I'm unable to reproduce the problem :/
[15:24] <dimitern> rvba, once the upload completes, i'll paste a link in the bug to the disk image + xml file for the machine, perhaps that'll help
[15:27] <rbasak> roaksoax: python-seamicroclient MIR accepted. What will pull it into main? The next maas upload? Bug 1298130.
[15:29] <rvba> dimitern: you got the failure when using the CLI right?  Don't you have the invocation line somewhere in your history?
[15:29] <dimitern> rvba, both cli and api; let me check
[15:29] <roaksoax> rbasak: hey! thanks for taking care of it. And yes, it will be pilled by maas upload
[15:30] <dimitern> rvba, example: maas maas-root networks create name=main ip=192.168.50.0 netmask=255.255.255.0 description="Main MAAS network"
[15:32] <rvba> dimitern: works for me in a dev env. http://paste.ubuntu.com/7185307/.  I'll try with a package.
[15:34] <dimitern> rvba, if you still can't repro it, try upgrading from the daily-ok
[15:35] <dimitern> rvba, (i suspect my upgrade might be incomplete or something)
[15:35] <rvba> dimitern: you're getting this with the package from daily-ok?
[15:36] <dimitern> rvba, no, that's from the daily-builds r2188, but i originally installed the daily-ok one and upgraded later
[15:36] <rvba> okay
[16:05] <tych0> hi allenap (or anyone), maas nodes when a network is bridged are supposed to talk to the world through a squid proxy, right?
[16:06] <allenap> tych0: Is that the cluster’s network, or the region?
[16:07] <tych0> i don't understand the question :-(
[16:07] <tych0> the cluster and the region are on the same box
[16:07] <tych0> it is the slave nodes that aren't running through a squid
[16:07] <allenap> There’s nothing in MAAS that says a node *must* talk to the world through squid. It is there as a service, and we set the proxy for apt (iirc) to point to it, but MAAS doesn’t enforce anything beyond that.
[16:08] <tych0> ok
[16:08] <tych0> so my nodes aren't talking through the apt proxy either
[16:08] <tych0> should i file a bug?
[16:09] <allenap> tych0: Yeah, that sounds like a bug.
[16:09] <tych0> ok