[01:59] <bigjools> bjf: yeah it's a packaging bug, is filed somewhere
[03:02] <bjf> bigjools, cool, just wanted to let you know in case you wanted me to file a bug for it
[03:50] <smoser> roaksoax, tomorrow. sorry.
[04:26] <bigjools> hi :)
[04:26] <Lord_Set> Hello
[04:26] <Lord_Set> Getting some awesome pxe errors
[04:26] <Lord_Set> 2014-02-11 20:01:17-0800 [HTTPPageGetter,client] Logged OOPS id OOPS-9168ac1b2e875425f6b7ee91899da19a: No exception type: No exception value
[04:26] <Lord_Set> 2014-02-11 20:01:17-0800 [HTTPPageGetter,client] Logged OOPS id OOPS-e3d0e778908b133237b872870492049b: ParserError: while parsing a block mapping
[04:26] <Lord_Set>           in "/etc/maas/pserv.yaml", line 60, column 5
[04:26] <Lord_Set>         expected <block end>, but found '<block mapping start>'
[04:26] <Lord_Set>           in "/etc/maas/pserv.yaml", line 68, column 6
[04:27] <bigjools> did you modify pserv.yaml?
[04:27] <Lord_Set> I uncommented the lines that shouldn't have been commented out like the tftp server lines
[04:27] <Lord_Set> Didn't touch anything else
[04:28] <bigjools> it uses defaults, you don;t need to touch them
[04:28] <bigjools> can you paste me your config?
[04:28] <Lord_Set> Sure
[04:28] <bigjools> or better, revert and try again and see if it workd
[04:28] <bigjools> works
[04:34] <bigjools> Lord_Set: can you re-comment those lines
[04:35] <bigjools> they don;t line up with the block so it's confusing the yaml parser
[04:36] <Lord_Set> Sure
[04:38] <Lord_Set> That worked! thanks
[04:38] <bigjools> cool
[04:38] <Lord_Set> Not sure why it had those uncommented
[04:38] <bigjools> me neither
[04:44] <Lord_Set> Doing a big test deploying on a full rack for Openstack deployment
[04:44] <Lord_Set> err deployment
[04:45] <bigjools> nice
[04:45] <Lord_Set> The rack is at SwitchNAP in Vegas :)
[06:54] <bigjools> roaksoax: I took the liberty of implementing the packaging change for the tool renaming: https://code.launchpad.net/~julian-edwards/maas/packaging/+merge/205901
[06:54] <bigjools> waiting for your review
[07:55] <rvba> bigjools: I'm using the package from the daily PPA and a node enlistment just failed with: http://paste.ubuntu.com/6918675/.  I'm guessing maas-enlist  needs updating… ?
[09:09] <Lord_Set> Quick question for you guys... What do you reccomend for remote power management and provisioning of MAAS nodes? WoL? IMPI? ILO 4?
[09:10] <Lord_Set> We are running most HP 5th and 6th generation servers I believe with ILO 2 natively built in.
[09:11] <Lord_Set> Also outside of that any suggestions or recommended paths for openstack, hadoop, and savannah deployment once the NAAS nodes are deployed?
[09:12] <Lord_Set> Our original test platform was with Mirantis but decided to move away from it due to its inability to provision across geographical locations easily.
[09:21] <jtv> Lord_Set: generally IPMI.  Don't know about HP specifically — no experience with the ILO driver, but it's supposed to have some peculiarities.
[09:57] <bigjools> Lord_Set: ipmi2 will work OOTB
[09:57] <bigjools> on HP
[10:16] <rvba> jtv: well, I guess what we've done must be standard for packaged Django applications.  But if you think we can do better, it's worth talking to Andres about it.
[10:17] <jtv> Well seeing now that we didn't use peer auth, I would guess that something in the infrastructure doesn't support it.  In fact it rings a vague bell.
[11:39] <rvba> jtv: just filed https://bugs.launchpad.net/maas/+bug/1279304
[11:52] <rvba> jtv: btw, did you resolve your uvtools issues?
[11:56] <jtv> Yes!
[11:56] <jtv> It's a libvirt problem — you now need to ensure that the "default" network is started.
[11:57] <rvba> Is this something that will be done by uvtool or does this mean we need to update maas-test?
[13:59] <rvba> jtv: testing a Saucy MAAS server now…
[14:01] <jtv> rvba: keep an eye on the console.
[14:02] <jtv> The traceback happens before the JSON data dump.
[14:02] <rvba> jtv: I don't have a monitor hooked up to the node.
[14:02] <rvba> jtv: but the test should fail correct?
[14:03] <jtv> I don't know.
[14:03] <jtv> I had test failures, but those might be for different reasons.
[14:03] <jtv> It's quite possible that the error gets ignored and things work more-or-less-OK.
[14:04] <rvba> That would explain the success testing stuff in the lab.
[14:04] <jtv> Don't we have any validation of Node.system_id anywhere?  I'm not seeing it in the model or the form.
[14:04] <jtv> Sometimes I guess having really really slow hardware has its advantages.
[14:05] <rvba> Don't know if we validate system ids anywhere.
[14:05] <jtv> Anyway, I fixed the bug (probably mostly on intuition) for trunk in Burlingame, because the python 3 stuff looked more urgent then.
[14:41] <jtv> rvba: here's a stab at the form approach to the API call → https://code.launchpad.net/~jtv/maas/validate-network-nodes-filter/+merge/205972
[14:44] <rvba> jtv: cool, I'll have a look in a moment.
[14:44] <jtv> Thanks.
[16:13] <tomixxx4> hi, does anyone have a download link to a boot images which can be used from the nodes?
[16:14] <tomixxx4> or can i simply install "ubuntu server" on the nodes too?
[16:16] <jtv> tomixxx4: the cluster controller imports those by itself.
[16:16] <jtv> There's a button in the UI.
[16:16] <tomixxx4> jtv: ok but assume the network interface is "unamanged", how can the nodes get the images then?
[16:17] <jtv> The DHCP server has to be told to make the nodes netboot from the cluster controller.
[16:17] <jtv> That's the custom DHCP server configuration I mentioned in the past.
[16:17] <tomixxx4> jtv: maas-dhcp-server does not work in my case
[16:17] <jtv> What's the problem?
[16:18] <tomixxx4> jtv: when i boot the nodes, the nodes print out "TFTP prefix: unable to loacte configuraiton file"
[16:19] <tomixxx4> jtv: so, i want to boot from a usb-stick. the question is, if i can simply install the same ubuntu server image than used for the maas-server
[16:19]  * jtv greps source
[16:20] <jtv> Got me there.  I don't know!
[16:20] <jtv> But netbooting is pretty central.
[16:20] <tomixxx4> jtv: ok, the dashboard mention sth about "avahi boot"
[16:21] <jtv> I never looked into that... maybe rvba would know.
[16:21] <tomixxx4> jtv: i have tried many things to get this dhcp - functionality to run, but i have still made no real progress. i have re-installed maas a few minutes ago ;)
[16:22] <tomixxx4> my last hope is to ignore dhcp-server-funktionality, connect the nodes directly to the external-network (so that they have i-net-access) and voila. but first i need a boot image
[16:23] <jtv> No chance of running the built-in DHCP server?
[16:24] <tomixxx4> no, it seems not. :( i never got thhis error before (TFTP prefix...) but since i tried to NAT in order to connect the nodes to the i-net, it does not work anymore.
[16:25] <tomixxx4> even if i clear NAT-tables now, i get this error message
[16:25] <tomixxx4> I have also tried to reboot ubuntu server and so one.
[16:26] <tomixxx4> iptables after reboot was empty but the nodes were not able to download the pxe images...
[16:27] <tomixxx4> jtv: the original problem was: if the nodes have no access to internet, juju does not work
[16:28] <jtv> The error does seem to mean that the node is trying to download its boot image over TFTP, which is good.
[16:28] <tomixxx4> jtv: juju does not work, because i have to deploy multiple lxc containers on a single node and the lxc-container creation failed because of no internet
[16:28] <jtv> Argh.
[16:28] <tomixxx4> yeah...
[16:28] <jtv> No way of giving the nodes access to the internet?
[16:29] <jtv> The TFTP connection should be straight to the cluster controller, so within the network you control — that part shouldn't require internet access, as long as the cluster has imported the images.
[16:29] <tomixxx4> the idea was maas-dhcp-server + NAT, as the dhcp-server has two interfaces, one connected to the outside-internetworking-network
[16:29] <jtv> (By the way, if you want to look at the images, they're on the cluster controller under /var/lib/maas)
[16:29] <tomixxx4> jtv: yeah, the images are there
[16:30] <tomixxx4> resp. the were there
[16:30] <jtv> You should be OK running the DHCP server on the gateway — just a matter of making sure you configure the right interface.
[16:31] <jtv> If the interface is already configured when you set up MAAS, MAAS will pick it up automatically with its details, and you can just set up DHCP in the MAAS UI.
[16:31] <tomixxx4> jtv: i got an bash script from gmb for the NAT thing so this should not be the problem.
[16:35] <tomixxx4> jtv: interface-configuration looks as follow: http://pastebin.ubuntu.com/6920783 and bash script for NAT: http://pastebin.ubuntu.com/6920787
[16:36] <tomixxx4> whereas eth0 connects the server to the nodes and eht1 connects the server to the i-net
[16:36] <jtv> Right.
[16:37] <jtv> That part looks good.
[16:37] <jtv> A bit too tired now to understand the shell script...
[16:37] <jtv> (Timezones)
[16:37] <tomixxx4> jtv: i have already attache dns-nameserver to the eth0, because otherwise there is a lookup problem later on in juju
[16:39] <tomixxx4> jtv: 11:37 p.m. ? ^^
[16:39] <jtv> Just about!
[16:39] <jtv> So... it sounds as if you're successfully doing NAT and DNS?
[16:40] <tomixxx4> dont know, maybe this tftp-exception is caused by misconfiguration
[16:41] <tomixxx4> jtv: at least, dhcp seems to work because the nodes get their ips and so one
[16:41] <tomixxx4> jtv: but they cannot downlaod the boot images...
[16:42] <jtv> Where exactly was that TFTP error message, by the way?  On the node's console?
[16:42] <tomixxx4> yep, on the nodes console
[16:43] <jtv> Then something you might try is force the tftp server to log to a file.  It produces lots and lots of debug output, really horrible, but I find it can help debug these problems.
[16:44] <jtv> Unfortunately I'm about to fall asleep and don't recall where that can be done.
[16:44] <jtv> We direct the output to /dev/null because there's just too much.
[16:44] <jtv> But if nothing else, it would tell you whether the TFTP server got the node's request at all.
[16:45] <tomixxx4> kk, i will try this but first i will try to do sth witouth dhcp
[16:46] <jtv> I think it'll be harder!
[16:47] <tomixxx4> what is the option "use the fast installer" ?
[16:47] <tomixxx4> in the node menu
[16:47] <jtv> All MAAS can really tell the node is: "next time you wake up, netboot.  Now, reboot."
[16:47] <jtv> The fast installer has some kind of ready-made image.
[16:47] <jtv> Doesn't always apply, but when it does, it installs the nodes faster.
[16:47] <tomixxx4> jtv: and i do not need dhcp for this?
[16:48] <jtv> You probably still do, because DHCP is part of the netbooting process.
[16:48] <jtv> (DHCP is really an extended version of BOOTP as I understand it)
[16:55] <tomixxx4> how does the maas-server know, when the node is "ready" ?
[17:04] <tomixxx4> j4i: installing "ubuntu server 12.04.03" as node boot image does not work
[17:16] <jtv> tomixxx4: a node becomes Ready when it completes the commissioning phase.  It reports that to the region controller through a web API.
[17:16] <tomixxx4> k
[17:16] <jtv> At that point, it is available for users to allocate.
[17:16] <jtv> When a user has the node allocated, it will be in Allocated state.
[17:18] <tomixxx4> i know, i had already nodes allocated :D
[17:18] <tomixxx4> i was so far
[17:19] <tomixxx4> question just arrised because i have tried to install boot image from usb-stick but nodes did not become "ready" after installation
[17:21] <tomixxx4> DOES maas dashbourd confuse ethernet-names?
[17:23] <jtv> I don't understand that last question...
[17:23] <jtv> You can't just boot from a USB stick completely; MAAS boots the node several times, with different images and options.
[17:24] <tomixxx4> kk
[17:24] <jtv> The images are (1) an ephemeral ("commissioning") image for enlistment & commissioning; and (2) an actual installer for deployment once you allocate.
[17:24] <tomixxx4> how many times boot maas, because i always have to manually POWER ON my nodes
[17:24] <jtv> Oops, there's my message to stop working and come home.  :)
[17:24] <jtv> Once for enlistment, once for commissioning, and once for deployment.
[17:25] <tomixxx4> kk
[17:25] <jtv> Once it's allocated to you, it's yours to reboot as often as you like.  :)
[17:25] <jtv> nn!
[17:27] <tomixxx4> gn8