search

logicminds / rubyipmi

Command line wrapper for ipmitool and freeipmi
GNU Lesser General Public License v2.1
35 stars 32 forks source link

Support multiple driver-types and add flexible options hash #19

Closed spkane closed 10 years ago

spkane commented 10 years ago

This commit makes it possible to define the IPMI driver that should be used with the underlying tools (i.e lan 1.5 or lan 2.0)

It also adds an options hash that maintain backwards compatibility with the positional arguments, but also allows provider, debug, and driver to be provided via the hash as named arguments.

logicminds commented 10 years ago

The driver type is actually automatic now. Rubyipmi will first try 1.5 and then try 2.0 before failing. Unless this functionality is broken, I don't see any added value here. However, I see the need to allow more flexibility for situations like using the open driver type.

I'll take a deeper look and see if I can incorporate this into the current code base.

spkane commented 10 years ago

Is that functionality on the development branch?

I have only been using the master branch, and it doesn't work there. Being able to specify the driver, like the provider, is a good way to save some time however, when you already know what will work.

logicminds commented 10 years ago

Its in master and on ruby gems.org

Do you have any examples or conditions where this doesn't work?

Are you using freeipmi or ipmitool?

spkane commented 10 years ago

Using rubyipmi (0.7.0) from rubygem with Dell 12th generation servers (Rx20) both freeipmi and ipmitool fail to return results, without specifically using the LAN 2.0 driver-types.

crhan commented 10 years ago

:+1: great work

@spkane And I think you can make lan20 to be the default value. Are you guys really using server with legacy IPMI version? Those servers are too old to be managed.

The driver type is actually automatic now. Rubyipmi will first try 1.5 and then try 2.0 before failing

@logicminds Don't work in my case. And I find out that the errorcodes.rb doesn't really help in the real world. IPMI call is so unpredictable, and I collected some common case of IPMI failing messages across multiple OEMs to raise custom exceptions. https://github.com/crhan/rubyipmi/commit/77c54d6b2c5862430e098f547e4ac1132a3d7137

spkane commented 10 years ago

@crhan I thought about it, but I didn't want to change the existing behavior.

I also thought that it might be best to fall back to the lower-level's tool default, if nothing was provided. However, I would be fine with lan20 being the default. With Dell hardware anyhow, lan20 works fine with both 11th and 12th generation servers, which covers at least the last 5 years.

crhan commented 10 years ago

Do you have any examples or conditions where this doesn't work?

I have several OEM servers need to be managed, including HP, DELL, Inspire, Huawei, etc... That is more than a hundred models to be considered. It is really hopeless let this gem to guess for every case. And due to the difference understanding and implementation of IPMI specification, guessing is a bad idea and beyond the capacity of this gem in the current stage.