[00:01] i deploy a node, the bootloader gets an ip address fine and it netboots but the installer fails to DHCP [00:02] or rather, it doesn't think it's DHCPed successfully [00:02] but i can ping it so... [00:48] rraaaaaaaaararar [01:06] mwhudson: is your daughter at the keyboard again? [01:06] no, just a slightly hacked off daddy [01:46] bigjools: can you use maas-cli to release all nodes in one go? [01:46] mwhudson: I don't know off hand - I suspect not [01:46] ok [01:46] we're adding mass-action support in the next week or so [01:46] at least in the UI [01:48] well [01:48] given that there is no ui at all for releasing ... [01:50] you can parse json with awk, right? [01:50] * mwhudson does evil [01:51] ha [01:53] roaksoax: did you backport raphael and yui3 to precise, or did we have to keep them in-tree for 1.2? [01:53] * bigjools wonders about security updates ... [02:02] aaaaaaaaaaaar [02:02] bigjools: would you expect maas to support deploying raring to armhf yet? [02:03] i see raring has appeared in the distro options [02:03] but there's only precise and quantal in /var/lib/maas/ephemeral/ [02:04] mwhudson: I don't know, it depends on whether the ephemeral images support it and that's largely out of my hands [02:04] oh well [02:04] i guess having [02:04] RELEASES="precise quantal" [02:04] in /etc/maas/import_pxe_files ain't gonna help [02:05] bug 1115178 [02:05] bug 1115178 in MAAS trunk "Raring ephemeral info not available on https://maas.ubuntu.com/images/" [Critical,Fix released] https://launchpad.net/bugs/1115178 [02:05] http://maas.ubuntu.com/images/ephemeral/daily/raring/20130521/ [02:05] images are there [02:06] the RELEASES are set deliberately tight otherwise you wait ages for a download of stuff you might never use [02:06] * mwhudson chases bugs to https://bugs.launchpad.net/maas/+bug/1177932 [02:06] Launchpad bug 1177932 in MAAS "Unable to select which pxe files to download by both series and architecture." [High,Triaged] [02:06] yeah that one's on our list of things to fix this cycle [02:06] bigjools: they are speed with packaging [02:07] shipped* [02:08] roaksoax: yeah, because they are in the tree :) [02:09] roaksoax: but what's the plan for security updates? [02:09] bigjools: yeah so since they were removed on quabtal and i didn't wasn't to differ from that source then i had to put them in packaged as it was also recommended [02:10] bigjools: for yui? [02:11] roaksoax: well anything that's in-tree but not packaged in precise [02:11] will the security team be aware and responsive? [02:12] bigjools: evrything in 1.2 is in tree but the js files and i think python-tx-tftp [02:13] but we dont need to keep python-tx-tftp in tree anymore [02:13] roaksoax: yes exactly - if there is any change to the upstream js we need a plan to fix it in maas [02:15] bigjools: so yes if there's a security fix in yui or Raphael then it would need to be backported to raring quantal [02:15] and precise on the maas packaging [02:15] i think jdstrand is aware of us shipping the yui stuff there [02:15] roaksoax: will the maas-packaging be handled by the security team? [02:15] right [02:15] that's what I needed to know, thanks [02:16] bigjools: so the branches wont be touchrd [02:16] bigjools: the ones under ~maas-maintainers [02:16] the securitu team works against the ones on the release [02:17] so we are "upstream" for packaging [02:17] so whatevrr fix that need to be backported will be done via patches on thr ubuntu packaging [02:18] right [02:18] so say we fix something on 1.2, i will cherry pick and SRU as a patch in debian/patches [02:18] but we can include the same patch upstream [02:19] bigjools: yes so i think we should fix upstream, and from there sru [02:19] thats the normal procrss [02:19] cool [02:21] bigjools: btw i would like to have a catch up call to agree in these thinga and see where you guys need ne [02:21] me [02:22] roaksoax: sounds good [02:22] * bigjools heads out for lunch [13:33] roaksoax: that's right, none of the services are started. I can start them manually (sudo service maas-pserv start) but they are not started right after the package gets installed. [13:34] rvba: i installed saucy and then maas [13:34] and all of the success seem to be running just fine [13:35] upgrade saucy and test again [13:35] that's weird, I just tested it with the daily pacakge (1.4+bzr1475+dfsg-0+1487+181~ppa0~saucy1). [13:36] roaksoax: also (you'll tell me if it's normal or not) but ls /etc/init.d/maas*=> no file [13:46] rvba: then maybe something change in upstream packaging and broke it? [13:46] rvba: and i don't know, maybe something changed in upstart and is no longer creating that [13:48] roaksoax: I suspect something changed in upstart indeed… but I was kinda relying on your expertise here :) [13:48] roaksoax: If only I could get canonistack to work, then I could test with the latest saucy… [13:50] rvba: i'll tr again asi uploade\d something to sauycyc yesterday [13:50] and shuldhave built with whatever is in saucy [14:05] rvba: oh btw... there's what i believe a critical bug that needs attention [14:05] roaksoax: which one? [14:06] rvba: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1153077 [14:06] roaksoax: btw, you said you had an output of lshw that was causing problems in MAAS. [14:06] Launchpad bug 1153077 in maas (Ubuntu) "rabbitmq queue fills up and celery stops executing tasks when upload_dhcp_leases is done every minute (by default)" [High,Confirmed] [14:06] rvba: yes that too, let me get it [15:28] roaksoax, ping [15:29] i'm poking at a maas install... i basically dleted everything and upgraded to raring [15:29] apt-get --purge remove maas-everythgin-here [15:29] and then install maas [15:29] booted nodes. [15:29] they enlist fine [15:30] but then i can't power them on as the ipmi detected creds are not correct [15:43] smoser: let me think [15:44] smoser: so during enlistment maas created the credentials [15:44] yes. it did. [15:44] smoser: they were sent back to maas [15:44] smoser: but they don't work? [15:44] the username that shows up in maas is 'maas' [15:44] not 'maas-commission' [15:44] smoser: that's correct [15:44] well the user on the system is 'maas-commission' [15:44] (per user lsit) [15:45] smoser: right but maas should have create a user maas instead [15:45] smoser: let me check [15:50] smoser: ok, found the issue [16:28] smoser: what is wrong with this: show_re = re.compile("Username.*%s\\b" % user) [16:31] roaksoax, looks reasonable. [16:31] smoser: doesn't seem to work, ANyway, I know how to fix it [16:33] >>> bool(re.search("Username.*%s" % "maas", "Username foo")) [16:33] False [16:33] >>> bool(re.search("Username.*%s" % "maas", "Username maas")) [16:33] True [16:33] seems reasonable here. [16:33] smoser: yeah but user=maas-commission, and that regex matches maas-commission *and* "maas" [16:36] smoser: ok I have fixed it now [16:37] smoser: you should be able to just enlist/commission and it will make suer that maas-commission is changed back to maas in the BMC [16:37] well, enlist worked, but then maas doesn't power system on [16:37] so i have to do that manually [16:37] smoser: ok power them on manually and during the commissioning it will fix the user issue [16:38] smoser: so for deployment they should be just fine [16:38] whats the enlistment template [16:39] smoser: ok so I started .17 to test this [16:39] smoser: /usr/share/maas/preseeds/enlist_userdata [16:40] whta is the enlistment template ? [16:40] power on parameters do not affect the 'default' boot [16:40] meaning i can't get '-- console=ttyS1,115200' to it [16:41] roaksoax, you ahve to 'pxe-boot'. i'm not sure why, but they're not set to pxeboot [16:41] and you didn't accept that node [16:41] oh. you did do that. [16:41] smoser: yeah just did the pxe-boot [16:41] smoser: maas tells the machine to PXE when it controls them [16:42] smoser: let me test in that node whether it worked or not [16:43] that doesnt seem to work, roaksoax [16:43] oh. [16:43] i see [16:43] well maybe it would have worked, but maas can't power it on :) [16:44] smoser: now it can: [16:44] roaksoax@maas:~$ ipmipower -h 192.168.9.17 -u maas -p 3jaWUoCvrC34U --stat [16:44] 192.168.9.17: off [16:45] smoser: they either need to commission or enlisted again [16:45] smoser: so that it gets fixed [16:46] can i easily tell maas to forget all nodes ? [16:46] smoser: i think so yes, I think allenap added a command to do so [16:47] or maybe not [16:47] and see question above... what is the preseed for "default" ? [16:48] (enlist) [16:48] er.. not preseed [16:48] temlate. pxe boot template. [16:48] smoser: what do you mean default? [16:50] when its not known to maas [16:50] and it boots into the enlistment [16:50] what is that one [16:51] smoser: the PXE template, should be this one: /usr/share/pyshared/provisioningserver/pxe/config.commissioning.template [16:51] oh, really? that kind of sucks. [16:52] smoser: file a bug and maybe we can get it changed [16:52] i'll file a bug. you need to file one for your isssue that you sovled there also. [16:52] Daviey, i think you had some script for "maas forget everythign" [16:52] right ? [17:01] smoser: yes [17:01] delete-all ? [17:01] smoser: or you mean EVERYTHING? [17:06] delete-all was it. [17:07] did you have a "accept-all" ? [17:07] never mind. i'll get it. [17:28] roaksoax, is there a way to create a non-admin user ? [17:28] from the cmdline [17:28] and what is the difference from maas perspective on 'admin' ? [17:28] rvba, [17:35] smoser: There was an accept all [17:50] Daviey, just for later reference [17:50] maas-cli maaslocal nodes accept-all [17:54] roaksoax, did you open a bug ? [17:54] i opened https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1182980 [17:54] Launchpad bug 1182980 in maas (Ubuntu) "global parameters do not apply to enlistment" [Undecided,New] [17:55] but you ened to open one for the issue you solved [18:11] smosmofor my error yes just did (sorry i was caught up doing my first openstack mp) [18:11] smoser: ^^ [18:19] roaksoax, do you know how to add a user other than 'admin" ? [18:19] ie, there is maas createadmin [18:20] but can i create *non* admin via cli? [18:22] smoser: i don't think you can through the CLI === marlinc is now known as Marlinc [20:02] roaksoax, so... [20:02] i'm confused how maas interacts with dns [20:03] smoser: ok... [20:04] smoser: what confuses you? [20:05] on this system, it seems to be somehow poopulating stuff in /var/lib/bind/ [20:05] but i'm not sure how [20:07] smoser: did you wipe out the previous configuration? [20:08] smoser: maas is not configured for DNS/DHCP [20:08] [2013-05-22 21:07:08,910: INFO/PoolWorker-13] The DHCP leases file does not exist. This is only a problem if this cluster controller is managing its DHCP server. If that's the case then you need to install the 'maas-dhcp' package on this cluster controller. [20:09] smoser: are you mlooking to manage DHCP/DNS with the MAAS server as well? there's no other DNS/DHCP server there right? [20:09] smoser: IIRC, bind was manually configured by sabdfl to provide DNS [20:09] don't know if that was kept [20:09] well, something is odd. [20:10] smoser: yes [20:10] smoser: bind is manually configured [20:10] becase timestamps on db.cloud in /var/lib/bind are very recent [20:10] (2 hours ago) [20:10] and i didn't touch those. [20:10] smoser: yeah, it was manually configure [21:04] smoser: this is the manual integration i was saying. === kentb is now known as kentb-out