[00:01] <mwhudson> i deploy a node, the bootloader gets an ip address fine and it netboots but the installer fails to DHCP
[00:02] <mwhudson> or rather, it doesn't think it's DHCPed successfully
[00:02] <mwhudson> but i can ping it so...
[00:48] <mwhudson> rraaaaaaaaararar
[01:06] <bigjools> mwhudson: is your daughter at the keyboard again?
[01:06] <mwhudson> no, just a slightly hacked off daddy
[01:46] <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:48] <mwhudson> well
[01:48] <mwhudson> given that there is no ui at all for releasing ...
[01:50] <mwhudson> you can parse json with awk, right?
[01:50]  * mwhudson does evil
[01:51] <bigjools> ha
[01:53] <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 ...
[02:02] <mwhudson> aaaaaaaaaaaar
[02:02] <mwhudson> bigjools: would you expect maas to support deploying raring to armhf yet?
[02:03] <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:04] <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:05] <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:06] <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:07] <roaksoax> shipped*
[02:08] <bigjools> roaksoax: yeah, because they are in the tree :)
[02:09] <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:10] <roaksoax> bigjools: for yui?
[02:11] <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:12] <roaksoax> bigjools: evrything in 1.2 is in tree but the js files and i think python-tx-tftp
[02:13] <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:15] <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:16] <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:17] <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:18] <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:19] <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:21] <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:22] <bigjools> roaksoax: sounds good
[02:22]  * bigjools heads out for lunch
[13:33] <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:34] <roaksoax> rvba: i installed saucy and then maas
[13:34] <roaksoax> and all of the success seem to be running just fine
[13:35] <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:36] <rvba> roaksoax: also (you'll tell me if it's normal or not) but ls /etc/init.d/maas*=> no file
[13:46] <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:48] <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:50] <roaksoax> rvba: i'll tr again asi uploade\d something to sauycyc yesterday
[13:50] <roaksoax> and shuldhave built with whatever is in saucy
[14:05] <roaksoax> rvba: oh btw... there's what i believe a critical bug that needs attention
[14:05] <rvba> roaksoax: which one?
[14:06] <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
[15:28] <smoser> roaksoax, ping
[15:29] <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:30] <smoser> but then i can't power them on as the ipmi detected creds are not correct
[15:43] <roaksoax> smoser: let me think
[15:44] <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:45] <roaksoax> smoser: right but maas should have create a user maas instead
[15:45] <roaksoax> smoser: let me check
[15:50] <roaksoax> smoser: ok, found the issue
[16:28] <roaksoax> smoser: what is wrong with this: show_re = re.compile("Username.*%s\\b" % user)
[16:31] <smoser> roaksoax, looks reasonable.
[16:31] <roaksoax> smoser: doesn't seem to work, ANyway, I know how to fix it
[16:33] <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:36] <roaksoax> smoser: ok I have fixed it now
[16:37] <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:38] <roaksoax> smoser: so for deployment they should be just fine
[16:38] <smoser> whats the enlistment template
[16:39] <roaksoax> smoser: ok so I started .17 to test this
[16:39] <roaksoax> smoser: /usr/share/maas/preseeds/enlist_userdata
[16:40] <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:41] <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:42] <roaksoax> smoser: let me test in that node whether it worked or not
[16:43] <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:44] <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:45] <roaksoax> smoser: they either need to commission or enlisted again
[16:45] <roaksoax> smoser: so that it gets fixed
[16:46] <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:47] <roaksoax> or maybe not
[16:47] <smoser> and see question above... what is the preseed for "default" ?
[16:48] <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:50] <smoser> when its not known to maas
[16:50] <smoser> and it boots into the enlistment
[16:50] <smoser> what is that one
[16:51] <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:52] <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 ?
[17:01] <Daviey> smoser: yes
[17:01] <Daviey> delete-all ?
[17:01] <Daviey> smoser: or you mean EVERYTHING?
[17:06] <smoser> delete-all was it.
[17:07] <smoser> did you have a "accept-all" ?
[17:07] <smoser> never mind. i'll get it.
[17:28] <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:35] <Daviey> smoser: There was an accept all
[17:50] <smoser> Daviey, just for later reference
[17:50] <smoser> maas-cli maaslocal nodes accept-all
[17:54] <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:55] <smoser> but you ened to open one for the issue you solved
[18:11] <roaksoax> smosmofor my error yes just did (sorry i was caught up doing my first openstack mp)
[18:11] <roaksoax> smoser: ^^
[18:19] <smoser> roaksoax, do you know how to add a user other than 'admin" ?
[18:19] <smoser> ie, there is maas createadmin
[18:20] <smoser> but can i create *non* admin via cli?
[18:22] <roaksoax> smoser: i don't think you can through the CLI
=== marlinc is now known as Marlinc
[20:02] <smoser> roaksoax, so...
[20:02] <smoser> i'm confused how maas interacts with dns
[20:03] <roaksoax> smoser: ok...
[20:04] <roaksoax> smoser: what confuses you?
[20:05] <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:07] <roaksoax> smoser: did you wipe out the previous configuration?
[20:08] <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:09] <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:10] <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
[21:04] <Daviey> smoser: this is the manual integration i was saying.
=== kentb is now known as kentb-out