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