=== lifeless_ is now known as lifeless [01:03] mwhudson: now would be a good time to chat... [01:38] bigjools: hey [01:39] bigjools: still good? HO? [01:39] mwhudson: yes - give me a couple of mins [01:39] bigjools: i need to caffeinate so np [01:39] understandable [01:47] bigjools: let me know when you're ready [01:47] mwhudson: ready! [01:47] ok [01:47] call meh [01:47] bigjools: can you drive g+ reliably? [01:47] yeah... [01:47] * mwhudson clicks some things [01:48] "Julian isn't on Hangouts right now. He'll see your messages later [01:48] " [01:48] hahahaha [01:48] calling you [01:48] ah [01:48] i think i'm calling you [01:48] and failed [01:49] first time I had this with anyone [01:55] could be hangouts vs chat :) [01:55] cause youknow, standards, meh. [02:13] the online presence detection seems a little flaky [02:14] * bigjools lunches [15:05] rvba: around? [15:09] jtv: aound? [15:09] Hi roaksoax === racedo` is now known as racedo [15:11] jtv: howdy! So I'm wondering something quick. If I add a template snippet for commissioning user data, I should do this right? http://paste.ubuntu.com/5739010/ [15:12] jtv: in other words, if I add a snippet, i need to do this in the template: {{maas_ipmi_autodetect_py}} [15:14] roaksoax: it's been a while, to be honest — best thing for this one is to cargo-cult it from how the other snippets work. [15:14] jtv: ack! thanks [15:15] If you're moving monolithic code into snippets, that's good news — means we can test them etc. [15:15] jtv: yeah.. though I don't see tests for maas_signal for example [15:15] Be careful of dependencies between snippets, and on snippets etc. though. [15:15] I think maas_signal was somewhat out of our control. [15:16] yeah well I guess the same applies for maas-ipmi-autodetect [15:16] jtv: ok so now I need to inject the same file into the enlistment preseed [15:17] jtv: I'm guessing {{maas_ipmi_autodetect_py}} is not being made available elsewhere? [15:17] Right — the snippets aren't available except as part of the commissioning preseeds. [15:18] jtv: ok, so since enlistment "is" commissioning, I think I could easily make it available. Will give it a try, thanks! [15:18] What do you mean by "is"? [15:18] (I sound like Bill Clinton, don't I?) [15:19] jtv: heh, so enlistment is basically the same as commissioning, the only basic difference is that it uses a different preseed file [15:20] From which perspective exactly? There are different ways of looking at it. For the MAAS code, the two are separate *but* there doesn't have to be a human interaction between them. [15:21] jtv: from the maas point of view, IIRC, they both have the same 'purpose' [15:21] But as for the preseeds, maybe if you can colocate, you can reuse the snippets. I just hope the two won't "contaminate" each other! [15:21] Ah, the boot-image purpose! Yes they're both using the same one there. [15:23] yep [15:51] jtv: where is all thede code in charge of rendering the commissioning userdata? [15:52] roaksoax: the lowest-level code is in src/provisioningserver/commissioning/snippets.py IIRC [15:52] Ahem. src/metadataserver/commissioning, that is. [15:52] cool thanks :) [15:53] And the user_data.py module works at the level just above that. [15:55] jtv: ok so what I want to do is to make the snippets available for the enlistment [15:55] processes [15:56] how do you best suggest to do that? [15:56] Yeah, that's going to take a bit of design. [15:56] should I simply do something similar to what generate_user_data does? [15:56] jewell yeah, I already can list the snippets, so importing that won't be that hard, the only thing is to made them available to the enlistment context [15:57] It may be a matter of parameterizing that code, so that you can apply it using different snippets directories. [15:57] jtv: right, but i want the same snippets [15:57] to not have the same code in two different places [15:57] so consuming what it's there makes more sense [15:58] I don't remember if the main template needs to include those snippets explicitly or not... If it does then yes, you could just combine them into a single directory, like a kind of standard library. [16:00] jtv: http://paste.ubuntu.com/5739174/ -> this is what I waas thinking [16:00] My machine is becoming unusable... will reboot soon [16:02] roaksoax: is generate_user_data too different from what you need? [16:03] jtv: doesn't seem to be other than the location of files are different [16:04] If all it takes is some different templates (and the same snippets directory), I'd approach it like this: [16:05] 1. Split out an implementation function that basically does all the work, except for locating those templates at the top. [16:05] 2. See if the call sites can be conveniently changed to look up the templates themselves, and just call that new function instead (so that the remaining version of generate_user_data can just go away). [16:06] 3. Have the enlistment version call the same function, but with different templates. [16:06] 4. See if the code needs moving. [16:06] Mind the "If" at the beginning though. :) [16:06] jtv: ok cool [16:06] i'll look into that [16:07] Great. I'm off now, to be back Tuesday. [16:07] So feel free to ask the others. :) [16:07] alright have a good long weekend [16:07] Thanks! [17:08] hey, has anyone seen issues where the TFTP server stops responding on MAAS 1.4.5? I understand this is now a twisted based python server rather than a standalone. it worked before to get all my nodes PXE booted and enlisted but not it's stopped working and I am at a loss as to why [17:12] roaksoax, ^ [17:13] Campbell, haven't seen it before.. is there anything in /var/log/maas/pserv.log [17:16] Lots of healthy logs from yesterday when I brought the servers in but today very little since I've been trying to bootstrap juju http://pastebin.com/vtFRbneU [17:19] Is there a specific process I should be looking for to see if it's alive? [17:20] netstat shows that nothing is listening on port 69 [17:23] Campbell: what happens when you try to PXE boot? it simply won't? [17:23] yeah, it sits there trying to connect to the TFTP server and cant [17:24] Campbell: is your maas server using DHCP? [17:25] No, I have a separate DHCP server which is serving this network [17:25] it seems to be working fine, the machines are getting an IP address as teh PXE boot and we've got the ip helper enabled to forward UDP traffic [17:31] I am unable to telnet onto port 69 on the MAAS server locally either. Looks like TFTP is dead. [17:54] Campbell, the maas pserv instance [17:54] is the tftp server [17:55] Campbell, sudo service maas-pserv status [17:58] maas-pserv start/running, process 1420 [17:58] Looks like it's there [18:00] actually its not when I do ps -d [18:01] Campbell: sudo service maas-pserv restart [18:01] and see what happens [18:02] pserv.log should give an idea of what's happening [18:04] nothing from what I pasted earlier [18:04] I'll try and force a restart on pserv and see what that does [18:05] Just get this in the log 2013-06-06 11:04:40-0700 [-] Received SIGTERM, shutting down. [18:08] Campbell: can you do this in the maas server?: [18:08] ubuntu@cluster1:~$ tftp localhost [18:08] tftp> get pxelinux.0 [18:08] Received 27154 bytes in 0.0 seconds [18:08] permmission denied [18:10] ahnot I got it [18:10] so its probably network related [18:10] I was running the get from a directory I didn't have write permissions in [18:12] Campbell: yeah, so to me, given that you have a external DHCP< it is either giving a wrong ip to the MAAS server (different from next-server) [18:12] that's the most likely cause of the issue [18:13] OK. I'll do some more investigation. Thanks for the pointers :) [18:38] I've got the PXE boot happening again. I think recycling the maas-pserv did the trick. That's the only thing I've done that I think might have been material.