Description of problem: OSP11 introduces the usage of Virtual BMC to simulate IPMI on libvirt VMs. When configuring Virtual BMC we need to specify the ip and port on which the VBMC should listen to. This ip/port is then referenced into the instackenv json file. If the user specify a non standard IPMI port (623) the instackenv validation fails with the following error. Error: Unable to establish IPMI v2 / RMCP+ session ERROR: ipmitool failed Skipping validation, registering nodes and introspecting them works fine. Version-Release number of selected component (if applicable): 11 How reproducible: Always Steps to Reproduce: 1. Configure virtual bmc - use non standard ports 2. create an instackenv json file 3. run openstack baremetal instackenv validate Actual results: For each node: Error: Unable to establish IPMI v2 / RMCP+ session ERROR: ipmitool failed If running verbose: Checking node 192.168.122.1 Identified baremetal node Executing: ipmitool -R 1 -I lanplus -H 192.168.122.1 -U admin -P xxx chassis status Error: Unable to establish IPMI v2 / RMCP+ session ERROR: ipmitool failed We can see that the cli is not passing the -p port option and instead uses the default port. Expected results: cli should use the port referenced into the instackenv (pm_port) Additional info: # vbmc list +---------------------+---------+---------+------+ | Domain name | Status | Address | Port | +---------------------+---------+---------+------+ | overcloud-ceph01 | running | :: | 6230 | | overcloud-ceph02 | running | :: | 6231 | | overcloud-ceph03 | running | :: | 6232 | | overcloud-compute01 | running | :: | 6233 | | overcloud-compute02 | running | :: | 6234 | | overcloud-ctrl01 | running | :: | 6235 | | overcloud-ctrl02 | running | :: | 6236 | | overcloud-ctrl03 | running | :: | 6237 | | overcloud-networker | running | :: | 6238 | +---------------------+---------+---------+------+ instackenv: "nodes": [ { "pm_user": "admin", "mac": [ "52:54:00:1b:b1:ee" ], "pm_type": "pxe_ipmitool", "pm_port": "6235", "pm_password": "xxx", "pm_addr": "192.168.122.1", "capabilities": "profile:control", "name": "overcloud-ctrl01" }, (...)
Hi! Indeed, this command has not been updated for ages. We have a new validation workflow that should be used instead. This should be easy to fix for OSP 12, but for 11 is requires backporting this new workflow. I will ask the folks if it's possible. If it's not, I'll fix it for 12 on. A workaround is to not use this command for now.
*** Bug 1442879 has been marked as a duplicate of this bug. ***
The fix was done by Tony in Rocky, but we may be able to backport it to Queens. Note that the fix is introducing a new flag to another command, since the command in question was removed in Queens.
Installed latest OSP13 $ cat /etc/yum.repos.d/latest-installed 13 -p 2018-08-07.4 $ rpm -qa | grep python-tripleoclient* python-tripleoclient-9.2.3-4.el7ost.noarch Verified that Gerrit changes were included in this release. Verified that fixed or later version of python-trippleoclient is installed. Please reopen if this issue is still present.
This bug is marked for inclusion in the errata but does not currently contain draft documentation text. To ensure the timely release of this advisory please provide draft documentation text for this bug as soon as possible. If you do not think this bug requires errata documentation, set the requires_doc_text flag to "-". To add draft documentation text: * Select the documentation type from the "Doc Type" drop down field. * A template will be provided in the "Doc Text" field based on the "Doc Type" value selected. Enter draft text in the "Doc Text" field.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2574