luyf5
ca9810ca3a
https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/919828c30e8c6540f98363885aeb9b69e01b2092 153295)As an user I want to get the inventory information of RS160 https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/bec53c4b29f7bade6820d5bc6cba0d2c76e80c7a Fixes problems in previous commit regarding support of RS160 https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/fa25b97c891e6edef64267c60cc9fb3e23f01079 (60750) [legacy_Server][Kent2U4N] Get a wrong UUID of the Kent https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/2856c78477aa4081479ed3b55d229b5a4bd31a2a Refine the code in parse_firmware_info to get the firmware version https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/1313280d4035b4417a02b8d82b9a353ff1cfb535 (66249)[legacy_Server]Unreasonable firmware GUI diaplay for RS160 https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/7ba0bf98698df7132333d87bb52da9b11cf833f6 (63296) PIT - LXCA Unable to manage RS160 (Endpoint inventory collection has failed) https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/39a52cb29895b2c4f1655b50a66a51c549a91269 (63715)[discovery_Inventory]Only get Memory information of B1 & B2 slot https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/2b52df7542e7b45f64be9a3c33d9a3de92f2d76d (64213)[discovery_Inventory][Riddler_Nov_SDV_LXCA][1.2.1-41]Motherboard LED & LXCA Light Path LED behavior are mismatch when trigger sensor https://gitlab.icelab.lenovo.com/pygcon/pyghmi/commit/fa20ef890cc2119a8038a772daab77dd6cfa04ca (67305)[discovery_inventory]When memory install solt 3 and slot 4,Memory Installed Bay Number display error on LXCA Inventory Details page. Change-Id: I291ca294ab490ce8f6913def95b2e663d6cefda2
pyghmi
Pyghmi is a pure Python (mostly IPMI) server management library.
Building and installing
(These instructions have been tested on CentOS 7)
Clone the repository, generate the RPM and install it:
$ git clone https://github.com/openstack/pyghmi.git
$ cd pyghmi/
$ python setup.py bdist_rpm
$ sudo rpm -ivh dist/pyghmi-*.noarch.rpm
Using
There are a few use examples in the bin folder:
fakebmc: simply fakes a BMC that supports a few IPMI commands (useful for testing)pyghmicons: a remote console based on SOL redirection over IPMIpyghmiutil: an IPMI client that supports a few direct uses of pyghmi (also useful for testing and prototyping new features)virshbmc: a BMC emulation wrapper using libvirt
Extending
If you plan on adding support for new features, you'll most likely be interested
in adding your methods to pyghmi/ipmi/command.py. See methods such as
get_users and set_power for examples of how to use internal mechanisms to
implement new features. And please, always document new methods.
Sometimes you may want to implement OEM-specific code. For example, retrieving firmware version information is not a part of standard IPMI, but some servers are known to support it via custom OEM commands. If this is the case, follow these steps:
- Add your generic retrieval function (stub) to the
OEMHandlerclass inpyghmi/ipmi/oem/generic.py. And please, document its intent, parameters and expected return values. - Implement the specific methods that your server supports in subdirectories in
the
oemfolder (consider thelenovosubmodule as an example). A OEM folder will contain at least one class inheriting fromOEMHandler, and optionally helpers for running and parsing custom OEM commands. - Register mapping policies in
pyghmi/ipmi/oem/lookup.pyso pyghmi knows how to associate a BMC session with the specific OEM code you implemented.
A good way of testing the new feature is using bin/pyghmiutil. Just add an
extension for the new feature you just implemented (as a new command) and call
it from the command line:
$ IPMIPASSWORD=passw0rd bin/pyghmiutil [BMC IP address] username my_new_feature_command