Bug 1416530

This bugzilla has been removed from the release and needs to be reviewed for targeting another release.

A small correction: we don't support virtual nodes in the overcloud, only in the undercloud. Changing the subject accordingly.

Setting priority to high, as SSH drivers are very likely to be removed in early Pike.

I'd propose to document the workflow upstream

Added the initial stab at documenting the process (see external links)

To verify need to see that it's possible to manually switch from pxe_ssh to virtualbmc.

We have upstream documentation outlined in http://tripleo.org/environments/virtualbmc.html#migrating-from-pxe-ssh-to-virtualbmc. Do we need to clone this bug against the documentation component now?

Hi Mike, we'd need verifying wether the current documentation upstream is enough to describe how to move from pxe_ssh to vbmc + pxe_ipmitool. After that, we can request documenting it downstream (and include any additional information found during the verification).

Hi Ramon,

I agree and the upstream documentation "Migrating from pxe_ssh to VirtualBMC"[1]
is lacking specific information to point to adding support for the 
pxe_ipmitool driver.  It should provide references on how to enable this driver
for both undercloud and overcloud use cases.

For example: 
[stack@undercloud-0 ~]$ openstack baremetal driver list
+---------------------+----------------------------------------------------------------+
| Supported driver(s) | Active host(s)                                                 |
+---------------------+----------------------------------------------------------------+
| ipmi                | overcloud-ironic-0.localdomain, overcloud-ironic-1.localdomain |
| pxe_ssh             | overcloud-ironic-0.localdomain, overcloud-ironic-1.localdomain |
+---------------------+----------------------------------------------------------------+

If we follow the steps 'Creating virtual BMC'[2] in current doc: "If you already have a virtual cloud deployed and want to migrate from the deprecated pxe_ssh driver to pxe_ipmitool using VirtualBMC, follow Creating virtual BMC, then update the existing nodes to change their drivers and certain driver properties:" then do next steps in the current documentation the user would have following error as need below example:
"No valid host was found. Reason: No conductor service registered which supports driver pxe_ipmitool. (HTTP 400)"

[stack@undercloud-0 ~]$ openstack baremetal node set ironic-0     --driver pxe_ipmitool     --driver-info ipmi_address=172.16.0.1     --driver-info ipmi_port=6232     --driver-info ipmi_username="admin"     --driver-info ipmi_password="password"
No valid host was found. Reason: No conductor service registered which supports driver pxe_ipmitool. (HTTP 400)



[1] http://tripleo.org/environments/virtualbmc.html#migrating-from-pxe-ssh-to-virtualbmc
[2] http://tripleo.org/environments/virtualbmc.html#creating-virtual-bmc

Thanks Mike, +1, good catch. Users who have followed the upstream documentation "Bare Metal Instances in the Overcloud" [1] will find this issue as this documentation in the examples shows how to test the functionality with pxe_ssh by setting:

parameter_defaults:
    IronicEnabledDrivers:
        - pxe_ssh

Meaning that this will be the only available driver.

I'd suggest creating a patch that adds this information to the upstream VirtualBMC documentation [2].

As part of the migration, if coming from an upgrade, the templates with the TripleO parameter IronicEnabledDrivers should be updated to contain pxe_ipmitool.

[1] https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/baremetal_overcloud.html#configuring-and-deploying-overcloud

[2] https://docs.openstack.org/developer/tripleo-docs/environments/virtualbmc.html

upstream doc review has completed today. https://review.openstack.org/#/c/460338/

Hi
Can you either:
- add the gerrit ID of the actual change so that we can doble check if we did got the actual fix?
- or check if our current downstream build is OK?
Thanks

Hi Thierry, the upstream documentation patch is mentioned in comment #12. Downstream documentation is expected to follow by the documentation team. It is my understanding there isn't any code patch required.

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/RHEA-2017:3462