[07:31] Hey is there anyone that could help me with setting up MAAS on virtual box im having a major issue [07:32] I can't think why it would suddenly stop working - can you paste a screen shot of the failure? [07:34] what path is it using to TFTP the boot image? [07:35] bigjools, is that directed at me? [07:35] m4fiya: ^ [07:35] oh okay, i didn't think i had to setup the path specfically, shouldn't it do this automatically? [07:36] it does, but if it can't find an image then either the image is missing or the TFTP path went wrong [07:36] I've not encountered either of these types of failure before [07:36] are you using the 12.04 package? [07:36] yes I am [07:37] usually when booting the console will say what path it's using to try and download a boot image [07:37] see if you can find that under /var/lib/tftpboot [07:37] hmm, I'm guessing thats not something Virtual Box does [07:37] damn [07:38] would VMware do this? [07:38] no idea, sorry. [07:38] I've mostly been testing with real hardware lately [07:38] We can't all be that lucky ;) [07:38] heh [07:38] I do want to make sure the VM stuff works though [07:39] it's definitely trying to PXE boot? [07:39] I have turned every other type of boot off but the hard disk [07:39] that's your problem then [07:40] boot order should always be PXE [07:40] I mean other then Hard disk and PXE [07:40] PXE first - in fact that's all you need [07:40] since the server uses chain.c32 to make it local boot when necessary [07:41] Also is there specific DHCP setting I need to make on my router? [07:41] it should be fine if you already enlisted a node [07:41] the "next-server" setting tells clients where to TFTP images from [07:42] im going to try and use VMware and see if it works [07:43] I have tried on multiple machines, one running Ubuntu as the Host and one running Windows as the Host [07:43] Now it seems like DHCP is failing [07:44] that won't help [07:44] can you delete the node and re-enlist it? [07:44] to see if anything changed in your environment [07:45] Well i just tried to install a new node, and it seems like the DHCP service is failing, does the MAAS management server need to be the DHCP? [07:46] no, it can be remote [07:46] does this need to be specified, or does it auto DHCP [07:46] but as I said the next-server needs to be configured, or nothing will be able to PXE boot [07:46] what is the next-server? [07:46] it tells the client where to TFTP a boot image [07:46] it is the MAAS server [07:47] oh okay, well i have the MAAS server up and running [07:47] does your DHCP server have this setting? [07:47] if it's in your router it might be called something else [07:48] it doesn't seem like it does have a setting like that [07:49] by default does the MAAS server try to act as the DHCP? [07:50] it can do if you want [07:50] I can't remember if that's default or not [07:52] if you look in /etc/cobbler/settings there's a manage_dhcp setting [07:53] I have to run out for 30 minutes, will help later if you're stiull stuck [09:37] allenap: here's a first attempt to “make run” and then ctrl-C. It didn't get very far (looks like rabbit doesn't run by default on my system, for whatever reason) but the problem occurs. This is on a freshly booted system: http://paste.ubuntu.com/1160493/ [09:37] The first ctrl-C gave me “--> Stop `celeryd`” [09:38] And then a second one got me back to the command prompt. [09:38] If I don't do that, things seem to hang indefinitely. [09:38] I'll reboot now to clean up, and try to give you a less noisy run with rabbit started. [09:44] allenap: “make distclean” also hangs while killing celery. [09:46] allenap: better log here, after starting rabbit manually — http://paste.ubuntu.com/1160508/ [09:52] * allenap is looking now [10:00] allenap: killing the “supervise” process for celery gets the shutdown going again, but doesn't remove those /run/lock/maas.dev.* files. [10:01] Hmm... nor does it kill all celery processes. [10:01] jtv: I'm looking at signal handling in celery at the moment, to see if it responds to the correct signals. [10:01] Thanks. [10:08] jtv: Signal handling is fine, it's attempting a "warm" shutdown, but it's stuck on accept(...) from /tmp/pymp-m1mA71/listener-_H1dxR (on my machine). The "pymp" bit there suggests it's a multiprocessing socket. All the child processes are defunct, so it hasn't collected them yet. Something's funky. [10:09] It should come out of the accept() with EINTR, no? [10:11] jtv: I guess so, but perhaps it's doing something "clever". [10:12] Yeah. Might even be the sort of thing that newer interpreter versions helpfully hide. [10:14] allenap: interesting news on my front is that the bulk of datagram-received messages comes from bootstrap.py. Almost as if some work is being done over and over again that should be delegated just once. [10:19] jtv: Yes, there is some element of that iirc. [10:23] Getting the feeling that the “session” was supposed to take over after bootstrapping, but instead, the bootstrapping packet-handling code remained in front of the session's for convenience. [10:25] Maybe because the concrete bootstrapping class keeps checking if this packet is the initial one. If that could be moved into the base class, maybe the division of labour could be more effective. [10:41] Erm, python-celery appears to still be in universe. [10:43] allenap: that sounds a bit like a complication [10:48] Indeed, a fairly big one :) [11:14] smoser: when you get in, I need ephemeral images published for armhf+highbank. What's involved for this? [11:15] Gah, now the webapp won't stop... because it's hanging on an accept(). [11:15] Yeah I got that [11:15] Again, related to multiprocessing. [11:16] Standard process seems to be to pkill -9 celeryd, find the webapp and kill that, then rm /run/lock/maas* [11:16] python is very bad at doing the right thing by default with signals when its using threads [11:18] http://paste.ubuntu.com/1160627/ fixes the webapp problem (though it also stops the cache from working). [11:22] http://paste.ubuntu.com/1160632/ fixes the celeryd shutdown problem. [11:22] jtv: ^ [11:23] allenap: where “the” cache is which? [11:23] Ahhh, it's the Manager that's holding things up then? [11:24] Damn. I liked the shared-memory solution — not sure why we ended up with the Manager in the first place. [11:24] jtv: Only in the webapp, where it's not needed. That change didn't help getting celeryd to stop. [11:25] Maybe it should have been a property, so that at least it doesn't get created until used. [11:25] Right, lunch time here. [11:25] Yeah. [11:26] Thanks for figuring this out. I'll see if that change happens to be low-hanging fruit. [11:29] Oh bugger no it isn't. [11:57] howdy [11:57] allenap: http://paste.ubuntu.com/1160673/ --> so that's maas-provision [11:57] allenap: where from will it export the MAAS_PROVISION_SETTINGS [12:13] if I put a 'in-target wget http/.../' inside my preseed file, the node can't get my file. what should I do to make my files avaible to nodes? [12:14] roaksoax: I have to go out now. I'll be back in ~4h, and I'll try to sort out the MAAS_PROVISIONING_SETTINGS problem then. Would you be able to document how we can build the packaging recipe locally, ourselves? [12:14] allenap: bzr bd ? [12:14] :) [12:14] allenap: it failed to build because I forgot to commit a patch [12:15] roaksoax: Is that it? I know almost nothing about packaging, so baby steps please :) [12:15] * allenap goes. [15:31] allenap: let me know when you are around again [16:12] roaksoax: I'm back. [16:13] allenap: https://code.launchpad.net/~andreserl/maas/maas_lp1040047/+merge/120769 [16:13] please :) [16:13] roaksoax: On it :) [16:30] allenap: thanks! :) [16:36] roaksoax: Btw, I realised earlier that python-celery is in universe. MAAS depends on it now. Do we have any plans around that? [16:36] allenap: python-celery is in main afaik [16:37] allenap: apt-cache show python-celery | grep main [16:37] Filename: pool/main/c/celery/python-celery_2.5.3-1ubuntu1_all.deb [16:38] roaksoax: I wonder why I'm not seeing that. I've got 2.4.6-1 in universe here. Are you looking at Precise? [16:38] allenap: in precise is in universe [16:39] Ah. [16:39] allenap: and since we are not SRU'ing maas, there's no need to deal with it now :) [16:39] allenap: in quantal is in main [16:39] roaksoax: I thought we *were* SRU'ing it. [16:39] That's what we've been pushing towards this week. [16:40] allenap: not for 12.04.1 [16:41] roaksoax: No, we've missed that :-/ But can we get python-celery into main now? [16:42] allenap: well that's a whooooooooole different problem [16:42] allenap: technically we can't [16:42] but its been done before afail [16:42] afaik [16:42] allenap: that's something Daviey or smoser will have to take care of though [16:47] I shall await comment from them :) [16:50] allenap: btw.. as soon as the patch above lands ai can rol packages [16:50] i'm off to lunch now though [17:00] roaksoax: Cool. I'll be having dinner soon, but I'll be back once the kids are in bed. [17:07] allrnpa the fix above we discussed the same with rvba and smoser [17:08] cant recall but i think wr agreed not to do tjat [17:15] clearly bigjools missed the "not going to SRU" memo. [17:16] i dont know if daviey agreed to that or not, and i definitely understand pressure to get new maas into 12.04. [17:16] however, it clearly does not follow the "stable release update" path. [17:18] smoser: I think we all - Red and flacoste - missed that memo :) [17:18] * allenap will be back in ~2h [17:20] well, we clearly missed 12.04.1 [17:20] and it clearly does not really fit SRU https://wiki.ubuntu.com/StableReleaseUpdates [17:21] personally, i feel the best way to service 12.04.1 maas with current maas trunk is via ppa. [17:21] but i suspect that is not popular. [17:21] /me is eating mexican food for smosers amusement [17:21] and i'm sure that rules could be bent to accomodate the main dependency. i just dont know about the value of bending the rules. [17:54] if I put a 'in-target wget http/.../' inside my preseed file, the node can't get my file. what should I do to make my files avaible to nodes? [17:55] guimaluf, what is wrong with the wget? is dns failiing? you can try wget outside and then copy in [17:56] smoser, proxy issue [17:56] it cant hit the file [17:57] Aug 20 17:28:42 node-782bcb77e1d4 in-target: --2012-08-20 14:28:42-- http://150.164.3.236/cblr/aux/postscript.sh [17:57] Aug 20 17:28:42 node-782bcb77e1d4 in-target: Connecting to 150.164.3.236:8000... [17:57] Aug 20 17:28:42 node-782bcb77e1d4 in-target: connected. [17:57] Aug 20 17:28:42 node-782bcb77e1d4 in-target: Proxy request sent, awaiting response... [17:57] Aug 20 17:28:42 node-782bcb77e1d4 in-target: 403 Forbidden [17:57] Aug 20 17:28:42 node-782bcb77e1d4 in-target: 2012-08-20 14:28:42 ERROR 403: Forbidden. [18:07] allenap: so I just saw your diff and seems reasonable. However, will that add /usr/sbin to the path to everything else that is run, or just for that command in particular? [18:07] guimaluf, is it just that url? [18:08] smoser, yep [18:09] smoser, anyway my maas server can't deploy the ssh-pubkey and I cant download files in that manner [18:13] guimaluf, is your system clock on the target reasonably set? [18:13] yes [18:13] the clock was my first big issue setting up maas. [18:14] I fixed in many ways. the ephemeral disk.img has the pre-start ntpdate script. [18:14] but maybe isnt enough [19:04] roaksoax: Just for that command. [19:09] roaksoax: Btw, we often +1 merge proposals with comments that need to be acted on. If we were being strict we'd mark them as Needs Fixing, but we approve them so that we don't block each other as the world turns. [19:15] allenap: ok, since you alread proposed an alternate fix, could you propose a branch? [20:25] roaksoax: Okay, I'll do that. Can you email the list instructions on how to build the package? [20:25] locally. [20:29] allenap: will do by EOD [20:29] roaksoax: Thanks. [20:30] allenap: btw.. are you committing the env change today? [20:31] roaksoax: I can, if you need it? [20:31] allenap:no not really [20:31] allenap: i do need you to approve something before yo leave [20:31] allenap: https://code.launchpad.net/~andreserl/maas/packaging_bzr911/+merge/120865 [20:32] * allenap looks [20:36] roaksoax: Approved. If someone isn't around I'd say it's safe to self-approve those and keep moving. [20:36] allenap: thanks [20:36] allenap: i thought self approving didn't work :) [20:36] roaksoax: I do it from time to time. [20:37] allenap: good to know. cause i thought the lander didn't process those self approved MP's [20:43] roaksoax: Could you look at https://code.launchpad.net/~allenap/maas/alt-fix-for-maas_lp1040047/+merge/120866? I am doing it after all, before I forget. [20:44] allenap: looks good to me, has it been tested? === dpb_ is now known as Guest92976 [20:51] roaksoax: Yes. [20:51] roaksoax: Ah, you mean, is there a test for it. No, not specifically. [20:52] The code is exercised, but that specific behaviour is not checked. [20:55] roaksoax: I'm signing off now. Have a good evening! [21:04] allenap: you do aswell