[04:53] Ohhhh WHAT? Test failure while landing? I tested locally! [04:53] Rabbit. [04:54] maasserver.tests.test_rabbit.TestRabbitBase.test_base_channel_creates_exchange [04:54] Timeout. [04:54] bigjools: is that related to what you just debugged with Scott? [04:54] jtv: no [04:54] random [04:54] not seen that for a long time [04:55] {cannot_listen,{127,0,0,1},59471,eaddrinuse}}}, [04:55] That seems to be the nub of it. [04:55] yeah [04:55] nub [04:55] I guess it was just an unlucky choice of port... retrying. [04:58] Oh dear. And an error in simplestreams. === vladk|offline is now known as vladk [05:20] bigjools: should I backport my fix for the inscrutable-import-error bug to 1.5? Or is there no point now? [05:20] jtv: no point IMO [05:21] OK [05:21] downgrade the bug from panic status [05:23] Done. [05:50] That error in the simplestreams went away, but now I'm getting one about an unexpected sha256 checksum. [05:51] jtv: I expect the mirror might still be running [05:52] which prompts another question ... [06:12] Same exception again. That makes it hard to do full Q/A. [06:15] jtv: worked here [06:15] hmmm [06:15] if we have a label of "rc" is anything going to bork? [06:16] IOW did we rely on "release" anywhere? === vladk is now known as vladk|offline [06:29] bigjools: I think it will work just fine. [06:29] We were using 'daily' before. [06:29] * bigjools likes the optimism [06:31] bigjools: the node failed to boot in the lab. [06:31] :/ [06:31] shit [06:31] 'No such image' [06:31] * rvba investigates [06:31] … [06:31] rvba: is it hard-coded anywhere? [06:31] in the tests [06:32] bigjools: no, the test just want an image for Trusty. Again, it was working with the 'daily' images. [06:32] bigjools: no Trusty image was imported. [06:32] I just see the precise images. [06:32] rvba: are the tests using the default config? [06:32] * rvba checks [06:32] I imported trusty "rc" ok on a new install [06:34] yes (http://paste.ubuntu.com/7233732/ that's the config from the lab) [06:35] /var/lib/maas/boot-resources/ contains only the precise images. [06:37] bigjools: I don't see any reference to 'rc' images in http://maas.ubuntu.com/images/ephemeral-v2/releases/streams/v1/com.ubuntu.maas:v2:download.json [06:37] What am I missing? [06:37] WFM, so, WTH [06:38] * rvba tries on canonistack [06:38] could be a mirroring problem [06:38] I do see "rc" in the sjson. [06:39] Oh, that's in the regular json too. [06:39] jtv: I don't see it! [06:39] "updated": "Fri, 11 Apr 2014 00:45:23 +0000", [06:39] bigjools: arg, I was looking at a ached version of the json [06:39] Now I see it too [06:39] cached* [06:40] bigjools: maybe that's what happened in the lab too [06:40] Science: “I'll believe it when I see it.” Religion: “I'll see it when I believe it.” [06:40] Sounds as if maybe the caching headers on the index are set to cache too aggressively. [06:40] "updated": "Fri, 11 Apr 2014 00:45:23 +0000", [06:40] "products": { [06:40] "com.ubuntu.maas:v2:boot:14.04:armhf:generic-lpae": { [06:40] "label": "rc", [06:40] Maybe the http headers were designed for etags, then had the etags removed or not implemented? [06:40] oh see it now [06:41] rvba: the lab will work once it can import the right image then :) [06:41] bigjools: trying to clear the cache now… [06:41] The cached data in the proxy that is. === CyberJacob|Away is now known as CyberJacob [06:45] I got a checksum error, but disabling imports of the "rc" label seems to get me past it. [06:51] bigjools: my run on a canonistack machine imported the 'rc' images all right. (Same as what you saw.) [06:52] jtv, rvba: I suspect proxies are screwing things over [06:52] Yep [06:52] Investigating that now [06:55] Arg, I don't have permission to clear the cache on the proxy machine. [06:57] rvba: I do know that it worked in the Garage MAAS come to think of it [06:58] not this exact package but the rc data worked IIRC [06:58] Okay [06:58] Would be good to get an end-to-end test to pass though. [06:59] But I'm not too worried. [07:04] k [07:05] I would suspect the configuration or the original httpd more than the proxies. [07:06] For example, if the directory with the index is set up for aggressive caching because they look like they only have static files... [07:07] What's weird is that when I wget the index in the lab (using the same proxy the test script uses), I get the right index with the references to the 'rc' images. [07:11] Well, the headers from the httpd say what caching is _allowed_. After that, every proxy or client gets to decide to what extent it wants to use that. [07:11] * jtv hates the quagmire of over-aggressive proxies [07:11] There is no more objective reality in that situation. [07:16] Running the int. tests manually… [07:22] If maas-import-pxe-files was a bit more verbose, that would help… [07:44] bigjools: importing the images in the lab without going through the proxy. It's going to take time, but we will have our answer. [07:44] rvba: ok [07:45] rvba: need to get the proxy fixed then if it's aggressively caching like that [07:45] Yeah [07:45] I'll need Diogo to help me with that cause I don't have permissions to manipulate the proxy. === CyberJacob is now known as CyberJacob|Away === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [09:08] Import done. [09:08] 'rc' images are there. [09:09] Running the rest of the test now… [09:28] allenap: time for a tiny review? https://code.launchpad.net/~rvb/maas/show-version-doc/+merge/215377 [09:29] rvba, allenap: How can I find out why maas-dhcp-server won’t start for me? `sudo service maas-dhcp-server-start` just give me “maas-dhcp-server stop/waiting”. [09:29] gmb: upstart log/syslog [09:30] Gah! [09:30] rvba: Thanks. Forgot about upstart log. syslog is silent on the issue. [09:30] gmb: the question you just asked should go into the FAQ. [09:30] Hmm: “/var/lib/maas/dhcpd-interfaces does not exist. Aborting” [09:30] rvba: Agreed. [09:30] Will take care of it. [09:31] Great, thanks. [09:33] rvba: How about a bzipped normal review? Ha. Now I’m scraping the bottom of the barrel in a different way :) [09:41] allenap: thanks for the review === vladk is now known as vladk|lunch === vladk|lunch is now known as vladk [13:19] allenap: gmb: could one of you have a look at bug 1306303 please? I'm still trying to figure out this proxy problem. [13:19] bug 1306303 in MAAS "Enlistment fails with "400 BAD REQUEST" in logs" [Undecided,New] https://launchpad.net/bugs/1306303 [13:34] rvba: I might not be able to do it until much later, but sure. [14:58] allenap, ping [15:45] gmb: found another gaping hole in the documentation (since you seem to be in a writing frenzy): the commissioning phase doesn't seem to be described anywhere. Nothing tells you that you have access to the commissioning scripts' results for instance. [15:49] Hi MAAS people, I really like the idea of MAAS, but I already have chef instead of juju. what is the relative difficulty of using not juju to configure servers when deploying with MAAS? [15:50] d_`: juju is just a client of MAAS. MAAS is pretty agnostic in this regard. It just provisions servers and hands them over to clients. [15:51] d_`: in other words, you shouldn't have trouble using Chef with MAAS. [15:51] rvba: thanks for the quick reply, that's really encouraging. I think I'm going to set up a lab today [15:53] rvba: since you have a canonical masked host, do you know what's up with the 14.04 RC? why it's not out? [15:56] d_`: no idea, sorry. [15:57] d_`: you might want to ask around in #ubuntu-release. [15:58] rvba: haha, no problem. thanks for the quick answers === vladk is now known as vladk|offline === roadmr is now known as roadmr_afk === CyberJacob|Away is now known as CyberJacob === vladk|offline is now known as vladk === roadmr_afk is now known as roadmr === CyberJacob is now known as CyberJacob|Away === vladk is now known as vladk|offline