[14:19] <mup> Bug #1687420 opened: Maas api /machines/{system_id}/?op=restore_networking_configuration does not clear network config <MAAS:New> <https://launchpad.net/bugs/1687420>
[14:55] <vasey> mpontillo: i have a node (manual power control) i want to use for my juju controller node, but the RAM is showing up as 0.0 GB...any idea why that might be?
[15:28] <vasey> mpontillo: update, i'm now using the vmware power control successfully (followed your certificate fix steps), and i'm still seeing 0.0GiB RAM, even though it's configured with 3.5GB
[15:29] <vasey> mpontillo: and the juju bootstrapper needs to see in maas that the system has 3.5GB of ram for it to deploy, but it's just not there atm
[15:36] <wasosa> Hi all, I'm trying to get going with maas, but I'm stuck on getting storage information during commissioning. The 00-maas-07-block-devices.out I get back looks ok to me, but I cannot deploy because storage info is 'missing'. Any help is appreciated. I'm using maas 2.1.5+bzr5596-0ubuntu1~16.04.1.
[15:37] <wasosa> I'm trying to deploy to a machine with an nvme drive; I found this https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1642903, but I'm not sure that's the issue (symlinks look ok on the node).
[15:42] <xygnal> roaksoax: mpontillo: estimates on rc4?  waiting on thoe missing hooks for dhcp relay.
[15:43] <pmatulis> vasey, did you commission it?
[15:43] <vasey> pmatulis: yes, just deployed ubuntu 17 to it as well, still isn't showing any RAM in the maas ui
[15:56] <roaksoax> xygnal: in progress, mpontillo will work on those
[16:03] <vasey> pmatulis: trying to add the machine manually now
[16:22] <vasey> pmatulis: still no dice ;( is this a vmware issue or possibly a lshw output formatting issue? is there a way to manually tell MAAS how uch RAM a machine has?
[16:33] <wasosa> I can see where the errors are added(storage_layout_issues() in /usr/lib/python3/dist-packages/maasserver/models/node.py), but I haven't yet figured out where the problem occurs.
[16:35] <vasey> mpontillo: pmatulis: https://pastebin.com/ff3DE6aP my 00-maas-01-lshw output contains the amount of ram my VM has; why isn't it being reported in the maas machine description?
=== stormmore is now known as Budgie^Smore
[16:48] <mpontillo> vasey: can you post any relevant details on this bug report? https://bugs.launchpad.net/maas/+bug/1682150
[16:50] <mpontillo> vasey: if you can pastebin full output from your lshw commissioning script it may help us to write a test case
[17:19] <vasey> mpontillo: thanks, here's that output https://pastebin.com/upD20kWv
[17:46] <bigtexun> I changed the IP address of my MAAS server as I was learning how to configure it, and I ran sudo dpkg-reconfigure maas-region-controller, but when I deploy a machine MAAS inserts the old IP address in resolv.conf, where do I fix that?
[17:48] <bigtexun> It also inserts the new IP...  But DNS is timing out on the deployed machine, so things like sudo take forever.  Deployment was successful, despite MAAS failing the deployment.  I assume the DNS timeout is triggering the deploy fail indication in MAAS...
[17:58] <wasosa> I was able to confirm that `self.blockdevice_set.all()` returns an empy list (via print statement) inside storage_layout_issues(). I still can't tell where that comes from, but I'll keep digging. Any pointers are welcome ;-)
[18:19] <mpontillo> vasey: that's interesting, but I was actually interested in the full output from the 00-maas-01-lshw commissioning script. looks like you pasted the lldp output
[18:20] <mpontillo> bigtexun: check /etc/maas/regiond.conf
[18:20] <mpontillo> bigtexun: and /etc/maas/rackd.conf
[18:21] <mpontillo> bigtexun: it sounds like you've reconfigured the region but may also need to reconfigure the rack; try "sudo dpkg-reconfigure -plow maas-rack-controller"
[18:25] <vasey> mpontillo: sorry about that! here it is: https://pastebin.com/01kV39Ee
[18:38] <wasosa> One more crumb: I only see one row in the maasserver_blockdevice table, and it doesn't look like my drive:maasdb=# select * from maasserver_blockdevice;  id |            created            |            updated            | name |                id_path                 |     size     | block_size |    tags    | node_id  ----+-------------------------------+-------------------------------+------+----------------------------------------+-
[18:39] <wasosa> Bah, sorry.
[18:39] <wasosa>  id |            created            |            updated            | name |                id_path                 |     size     | block_size |    tags    | node_id  ----+-------------------------------+-------------------------------+------+----------------------------------------+--------------+------------+------------+---------   1 | 2017-04-19 13:37:46.604938-07 | 2017-05-01 10:54:26.505265-07 | sda  | /dev/disk/by-id/wwn-0x5002
[19:09] <pmatulis> wasosa, use a pastebin next time
[19:13] <wasosa> Will do, thanks: https://pastebin.com/ZB4Ef3ML
[19:14] <wasosa> So it seems the blockdevice info is coming back from the node to the server, but is not making its way into the database.
[19:20] <xygnal> question:  when does the user_data metadata get passed through to cloud-init on the guest?
[19:20] <xygnal> is after after deployment? during deployment?
[19:43] <xygnal> one follow up question to that one, is user_data pased through regardless of image source?we use custom, but our image has cloud-init
[19:44] <xygnal> would like to apply the user_data field
[19:52] <bigtexun> mpontillo: Thanks!  I'll try that.  Shortly before you posted I decided to try rebooting the MAAS server, and that caused PXE to start failing, so perhaps this will fix me up...
[19:56] <roaksoax> bigtexun: dpkg-resource the rack controller too
[20:00] <Mac_> Hi there,
[20:00] <Mac_> I'm running CiaB to deploy Thunder ARM64 compute node by MAAS, and I have had no problem with that until now. This week when I tried to do it again, the Thunder alway give me the following message:
[20:01] <Mac_> CORD cord-in-a-box script
[20:01] <Mac_> EFI stub: Booting Linux Kernel... ConvertPages: Incompatible memory types EFI stub: ERROR: Failed to alloc kernel memory EFI stub: ERROR: Failed to relocate kernel Unloading driver at 0x11F8400A000    Failed to boot both default and fallback entries.  Press any key to continue...  Booting under MAAS direction... error: couldn't send network packet. unaligned pointer 0x11fea8f89d0 borted. Press any key to exit.error: you need to load the ke
[20:01] <Mac_> MAAS Version 1.9.5+bzr4599-0ubuntu1 (14.04.1) This seems to me that something wrong with the EFI image MAAS has. Any suggestions for further debugging? Thanks.
[20:02] <bigtexun> roaksoax:  Thanks, I only have the one server...  This is a first-time installation.  Everything except DNS was working on the deployed node this morning...  I was focused on just fixing the IP problem in DNS, and I rebooted after I posted my question today...  And after booting pxe stopped working.
[20:06] <bigtexun> Since I have no data, just my MAAS sandbox, and a single physical node, I'm going to do a clean install with no IP address changes and see if everything works.
[20:06] <bigtexun> perhaps I fat-fingered something in the week I spend getting this thing working.
[20:14] <mup> Bug #1687463 opened: Pods listing page header still shows "Add pod" when pod from list is selected. <MAAS:In Progress by newell-jensen> <MAAS RSD :In Progress by newell-jensen> <https://launchpad.net/bugs/1687463>
[20:31] <roaksoax> Budgie^Smore: restarting regiond and rackd
[20:31] <roaksoax> err
[20:31] <roaksoax> sry
[20:41] <roaksoax> /w/win 5
[21:05] <Budgie^Smore> lol no worries roaksoax :)
[22:35] <mup> Bug #1687487 opened: Virsh pod creation failed with "Node with hostname already exists." <MAAS:Confirmed> <https://launchpad.net/bugs/1687487>
[23:35] <mup> Bug #1687500 opened: Unable to configure DHCP due to IPAddress not assoicated with subnet <MAAS:In Progress by ltrager> <https://launchpad.net/bugs/1687500>