Please keep a per-host configuration for this. Per model would work unless the same model is using different BMC firmware versions.

Good point, so the current plan is:

• Use Hardware model (new database column) when set.
• Use Host parameter named "ipmidriver" when set.
• Use Global setting "ipmi_driver" when set.
• Don't send it (and use default "lan20" set by rubyipmi" instead - will work with Foreman 1.9+).

We should modify the error message to instruct the user to set this appropriately when the operation fails.

Also we can pre-populate Hardware model table from now on. The very fist pair would be: "PowerEdge R720" and "lan20" which I have tested on Friday.

Lukas Zapletal wrote:

• Use Host parameter named "ipmidriver" when set.

Avoid specially named host parameters I'd say, it should be a first class attribute if it's meant to be used.

• Use Global setting "ipmi_driver" when set.
• Don't send it (and use default "lan20" set by rubyipmi" instead - will work with Foreman 1.9+).

I'd suggest doing one or the other to reduce the complexity, e.g. stick to rubyipmi's defaults instead of introducing another global setting.

I'd suggest doing one or the other to reduce the complexity, e.g. stick to rubyipmi's defaults instead of introducing another global setting.

Don't you think explicit is better than implicit ? I mean, rubyipmi changed their default behavior recently and this caused me headaches (BMC would stop working all of a sudden).
I think explicit default IPMI driver set in Foreman would make things clearer and would avoid such problem in the future.

• M610, M620, M420, M630, (and maybe M610x too but I don't know how the system reports its model)
• R610, R620, R630
• R710, R720, R730

I switched the default driver in rubyipmi from auto to lan20 because there were more people having issues with the auto detection mechanism which works ok but not great. However, now that the default is swtiched to lan20 everyone with really ancient hardware is forced to specify lan15. I didn't think this was a big issue, because of the huge amount of security flaws with IPMI 1.0 and IPMI1.5 that nobody would ever run it in production. But a few people run this old hardware in their home labs. As a stop gap we could add a setting called default_ipmi_driver to the bmc smart proxy and use that setting whenever one is not specified in the options hash. Folks with older hardware would at least be able to get by until this ticket is completed.

This would work similar to the default provider: https://github.com/theforeman/smart-proxy/blob/develop/modules/bmc/bmc_api.rb#L267

If you set the driver-type value to auto, the rubyipmi will always try the lan driver first, fail and then the lan20 driver. This has a side affect executing twice the IPMI commands being called. So if your going to set these options in the database I would set auto for anything you are unsure about such as old hardware, new hardware set to lan20 or nothing and the default lan20 would be used. Additionally my comments above about using a smart proxy default setting could override Rubyipmi's default if needed. I have seen several instances where folks want a different privilege type because the server factory made it that way. So being able to configure this on a per server model / host level would be pretty nice and catch a few more edge cases.

Also I think we can auto detect IPMI version info too.

# > dmidecode --type 38
# dmidecode 2.10
SMBIOS 2.5 present.

Handle 0x0049, DMI type 38, 18 bytes
IPMI Device Information
        Interface Type: KCS (Keyboard Control Style)
        Specification Version: 2.0
        I2C Slave Address: 0x10
        NV Storage Device: Not Present
        Base Address: 0x0000000000000CA2 (I/O)
        Register Spacing: Successive Byte Boundaries