power_driver parameter is not preserved

Could you please paste the output of the 30-maas-01-bmc-config commissioning script for the machine?

modprobe: ERROR: could not insert 'ipmi_si': No such device
ERROR: Failed to commit `User3:Password'
INFO: Loading IPMI kernel modules...
INFO: Checking for HP Moonshot...
INFO: Checking for IPMI...
INFO: IPMI detected!
INFO: Reading current IPMI BMC values...
INFO: Configuring IPMI Lan_Channel...
INFO: Configuring IPMI Lan_Channel_Auth...
INFO: Lan_Channel_Auth settings unavailable!
INFO: Configuring IPMI cipher suite ids...
INFO: Gathering supported cipher suites and current configuration...
INFO: BMC supports the following ciphers - [1, 2, 3, 6, 7, 8, 11, 12, 15, 16, 17]
INFO: Current cipher suite configuration - XXXXXXXXXXXXXXX
INFO: New cipher suite configuration - XXXXXXXXXXXXXXX
INFO: MAAS will use IPMI cipher suite id "17" for BMC communication
WARNING: No K_g BMC key found or configured, communication with BMC will not use a session key!
INFO: Configuring IPMI Serial_Channel...
INFO: Serial_Channel settings unavailable!
INFO: Configuring IPMI SOL_Conf...
INFO: Found existing IPMI user "maas"!
INFO: Configuring IPMI BMC user "maas"...
INFO: IPMI user number - User3
INFO: IPMI user privilege level - Administrator
INFO: IPMI Version - LAN_2_0
INFO: IPMI boot type - efi

During commissioning, MAAS detects that IPMI2. is available and thus uses that.

From the previous output no cipher suite is enabled and MAAS falls back to 17, but can't really comunicate with the BMC.

Also note that you can use the `skip_bmc_config` flag when adding the machine from the API to prevent MAAS from configuring the BMC (thus overriding the provided config).

Apparently `skip_bmc_config` has no effect - let's ensure that MAAS users who specify IPMI details get them persisted after commissioning

we found two issues while debugging this:

1) the user forces an IPMI version

maas root machines create hostname=test-13 \
    zone=zone1 architecture=arm64/generic \
    mac_addresses=XX:XX:XX:XX:XX:XX \
    power_type=ipmi \
    power_parameters_power_address=XXX.XXX.XXX.XXX \
    power_parameters_power_user=admin \
    power_parameters_power_pass=admin \
    power_parameters_power_driver=LAN \
    power_parameters_power_boot_type=efi

The observed behaviour is the machine powers up, commissioning is successful and then MAAS fails to power it off. What actually happens is that MAAS powers up the machine with the used-supplied power-parameters, runs 30-bmc-config with the default parameter values (maas_auto_ipmi_user and maas_auto_ipmi_user_password) and overwrites the user values with the detected ones (changing the power driver to LAN_2), and then it fails to power it off because the new values are invalid.

The fix is to change the script to use existing power parameters if present.

2) the user skips BMC configuration adding skip_bmc_config=1 to the command line

MAAS is running the script even when unsolicited in some scenarios. I'm still looking for what triggers this bug. The observed behaviour is that MAAS crashes when the script reports back its results, which is unexpected because the script status is skipped:

2022-02-04 16:13:35 maasserver: [error] ################################ Exception: ################################
2022-02-04 16:13:35 maasserver: [error] Traceback (most recent call last):
  File "/snap/maas/18203/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/snap/maas/18203/lib/python3.8/site-packages/maasserver/utils/views.py", line 284, in view_atomic_with_post_commit_savepoint
    return view_atomic(*args, **kwargs)
  File "/usr/lib/python3.8/contextlib.py", line 75, in inner
    return func(*args, **kwds)
  File "/snap/maas/18203/lib/python3.8/site-packages/maasserver/api/support.py", line 56, in __call__
    response = super().__call__(request, *args, **kwargs)
  File "/snap/maas/18203/usr/lib/python3/dist-packages/django/views/decorators/vary.py", line 20, in inner_func
    response = func(*args, **kwargs)
  File "/snap/maas/18203/usr/lib/python3.8/dist-packages/piston3/resource.py", line 197, in __call__
    result = self.error_handler(e, request, meth, em_format)
  File "/snap/maas/18203/usr/lib/python3.8/dist-packages/piston3/resource.py", line 195, in __call__
    result = meth(request, *args, **kwargs)
  File "/snap/maas/18203/lib/python3.8/site-packages/maasserver/api/support.py", line 308, in dispatch
    return function(self, request, *args, **kwargs)
  File "/snap/maas/18203/lib/python3.8/site-packages/metadataserver/api.py", line 817, in signal
    target_status = process(node, request, status)
  File "/snap/maas/18203/lib/python3.8/site-packages/metadataserver/api.py", line 641, in _process_commissioning
    self._store_results(
  File "/snap/maas/18203/lib/python3.8/site-packages/metadataserver/api.py", line 529, in _store_results
    script_result.store_result(
  File "/snap...

In the upcoming release (3.2) we intend to help the user to detect the original problem, which was all ciphers being disabled either by the default BMC configuration or by a previous MAAS release.

While debugging this we came across two MAAS limitations that we aim to address in future releases:

1) power parameters detected by enlistment/commissioning scripts override values supplied by the user. Whether this is a bug or a feature is up for debate, and there's a workaround using a custom script to patch the file BMC_CONFIG_PATH with the desired values before it is uploaded.

2) the user cannot skip BMC configuration during enlistment. This is a result of the target host using an anonymous endpoint to download from MAAS scripts run before the enlistment, so MAAS is unaware of the host id and cannot give it instructions to skip any script. A possible fix is to split the BCM handling in two scripts, one to detect current power parameters and another to configure them. The former always run during enlistment and the latter runs during commissioning when the host id is already known.