MAAS only learns of new hardware by delete and re-add

[Mick Gregg]

Once MAAS has learnt of a node it seems to have no way to re-inspect the node for hardware changes. We require a means to have MAAS look for hardware changes, especially when nodes are already deployed.

Use cases:
1. A machine's mainboard has been replaced, meaning the node has new MAC addrs. The node fails to PXE boot, and we cannot update the MAC addresses as the node is deployed.
1.1 We needed to hack maasserver/api/interfaces.py to allow a deployed node to be updated
1.2 MAAS version is 1.9.0+bzr4533-0ubuntu1~trusty1

2. Scripted hardware RAID configuration is only possible with a tool run from the booted operating system. (No out-of-band tools are available for this brand of hardware.) We can run this tool in a commissioning script, but we can't then deploy as the new disk layout means the (sda, now a RAID array) disk serial is not recognised, and partitioning_commands to force use of the new sda in the preseed are ignored.
2.1 We need to commission with the RAID configuration commissioning script, delete the nodes, then re-add and re-commission the nodes, this time without the commissioning script. (Even re-commissioning without deleting first failed to see the change.)
2.2 MAAS version is 1.9.1+bzr4543-0ubuntu2~trusty1

In both these cases, a means to instruct MAAS to re-inspect the hardware could solve the problems. I haven't found one yet in the API.

[Mick Gregg (macgreagoir)]

I believe bug #1575567 is about detecting storage changes during re-commissioing. This bug us about detecting storage and other hardware changes after deployment as well.

[Peter Sabaini (peter-sabaini)]

I don't agree that this bug is a dupe of bug #1575567, that bug doesn't cover the use case of updated MAC addr (eg. due to NIC or mainboard change) I believe?

[Mike Pontillo (mpontillo)]

Recommissioning is intended to discover hardware changes, and should already handle the case of a MAC address or mainboard change.

[Mick Gregg (macgreagoir)]

Thanks Mike,

Does the change in bug #1575567 address use case 2. (RAID configuration after initial commissioning) OK? I don't have the hardware available any more to re-test, but had used the noted work-around in this case.

I don't think bug #1575567 handles case 1. where a mainboard replacement meant new MAC addrs. On this deployed production node, we could not recommission, obviously.

Cheers,

Mick

[Jamie Cockburn (daggaz)]

+1
we would like to be able to rescan the amount of memory in a deployed maas machine