Populate the power parameter mac_address during enlistment

When a MAC address is given MAAS issues an arp request to find the IP to use as the power address[1]. Any given power address is then ignored. Using ARP to map a MAC address with an IP isn't considered as reliable as just using the IP. As MAAS uses the power address to determine which rack controller to issue power commands from having both can cause power failures as well.

Do you have a use case for using ARP over an IP address or is this more of a cosmetic thing?

[1] https://git.launchpad.net/maas/tree/src/provisioningserver/drivers/power/ipmi.py#n313

Just realized I misread the code a bit. If both a MAC address and power address are set the MAC address will be ignored, not the power address. So we could fill in this information but it won't be used.

The use case for this we receive a new machine from a manufacturer (Dell in this case) we inbox the machine, rack, and power on. The machine pulls it's BMC IP from MAAS DHCP and PXE boots through the enlisting cycle. We may do that for a number of machines. The only information we know at this point from Dell is the service tag (serial number), MAC address of the BMC, and its location in the rack. For inventory purposes, we would like to be able to get the MAC and IP of the BMC from the API. We understand MAAS wouldn't use the MAC however it would be useful for our internal requirements.

We're planning on adding support for IPMI encryption this cycle. I'll try to squeeze this in as part of that work. In the meantime after commissioning runs you should be able to see all MAC addresses associated with the machine.

Please also publish the IP address. For background see support case 292765. Long story short, an entire rack was enlisted and then "accept-all". After that we adjusted the machine configuration to disallow "OS passthru" access to the iDRAC (Dell branded BMC/IPMI controller) which is implemented as a mutant form of usb NIC. From that point onward, we could no longer commission. The workaround was to delete them all, then adjust their configuration and re-enlist. one machine of 20 was inadvertently missed. It should have been trivial to diff the IP list from dhcp-lease-list (before we started the workaround process) as that produced the list of all 20 idracs. After the delete/re-enlist I attempted to dig out the IPMI addresses from "maas $ROLE machines read" but I was as unable to find the IPMI addresses as the mac addresses originally listed in this RFE. Since the GUI displays the IP address, surely that information is already handy ... just not provided (at least I couldn't find any of the 19 ip addresses I had handy in the output of 'maas admin machines read'