Do not run ipmi-locate during commissioning

Enlistment isn't really that destructive. IPMI supports multiple users via user slots (potential users), and the autodetect tool looks for an existing 'maas' user to set the password for. If there isn't one, it looks for an unused user slot, and sets its username to maas and then sets its password. If there is no 'maas' user and no unused user, it gives up, so it won't overwrite non-existing credentials for users other than 'maas'.

I was hesitant to support removing credential setting from commissioning because I've used it before (even very recently, post robustness) to reset bad credentials on a node. However, I usually have to do that because I've been hacking around, and even in those cases, I could delete the node and reenlist it instead.

So, I'm fine with your proposed approach.

On Wednesday 05 Nov 2014 17:51:06 you wrote:
> Why not leave ipmipower setup to be an enlistment-only step and not redo
> it for commissioning?

What about when someone enlists manually (in the web UI) and manually powers
up the machine hoping that MAAS will sort out the power parameters?

The commissioning environment always run the IPMI discovery/configuration again for various reasons:

1. Because solely enlisted/registered machines are not machines we trust. Machines are trusted once they are accepted into MAAS, and it is at that point, MAAS creates new credentials. The credentials created during commissioning are the credentials that we use for the rest of the operations.

2. To provide IPMI auto-discovery for cases where we enlist machines manually.

3. To be able to reset/change passwords on BMC's.

Now, to Jason's point, in our OIL use case, we have needed many times to reset/change the password of machines during commissioning. However, unlike his scenario, we cannot afford removing the machine and re-enlist the machine to either fix the credentials, reset the credentials or change the credentials. This means that for us it continues to be very important being able to auto-discover/change BMC's and its credentials.

In other environments, I do believe we need to be able to provide ways to our users to reset/change the BMC passwords, and commissioning is the step that it is needed for that. Our users should not have to delete the machine and register it again in order to be able to do so.

Furthermore, making this change in trunk (which will result in 1.7.1 as per discussed yesterday), will result in a significant change of behavior, which should not happen at this point of the 1.7 cycle.

That being said, what I do believe we should have the ability to disable/enable the BMC autodiscovery during commissioning. This way we provide the user the ability to select whether they want to be able to reset/change their BMC passwords or not. By default, to kiko's concerns, this could be disabled during commissioning, and enabled if users really need to use it.

So, this would mean having the ability to run different commissioning scripts, allowing the admin to select what scripts to run and what scripts not to run. This is the solution we should target for, and we had proposed it before and that's what we should do to address this bug report.

Thanks

(So just to clarify, the right way to fix this is to provide the ability to users to decide what commissioning scripts they run. In the meantime, we should not change the behavior, specially not for 1.7.X)