Add a plugin to get information from ipmitool

[gthvn1]

Commands are:

• get_all_sensors: run ipmitool sdr list - returns a JSON string with all sensors
• get_sensor: run ipmitool sdr get <sensor> - returns details about sensors passed as parameter
• get_ipmi_lan: returns network info of the IPMI server as a JSON

[gthvn1]

@AtaxyaNetwork , do you think that it will be possible to test this plugin on a 2crsi server in order to check that output are correct? Thanks a lot for your great help.

[gthvn1]

For info, @AtaxyaNetwork tested it several weeks ago and it looks ok. Don't know if it needs to be checked with XO team but for me it looks ok to merge it. @stormi I added you as reviewer but feel free to add someone else :)

[stormi]

• Is ipmitool guaranteed to report information structured as expected by the code on every XCP-ng host? I see no error handling outside the automatic one that will report the exception raised by python. I just tried on a nested XCP-ng VM and got [15:51 xcpng-ci-82-b1 ~]# ipmitool sdr list Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory.
• Code changes to this repository must come with unit tests in the same repository. Ideally also covering error handling.

[gthvn1]

This PR supersedes #47

[gthvn1]

@stormi in case of error it raises a raise_plugin_error raised from decorator error_wrapped. Isn't what is expected? I thought it was the purpose of the decorator.

[gthvn1]

In the Readme I see:

Error: raise a XenAPIPlugin.Failure describing the error, to do that: either raise the XenAPIPlugin.Failure exception directly or use error_wrapped from xcpngutils"

[gthvn1]

• And about tests I will add them

[stormi]

In the Readme I see:

Error: raise a XenAPIPlugin.Failure describing the error, to do that: either raise the XenAPIPlugin.Failure exception directly or use error_wrapped from xcpngutils"

Yes, but then errors that mean nothing to users will be displayed to users in XO. We'll likely need something better than Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory. hidden in some XO logs when the feature doesn't work as expected.

[gthvn1]

In the Readme I see:

Error: raise a XenAPIPlugin.Failure describing the error, to do that: either raise the XenAPIPlugin.Failure exception directly or use error_wrapped from xcpngutils"

Yes, but then errors that mean nothing to users will be displayed to users in XO. We'll likely need something better than Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory. hidden in some XO logs when the feature doesn't work as expected.

You will have "Error parameters: Command '['ipmitool', 'sdr', 'list']' failed with code: 1, stdout: '', stderr: 'Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory". It is the error parameters returned from the wrapper. What should I put instead? I mean it is the error :)

[gthvn1]

Isn't XO that should handle this better? Not sure to see what you want instead of the "real error"?

[stormi]

Depends what the API user (XO) would like. I think they would appreciate it if we provided a way to discriminate between "not supported on this hardware" and unexpected errors on supported hardware, for example.

[gthvn1]

So we should add some XO people to review right?

[gthvn1]

and I'm not sure to know how we can discriminate between "not supported on this hardware" and unexpected errors on supported hardware.