Project

General

Profile

Actions

Bug #10112

open

Allow user to define BMC driver / options per hardware model

Added by Lukas Zapletal almost 9 years ago. Updated about 7 years ago.

Status:
New
Priority:
Normal
Category:
BMC
Target version:
-
Difficulty:
easy
Triaged:
Fixed in Releases:
Found in Releases:

Description

Issue #7543 introduced options hash for BMC operations. We should allow users to define those per-host level. Using hardware model seems to be the best fit.


Related issues 3 (1 open2 closed)

Related to Smart Proxy - Bug #10102: BMC query fails with 'undefined method downcase for nil:NilClassNew04/09/2015Actions
Related to Smart Proxy - Bug #7543: allow additional rubyipmi connection options to be passed throughClosedCorey Osman09/19/2014Actions
Has duplicate Foreman - Bug #18091: BMC management doesn't work with Dell's iDRAC7Duplicate01/16/2017Actions
Actions #1

Updated by Lukas Zapletal almost 9 years ago

  • Related to Bug #10102: BMC query fails with 'undefined method downcase for nil:NilClass added
Actions #2

Updated by Lukas Zapletal almost 9 years ago

  • Project changed from Smart Proxy to Foreman
  • Category set to BMC
  • Difficulty set to easy
Actions #3

Updated by Dominic Cleal almost 9 years ago

  • Related to Bug #7543: allow additional rubyipmi connection options to be passed through added
Actions #4

Updated by Dominic Cleal almost 9 years ago

  • Description updated (diff)
Actions #5

Updated by Jérôme Vizcaino almost 9 years ago

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

Actions #6

Updated by Lukas Zapletal almost 9 years ago

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.

Actions #7

Updated by Dominic Cleal almost 9 years ago

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.

Actions #8

Updated by Jérôme Vizcaino almost 9 years ago

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.

Btw, you can set "lan20" driver for all the Dell PowerEdge family products starting from 11th Gen:
  • 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
Actions #9

Updated by Corey Osman over 8 years ago

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

Actions #10

Updated by Dominic Cleal about 7 years ago

  • Has duplicate Bug #18091: BMC management doesn't work with Dell's iDRAC7 added
Actions #11

Updated by Dominic Cleal about 7 years ago

  • Subject changed from Allow user to define BMC options per hardware model to Allow user to define BMC driver / options per hardware model
Actions

Also available in: Atom PDF