#maas 2013-04-02 <AskUbuntu_> relation error between nova-compute and nova cloud controller | http://askubuntu.com/q/277139 <roaksoax> rvba: howdy! <roaksoax> allenap: howdy! were you able to make a branch available with the changes needed for the cluster_url thing for the FPI? <roaksoax> rvba: were you able to take a look at https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579 ? <roaksoax> allenap: and does this make sense to you? http://paste.ubuntu.com/5670766/ <rvba> roaksoax: hi. Sorry, not yet; I know I'm a bit late with this I'll take a look tomorrow morning first thing. <roaksoax> rvba: awesome! thank you! <rvba> roaksoax: allenap is off today and tomorrow btw. <roaksoax> rvba: plop :) thanks!! <roaksoax> rvba: how was australia btw? lots of gofun? <rvba> roaksoax: it was great :). We got started on a library written in Go indeed. <roaksoax> rvba: awesome! <rvba> roaksoax: do you have a list of the things we need to do (for the FPI, etc) in MAAS? <rvba> There is https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579 <rvba> Then https://code.launchpad.net/~allenap/maas/preseed-cluster-host/+merge/149954 â¦ ? <rvba> And then there is bug #1148016. <ubot5> bug 1148016 in MAAS "Node always belongs to the same nodegroup/cluster" [Undecided,New] https://launchpad.net/bugs/1148016 <rvba> roaksoax: These are the 3 things I have on my TODO listâ¦ anything else? <roaksoax> rvba: allenap branch above as bigjools mentions it doesn';y fix the issue really, but it is an improvement to the code. I already made changes to that to support the cluster_host correctly <roaksoax> rvba: so bug #1148016 is the real blocker right now <ubot5> bug 1148016 in MAAS "Node always belongs to the same nodegroup/cluster" [Undecided,New] https://launchpad.net/bugs/1148016 <rvba> roaksoax: okâ¦ allenap is working on this one IIRC. <roaksoax> rvba: the bug is happening specially when the cluster controller is not managing any interfaces... hence maas doesn't know how to tell that a node belongs to a particular cluster controller <roaksoax> and I tested that in the same network <rvba> All right. <rvba> I think we've identified where the problem is. The only trick is that we will need to tweak the lab's network setup after the fix for this lands. <rvba> That's what alexlist was investigating. <roaksoax> biut i'm guessing its the same case on cluster with different networks (not managing dhcp/dns) <rvba> err, allenap <roaksoax> rvba: yeah he did say he was gonna make a branch available for me to test <rvba> roaksoax: I can probably do that for you since he is off todayâ¦ would a branch based on trunk work for you? <roaksoax> rvba: yeah that would be perfect <rvba> roaksoax: lp:~rvb/maas/all-interfaces <rvba> roaksoax: that branch changes the way we guess to which nodegroup a node should be attached. <rvba> All the interfaces are considered, not just the managed ones. <rvba> So, if you configure the interfaces correctly (and still leaves them "unmanaged"), you should be able to get the detection working, even when using an external DHCP server. <roaksoax> rvba: ok awesome! I'm gonna test it <roaksoax> thanks for making it available <rvba> np #maas 2013-04-04 <roaksoax> rvba: around? <roaksoax> rvba: i'm seeing this: http://pastebin.ubuntu.com/5676753/ any thoughts? <rvba> roaksoax: yepâ¦ <rvba> roaksoax: btw, you still need to merge https://code.launchpad.net/~andreserl/maas/ipmi_usercreation_ilo_versions_trunk/+merge/148579 in trunk right? <roaksoax> rvba: yeah so the reason why that did land in 1.2 and not trunk is because julian thought it would be better to have the testing of that in trunk,s ince it didn't make sense for 1.2 <roaksoax> rvba: and the above might be due to the nodegroup change? <rvba> roaksoax: right. Julian and I agreed that we don't really have time to add the testing so let's land this as is and file a bug about the lack of test for this. <roaksoax> rvba: ok sounds good to me <rvba> roaksoax: the error you pasted is due to the fact that 2 nodegroups match when we're trying to determine to which nodegroup a node should be attached. <roaksoax> rvba: so same network? <rvba> Yeah, the IP of the connecting node belongs to a network to which for nodegroups are connected to. <rvba> Thus we cannot determine to which is should be attached. <rvba> You can probably fix this by removing the network in question on one side. <roaksoax> yeah makes sense, I was jus testing whether your changes do fix the issue, but I just realized I was managing interfaces in both nodes <roaksoax> so makes sense <roaksoax> rvba: so this is a result of the revert you provided me with yesterday, righ? Since the current escenario I'm testing was working before that change <roaksoax> rvba: and this means that we cannot have 2 clusters in the same network <allenap> roaksoax: I've just had a chat with rvba, and we have a plan... <rvba> roaksoax: exactly <rvba> roaksoax: you can have two clusters in the same network, but you have to manually remove an interface (in MAAS) on one of the nodegroups. <roaksoax> rvba: ok I know how to setup an environment with 2 different clusters in different networks that's quite easy to do with kvm :) <roaksoax> rvba: I see <roaksoax> allenap: cool! what's the plan :)? <rvba> roaksoax: to tell to MAAS: this network, although physically attached to 2 nodegroups, is actually managed by *this* nodegroup. <roaksoax> right! makes sense <roaksoax> rvba: since the above error shows up even when both networks are *unmanaged* <allenap> roaksoax: I'll change the find_nodegroup() function to prioritise managed interfaces, but fall back to non-managed interfaces. Additionally, if more than one non-managed interface matches, we blow up, suggesting that either one interface is marked as managed, or to remove the other interface. <roaksoax> err both cluster interface are unmanaged <rvba> roaksoax: indeed, you need to *remove* one interface on one of the nodegroups/ <rvba> In your case, you don't have any managed interface. <roaksoax> rvba: right, say the master running in the region controller should not have any interface in the same network as the other cluster (bnoth managed/unmanaged) <rvba> roaksoax: exactly. <roaksoax> allenap: makes sense to me. But wouldn't it make better sense that if there's 2 cluster in the same network, to simply use 1 of those 2? <roaksoax> rvba: ok makes sense. Ok will setup an environment and test <allenap> roaksoax: That might be okay. I can't think of an issue with that offhand. rvba? <rvba> allenap: seems reasonable, as long as this only happens when no managed interfaces on this network are found I think that's ok. <allenap> rvba: If there's a managed interface, we will choose that one anyway. What if we find two managed interfaces for the same network? <roaksoax> if we found 2 managed interfaces in the same network that most likely would be the case that i'm using different ranges for DHCP. (which is what I was doing right now). <roaksoax> i guess it would make sense to try to detect from which one the node pxebooted from <roaksoax> if not fallback to the first one <allenap> roaksoax: When an interface is managed, the DHCP ranges are defined by the netmask, iirc, so you can't have two cluster controllers managing the same network. <rvba> Indeed, I don't think that's possible in MAAS right now. <roaksoax> allenap: right, but I can have 2 DHCP servers saying "Server IP between 800.716.0984 - 200" and another one that will server "800.716.0984 - 99" <roaksoax> s/server/serve <allenap> roaksoax: You /can/ do that, but it's not a supported configuration: the interface should be marked as unmanaged. <roaksoax> alright :) <allenap> Finding a node's nodegroup (aka cluster controller) in a nutshell: 1 managed interface on the network = choose this one; >1 managed interfaces on the network = misconfiguration; >1 unmanaged interfaces on a network = choose any <allenap> Version 2 of Finding a node's nodegroup (aka cluster controller) in a nutshell: 1 managed interface on the network = choose this one; >1 managed interfaces on the network = misconfiguration; 1 unmanaged interface on a network = choose this one; >1 unmanaged interfaces on a network = choose any <roaksoax> allenap: sounds good to me <allenap> Cool. <roaksoax> allenap: oh btw... i just made this change to python-tx-tftp in raring. Spads was getting his connection dropped and him and Daviey investigated and came up with the solution: http://pastebin.ubuntu.com/5676874/ <allenap> roaksoax: That's cool :) I'll submit that upstream (and also press for landing of the other patches). <roaksoax> allenap: that would be great! <AskUbuntu> Maas Web Interface not reachable after new installation! | http://askubuntu.com/q/277874 #maas 2013-04-05 <allenap> roaksoax: My branch for the find_nodegroup() stuff should be PPAed up in ~40 minutes: https://code.launchpad.net/~allenap/+recipe/find-nodegroup-redux <AskUbuntu> Mass post-node-enlisting installation fails or doesn't start! | http://askubuntu.com/q/278154 <roaksoax> allenap: awesome!! thanks a lot for working on it <allenap> roaksoax: You're welcome. I'm sorry I wasn't able to do it sooner. <allenap> I hope it works! <roaksoax> allenap: no worries I understand you've been busy :). I'm currently integrating FPI changes into it and then I'll do some testing <ALL`> can someone refer me to a good tutorial on setting up maas on ubuntu 12.04 LTS? <roaksoax> ALL`: maas.ubuntu.com <ALL`> roaksoax: thanks, I ended up downloading 12.10 instead and going with it so it matched the documentation. <roaksoax> ALL`: cool <ALL`> another question.... (i am pretty new to managing VMs/Clouds) if we have servers that their bios does not support PXE I assume we can use something like gPXE? <roaksoax> ALL`: yes #maas 2013-04-08 <alex_rus> Hello, is who? <roaksoax> allenap: howdy! so just tested your fix and seems to work for unmanaged networks (I have 2 clusters in 2 different networks) #maas 2013-04-09 <bigjools> roaksoax: fwiw I am getting apparmor problems with dhcp on quantal using the dailybuild package, is this known? <roaksoax> bigjools: no tomy knowledge. what kind of error? <bigjools> roaksoax: Apr 9 12:35:44 maas dhcpd: Open a socket for LPF: Permission denied <bigjools> Apr 9 12:35:44 maas kernel: [ 1194.554101] type=1400 audit(1365474944.338:53): appar <bigjools> mor="DENIED" operation="create" parent=1 profile="/usr/sbin/dhcpd" pid=3444 comm="dhc <bigjools> pd" family="packet" sock_type="raw" protocol=768 <roaksoax> bigjools: has packaging changed in upstream? cause trunk should have all of the fixes that were made for qusntal <bigjools> roaksoax: dunno - this is a build from a month ago <bigjools> roaksoax: the daily ppa is a mess of versions <bigjools> could do with an overhaul <roaksoax> bigjools: thats weird <roaksoax> yeah <bigjools> anyway, testing the experimental Go-juju provider <roaksoax> bigjools: i have not sern those issues running raring nor the sru prepared package <bigjools> roaksoax: I suspect the package itself is screwed, I don't trust them any more because of so many version problems (upload fail with duped files) <bigjools> this makes me sad <roaksoax> yeah <bigjools> roaksoax: commissioning and enlistment are taking *ages* now... :/ <TheChistoso_> i can't get the MAAS notice "The region controller does not know whether any boot images have been imported yet. If this message does not disappear in 5 minutes..." to go away <TheChistoso_> where are these logs I'm supposed to inspect? <TheChistoso_> anybody here? <roaksoax> bigjools: i think I know why that is.. and I already have a fix for it <roaksoax> allenap: howdy!! So FPI is mostly done, I do, however, have a question for you <roaksoax> allenap: check https://code.launchpad.net/~andreserl/maas/trunk-fpi/+merge/152039 and look at line 707 <roaksoax> allenap: how do you think we should approach obtaining the interface in order to obtain the IP when there are no managed networks? <allenap> roaksoax: I can't think of a better way than that. Do you have anything in mind? <roaksoax> allenap: no idea.. wsa trying to think of a way but other than obtaining the first one, there doesn'y seem to be much of a solution <allenap> roaksoax: Stick with that for now then. <roaksoax> allenap: will do, thanks! <TheChistoso_> hello! <bigjools> roaksoax: would be be in the ipmi detection by any chance? <bigjools> s/be be/it be/ <roaksoax> bigjools: were you using a branch with the new ipmi detection? <roaksoax> bigjools: or did you enable the IPMI params? <bigjools> roaksoax: argh, sorry, desktop problems. my mouse keeps disconnecting itself and replugging doesn't work, I need to reboot. <bigjools> anyway, it is slow with or without ipmi params enabled <roaksoax> bigjools: have you grabbed any logs? (such as cloud init ones?) <roaksoax> bigjools: while i have runned into slow ipmi detection myself, Its for network issues as my network setup is a strange one <bigjools> roaksoax: not yet, fighting maas <bigjools> and I need the backdoor image... grar <roaksoax> bigjools: re on your re-writing thing.. I agree. I wanted to separate the ipmi detection on a separate package/binary... however, the particular bug that's been fixed there is a bug that was targetted for 1.2 and has been there for a long time <roaksoax> and the only thing that caused is longer time on enlistment/commissioning for trying to discover ipmi <bigjools> roaksoax: only longer on VMs though? <bigjools> it takes about 10 minutes to complete on the HP microservers now <roaksoax> bigjools: with today's fix, it should not even try to detect ipmi in VM's <roaksoax> bigjools: and that's weird, I have my microservers here working just fine <roaksoax> bigjools: they were taking longer than usual only because of my network setup <bigjools> roaksoax: I suspect my maas is screwed up, I had to downgrade because of the crazy package versioning and it may have gone wrong <bigjools> I will reinstall <roaksoax> bigjools: ok <roaksoax> bigjools: what are you using, daily builds? <bigjools> yeah <roaksoax> weird then <bigjools> I previously had a home-made trunk build on quantal <bigjools> I switched to daily <bigjools> but the south migrations in the DB was screwed <roaksoax> yeah that's a likely cause of nighmare's * bigjools getting fed up of twitter follow spam <roaksoax> bigjools: i'll be on and off for the next hour/2 hour so let me know your findings <bigjools> roaksoax: I'll be a while - I am upgrading the server to raring #maas 2013-04-10 <roaksoax> allenap: any updaes? <roaksoax> err <roaksoax> bigjools: any luck> <roaksoax> ? <bigjools> roaksoax: literally just finished <bigjools> seems ok now <bigjools> however <bigjools> I did see an error fly by from maas-ipmi something about None type not having a group attribute <roaksoax> bigjools: ok let me check <bigjools> then it shut down so it disappeared :/ <bigjools> this is raring packages btw <bigjools> I need to take the dog out now, leave me a message if you want me to do anything <roaksoax> bigjools: i'm testing enlistment here and see what happens <roaksoax> bigjools: did it add the power settings correctly? <roaksoax> bigjools: I just tested it, it works just fine for me <roaksoax> bigjools: maybe your bmc is locked out? <bigjools> roaksoax: I can't find the commissioning data after reinstall, did you move it? <roaksoax> bigjools: jtv did <roaksoax> bigjools: it's in /usr/share/maas/pyshared/metadataserver/commission/user_data.template IIRC <bigjools> aha <bigjools> /usr/share/maas/preseeds/enlist_userdata <bigjools> everything worked but I hadn't enabled the BMC options for the HP so no power was detected <roaksoax> bigjools: yeah that's enlistment, commissioning is under metadataserver (instead of /etc/maas/commissioning-user-data) <roaksoax> bigjools: ah! that was it then :) <bigjools> mmmm which do we change? <bigjools> /usr/share/pyshared/metadataserver/commissioning/user_data.template <bigjools> has the same code <roaksoax> bigjools: yeah, so I really wanna make it a binary <roaksoax> bigjools: along with maas-signal <bigjools> that'd be nice <roaksoax> (which is used during commissioning) <roaksoax> so we can ditch all the dup code <bigjools> no complains from me :) <bigjools> complaints* <roaksoax> cool, I'll try to get that done this week <bigjools> roaksoax: just testing a new enlistment with the impi options set up, let's see ... <bigjools> ipmi even <bigjools> roaksoax: didn't detect it on enlistment <roaksoax> bigjools: i would need to see logs why. I have just tested it myself <roaksoax> and it worked like a charm <bigjools> getting logs is hard :( <bigjools> we really need to make them all go back to the maas host <roaksoax> bigjools: nah! get the backport image thing and at touch /tmp/block-poweroff to the user data <roaksoax> bigjools: and then you just ssh in and that's it :) <roaksoax> bigjools: but yes, we need to get all those logs back to maas <bigjools> roaksoax: that is too hard, really, when all we should do is rsyslog <roaksoax> agreed <bigjools> heck even my router logs using rsyslog to my server :) <roaksoax> heh :) <bigjools> I actually thought we had rsyslog set up <bigjools> isn't it on the kernel cmd line? <roaksoax> bigjools: we do, it only works for deployments <roaksoax> bigjools: it doesn't work for ephemeral images <bigjools> ah <bigjools> shame <roaksoax> bigjools: indeed.. but anyways... i thought danwest was gonna be in charge of maas from now on.. <bigjools> roaksoax: apparently so <bigjools> roaksoax: so, I enabled this line: <bigjools> IPMI_SI_PARAMS="type=kcs ports=0xca2" <roaksoax> bigjools: that should be all you need <bigjools> in /usr/share/pyshared/metadataserver/commissioning/user_data.template <bigjools> and <bigjools> /usr/share/maas/preseeds/enlist_userdata <bigjools> didn't get power params on enlist or commissioning <bigjools> this has happened before - the BMC goes all weird <roaksoax> bigjools: boomer, I'm guessing there's an issue with your BMC? <roaksoax> bigjools: yeah... I upgraded to the latest fiirmware <roaksoax> so maybe you should do the same <bigjools> last time, it refused DHCP OFFER all the time <bigjools> then it worked for a while <bigjools> oh <bigjools> Apr 10 14:10:20 maas dhcpd: Can't create new lease file: Permission denied <bigjools> apparmor fix needed <bigjools> it existed already I think <roaksoax> bigjools: i'll test that tomorrow and see what happens. cause I'm pretty sure it was working <roaksoax> bigjools: unless the fixes got dropped <bigjools> let me check my BMC hang on <bigjools> ah bollocks this one's easy <bigjools> the BMC has no ethernet cable in it :) <roaksoax> lol <roaksoax> :) <bigjools> EOUTOFROUTERPORTS <bigjools> I'll delete it and do it again <bigjools> so I plugged in a cable and it's not DHCP requested yet :/ <roaksoax> bigjools: ok I think it got dropped <roaksoax> the change in isc-dhcp <bigjools> damn <roaksoax> i'm checking now just o be sure <bigjools> that was really screwing people over <roaksoax> bigjools: nope, my bad, the fix is there <roaksoax> bigjools: check in /etc/appamor.d/dhcpd.d/ whether there's the maas profile <bigjools> roaksoax: no :/ <bigjools> why is that missing? I install maas-dhcp <bigjools> installed <roaksoax> aas-dhcp.install:/debian/tmp/etc/apparmor.d/dhcpd.d/maas <roaksoax> maas-dhcp.install:/debian/tmp/etc/apparmor.d/dhcpd.d/maas <roaksoax> maas is installing it <bigjools> maas is installed <roaksoax> roaksoax@pursue:/etc/apparmor.d/dhcpd.d$ ls <roaksoax> maas <bigjools> oh wait it's there <bigjools> so I suspect there's a profile problem where it can't delete and make a new file <bigjools> ? <bigjools> or open as new <bigjools> overwriting an old one <bigjools> aha I see IPMI <bigjools> and it powered on when I did "accept & commission" <bigjools> \o/ <roaksoax> \o/ <roaksoax> bigjools: alright, the other i can think of is that the profile has not being loaded with the maas related stuff <roaksoax> see maas-dhcp.postinst in http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/169 <bigjools> roaksoax: it must be, it works <bigjools> it's just that error on restarting it if there's an existing file <bigjools> it can't clean out the file AFAICS <bigjools> so it'll grow forever <roaksoax> ah! I see <roaksoax> alright then <roaksoax> knowing you got it working <roaksoax> i'm gonna go pass out :) <bigjools> heh <roaksoax> have a good day man * roaksoax sleeps <bigjools> it must be late there <roaksoax> half past midnight :) <bigjools> go sleep! <bigjools> thanks! <roaksoax> np :) #maas 2013-04-11 <Gayman_> could i log into maas node directly?? <bigjools> Gayman_: if you use Juju yes, or if you set an ssh key in maas, yes <Gayman_> should i create the ssh key before installation of the new node, or there is some way that i can transfer the key to the nede <bigjools> no it needs to be done in advance <Gayman_> how i can do so ?? <Gayman_> do you mean that i have to create the key before start installation of the new node? <bigjools> it's easiest to use juju, maas works best that way <Gayman_> ok, but how to transfer the key from the maas master to mass node , with or without juju.. <bigjools> you set it on your user preferences in maas and then it'll be uploaded to the node when it installs <bigjools> with juju, it just works too <Gayman_> do you mean to copy past the ssh pub key of the master maas into the preferences UI page , i do so and it says invalid key <jtv> Gayman_: I'm not sure about "of the master maas"... What you need to do is copy (the text of) your own ssh pub key into that UI page, so that you can then use your own private key to log into nodes that are allocated to you. <Gayman_> i try to do so many tims i get "Invalid SSH public key" <Gayman_> could i download maas package into the maas server so when adding new node i don't have to connect to internet?\ <roaksoax> rvba: still around? <18WADAAUZ> how to save a copy of all needed software -into master maas node- for enlist new node, so i don't need to download this package each time i enlist new node <roaksoax> 18WADAAUZ: edit /usr/share/maas/preseeds/enlist_userdata and eble apt_proxy to use the proxy <bigjools> 18WADAAUZ: the default installation of maas includes a proxy so that all nodes use it, so unless you changed something it will already download it only once <bigjools> roaksoax: he doesn't need to edit that #maas 2013-04-12 <roaksoax> bigjools: he does if he is using quantal <roaksoax> 18WADAAUZ: are you using quantal? <18WADAAUZ> no <roaksoax> 18WADAAUZ: raring? <18WADAAUZ> no <18WADAAUZ> i am very new to maas <roaksoax> 18WADAAUZ: what ubuntu release are oyu using? <18WADAAUZ> 12.04.2 <roaksoax> 18WADAAUZ: so you should already be using the proxy by defaul IIRC <bigjools> roaksoax: it still uses squid-deb-proxy in quantal, no? <bigjools> roaksoax: and when are we going to SRU? :) <roaksoax> bigjools: yes, but proxy access for enlistment/commissioning is not enabled by default <roaksoax> bigjools: it is in the queue already waiting for verification :) <roaksoax> bigjools: first python-tx-tftp and python-django need to be verified <roaksoax> before we verify maas <bigjools> roaksoax: very disappointed with the comments on the dhcp bug :/ <roaksoax> bigjools: link? <bigjools> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570 <ubot5> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] <18WADAAUZ> about proxy configration, i was think it is only to allow the master maas server to get internet connection. not internal proxy <roaksoax> bigjools: that woudl also probably require TB exception <18WADAAUZ> do i have to configure the proxy setting inside maas server manulay?? <bigjools> roaksoax: I can't remember where the proxy stuff was backported <bigjools> if at all <donmai> hello, is there an channel for MAAS support? <donmai> or would questions go here <jtv> donmai: yes, questions go here â it's still a bit quiet though because Europe is only just waking up. <amir___> hi <amir___> I have created a new MAAS ,what will the username and password for login <amir___> kinly help me <roaksoax> rvba: howdy!! <roaksoax> rvba: still around? <AskUbuntu> MAAS PXE Boot fail. IP-Config : no response | http://askubuntu.com/q/280811 #maas 2013-04-14 <Gayman_> for simple MAAS server and 3 nodes do i need to set nova.conf to accept multihost #maas 2013-04-15 <AskUbuntu> Juju not seeing the MaaS slaves... at least not after some time? | http://askubuntu.com/q/281640 #maas 2013-04-16 <julianwa> racedo: ping <raywang> bigjools, ping <bigjools> hi raywang <raywang> hi bigjools we are facing a serious problem. When trying to add ssh key into maas, it report "invalid ssh public key" <bigjools> raywang: are you not using juju? <raywang> which we guarantee the key is no problem (try three times for new keys) <raywang> bigjools, we will use juju, but before that, we are trying to insert public key to maas <bigjools> raywang: you don't need to add a key to maas if you use juju <raywang> bigjools, sorry, I mean "Add SSH Key" to maas <raywang> bigjools, are you saying "there is no need to add ssh key to maas manually? if use juju to deploy services, it will grab the public key, and add it into VM automatically <bigjools> raywang: that's correct <bigjools> the manual ssh key adding is only needed if you plan on using maas to manually start nodes <raywang> bigjools, in other words, if we don't use juju and don add ssh key, how can we login the system without inserting the public key? <bigjools> if you are using juju it just works <raywang> bigjools, does 0.6 version of juju works? <bigjools> if it has maas in it, it should do * bigjools can't remember juju versions <raywang> ok <raywang> bigjools, i just want to make sure this is the feature of juju go version <bigjools> raywang: yes it wll be the same in Go <raywang> if the case is we start the node manually, so we have to add ssh public key to maas, and this time we fail to add the key, how can we find out where is the problem? :-) <bigjools> raywang: you can't! <bigjools> it ought to prevent manual startup if there's no ssh key <raywang> bigjools, got it, so anyway to find out why it fail to add the ssh public key? <raywang> any way <bigjools> raywang: which version of maas? <bigjools> and can you paste me the public key string you're trying to add <raywang> maas 1.2+bzr1373+dfsg-0ubuntu1~12.04.1~ppa1 <raywang> from ppa:maas-maintainers/stable <bigjools> good :) <julianwa> bigjools: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4SrSolwrO33ZYsRtoMWlouEgVcztNJwdOi1g6MwS3Ihnb9coVnHYMNPeeuj5HLOtJ4obkupAWJcKS/6c26k56V3ry0bILduQatxCb9lHzj <julianwa> Zc2wKm84szcU77pPO4XIloyWPM3GX+xBZb3lj6C6PzvIeMpeXYPa+fIoXwBmKK0ae+P+zK3HBR4AwuuBdgpFzPaB2S2e1phVzocdI7oC38dhOj4GFK2+rcdqPGnlJZp49vGhvftTLNHUU7Wc1 <julianwa> V1ydIasO/5+opP+CTqvbx34aec6WN3ASAyiC/QhgP8fLST6LlHqfDAVOUJMKE1f7gWpNcqpBvf768PqxEO0xNemf maasadmin@MAAS-ADMIN <bigjools> ok hang on <raywang> bigjools, ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4SrSolwrO33ZYsRtoMWlouEgVcztNJwdOi1g6MwS3Ihnb9coVnHYMNPeeuj5HLOtJ4obkupAWJcKS/6c26k56V3ry0bILduQatxCb9lHzjEZc2wKm84szcU77pPO4XIloyWPM3GX+xBZb3lj6C6PzvIeMpeXYPa+fIoXwBmKK0ae+P+zK3HBR4AwuuBdgpFzPaB2S2e1phVzocdI7oC38dhOj4GFK2+rcdqPGnlJZp49vGhvftTLNHUU7Wc14V1ydIasO/5+opP+CTqvbx34aec6WN3ASAyiC/QhgP8fLST6LlHqfDAVOUJMKE1f7gWpNcqpBvf768PqxEO0xNemf maasadmin@MAAS-ADMIN <bigjools> are you pasting it in without line breaks? <bigjools> in maas's dialog <bigjools> because I can add your key into my running maas <bigjools> raywang: ^ <raywang> bigjools, yeah, you are probably right, the content we copy from "screen" has line breaks i guess <bigjools> raywang: yes, I could tell from the way julianwa pasted it :) <raywang> bigjools, great, thank you! <raywang> bigjools, it's great to have you in the same timezone :) <julianwa> bigjools: screen's problem.. <bigjools> raywang: easiest way is to "cat ~/.ssh/id_rsa.pub" <bigjools> then copy/paste from that <raywang> bigjools, yes, that's how we did <bigjools> the terminal won't have line breaks <bigjools> cool <bigjools> raywang: glad to help :) <raywang> bigjools, we just "cat ~/.ssh/id_rsa.pub", and copy from the terminal <raywang> bigjools, maybe 'screen' screw it up <bigjools> quite possible <bigjools> screen generally screws things up <julianwa> you are right. <julianwa> bigjools: when we using maas to manage vm, it always takes us so long time to wait ipmi while enlist/comissioning/install <bigjools> julianwa: there's a fix coming for that soon <bigjools> it may even be in the daily builds <julianwa> bigjools: cool. <dragunov11> Am getting the "exceptions.AssertionError: No PXE template found in '/usr/lib/python2.7/dist-packages/provisioningserver/pxe'!" error <dragunov11> even after accepting the nodes for commissioning. <dragunov11> I referred to this https://bugs.launchpad.net/maas/+bug/1064212 . But it happens with me even if the node is in "Ready" state. <ubot5> Launchpad bug 1064212 in MAAS "If a machine is booted manually when in status "declared", TFTP server tracebacks" [Low,Triaged] <dragunov11> Any particular solution guys? <bigjools> the node must be started via MAAS <bigjools> not manually <dragunov11> How do I start the node through MAAS ? <dragunov11> using WoL ? <bigjools> use the button in the UI or preferably connect it to juju <bigjools> once maas thinks the node is starting up, you can start it manually if you want <dragunov11> oh ok. <bigjools> but it's obviously more convenient to have WoL or some other power control <dragunov11> Ok. Going to try it now. <dragunov11> Its working. Thanks bigjools <bigjools> ok #maas 2013-04-17 <AskUbuntu> Does MAAS still support Wake-On-LAN (from 13.04 onwards)? | http://askubuntu.com/q/282351 <k0d> Hej! I'm trying to get power management to work but I'm not sure how to get this to work properly. <k0d> I've got a bare-metal server to work, but not a VM machine. <k0d> Does anyone have previous luck in getting that to work? <roaksoax> rvba: around? #maas 2013-04-18 <Matrix3000> guys, need some help <Matrix3000> base install of maas right now doesn't function out of the box <Matrix3000> at least from the 12.04.2 release cd <Matrix3000> also maas-cli doesn't exist anymore <k0d> Hej! So I've got Maas controlling various nodes, but now I'd like to reinstall one. I don't really see an easy way to 'reprovision' a node. <bigjools> k0d: you just ask maas to release it. it gets reinstalled when it is next used. <melmoth> k0d, remove all service from it with juju destroy-service, then unallocate the machine with juju terminate-machine <melmoth> then it should appears back in Ready state in the web gui. <melmoth> you can then redeploy stuff on it <k0d> ok, what I don't understand yet is the juju thing ;) <k0d> I haven't actually got that installed yet <k0d> bigjools: I missed your message ;) I can use maas-cli to release itâ¦I've done that bit before! <bigjools> k0d: there you gop <bigjools> go <k0d> Is there a reason that it's not available inside of the web interface? <bigjools> it's just not implemented <bigjools> it should be there <k0d> Ok, I see. <k0d> To me it feels like this is a very good system, with a defined plan/goal, but it's not all been implemented yet. <k0d> bigjools: melmoth: thanks for your help! <k0d> It's really nice to be able to start/stop nodes with the power management things, but I don't seem to be able to get it to work with my virtual machinesâ¦only the bare-metal ones. <k0d> :( <k0d> I'm using VMWare, maybe I need to switch to something else that virsh works well with, but then I don't yet understand how to configure that. Does anyone have knowledge/experience with it? <k0d> Hej, I'm trying to pass on control of a node to puppet after it's been installed. <k0d> juju seems to be the wrong way for me to go about this <k0d> Does anyone know how to configure the cloud-init config that gets sent? <roaksoax> rvba: around? <vasu> Q: I installed maas on 12.10 in VMware. with 2 NICS. on the private NIC (disabled dhcp), i have a 2nd VM booting via PXE. <vasu> the 2nd VM gets dhcp ip from MAAS, but fails to get tftp image. <vasu> anybody has a hint for me, where to look? <ppetraki> roaksoax, could you please get someone to review this? https://code.launchpad.net/~vanhoof/maas/ipmi-state-fix_lp1086160/+merge/159714 <ppetraki> trivial code change, big impact <roaksoax> ppetraki: done #maas 2013-04-20 <mwhudson> hu <mwhudson> *hi <mwhudson> i'm trying to follow https://maas.ubuntu.com/docs/quantal/juju-quick-start.html and having a few problems <mwhudson> the first was <mwhudson> error: Environments configuration error: /home/ubuntu/.juju/environments.yaml: environments.maas.default-series: required value not found <mwhudson> so i added that <mwhudson> then there was nothing listening on localhost:5420 <mwhudson> there is something mass-ish on 5242 though <mwhudson> but changing the url to that doesn't work either <mwhudson> ah <mwhudson> just setting maas-server to http://localhost/MAAS/ works <mwhudson> next: 2013-04-19 19:58:49,376 ERROR No matching node is available. #maas 2013-04-22 <bigjools> roaksoax: did you see https://code.launchpad.net/~allenap/maas/remove-ipmi-optimisation/+merge/160146 <roaksoax> bigjools: yeah... did you see this: http://pastebin.ubuntu.com/5594094/ <roaksoax> bigjools: i just upgraded a machine from quantal t raring and seeing that error <bigjools> looking <bigjools> roaksoax: is that with the latest power fix? <roaksoax> bigjools: i believe so yes <bigjools> they tested it in the lab <bigjools> and it was ok <bigjools> so - confused <roaksoax> i'm gonna revert it and see what happens <bigjools> where are you running that? <roaksoax> bigjools: this is virsh btw, not ipmi <roaksoax> in a lab <roaksoax> bigjools: maybe this is the issue: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/revision/1456 <bigjools> roaksoax: why is ipmi set as the power type for a VM? <roaksoax> bigjools: is not ipmi, it is virsh <bigjools> roaksoax: that revno is not a problem, it is doing the right thing <bigjools> so you have a failure in the virsh script <bigjools> it needs to be debugged <roaksoax> bigjools: yeah the virsh script hasn't really changed, so it shouldn't fail <bigjools> sorry - I didn't realise you were talking about virsh all of a sudden :) <roaksoax> hehe <bigjools> roaksoax: it was probably failing before and we didn't know <roaksoax> yeah this is our virtual-maas <bigjools> now we know <bigjools> roaksoax: could just be exit status on script <roaksoax> bigjools: i'm thinking that it might be not having access to virsh <roaksoax> that's what I'm thinking <bigjools> the same code works with ipmi and friends <bigjools> we never tested virsh very much as it's not "metal" :) <bigjools> and now you're using it a lot more <roaksoax> bigjools: ok apparently is virsh issue <bigjools> phew <roaksoax> i mean not having permission for virsh <roaksoax> but that's strange since there's a sudoers file for it <bigjools> roaksoax: we could do with more info printed in that error <roaksoax> indeed <roaksoax> bigjools: http://paste.ubuntu.com/5594116/ --> tha obviously doesn't fail - this does: http://pastebin.ubuntu.com/5594122/ <roaksoax> bigjools: so probably permissions <bigjools> roaksoax: agreed <roaksoax> i'll investigate tomorrow im off now <bigjools> roaksoax: cheers <mwhudson> bigjools: good morning <bigjools> wotcha mwhudson <mwhudson> bigjools: i installed maas on calxeda the other day <mwhudson> bigjools: mostly it worked fine but i got a bit confused about a few things <bigjools> understandable :) <mwhudson> bigjools: the biggest one was that juju defaults to asking for an amd64 node for bootstrap <mwhudson> and it took me a long time to figure out this was why it wasn't getting an instance <bigjools> that's not very nice if it, why should it care I wonder <bigjools> of it* <bigjools> which juju? <mwhudson> py <bigjools> weird then <bigjools> does the Go version work on ARM? :) <mwhudson> i ended up adding logging statements to the maas api server to print out the arguments... <mwhudson> which was a bit sad-making <mwhudson> bigjools: i don't think so <bigjools> :/ <mwhudson> bigjools: the other thing i wanted to bug you about was that ages ago you said that maas would soon gain the ability to splat a tarball onto disk rather than running debian-installer <mwhudson> bigjools: did that happen? <bigjools> mwhudson: it's WIP. roaksoax and smoser are working on the installer, the MAAS changes are done though. <mwhudson> ok <mwhudson> is there a blueprint i can subscribe to or anything? <bigjools> hmmm not on my list #maas 2013-04-23 <mwhudson> bigjools: oh, the other thing that was confusing me was whether i should set the nodes to pxe or disk boot by default <bigjools> mwhudson: always pxe <mwhudson> or if it doesn't matter and maas always runs "chassis bootdev $arg" as appropriate anyway <mwhudson> ok <bigjools> maas will make the node DTRT <mwhudson> bigjools: does maas work to deploy quantal on arm server do you know? <mwhudson> i got some error when i tried, but well, i was doing all sort of things i didn't understand at that point <mwhudson> bigjools: also will i be happier with packages from quantal(-updates) or the daily or stable ppa? <bigjools> mwhudson: PPA is better right now but there's and SRU imminent <bigjools> an* <mwhudson> this ppa? https://launchpad.net/~maas-maintainers/+archive/dailybuilds/+packages <bigjools> yes <mwhudson> ta <bigjools> also raring is better <mwhudson> oh ok <bigjools> it has a few more features <bigjools> I don't know about deploying quantal on arm, I'd talk to rbasak <mwhudson> i don't know how to install raring on highbank... <bigjools> do you need to install the server on arm? <bigjools> you can run it on x86 and deploy to arm <mwhudson> hm <mwhudson> for now it's probably easier to install on arm <mwhudson> http://ports.ubuntu.com/dists/raring/main/installer-armhf/current/images/generic/netboot/ looks promising <lifeless> mwhudson: whatchya working on? <mwhudson> lifeless: arm server stuff <mwhudson> benchmarking, in particular <lifeless> mwhudson: ah, so automated bare metal setups ? <mwhudson> yeah <mwhudson> and deployment of services that one might want to benchmark <lifeless> mwhudson: this a linaro thing? <mwhudson> yep <Matrix3000> anyone able to explain why dhcp doesn't work on clients after install maas-dhcp <Matrix3000> can't get them to PXE boot, when everything is permitted <Matrix3000> there are no other dhcp servers on the network <Matrix3000> where should dhcp be finding the config file <Matrix3000> anyone here that can explain the dhcp pxe boot issues, installed maas-dhcp, still nothing broadcasted <roaksoax> Matrix3000: Did you configure maas to provide DHCP? <Matrix3000> how do I specify that <Matrix3000> cause on 12.04 implementation it was fairly automatic, but in 12.10 doesn't look to be <roaksoax> Matrix3000: go to the web UI and modify the settings there fro a cluster controller <roaksoax> you'll be able to add it <Matrix3000> ok will try in a minute <roaksoax> bigjools: let me know when around <Matrix3000> roaksaox: that did not help, but i found where to change it <Matrix3000> still not gettign any dhcp sent to it * mwhudson is installing maas for the third time in the last 3 working days... <mwhudson> (this time for sure!) <bigjools> \o/ <bigjools> yo roaksoax <mwhudson> although h,, <mwhudson> hmm <mwhudson> i thought i'd be clever and install it in a raring container on a precise host <mwhudson> but i guess i'll need to do something cleverer to make sure that pserv can get tftp traffic <lifeless> naaaaat <mwhudson> that's the problem rather than the solution isn't it? <bigjools> there's your problem - don't try and be clever :) <mwhudson> i guerss <bigjools> accept the matrix <roaksoax> bigjools: o/ <roaksoax> bigjools: hey so I was thinking ... we should just go for a migration path fro the SRU <bigjools> roaksoax: how would you see that working? <roaksoax> bigjools: if in upgrade from the precise version we have DNS/DHCP configured, configure it in MAAS itself <bigjools> roaksoax: you would have to parse the dhcpd.conf <roaksoax> bigjools: i can get the info from debconf i think :) <bigjools> I am not sure this effort is worth the hassle <roaksoax> if precise still does that (can't even remember :) ) <roaksoax> bigjools: i know, but its the only way it will get accepted <roaksoax> at least from his perspective <bigjools> roaksoax: grarrrrr. remind me of the bug number again? <roaksoax> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1109283 <ubot5> Launchpad bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix committed] <bigjools> ta #maas 2013-04-24 <mwhudson> whuh <mwhudson> maas-cluster-celery is failing to start for me <mwhudson> sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) <mwhudson> OSError: [Errno 13] Permission denied <mwhudson> [2013-04-24 02:13:58,398: INFO/MainProcess] process shutting down <bigjools> wha <mwhudson> dailybuilds ppa installed on precise <mwhudson> seems to be inside celery's start up code :( <mwhudson> python -c "import multiprocessing.queues; multiprocessing.queues.SimpleQueue()" fails the same way <mwhudson> hm, seems to be /run/shm permissions * mwhudson tries rebooting the server (needs doing anyway) <mwhudson> ok that fixed it <mwhudson> bigjools: argh <bigjools> ruh roh <mwhudson> bigjools: pserv doesn't appear to be serving a pxelinux.0 file <bigjools> did you import images? <mwhudson> yes <mwhudson> but i had that celery oddness <bigjools> arm is a bit different here <mwhudson> so maybe something didn't happen that shoulda orta <bigjools> mebbe <mwhudson> the "region controller doesn't know about images" went away eventually though <mwhudson> re run the import pxe script? <bigjools> mmmm if that's gone then it;s imported them <bigjools> but some of it could have failed <bigjools> did you run it manually or use the UI? <mwhudson> manually <mwhudson> oh <mwhudson> right, so the symptom i have of this is that the automatic pxe boot fails in uboot <mwhudson> if i set ipaddr and serverip and run pxe get; pxe boot it works and the node gets commissioned <bigjools> trying to remember how arm works ... <mwhudson> so it's really just pxelinux.0 not being there that trips it up <bigjools> it ignores that though, I thought? <mwhudson> mwhudson@lava-leg01:~$ tftp localhost <mwhudson> tftp> get pxelinux.0 <mwhudson> Received 26837 bytes in 0.0 seconds <mwhudson> what <mwhudson> adsadasdasdsada <bigjools> it just uses the location of it as a base directory for eveything else <mwhudson> right <mwhudson> but if it returns file not found it complains <bigjools> ok <bigjools> but you can get it as you just showed :) <mwhudson> i can /now/ <bigjools> however, the tftp server is sensitive to where the request comes from <mwhudson> probably because i re-ran maas-import-pxe-files <mwhudson> exceptions.AssertionError: No PXE template found in '/usr/lib/python2.7/dist-packages/provisioningserver/pxe'! <mwhudson> now i get that ^ <bigjools> vart da furk <mwhudson> oh <mwhudson> i think this is https://bugs.launchpad.net/maas/+bug/1064212 <ubot5> Launchpad bug 1064212 in MAAS "If a machine is booted manually when in status "declared", TFTP server tracebacks" [Low,Triaged] <mwhudson> it's booting ok now <bigjools> could be yes <bigjools> maas has to know it's required to boot <bigjools> ideally we'd send something that shuts it down again <mwhudson> ok nodes are declaring themselves now <bigjools> yay <mwhudson> and now i can't get juju to work :) <mwhudson> (juju-go this time) <AskUbuntu> How to cat the `MAAS Key` of a user via `maas shell`? | http://askubuntu.com/q/284939 <rvba> Hi mgz, would you mind having a quick look at this when you'll get a chance: https://code.launchpad.net/~rvb/maas/empty-tag-bug-131232/+merge/160672 ? <rvba> I just want to know if it seems sane to you because you know that code probably better than I do. <mgz> rvba: sure <rvba> ta <allenap> roaksoax: Have you seen https://bugs.launchpad.net/maas/+bug/1172303? Do you know if this is just a difference between the packaging in quantal and raring? <ubot5> Launchpad bug 1172303 in MAAS "MAAS_URL on maas_cluster.conf is quoted on quantal but not quoted on raring" [Undecided,New] <roaksoax> allenap: i think is packaging.. IIRC matsubara made a change recently and that might have changed the behavior <roaksoax> allenap: this might be the cause: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/173 <roaksoax> matsubara: ^^ <roaksoax> allenap: yeah that's what has changed <roaksoax> matsubara: your fix broke something :) <roaksoax> allenap: we want it quoted right? <roaksoax> allenap: this would fix it: http://paste.ubuntu.com/5598853/ <allenap> roaksoax: What branch is used for the raring package then, if not that one? <allenap> roaksoax: That change in r173 looks like it's adding the quotes that the integration test is expecting to find, but it's odd that they're in quantal but not raring. I would have expected the other way round if anything. <roaksoax> allenap: that's the branch that's being used. I think the reason why its not being seen on quantal is because the affected change is in the SRU , with is in -proposed and not in -updates <roaksoax> allenap: so matsubara miught be comparing to that <roaksoax> allenap: oh hold on, what's on -updates doe snot have maas_url <roaksoax> allenap: so something has changed then <roaksoax> allenap: ont he dpkg-reconfigure it seems that the quotes never get added <allenap> matsubara: ^ I have to go now, but perhaps that'll lead to the root problem. Thanks roaksoax. <matsubara> thanks allenap and roaksoax <roaksoax> matsubara: i think this is the appropriate fix: http://paste.ubuntu.com/5598853/ <roaksoax> matsubara: manually applying this fix gives me: http://pastebin.ubuntu.com/5598866/ <matsubara> roaksoax, cool. so I just need to merge propose that against lp:~maas-maintainers/maas/packaging and packaging.quantal? <roaksoax> matsubara: and precise.sru <roaksoax> rvba: still around? <matsubara> roaksoax, ah ok. I'll mp it <allenap> roaksoax: I'm not sure that's the right fix. That changes the quotes from single to double, but the test is looking for single quotes, and the failure is that there are no rodriguezcrystal@example.org. * allenap really goes. <roaksoax> allenap: http://pastebin.ubuntu.com/5598887/ <roaksoax> allenap: yeah, so we should standarize and make the test not look for single quotes, but look for double quotes <roaksoax> because that's how everything is being done <matsubara> roaksoax, ok. I'll update the tests as well <roaksoax> allenap: the initial change was driven becuase a test was broken due to a leading whitespace <roaksoax> so we never noticed that there were no quotes in the first place <roaksoax> which would have been providing the above fix instead of the commited fix <matsubara> roaksoax, https://code.launchpad.net/~matsubara/maas/fix-MAAS_URL-quotes/+merge/160722 https://code.launchpad.net/~matsubara/maas/fix-MAAS_URL-quotes-quantal/+merge/160723 https://code.launchpad.net/~matsubara/maas/fix-MAAS_URL-quotes-precise/+merge/160725 <matsubara> I need to go for a dentist appointment and should be back in ~1h #maas 2013-04-25 <mwhudson> argh <mwhudson> this doesn't look good <mwhudson> Bytes transferred = 70 (46 hex) <mwhudson> Config file found <mwhudson> Ignoring unknown command: SAY <mwhudson> Ignoring unknown command: LOCALBOOT <mwhudson> 1: local <mwhudson> No kernel given, skipping local <mwhudson> ?? <mwhudson> oops, mischan :) <mwhudson> bigjools: have you heard anything about the pxe command "localboot" not being recognized on arm servers? #maas 2013-04-26 <bigjools> mwhudson: I have done very little testing on arm (read: none, personally), as rbasak was managing that side of things. <mwhudson> bigjools: i figured out the problem <mwhudson> bigjools: and filed a bug <bigjools> cool <mwhudson> bigjools: sorry for the noise <bigjools> no problem <bigjools> in terms of crap I see on IRC, this is *not* noise :) <mwhudson> :) <bigjools> roaksoax: we added an api helper to help with the sru migration thing you and I talked about: https://code.launchpad.net/~rvb/maas/api-update-cluster/+merge/160641 <lifeless> &^*&$*%$\ <lifeless> ^- noise <bigjools> lifeless: bless you <bigjools> mwhudson: are you using raring or quantal, or perhaps both? <mwhudson> bigjools: precise <bigjools> argh <mwhudson> at least, maas is installed on precise <bigjools> from the PPA, please say from the PPA <mwhudson> yes, from the ppa <mwhudson> 1.2+bzr1373+dfsg-0+1374+170~ppa0~precise1 <mwhudson> if you want to tell me how to get my raring lxc an ip address on the lan... <bigjools> does lxc not have bridged networking? I know nothing about lxc... <mwhudson> not in an easy to set up form it seems <mwhudson> just nat <mwhudson> it's probably not hard if you know what you're doing <lifeless> mwhudson: there is a bridge device <lifeless> mwhudson: lxcbr or some such; you can just configure lxc to use a different bridge <lifeless> mwhudson: and put *that bridge* onto the LAN via /e/n/i + brtools. <mwhudson> lifeless: ok, most of the howtos around on the internet seem to involve editing the config of eth0 and that scares me a bit <lifeless> mwhudson: note that when you do this, your own lan config needs to move to the bridge <mwhudson> because the server is in the uk and i am not <mwhudson> ah right <mwhudson> see abouve :) <lifeless> mwhudson: right, and? <mwhudson> well, i just don't want to break the hosts lan config <lifeless> fair enough <mwhudson> i'll see about getting serial console access and then play with it <lifeless> you could futz around with nat rules but thats way harder <mwhudson> yeah that doesn't appear <mwhudson> *appeal <rvba> rbasak: Hi Robie, would you mind having a look at bug 1172966 at your earliest convenience? I'm pretty surprised to see that bug because, as I say in my comment, we've tested installation on ARM nodes everyday. <ubot5> bug 1172966 in MAAS trunk "SAY command in config.local.template breaks local boot on highbank" [High,Fix committed] https://launchpad.net/bugs/1172966 <rbasak> rvba: ack - I've responded in the bug <rvba> ta <rvba> rbasak: is there a way to log inside the node and get the info about the U-Boot version? Because for some reason, I cannot connect to the machines using ipmitool. <rbasak> rvba: I'm not aware of any way to do that, sorry. There might be a special wasy that Rob Herring would know, but I don't know it. <rbasak> rvba: if you can't connect with ipmitool, perhaps there is already something connected and logging the serial output? <rvba> rbasak: something like a rsyslogd on the MAAS server? <rbasak> rvba: in the lab I developed it on, I set up conserver to keep an ipmitool running, so everything got logged to /var/log/conserver. Not sure about what's going ione in the MAAS QA lab though <rvba> rbasak: I don't think there is anything like that in the QA lab. <AskUbuntu> When will Raring make it to "Released" status in MAAS? | http://askubuntu.com/q/285960 <jlondon> Howdy. I asked a while back if there was a way to have different partition schemes for different servers in MaaS. Is this possible? <AskUbuntu> How do you actually configure DHCP in MaaS? | http://askubuntu.com/q/286175 #maas 2013-04-27 <roaksoax> q/win 2 #maas 2013-04-28 <paravis> Hello! Anyone awake? I have a simple question ... #maas 2013-04-29 <mwhudson> bigjools: hello yet again <mwhudson> bigjools: do you know why juju might thing that maas nodes have a public-address like "calxeda01-18-00.localdomain"? <mwhudson> the .localdomain doesn't work in our set up <bigjools> mwhudson: because you probably left the default setting on the cluster name <bigjools> you have to de-enlist everything, rename the cluster and start again <mwhudson> oh yay! <mwhudson> where do i rename it? <bigjools> you might get away with just releasing nodes <bigjools> but you'd have to edit all the nodes' hostnames too <bigjools> edit the cluster, there's a domain or name or something <mwhudson> the fqdn in the nodes' pages is what i want, no localdomain there <bigjools> should be blindingly obvious, I hope <bigjools> you need to edit the nodes then <mwhudson> and there is "Default domain for new nodes" on /settings/ but that's set to "local" <bigjools> right <bigjools> so just destroy-env and rename the nodes <mwhudson> afaics the node names are already correct though <bigjools> no need to add a domain IIRC <mwhudson> i don't understand what i would rename them too <bigjools> if I recall correctly (sorry this has always just worked for me), the nodes should have a name without a dot <bigjools> then it uses the cluster's name as a domain <mwhudson> hmm <mwhudson> this doesn't appear to be what is happening * mwhudson rummages through the source <mwhudson> hah, the cluster name is "Cluster 74184da7-7791-4a3b-a057-95d6a5b4bd60" <mwhudson> i don't think that's making an appearance <mwhudson> bigjools: is there a way of running a 'manage.py shell' sort of thing for maas? <bigjools> mwhudson: "maas shell" <bigjools> I'm interested in why it's gone a bit Pete Tong for you, since this stuff really does just work for me with no messing <mwhudson> >>> n.fqdn <mwhudson> u'calxeda01-17-00' <mwhudson> that's correct <mwhudson> can i see the serialized form of this node that's being sent to juju
{'channel': 'maas', 'month': 4}