For IPMI at least, the problem appears to be bad data. Power parameters
are stored in the power_parameters JSON field on the Node.
* If no choice is made for the "Power driver" field in the UI, the value
stored for "power_driver" is the following *list*:
["LAN_2_0", "LAN_2_0 [IPMI 2.0]"]
* Once "LAN_2_0 [IPMI 2.0]" is selected in the UI, "power_driver" is set
to the *string* "LAN_2_0" in the database.
* Selecting "LAN [IPMI 1.5]" in the UI causes the "power_driver" setting
to disappear from the power parameters stored in the database.
It's not the driver's fault the data is bad. Ideally it wouldn't be the
driver's responsibility to deal with this bad data, but pragmatically we
may want it to.
Likely next steps:
-> Update IPMI driver to deal with bad data and DTRT.
-> Fix validation of power parameters to avoid adding new bad data.
-> Fix existing power parameters in running MAAS installations.
For IPMI at least, the problem appears to be bad data. Power parameters
are stored in the power_parameters JSON field on the Node.
* If no choice is made for the "Power driver" field in the UI, the value
stored for "power_driver" is the following *list*:
["LAN_2_0", "LAN_2_0 [IPMI 2.0]"]
* Once "LAN_2_0 [IPMI 2.0]" is selected in the UI, "power_driver" is set
to the *string* "LAN_2_0" in the database.
* Selecting "LAN [IPMI 1.5]" in the UI causes the "power_driver" setting
to disappear from the power parameters stored in the database.
It's not the driver's fault the data is bad. Ideally it wouldn't be the
driver's responsibility to deal with this bad data, but pragmatically we
may want it to.
Likely next steps:
-> Update IPMI driver to deal with bad data and DTRT.
-> Fix validation of power parameters to avoid adding new bad data.
-> Fix existing power parameters in running MAAS installations.