[00:05] <mup> Bug #1510323 opened: Machine validation when adding a node to MaaS <canonical-bootstack> <MAAS:New> <https://launchpad.net/bugs/1510323>
[00:18] <lathiat> SpeeR: Not super cleanly but what I did was added VMs on that host through libvirt to the maas.. specifically to run my juju state server and not waste another node on that
[00:18] <lathiat> actually i guess that is cleanish
[01:08] <mup> Bug #1510334 opened: bcache cache_mode setting not configured on servers <MAAS:New> <https://launchpad.net/bugs/1510334>
[01:11] <mup> Bug #1510334 changed: bcache cache_mode setting not configured on servers <MAAS:New> <https://launchpad.net/bugs/1510334>
[01:20] <mup> Bug #1510334 opened: bcache cache_mode setting not configured on servers <MAAS:New> <https://launchpad.net/bugs/1510334>
[05:36] <mup> Bug #1510161 changed: cannot change locale (en_US) <MAAS:Invalid> <https://launchpad.net/bugs/1510161>
=== Gary is now known as Guest89897
[10:07] <mup> Bug #1510447 opened: on the file system table, change name to “File system” (lower case S) <ui> <MAAS:New> <https://launchpad.net/bugs/1510447>
[10:37] <mup> Bug # opened: 1510452, 1510453, 1510455, 1510457, 1510458, 1510465, 1510466, 1510467, 1510468, 1510469
[10:46] <mup> Bug #1510471 opened: when partitioning, there should be 20px padding between the sizing fields <ui> <MAAS:New> <https://launchpad.net/bugs/1510471>
[10:46] <mup> Bug #1510472 opened: when formatting/mounting, the button says “Format & Mount” - this should just be “Mount” <ui> <MAAS:New> <https://launchpad.net/bugs/1510472>
[10:46] <mup> Bug #1510474 opened: when partitioning and adding a logical volume, remove the empty column between the config fields, and the file system and mount point <ui> <MAAS:New> <https://launchpad.net/bugs/1510474>
[10:55] <mup> Bug #1510471 changed: when partitioning, there should be 20px padding between the sizing fields <ui> <MAAS:New> <https://launchpad.net/bugs/1510471>
[10:55] <mup> Bug #1510472 changed: when formatting/mounting, the button says “Format & Mount” - this should just be “Mount” <ui> <MAAS:New> <https://launchpad.net/bugs/1510472>
[10:55] <mup> Bug #1510474 changed: when partitioning and adding a logical volume, remove the empty column between the config fields, and the file system and mount point <ui> <MAAS:New> <https://launchpad.net/bugs/1510474>
[10:58] <mup> Bug #1510471 opened: when partitioning, there should be 20px padding between the sizing fields <ui> <MAAS:New> <https://launchpad.net/bugs/1510471>
[10:58] <mup> Bug #1510472 opened: when formatting/mounting, the button says “Format & Mount” - this should just be “Mount” <ui> <MAAS:New> <https://launchpad.net/bugs/1510472>
[10:58] <mup> Bug #1510474 opened: when partitioning and adding a logical volume, remove the empty column between the config fields, and the file system and mount point <ui> <MAAS:New> <https://launchpad.net/bugs/1510474>
[11:04] <mup> Bug #1510471 changed: when partitioning, there should be 20px padding between the sizing fields <ui> <MAAS:New> <https://launchpad.net/bugs/1510471>
[11:04] <mup> Bug #1510472 changed: when formatting/mounting, the button says “Format & Mount” - this should just be “Mount” <ui> <MAAS:New> <https://launchpad.net/bugs/1510472>
[11:04] <mup> Bug #1510474 changed: when partitioning and adding a logical volume, remove the empty column between the config fields, and the file system and mount point <ui> <MAAS:New> <https://launchpad.net/bugs/1510474>
[11:07] <mup> Bug #1510471 opened: when partitioning, there should be 20px padding between the sizing fields <ui> <MAAS:New> <https://launchpad.net/bugs/1510471>
[11:07] <mup> Bug #1510472 opened: when formatting/mounting, the button says “Format & Mount” - this should just be “Mount” <ui> <MAAS:New> <https://launchpad.net/bugs/1510472>
[11:07] <mup> Bug #1510474 opened: when partitioning and adding a logical volume, remove the empty column between the config fields, and the file system and mount point <ui> <MAAS:New> <https://launchpad.net/bugs/1510474>
[11:10] <mup> Bug # opened: 1510482, 1510486, 1510488, 1510489
[11:40] <mup> Bug #1510499 opened: Page header extra spacing caused by actions <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1510499>
[13:43] <mup> Bug #1510452 changed: users should be able to unmount and delete the device <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1510452>
[13:46] <mup> Bug #1510452 opened: users should be able to unmount and delete the device <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1510452>
[13:52] <mup> Bug #1510452 changed: users should be able to unmount and delete the device <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1510452>
=== marlinc_ is now known as marlinc
[14:23] <mup> Bug #1510323 changed: Machine validation when adding a node to MaaS <canonical-bootstack> <MAAS:Triaged> <https://launchpad.net/bugs/1510323>
[15:11] <gtmanfred> http://stable.packages.cloudmonitoring.rackspace.com/pki/agent/redhat-7.asc this key is still not available
[15:12] <gtmanfred> https://github.rackspace.com/Servermill/servermill/blob/preprod/servermill/scripts/mckick.py#L496-L509
[15:12] <gtmanfred> oh, i think I did it wrong
[15:13] <gtmanfred> https://monitoring.api.rackspacecloud.com/pki/agent/redhat-7.asc is the correct one
[15:13] <gtmanfred> and works
[15:13] <gtmanfred> thanks
[16:01] <marka13> MAAS Version 1.9.0 (beta1+bzr4417) - cloud-init just hangs during commissioning now.  It was working for me before the update
[16:02] <marka13> acts like it won't connect
[16:02] <marka13> but have ssh'd into the box and verified internet connectivity
[16:11] <marka13> Oct 27 10:52:20 os-juju [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_keys_to_console' due to: No module named cc_keys_to_console
[16:11] <marka13> Oct 27 10:52:20 os-juju [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_phone_home' due to: No module named cc_phone_home
[16:11] <marka13> Oct 27 10:52:20 os-juju [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_final_message' due to: No module named cc_final_message
[16:11] <marka13> Oct 27 10:52:20 os-juju [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_power_state_change' due to: No module named cc_power_state_change
[16:11] <marka13> Oct 27 10:52:20 os-juju [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'ubuntu' due to: No module named ubuntu
[16:11] <marka13> Oct 27 10:52:20 os-juju [CLOUDINIT] cc_rightscale_userdata.py[DEBUG]: Failed to get raw userdata in module rightscale_userdata
[16:25] <roaksoax> marka13: that's strange, I just commissioned 40 machines with no issues after upgrading the beta1
[16:25] <roaksoax> marka13: but that error looks like a cloud-init issue, not MAAS'
[16:25] <roaksoax> marka13: do you have a full log?
[16:29] <marka13> not anymore - trying to find a way to get my servers commissioning again
[16:30] <marka13> Trying to get and keep maas working has been one of the most frustrating experiences ever
[16:31] <roaksoax> marka13: if you are using a development release, like 1.9.0 then I can image
[16:31] <roaksoax> imagine*
[16:31] <roaksoax> marka13: only, I've been running a 40 node cluster with no major issues since alpha1
[16:31] <marka13> well I had to move to 1.9 because 1.8 wouldn't work period
[16:31] <roaksoax> marka13: and upgrading pretty much daily
[16:31] <roaksoax> marka13: why wouldn't 1.8 work for you?
[16:32] <marka13> this what I got back from someone in canonical:
[16:32] <marka13> This might have been related to adding the proxy in the ephemeral environment, which got fixed in 1.9. This basically prevented packages from being installed in certain scenarios.
[16:32] <marka13> who knows what that means
[16:32] <marka13> but it went back to being broke
[16:33] <roaksoax> marka13: judging by the error you posted above, that doesn't seem a maas' issue, that seems like a cloud-init issue
[16:34] <marka13> and that runs separate from the maas installation?
[16:35] <roaksoax> marka13: during commissioning, the machine pxe boots, and loads the ephemeral image via iscsi
[16:35] <roaksoax> marka13: cloud-init in the ephemeral image, accesses the metadata server in MAAS to run the commissioning scripts
[16:35] <marka13> so an issue with the ephemeral image?
[16:36] <marka13> Oct 27 11:24:32 os-juju [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_final_message' due to: No module named cc_final_message
[16:36] <marka13> Oct 27 11:24:32 os-juju [CLOUDINIT] importer.py[DEBUG]: Found cc_final_message with attributes ['handle'] in ['cloudinit.config.cc_final_message']
[16:36] <marka13> looks like it fails and then finds it
[16:36] <roaksoax> marka13: most likely an issue with cloud-init itself, but I wouldn't be able to know for sure without a complete log
[16:38] <roaksoax> marka13: if you login into the commissioning environment, logs needed would be /var/log/cloud-init.log,cloud-init-output.log
[16:38] <marka13> http://paste.ubuntu.com/12980737/
[16:39] <marka13> http://paste.ubuntu.com/12980749/
[16:44]  * roaksoax investigates
[16:50] <roaksoax> marka13: http://paste.ubuntu.com/12980824/
[16:50] <roaksoax> marka13: http://paste.ubuntu.com/12980825/
[16:50] <roaksoax> marka13: i just commissioning a node
[16:50] <roaksoax> without issues
[17:05] <mup> Bug #1510629 opened: I can no longer see the IP address a node gets on the PXE interface on commissioning <MAAS:Triaged> <https://launchpad.net/bugs/1510629>
[17:15] <SpeeR> are there any logs to following while commissioning a node? I would like to see if anything is happening, or why something failed
[17:16] <roaksoax> SpeeR: maas stores some logs, mostly the commissioning logs
[17:16] <roaksoax> SpeeR: but we don't yet store the full cloud-init log
[17:16] <roaksoax> SpeeR: there's an open bug for that
[17:17] <SpeeR> ok thank you roaksoax
[17:28] <marka13> RoakSoax: Curious why mine just stopped completing all of a sudden
[17:28] <marka13> is there any easy means of just purging and reinstalling maas?
[18:07] <pryorda> Hey Guys, So im testing building a cluster in virtual box and running into something weird
[18:07] <pryorda> I point it to the server and it shuts down.
[18:07] <pryorda> Should I just be PXE booting in virtualbox?
[19:33] <marka13> roaksoax: Did a clean isntall of maas - 1.9.0 (beta1+bzr4417)  Same issue
[19:33] <marka13> cloudinit doesn't do anything
[19:43] <marka13> saw this now after reinstall:  [CLOUDINIT] cc_rightscale_userdata.py[DEBUG]: Failed to get raw userdata in module rightscale_userdata
[19:58] <marka13> http://pastebin.ubuntu.com/12982402/
[19:58] <marka13> request to http://10.0.0.10/MAAS/metadata//2012-03-01/ failed. sleeping 1.: HTTP Error 400: BAD REQUEST
[19:58] <marka13> what would cause that?
[23:15] <roaksoax> marka13: uhmmm that's completely weird
[23:16] <roaksoax> marka13: what about tail -f /var/log/maas/proxy/*.log
[23:16] <roaksoax> marka13: does commissioning try to obtain any packages that hit the proxy?
[23:16] <roaksoax> marka13: what's the config in /etc/maas/regiond.conf and /etc/maas/cluster.conf ?
[23:16] <roaksoax> marka13: what's the config in /etc/maas/regiond.conf and /etc/maas/clusterd.conf ?
[23:19] <roaksoax> marka13: also, do you have a log when the machine pxe boots? the exact moment it is pxe booting and downloading the images from MAAS?
[23:20] <roaksoax> marka13: although, this is a very interesting error: http://pastebin.ubuntu.com/12982402/
[23:20] <roaksoax> marka13: when that happens, request to http://10.0.0.10/MAAS/metadata//2012-03-01/ failed. sleeping 1.: HTTP Error 400: BAD REQUEST
[23:20] <roaksoax> marka13: do you have /var/log/maas/regiond.log ?