#maas 2012-12-03 <bigjools> roaksoax: hi <bigjools> did you see these? https://bugs.launchpad.net/maas/+bug/1086160 <bigjools> https://bugs.launchpad.net/maas/+bug/1086162 <ubot5> Launchpad bug 1086160 in MAAS "IPMI Power command does not work" [Undecided,New] <ubot5> Launchpad bug 1086162 in MAAS "IPMI based power management default to IPMI 1.5 based authentication" [Undecided,New] <roaksoax> bigjools: howdy im in class will looknat the, when i get back home <bigjools> roaksoax: no worries <roaksoax> bigjools: though the first one seems invalid <bigjools> roaksoax: my thoughts too <bigjools> I'll ask <roaksoax> second one might be the case #maas 2012-12-04 <mreed> hello, I am working on a maas setup on 12.04 and having issues with adding a node. Currently it is stuck in the commissioning state <mreed> its not a clock issue afaik , we synced the hardware clocks on the maas server and the node <mreed> currently we already have one node that is installed, and did make it to the ready state <mreed> also it appears that cloud-init didn't run <matsubara> mreed, so you have one node in ready and another one stuck in commissioning? <mreed> matsurbara: mostly correct, we have already deployed juju on the other node, but yes it was ready at one point <mreed> and the other node is stuck in commissioning <matsubara> mreed, what error do you get in the node that's stuck in commissioning? can you copy/paste (or take a screenshot of) the output of the console there? <sam_one> matsubara, I'm w/ mreed in the same pickle - we're trying to get something from the console... <melmoth> sam_one, just in case, did you try comment 19 ? https://answers.launchpad.net/maas/+question/196791 #maas 2012-12-05 <Aram> so, I'm writing the maas provider for go-juju. I want a test maas environment to work with. there's a mass/vdenv script that seems to bootstrap such an environment. <Aram> Can I use the packaged maas with that script or do I have to use the source? Or do you suggest something else? <Aram> maas/vdenv/HOWTO actually <flacoste> Aram: i'm not sure the state of vdenv tbh, smoser might able to give you more info there <flacoste> Aram: you could also ask milner from the Landscape what they used for integration testing <smoser> Aram, vdenv is probably *close* to working,, but probably not completely. <Aram> so, what do you recommend I should be using? <smoser> well, http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-quantal.txt is what i was doing to test ephemeral images... <smoser> and we could/should get some solution for "all in one" with kvm like you're wanting and vdenv provided. <smoser> the thing missing from that 'test-quantal.txt' list is power control of instances <smoser> vdenv hooked power control up also. <smoser> Aram, the link above i was doing in a kvm instance (ie, nested virt) but also tested on hardware. <Aram> thanks. <smoser> Aram, i'm sorry i dont have a better answer. i'd really like to have something liek you're after. <smoser> but i dont have the time to fix right now. <smoser> what i'd like to see is vdenv with maas running either in an lxc container or "on the host" rather than in an instance. #maas 2012-12-06 <rvba> rbasak: I'm enlisting ARM nodes all right, but when I try to deploy something with juju on them, juju is never able to connect to them. <rbasak> rvba: do you have serial output on the ARM nodes? You should be able to get this with ipmitool or freeipmi <rvba> rbasak: I'm using the package in the dailyppa on precise. <rvba> rbasak: this is happening in the lab <smoser> rvba, ping. <smoser> i'm playing aroudn with some stuff, and i'd liek a general bucke where i could put some information on start <smoser> is there anything like that ? <smoser> right now i can post to the api key value pairs with the start reqeust, but only 'user_data' and 'series' are paid attention to. <smoser> i'd like for other stuff i post to get somehow attached ot the node (probably removed on 'release') <rvba> smoser: hey <smoser> the end goal would be for me to be able to get at those key/value pairs inside the templates <rvba> smoser: if you have a look at the api code for start (http://paste.ubuntu.com/1414975/), we pass the 'user_data' to the start_nodes method and the 'series' is attached to the node. I don't know what you're trying to achieve really but looks like you might want to create new data attached to a node. <smoser> i'd like a general bucket <smoser> rather than "user_keys" or something. that everything got shoved into <smoser> in my installer templates, i can then read stuff from there <smoser> the specific motivation would be to pass something like: <smoser> installer=fast_pass <smoser> or <smoser> installer=d-i <smoser> that specific thing might make sense to have maas know about, but there are surely lots of other things that maas can just shuffle through. <rvba> One solution would be to create a new JSONField on the node with a meaningful name (:)) and use that to store your stuff. <rvba> This field would contain a json object that you could exploit in the installed templates. <rvba> (you would have to make it available to the templates of course) <rvba> smoser: maybe a JSONField is overkill if you just want to have one string to store installer parameters that can be stored as one line of text. <smoser> json is just text. <smoser> binary blob is most "I dont care" <smoser> second is text that "I dont care" <smoser> and if i'm suggesting that maas not care, then i'd suggest it really not care. <smoser> (ie, not insist on json) <smoser> rvba, i dont *hvae* to make it avaliable in the templates explicitly. as I can execute arbitrary python code there. <melmoth> is there a way in Maas to have several different preseed file used when a machine is being deployed ? <melmoth> like, on some box creating a new partition on the drive (so we can use them to deploy a swift storage or nova-volumes charms) ? <melmoth> (talking about maas on 12.04 btw) <smoser> melmoth, why would you not do that via user-data ? <smoser> what would be the value of doing it in the installer ? <smoser> you *can* accomplish this (even in 12.04 most likely) by having the template execute whatever python code you want and call out to another service even more data). <melmoth> i have no idea about the user-data thing. <smoser> ? <smoser> when you deploy a node in maas, it takes user-data ( just like on ec2/openstack ) <melmoth> i understand user-data for vm, but for bare metal, once lcoud init runs , the machine is alreadt installed, so you cannot shrink / can you ? <smoser> and cloud-init acts on that user-data. <smoser> well, you can shrink filesystems, yes. <smoser> but generally having the installer not take all for / if you wanted to use less makes more sense here. <melmoth> but only for some machine. <Aram> hi, I need a little hint. My maas controller has two ethernet interfaces. I want to use maas-dhcp and maas-dns. how do I tell maas-dhcp only to use eth1? I don't need a full answer, just a manual page name. <Aram> hmm... /etc/dhcp/dhcpd.conf does not get created by maas-dhcp. I was under the impression maas generates this files, do I need to create if by hand? <Aram> I solved the eth1 problem, btw <melmoth> any idea why bootstraping fail ? http://pastebin.com/gF72WSzq summary: The requested URL /MAAS/api/1.0/tags/ was not found on this server. <Aram> I guess I could use maas-provision generate-dhcp-config to generate it, but what omapi key to use? <matsubara> Aram, if you configure the controller through the web UI you'll be able to choose which interface is running the dhcp server <matsubara> Aram, or you can use the maas-cli <Aram> matsubara: thanks. found it. I feel stupid now. I didn't think of using the davidhull@example.net. <Aram> dhcpd seems to work now, but it can't find the tftp server <Aram> do I need to manually enable that as well? <matsubara> Aram, nope, the dhcpd.conf file is in /etc/maas/ can you paste that? the next_server parameter there is where the nodes will look for the tftp server <Aram> ah, yes, the next server is wrong. it's on a different network interface <matsubara> so, once you install maas, if you need to run dpkg-reconfigure maas to set the proper address for the pxe interface <Aram> hmm... dpkg-reconfigure mass doesn't do anything <Aram> maas <Aram> exists with status 0 <Aram> no output <Aram> same with -p low <Aram> ok, it was maas-region-controller, not maas, but dhcpd.conf is still wrong. <Aram> well, when running dpkg-reconfigure maas-region-controller, I did get an error. <Aram> this is the error <Aram> http://paste.ubuntu.com/1415395/ <Aram> don't know if the error is fatal or not, but it does rememer what I've set. <Aram> but dhcpd.conf has the old name <Aram> also the dns is wrong in dhcpd.conf, not only next-server <Aram> this is my dhcpd.conf: http://paste.ubuntu.com/1415399/ <Aram> matsubara: any idea about that error ^ ^ <matsubara> Aram, you can change that file manually and run sudo service maas-dhcp restart <matsubara> and check if the node will boot properly <Aram> matsubara: I did that, am I correct in assuming my changed won't be overwritten? anyway, now it finds the TFTP server but it stops at 'Trying to load: pxelinux.cfg/default' <Aram> s/changed/changes/ <Aram> Unable to locate configuration file <matsubara> Aram, did you run maas-import-pxe-files? <Aram> yes. <Aram> but in /var/lib/maas/tftp/amd64/generic there's only precise <Aram> and I set quantal in the web ui afterwards <matsubara> maybe it failed to download the quantal images? <Aram> it only tries to download precise <Aram> ran it again <Aram> precise node seems to boot via pxe, whohoo <Aram> but I'd like quantas as well <Aram> quantal <Aram> hmm, the precise node didn't auto-enlist <Aram> yep, nodes boot alright but with no auto enlistment <Aram> am I doing something wrong? <Aram> yes they do <Aram> it just took some time <Aram> I see two nodes <Aram> so now only the quantal problem remains <Aram> why does it take so long for new nodes to appear in the maas interface? #maas 2012-12-07 <Aram> can maas nodes have multiple nics. one for admin and pxe booting, and one for the rest of the world? the internet says some people have problems in this configuration. #maas 2012-12-09 <Aram> hi, so, the virsh option for power type doesn't really work ATM, right? #maas 2012-12-10 <Aram> how did this happen? <Aram> ubuntu@10-10-10-105:~$ hostname -f <Aram> 10-10-10-105.cluster0.maas0 <Aram> ubuntu@10-10-10-105:~$ ifconfig eth0 | grep inet | grep Bcast <Aram> inet addr:6585208393 Bcast:6585208393 Mask:6585208393 <Aram> <Aram> DNS and DHCP are managed by maas. <Aram> because of this, Juju doesn't work, as the hostnames are all mixed up. <rbasak> Aram: could you have a second instance of 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,Incomplete] https://launchpad.net/bugs/1069570 <rbasak> We never got to the bottom of that. Nobody else could reproduce it. <Aram> that seems to be the bug, yes. #maas 2012-12-11 <roaksoax> bigjools: howdy!! so wanted to let you lnow that im on holidays and will take care of the ipmi and fence_cdu next week <bigjools> roaksoax: hi <bigjools> are you on holiday this week? <roaksoax> yep <bigjools> ah ok <bigjools> what is the status of the apparmor change? <bigjools> and yui/raphael for precise <roaksoax> bigjools: still ib SRU queue <bigjools> and bug 1081660 :) <ubot5> Launchpad bug 1081660 in maas-enlist (Ubuntu) "If maas-enlist fails to reach a DNS server, the node will be named ";; connection timed out; no servers could be reached"" [Critical,Triaged] https://launchpad.net/bugs/1081660 <bigjools> did any of you get anywhere with the rejected django sru? <roaksoax> bigjools: the queue has veen processed slowly and django wad rejected so we need to take a dofferent approach <roaksoax> but will take care of aall that next week <bigjools> ok cheers <bigjools> flacoste: --^ <roaksoax> i will dedocate most of next week for maas so whatever you need me tontake care of just assign it to me * bigjools assigns the world to roaksoax <jtv> Anyone up for a review? https://code.launchpad.net/~jtv/maas/bug-1086239/+merge/139172 <Aram> rbasak: is there anything I can do to help you fix that bug? I'm writing the go-juju maas provider and it's critical I have this working. <Aram> bug 1069570 that is <ubot5> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Incomplete] https://launchpad.net/bugs/1069570 <rbasak> Aram: looking <rbasak> Aram: can you reliably reproduce it from scratch, starting from a node that is not enlisted to maas at all? <Aram> rbasak: yes, 100% reproductible. <rbasak> Aram: if so, then I'd like to see a tcpdump of all dhcp traffic taken on the dhcp server, together with the dhcp log and timings of when enlistment/commissioning/deployment took place <rbasak> Aram: something like "sudo tcpdump -nieth0 -w/tmp/dump.pcap -s0 arp or icmp or port 67 or port 68" please <Aram> ok. <rbasak> Aram: we're really not sure what is going on, but hopefully that will make the situation clearer. Assuming that you have the same bug. <Aram> seems to be the same thing. <rbasak> (also I'd like all ICMP traffic as well as DHCP traffic - that's already included in the command I just pasted) #maas 2012-12-12 <roaksoax> rvba: howdy. couldnyou guys please use this workflow forbthe prexise packaging branch : use quantal latest and apply precose dofferences on top and commit to precise branch <roaksoax> otherwise packaging will diverge and will become a PITA <roaksoax> Thebprecise branch is simplynthe quantal branch plusbthebchanges that are exclusive for precise <roaksoax> jtv: ^^ <rvba> roaksoax: hi. I'm note sure how easy it is but if it's doable, then it would simplify things indeed. I'll relay the message to Julian (he is the one who's worked the most of the packaging branches). <roaksoax> rvba: i created the precise branch thats how i have been working and thats how i yold julian thenprocess should be <roaksoax> rvba: otherwise you have divergebt branches with divergent changelogs <roaksoax> and im nit gonna sru like thayhe sru needs to get uplisded to raring <roaksoax> and from there sru to quantal and precise <roaksoax> quantal will have the same as rarinh and ptecise will have precise particulsr fixes on top <roaksoax> which are those relating to upstart and stuff <rvba> roaksoax: basically we've done all the changes in trunk, then backported the changes to the quantal and then to the precise. so they haven't diverged. <rvba> the quantal branch* <roaksoax> ok i will get things straught when i get back from hollidays <roaksoax> note that sru packages should be the same plus release changesnon top <roaksoax> thats how i will upload regardless of whats in thebbranches anyway <smoser> jtv, i think there is a bug i pointed out at https://code.launchpad.net/~jtv/maas/q-pkg-bug-1086239/+merge/139388 #maas 2012-12-13 <jtv> roaksoax, smoser: hi there... do you happen to know a good example, by any chance, of how to make an authenticated http (GET) request to the metadata server from the commissioning script? I know we have the python code in there, but are the credentials in a format that we can easily put to use in wget? <smoser> jtv, well, i dont know how easy or difficult wget and oauth would be. <smoser> is this as a one time thing or are you looking for general solution? <smoser> from an ephemeral instance, cloud-init's MAAS datasource can be run from the command line. <jtv> smoser: I'm looking to have the commissioning script make one authenticated GET request to the metadata service. No general solution needed, really. <smoser> i think the MAAS datasource can possibly do what you want <smoser> jtv, <smoser> python /usr/share/pyshared/cloudinit/sources/DataSourceMAAS.py <smoser> the argument to '--config' is a file in /etc/cloud/cloud.cfg.d/*cmdl* <smoser> and inside that file is the url you need also <jtv> smoser: I guess that's in the cloud-init source tree? <smoser> if you're booted into an ephemeral image, its ther for you. <jtv> And I guess I just wrap it in some python to invoke it? <smoser> i dont know why wrap in python <jtv> Well it's not an executable, is it? <jtv> Or is it? There's no hashbang... <smoser> oh. just run it with python <smoser> it has a main <jtv> I see. Sounds perfect! <smoser> jtv, http://paste.ubuntu.com/1429760/ <smoser> I've been wanting to write that for a while, so there it is. <smoser> maybe i'll send it to maas-devel <jtv> smoser: thanks. I hope I'll be able to look into it tomorrow. (Unwell at the moment, so we'll have to see how it develops) <smoser> jtv, but if you're looking for a way to make 'GET' requests in the ephemeral image, then the thing we want to get to is having a client in there that can easily do that (ie, add 'GET' support to maas-signal). <jtv> smoser: I guess you mean extracting some shared functionality. That probably makes sense. Wouldn't necessarily be something you'd still want to call maas-signal though. <freed0> anyone here deployed larger 20+ MAAS systems locally and not in the 'cloud'? <rbasak> Aram: hey, any joy with the DHCP/IP issue? <rbasak> Aram: I've just been reminded of bug 1064291, which might be relevant to the design of the go-juju maas provider <ubot5> Launchpad bug 1064291 in Release Notes for Ubuntu "Default constraints make no sense on MAAS" [Undecided,New] https://launchpad.net/bugs/1064291 #maas 2012-12-14 <ehw> rvba: ping <rvba> ehw: pong <ehw> rvba: hey there; would you happen to know which PPA build of MAAS is linked to the upcoming SRU? <rvba> ehw: roaksoax will probably rebuild the packages but the packages in the testing ppa (https://launchpad.net/~maas-maintainers/+archive/testing) are the ones you are looking for. <ehw> rvba: ok, thanks, having a look <ehw> rvba: hmm... so apt-get upgrade doesn't upgrade maas; dist-upgrade does upgrade maas, but blows away the database <rvba> ehw: do you have a stacktrace I could take a look at? <ehw> rvba: it doesn't give a stacktrace <ehw> rvba: going to my maas server now shows me "No admin user has been created yet" <ehw> rvba: apparently, the maas package removes the old one, then installs itself anew <rvba> ehw: weird, the db should have been upgraded in-place. I guess you're doing this on precise right? (because we're SRU'ing on precise and on quantal) <ehw> rvba: it's on precise <ehw> rvba: basically, just a fresh install of maas from main, setup a couple of nodes, then add in the PPA <ehw> rvba: apt-get update && apt-get upgrade doesn't offer an update of maas* (python-django does) <ehw> rvba: you need to do a apt-get dist-upgrade to upgrade maas <ehw> rvba: which involves purging the existing version of maas including the db <rvba> ehw: let me try that on a precise instance and get back to you. <ehw> rvba: alright, thanks <rvba> ehw: ok, so 'apt-get upgrade' did not work because some of the new dependencies are in a ppa (this will go away when the packages will be properly SRU'ed). if you explicitly run 'sudo apt-get install maas python-django-maas' the db will be upgraded (instead of simply wiped away as with 'dist-upgrade'). <ehw> rvba: ok, interesting thanks <rvba> np <ehw> rvba: did you just test this on your side? I'm getting bitten by pad.lv/1081391 <ehw> rvba: although the upgrade didn't blow away my db, it does fail because of that missing GenericIPAddressField <rvba> ehw: you need python-django version 1.3.1-4ubuntu1.5~ppa1 it will be SRU'ed but for now it's in the testing ppa too. <ehw> rvba: why wouldn't that be installed as a dependency during the maas upgrade? <rvba> ehw: does not look like we force the version (which is bad). <rvba> ehw: you can force the install of the right version with 'apt-get install python-django' <ehw> rvba: I guess that dependency is going to need to be fixed, though, before customers get hold of it :-/ <rvba> ehw: indeed. But as you can see from the comments on this bug you pointed out to me, the SRU of python-django is not yet done. If we can't do it, we've got an alternate solution. That's why we're waiting to change the dependency. <rvba> ehw: I'll file a bug about that just to make sure we do not lose track of that problem. <ehw> rvba: cool, thanks! would you mind subscribing me to that when you get it opened? <ehw> (my lp is eric-canonical) <rvba> ehw: sure <rvba> roaksoax: Hi, would you mind having a look at bug 1090334 when you'll be back? It's for the precise SRU packaging branch. <ubot5> Launchpad bug 1090334 in maas (Ubuntu) "MAAS (in precise) requires django >= 1.3.1-4ubuntu1.5" [Undecided,New] https://launchpad.net/bugs/1090334 #maas 2012-12-17 <joe_Vitel> Hello. I'm trying to set up a test MAAS/Juju/openstack environment. I've got every node running, and according to juju status they are all setup corrently as far as I can tell. The big issue is that I cannot log into the Openstack Dashboard using admin and the admin-password provided in the keystone config file when deploying keystone. Any ideas? <rnbrady> hey peeps <rnbrady> I'm deploying openstack via juju on maas <rnbrady> Wondering how few servers I can get away with #maas 2012-12-18 <roaksoax> rvba: howdy <roaksoax> rvba: so what's the status of the SRU stuff ? <roaksoax> rvba: is it ready for upload? <rvba> roaksoax: Hi Andres. <rvba> roaksoax: upstream is good. But there is bug 1090334 for the packaging. <ubot5> bug 1090334 in maas (Ubuntu) "MAAS (in precise) requires django >= 1.3.1-4ubuntu1.5" [High,Confirmed] https://launchpad.net/bugs/1090334 <roaksoax> rvba: right, there's an SRU for that <rvba> roaksoax: I thought the SRU was for the python-django package. This is for updating the dependencies of maas with the right version of python-django. <roaksoax> rvba: nope, there's SRU bugs with the stuff we require, such as GenericIPAddressField etc etc <rvba> roaksoax: right now, if you already have python-django and maas installed on precise and upgrade to the the SRU maas, the upgrade fails. <roaksoax> rvba: https://bugs.launchpad.net/ubuntu/precise/+source/python-django/+bug/1081392 <rvba> roaksoax: ok, so maybe you should close this bug with a pointer to the right SRU bug. <ubot5> Launchpad bug 1081392 in python-django (Ubuntu Precise) "[SRU] Include upstream fix for bug 15496" [High,New] <rvba> roaksoax: ok, but shouldn't we also update the dependencies needed by maas? <rvba> Even if the new version of python-django gets released, it will still be possible to break maas unless we force the version of python-django right? <roaksoax> rvba: in packaging? no not really <roaksoax> it will be released in -updates and as part of upgrading, it will also upgrade dependencies frist <rvba> Is the behaviour of apt-get different when the package is in a ppa then? <rvba> Because it's easy to break maas right now: <rvba> - on precise, install maas (the one which was released with precise) <rvba> - add the testing ppa <roaksoax> rvba: yes, the one in PPA has a higher version from the one in arcdhives, and that's why you are able to use that instead <rvba> - apt-get install maas => upgrade broken because python-django was not upgrade (although a new version is available in the ppa) <roaksoax> maybe there's a newer version on the archives now <rvba> All I'm saying is that if there is an old version already installed, upgrading maas does not automatically upgrade python-django, and this results in a broken maas. <roaksoax> rvba: right, so a sudo apt-get upgrade or (dist-upgrade) will upgrade dependencies first <roaksoax> hence, upgrading python-django <roaksoax> rvba: in any case, we can always add a hard requirement <roaksoax> for that particular version <roaksoax> but we shouldn'y really need on <roaksoax> lets just wait till django hits archives <rvba> Ok, you're the expert here. It's just weird to open up the door for breakages. <roaksoax> right <roaksoax> i agree, lets just wait for the dependencies to be released, then we take care of the final upgrade testing <rvba> roaksoax: same thing with isc-dhcp-server <roaksoax> yep <rvba> (there is no bug for that one) <roaksoax> rvba: there is <rvba> roaksoax: if you're going to update the packaging (to add hard requirements), that's probably something you can do now. After all, the right versions are in the ppa that we use for testing. <roaksoax> rvba: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-maas-next-steps <rvba> roaksoax: I suppose somewhere in that page there is the mention of the need to add a hard requirement for maas with the right version of isc-dhcp-server ;) <roaksoax> rvba: sure i don't have any objections on adding them <roaksoax> rvba: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1049177 <ubot5> Launchpad bug 1049177 in maas (Ubuntu Precise) "isc-dhcp-server apparmor profile should have include ".d" " [Undecided,New] <rvba> roaksoax: Again, I leave these changes up to you. But one user managed to break its maas installation while testing the package the other day. <roaksoax> rvba: TBH i have no objections on making those changes <roaksoax> since it shouldn't break anything <roaksoax> rvba: btw.. i'm gonna do this. 1. upload quantal changes to raring <roaksoax> rvba: 2. bug someone over getting the SRU's processed <roaksoax> 3. check if there's something else to upload to raring again.. and then SRU back to both quantal and precise <rvba> roaksoax: I think the most important right now is to get the SRU uploaded. <rvba> roaksoax: we have a weird problem with raring right now. <rvba> roaksoax: when we package trunk for quantal, all is fine, the integration tests pass. When we package the same thing for raring, some of the tests fail. <roaksoax> rvba: the quantal version we have *has* to be uploaded to raring in order for us to SRU <rvba> (but the package installs ok) <roaksoax> weird <rvba> roaksoax: ok then <roaksoax> rvba: so the thing is that since we are backporting a new upstream release <roaksoax> the release hsa to be released in ubuntu+1 <rvba> roaksoax: I see <roaksoax> then backported(SRU) back to previous releases <roaksoax> so we *have* to upload it to raring <roaksoax> rvba: are there other changes we'd like to add to the stabilization branch? <rvba> roaksoax: there is one fix that we did not backport. It's a very minor fix that fixes a tiny problem on the dev instance only (r 1279). It does not affect the prod davidhull@example.net. It is worth backporting that? <roaksoax> rvba: not really <rvba> roaksoax: ok, then we're good. <roaksoax> rvba: ok, I'd like to squeeze in the fence_cud power method for the QA team to use <rvba> roaksoax: as I said on the ML yesterday, the packages I've uploaded to the testing ppa have been tested (both using the integration test suite and manually) <roaksoax> I'll work on it now though <roaksoax> rvba: great! <jtv> smoser: hi scott â question: do I remember correctly that user_data as retrieved from the metadata API really isn't supposed to be more than 16KB? <smoser> in ec2 it is 16kb binary blob. <smoser> but that isnt any sort of requirement for maas <jtv> Ah OK <jtv> So then I wasted my time explaining in my MP why "kilobyte vs kibibyte" is missing the point entirely. <smoser> jtv, you probably do want some limit though. <jtv> Well... we no longer need it user-editable AFAICS; we have custom commissioning scripts now. <smoser> as the user storing that in the database could gro quite large. <smoser> user-data is user-editable <jtv> And it looks to me as if some Â¾ of the script could be moved into that mechanism, cutting the main thing down to 5KB. <smoser> that *is* a requirement. <jtv> User-data, or the commissioning script which we send to a commissioning node as user-data? <smoser> the former. <jtv> Ah OK <jtv> I've been neck-deep in the commissioning script today, so I'm rather conflating the two now. <jtv> The main commissioning script AFAICS no longer needs to be editable because there's a way for admins to inject their own code there. <jtv> And the IPMI code & configs look like prime candidates for moving into that mechanism. The main commissioning script is far too large and unwieldy, and if we're going to download a tarball from the server anyway, we might as well put that code there. <roaksoax> jtv: i already have plans to move the IPMI stuff out of commissioning and enlisting <roaksoax> jtv: by moving them into their own scripts and used by commissioning/enlistment user dat <jtv> roaksoax: great â we have a mechanism that can accommodate this easily <roaksoax> jtv: yeah, but we were thinking on putting these in a separate package <roaksoax> jtv: because maas-enlist is a utility being used to enlist machines manually, and detecting ipmi could be used as well <roaksoax> jtv: not only for commissioning/enlistment <jtv> roaksoax: being able to unit-test the code separately, or even to make manual tests easier, would be a big advantage. <roaksoax> jtv: that's the plan <jtv> rvba: did you find the problem with the packaging? I guess only user_data.template is not being installed, since the rest of the files are python? <rvba> jtv: I don't know. The html templates in ./src/maasserver/templates are shipped all right. <jtv> roaksoax, do you know what it would take to make the packaging install this new file, src/metadataserver/commissioning/user_data.template alongside the surrounding python files? <roaksoax> jtv: yes, setup.py <roaksoax> jtv: let check <roaksoax> jtv: wasn't there a file in the source that listed what to include and what to exclude? <rvba> roaksoax: probably MANIFEST.in <roaksoax> rvba: ah yes thanks!! <roaksoax> jtv: yeah add something to fence_cdu -a 6585208393 -n Panda_a42 -l ubuntu -p ubuntu -o status <jtv> \o/ <jtv> roaksoax: that last one was meant for someone else I guess? <roaksoax> jtv: yeah :) <jtv> Phew. I thought I'd gone mad. <jtv> rvba: are you making that change or do you want me to? <rvba> jtv: fix is coming up <jtv> Great <jtv> Because I'm almost asleep :) <roaksoax> jtv: so you could add something like: http://paste.ubuntu.com/1447968/ <roaksoax> or: http://paste.ubuntu.com/1447971/ <roaksoax> can't remember what wil work <rvba> jtv: https://code.launchpad.net/~rvb/maas/missing-files/+merge/140499 <jtv> roaksoax: rvba did something like that in the above MP ^ <jtv> Reviewed. <roaksoax> jtv: we no longer ship a file etc/maas/commissioning-user-data? <jtv> Nope. <jtv> It's generated on the fly now. <roaksoax> jtv: ack <jtv> roaksoax: most of the file is now in src/metadataserver/user_data.template, but some embedded python scripts are now separate files in src/metadataserver/snippets. <jtv> This means we can run our lint checkers and import formatters on those, and who knows, maybe even unit- test them. <roaksoax> jtv: cool, one thing though, where can I add custom scripts <jtv> roaksoax: custom scripts, as provided by the admins, are now stored in the database. Plus MAAS itself can also add in custom scripts that travel through the same mechanism, but aren't editable. <jtv> Currently there's only one such script, the tiny lshw one, so it's kept in-line in a name/content dict. I imagine we'll want to replace this with a directory at some point, and the separate ipmi-configs package could install files into that directory. <roaksoax> jtv: ack! <roaksoax> rvba: if you have the time, could you take a look at: https://code.launchpad.net/~andreserl/maas/lp1073462_fence_cdu_power_type/+merge/140504 <roaksoax> please? <roaksoax> thanks!! <rvba> roaksoax: I've got to step out now but I'll have a look at it tomorrow morning first thing unless jtv grabs it first. <jtv> rvba: it's Wednesday today, but not yet working hours. :) #maas 2012-12-20 <roaksoax> rvba: howdy!1 is the buildout for stabiliuzation branch broken? <rvba> allenap: can you please take care of this ^ while I try to get that fix inâ¦ <allenap> roaksoax: Is that 12.04-stabilization? <allenap> roaksoax: Sorry, wrong name. Which branch is that? <roaksoax> allenap: yes, that one: http://pastebin.ubuntu.com/1452360/ <roaksoax> bzr+ssh://bazaar.launchpad.net/+branch/maas/1.2/ <allenap> roaksoax: It works here, but I'm running on Quantal. Can you try `make distclean && make`? <roaksoax> me trying * roaksoax trying <roaksoax> allenap: same thing <roaksoax> allenap: i'm trying to test with this though: https://code.launchpad.net/~andreserl/maas/backport_rev1410_to_stabilization/+merge/140907 <roaksoax> but i don't think that's evern related <allenap> roaksoax: One more thing before I get a precise machine up: can you try `make install-dependencies`. <roaksoax> allenap: that branch should also work on quantal though :) <allenap> roaksoax: Your branch builds fine here too. It looks like it's failing when fetching something from PyPI, or a site it has found via PyPI. <allenap> roaksoax: I'm trying again here, building with a cleaned-out buildout cache. <allenap> roaksoax: Mmm, it works. I can't reproduce the issue you're seeing. Would it help if I just ran the tests for you? <roaksoax> allenap: yes please <roaksoax> allenap: yeah so something must be messed up here <allenap> roaksoax: It passes. There are some rabbit related failures, but they're in trunk too, so it's fine. <allenap> And the rabbit failures are probably something weird here. <roaksoax> weird indeed <roaksoax> allenap: since you tested the branch, could you please review/approve https://code.launchpad.net/~andreserl/maas/backport_rev1410_to_stabilization/+merge/140907 <rvba> roaksoax: I'll have a look <roaksoax> rvba: cool thanks <rvba> roaksoax: approved. Maybe you should file a bug and link it to the stabilization milestone. <rvba> roaksoax: just so we can have a accurate list of what's been committed to 1.2 <rvba> roaksoax: oh, there is a bug already :) <roaksoax> yeah :) <rvba> roaksoax: I got carried away and targeted bug 1086162 to 1.2. I hope I did good. <ubot5> bug 1086162 in maas (Ubuntu) "IPMI based power management default to IPMI 1.5 based authentication" [High,Triaged] https://launchpad.net/bugs/1086162 <roaksoax> rvba: yeah that's fine. I'm waiting for the merge on fence_cdu to push the fix for that too <roaksoax> rvba: is maas lander not working on maas/1.2? <rvba> roaksoax: it is working, I just landed a branch minutes ago <roaksoax> rvba: ah! so it is taking more than usual nowadays then <rvba> roaksoax: it is just that my branch was landed first <roaksoax> :) <roaksoax> rvba: if you could review these two, would be very much appreciated: https://code.launchpad.net/~andreserl/maas/maas_ipmi_lan2.0/+merge/140922 <roaksoax> https://code.launchpad.net/~andreserl/maas/maas_ipmi_lan2_stabilization/+merge/140935 <rvba> roaksoax: sure <roaksoax> thanks ! #maas 2012-12-21 <rvba> roaksoax: hello there. <rvba> roaksoax: ping <roaksoax> rvba arghhh i tested this manually in a lab and in my machones and worked as expected <roaksoax> rvba: were you able tobtrst this manually? <rvba> roaksoax: no, the tests fail. I suspect MAAS cannot power the nodes anymore. <rvba> roaksoax: when I issue ipmipower commands with --driver-type=LAN_2_0, they fail. <roaksoax> ipmipower Â --driver-type=LAN_2_0 Â -h ip -u pw -p user --stat <roaksoax> I get: "ip: BMC error" <roaksoax> ip should be replaced with a real ip <rvba> Yes, I know :) <roaksoax> ah ok <roaksoax> so 2.0 ahould also include 1.o authentication <roaksoax> which is what its strange to me <roaksoax> abd again i trsted this in 2 dofferent set of machines with no error wjatsoever <roaksoax> rvba: since the tests are broken... lets roll this change back and re-address it after thebhollidays <rvba> roaksoax: sounds good to me. <rvba> roaksoax: the fix could look like this: http://paste.ubuntu.com/1454885/ <roaksoax> rvba: cool i like it and we should default tobsomething for enlistment unless the c tells us that info <rvba> roaksoax: let's do that after the holiday. I'm going to do a test run in the lab (with the --driver-type=... manually removed) just to be 100% sure it's the problem, and if it's the case I'll roll-back the changes and re-open the bugs. <roaksoax> agreed <rvba> roaksoax: confirmed, I'm rolling back the changes. <roaksoax> rvba: cool thanks <HelpMeMAAS> Anyone here.. <HelpMeMAAS> I'm having problem with MAAS on 12.04 <HelpMeMAAS> says that mass-cli can't be found.. <HelpMeMAAS> and PXE boot ends in a kernel panic <HelpMeMAAS> Would I just be best off going to 12.10? #maas 2013-12-01 <Maldito> hello <Maldito> i have some newie question about maas and its function <Maldito> english isnt my first languaje <Maldito> I have 6 boxes with different specs <Maldito> i need to mount a high performance http server with (even more important) mysql <Maldito> can i create a cluster por a better performance? <Maldito> not just avalability (dispoinibilidad) #maas 2013-12-02 <rvba> roaksoax: Hiâ¦ it's not really urgent but could you have a look at this issue when you have time: https://bugs.launchpad.net/ubuntu/+source/python-django-piston/+bug/1256957 ? <ubot5> Ubuntu bug 1256957 in python-django-piston (Ubuntu) "AttributeError: 'WSGIRequest' object has no attribute 'raw_post_data' (Django 1.6 incompatibility)" [Undecided,New] <allenap> Do we have a merge robot for 1.4? <allenap> rvba: ^ do you know? <rvba> I don't know. matsubara ^, can you check Jenkins? <matsubara> allenap, rvba: I thought you guys were taking care of that since the charmification of the landers. <rvba> I'm not sure if we moved all the landers. Trunk has been moved, but I suspect it's the only one. <allenap> matsubara: Yeah, trunk for maas and maas-test only. I can set up the others if Jenkins no longer does it. <rvba> allenap: just try to approve you branch and see if there is a landerâ¦ if not, then I guess it's worth starting one on canonistack. <allenap> rvba: Yeah, no lander then :) <rvba> your* branch <allenap> rvba, matsubara: Do you know where bigjoolsâ tarmac charm is? <rvba> allenap: Isn't that documented in the gdoc he shared with a a while ago? <matsubara> allenap, https://code.launchpad.net/~julian-edwards/+junk/maas-tarmac-charm <allenap> rvba: Doesnât seem to be. <allenap> matsubara: Thanks. <rvba> allenap: any reason why we don't land https://code.launchpad.net/~tycho-s/maas/add-missing-node-fields/+merge/196946 ? <allenap> rvba: None. Maybe tych0 doesnât know that we normally leave it up to the author to choose when to land? <rvba> Okay. Let's give him a chance to do so when he sees this ping. <roaksoax> rvba: you want me to fix that in trusty? <rvba> roaksoax: yeah, that would be nice. <roaksoax> rvba: do we have django 1.6 in trusty? <rvba> roaksoax: It's in -proposed right now. <roaksoax> its been released <roaksoax> ok ill take care of it <rvba> roaksoax: Thanks. <tych0> hey, yeah, i was wondering about that <tych0> the launchpad status is listed as not approved or something <tych0> just didn't know if allenap had anything else <tych0> (also, last two days were a hoilday for US folks, so that probably has something to do with it too :-) <allenap> tych0: Nope, land away :) <tych0> oke doke <marcoceppi> Do I need to run my vmaas nodes on the same machines as maas master? <smoser> marcoceppi, i dont htink you ahve to <smoser> but you have to have the virsh stuff set up to access the other system <marcoceppi> smoser: hum, maybe I'll just have the maas master and virsh on the same machien. I honestly can't find any documention on vmaas in the maas docs <smoser> marcoceppi, there isnt <marcoceppi> \o/ * marcoceppi smells a blog post <smoser> i think that stokachu has done some of that ? <roaksoax> smoser: does this make sense to you? http://paste.ubuntu.com/6511498/ -> the creation of a package maas-region-controller-min which doesn't install the DB nor rabbitmq-server? <roaksoax> smoser: so it is used for the charm? <smoser> roaksoax, maas package depends on maas-region-controller-min ? <smoser> or is there a separate 'maas-region-controller' that it depends on <roaksoax> smoser: there will be maas-region-controller-min that will install everything, but postgresql and rabbitmq. maas-region-controller will depend on maas-region-controller-min + install/configure postgresql/rabbitmq (so upgrades don't break) <roaksoax> smoser: maas will continue to depend on maas-region-controller, which will install maas-region-controller-min <smoser> that seems to make sense to me <roaksoax> smoser: cool then! I'll work towards that then! Thanks! <bigjools> marcoceppi: there are docs written just not published yet <bigjools> I'll try and get the web site updated now <joseantoniordlmc> Hello <joseantoniordlmc> Does anyone know, the minimum requirements to test MAAS <joseantoniordlmc> ?? <bigjools> requirements in what sense? <joseantoniordlmc> to install ubuntu server for cloud, specifically hardware <marcoceppi> bigjools: thanks, I've got two servers, one I hope to vmaas, the other I need for physical maas <bigjools> joseantoniordlmc: there's nothing specific set out in the docs, but you need a machine capable of running postgres, Apache and rabbitmq. I've run it in as little as 1Gb but 2Gb is ideal. CPU wise, anything will do. <joseantoniordlmc> thanks #maas 2013-12-03 <bigjools> allenap: I need your advice. <bigjools> my branch to run the dhcp probing in the cluster controller needs authbind to run and will blow up without it <allenap> bigjools: Is that a problem? <bigjools> allenap: well, I can add instructions that nobody will read :) <allenap> bigjools: I guess we can configure authbind in packaging, but dev is the problem here? <bigjools> allenap: yes, packaging is easy. dev needs someone to do the authbind trick as per pserv/dns etc * allenap can't remember how authbind works... <bigjools> it won';t break anything else, it'll just leave errors in the log <bigjools> look in HACKING.txt <bigjools> sudo touch /etc/authbind/byport/68 <bigjools> chmod +x on it <bigjools> then authbind <command> <allenap> bigjools: The DNS and TFTP services run kind-of-degraded in dev. Can the DHCP probe run that way too, unless someone has set up authbind? Degraded for the probe probably means not running. <bigjools> allenap: yeah it'll just traceback in the log, no harm done <bigjools> I like that - it reminds you to do the authbind <bigjools> maybe I should catch the error and put a decent message in <allenap> bigjools: We could preempt questions by asking in advance on askubuntu, and replying, assuming thatâs okay with the t&cs. <rvba> bigjools: +1 for putting a decent message, your future self will thank you :) <bigjools> heh <allenap> bigjools: But yes, traceback with a âread HACKING.txt now or go back to herding goatsâ message sounds good. <bigjools> done :) <rvba> allenap: up for a review? https://code.launchpad.net/~rvb/maas/death-to-get-uri/+merge/197550 <allenap> rvba: Sure. Iâve got to finish bigjoolsâ first, then Iâll davidhull@example.net. * allenap is grateful that he remembered the apostrophe. <bigjools> allenap: so am I #maas 2013-12-04 <bigjools> roaksoax: I am landing a change to the cluster worker that will require it to have bind privs on port 68. I use authbind in the development environment but how do you want to approach this in packaging? <roaksoax> bigjools: im not home now(from the cell) but can we discuss this later? <roaksoax> binding to 68 might cause problems with otjet services <roaksoax> smoser ^^ <roaksoax> other* <bigjools> roaksoax: it uses SO_REUSEADDR <bigjools> no problem discussing later <roaksoax> cool <roaksoax> ttyl <smoser> i'm on my way out. and i'd have to think about this. <roaksoax> bigjools: ok, so where's the branch, why is it needed, and what impliations do you think it will cause? <bigjools> roaksoax: it's to detect dhcp servers, it has to bind to source port 68. end of. <roaksoax> bigjools: right, so what will bind to it? <bigjools> roaksoax: the cluster worker <roaksoax> bigjools: what other servicces use port68? <bigjools> roaksoax: it's the dhcp client source port <roaksoax> bootpc 68/tcp # BOOTP client <roaksoax> bootpc 68/udp <bigjools> so I hope nothing <bigjools> but even if there is something it doesn't matter <bigjools> I have tested locally with dnsmasq running and it's fine <bigjools> so, how can you sort this out in packaging? <roaksoax> bigjools: "This packet identifies that a client is searching for an IP address. The packet uses UDP port 68 as it's source address for the client, since it does not have an IP address that refers back to the client." <bigjools> dude the branch has landed and it ain't gonna change <roaksoax> bigjools: i'd need more information that that really. It seems that it is the port used by a dhcp-server to discovery clients right? so what happens if you bind that port and DHCP is useless? <roaksoax> what happens if it create DHCP issues? <bigjools> no, it is not used by a dhcp server <bigjools> dhcp serves on port 67 <roaksoax> bigjools: udp 0 0 6585208393:68 6585208393:* 15106/dhclient <bigjools> that's the client <roaksoax> bigjools: so dhclient seems to bind to port 68 <bigjools> yes, they all do <bigjools> that's why the cluster worker does it <roaksoax> bigjools: right, but have you tested this on a client that uses dhclient to obtain IP address? <bigjools> think about this <roaksoax> bigjools: note that I'm not against using the part, I just want to understand the implications of doing so <bigjools> why would your machine, which is running a dhcp server, also be running a dhclient? <roaksoax> bigjools: because mymachine obtains a DHCP from a router <bigjools> you can't do that you'd be running two dhcp servers <roaksoax> bigjools: my machine does not have a static IP address and DHCP's from another DHCP server <bigjools> so unless you configure them not to cross, it's stupid :) <bigjools> anyway I have tested this and it works fine even if you have a dhcp client running already <bigjools> it uses SO_REUSEADDR <bigjools> the point of the feature is to help idiots from shooting themselves in the foot by running more than one dhcp server <roaksoax> bigjools: yeah I understand that, I just want to make sure doing so doesn't coonflict with other operations mof the OS <roaksoax> if this is tested and doesn't then cool <bigjools> it won't <roaksoax> if it does, then sucks <roaksoax> as i said <roaksoax> I just want to understand the implications of doing so to make sure nothing will break <roaksoax> anyway <bigjools> it is very careful to use a transaction ID on the probe packet <bigjools> so won't clash <roaksoax> send me what you need for the packaging to email <roaksoax> i'm off now <bigjools> good night roaksoax <roaksoax> night <roaksoax> bigjools: is this a new daemon or what? <bigjools> roaksoax: no <bigjools> part of celery <roaksoax> bigjools: so then I don't think we will need packaging changes then <roaksoax> if it is being run by maas-region-celery <bigjools> does it run as root? <bigjools> if not we need changes to set up authbind <roaksoax> bigjools: it runs as maas user/pass <roaksoax> user/group <roaksoax> exec /usr/sbin/maas-region-celeryd --logfile=/var/log/maas/celery-region.log --schedule=/var/lib/maas/celerybeat-region-schedule --user=maas --group=maas <bigjools> so needs to be exec authbind --deep /usr/sbin/maas-reg..... <bigjools> after setting up /etc/authbind/byport/68 <bigjools> or similar <roaksoax> bigjools: ok, please send me that over email, my eyes will explode soon -> ved <roaksoax> bed <bigjools> ok :) <jtv> bigjools: shall I update the daily PPA to include the DHCP-probing code? <bigjools> jtv: no it won't work yet, needs packaging changes <jtv> That's unfortunate because my dhcp-checking branch for maas-test requires it. <bigjools> jtv: well go ahead anyway it'll just traceback in the celery log <bigjools> jtv: hit rebuild on the recipe <jtv> Shouldn't I land an update to the changelog first? <bigjools> no, daily build will DTRT <bigjools> recipes are fkin awesome <jtv> But we already have a build from yesterday in there, and it uses an old revision of trunk... <bigjools> when you hit rebuild it will pull latest trunk <jtv> Ah! <jtv> That is nice. <jtv> I'm all motivated to go back to work on LP. :) <bigjools> lol <ticking> Say, does somebody know if MAAS supports non pxe hardware? e.g. mac pros <bigjools> ticking: sort of <bigjools> provided it can tftp to the right place it'll get boot resources <ticking> but the avahi boot image is unsuported right? <bigjools> yeah that's getting junked entirely in 14.04 <ticking> so there is no standard way of using tftp anymore? <bigjools> define standard <ticking> boot cd/stick, configure, connect, be happy ^^ <bigjools> normally the machine requests pxeconfig first, but other hardware like arm that doesn't pxe will request a specific tftp path <ticking> ah I see, so the hardware does the tftp <bigjools> tftp is nothing to do with avahi <bigjools> avahi was just a way for the installer cd to discover the maas server <bigjools> but in the real world nobody is going to go around sticking CDs in hundreds of racks <ticking> ah I see, the wiki is worded as if there was a way to load the boot image with the help of some provided base system <bigjools> the general idea is that machines will be discovered from the maas server using ipmi <bigjools> it'll then attempt to power them up using ipmi and they'll hunt for a dhcp server which directs a pxe boot <ticking> yeah, I have a ton of decent mac pros lying around, being able to configure them quickly and painlessly would be nice <ticking> but they only support wake on lan, no pxe no tftp boot <bigjools> WoL is nasty <bigjools> you have no way of powering off <ticking> for now I'm only concerned with at least booting them ^^ <bigjools> I can't remember offhand how to direct machines to tftp from the right place when not using pxe <ticking> Interestingly it seems that mac pros do indeed support tftp ^^ <ticking> so thanks for the pointer <bigjools> are they power? <bigjools> because maas doesn't know about power :) <jtv> PowerPC, that is. <ticking> hrhr no <ticking> intel <ticking> x64 <ticking_> lol, liiks like I <ticking_> looks like I killed my switch with the netboot ^^ <tom___> hi, what is the minimum # of nodes required to deploy a MAAS server? <jtv> Absolute minimum? One node, plus one server. <tom___> can the node be a VM? (Virtual Box VM) <jtv> I think it can, but MAAS won't create it for you. <tom___> I want to learn how to setup Openstack with Ubuntu, and don't have many machines. <tom___> I can create the VB VM, and add it to MAAS? <tom___> ok, I get it <jtv> I don't know if virtualbox can simulate a BMC though. <tom___> what is a BMC? <jtv> Baseboard management controller. It's what lets MAAS reboot a node remotely. <tom___> No, VB probably not support that <tom___> I have some old PC, is BMC a requirement for the hardware? <jtv> Effectively, yes. <jtv>
{'channel': 'maas', 'month': 12}