Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1793175

Summary: Incorrect location for overcloud kernel and ramdisk for overcloud nodes is mandated when ipxe_enabled=False
Product: Red Hat OpenStack Reporter: Jeremy Freudberg <jfreudbe>
Component: python-tripleoclientAssignee: midavies
Status: CLOSED ERRATA QA Contact: Sasha Smolyak <ssmolyak>
Severity: high Docs Contact: RHOS Documentation Team <rhos-docs>
Priority: high    
Version: 16.0 (Train)CC: aschultz, bfournie, dtantsur, hbrock, jamsmith, jfreudbe, jslagle, mburns, midavies, shdunne
Target Milestone: z2Keywords: Triaged
Target Release: 16.0 (Train on RHEL 8.1)   
Hardware: ppc64le   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-tripleoclient-12.3.2-0.20200226135426.27ace2c.el8ost Doc Type: Bug Fix
Doc Text:
This update fixes a bug that caused the `openstack overcloud node import` command to fail with iPXE disabled ('ipxe_enabled=False'). With iPXE disabled, you must use the `--http-boot` argument to specify the location of kernel and ramdisk images (`--http-boot /var/lib/ironic/tftpboot`). Previously, the `openstack overcloud node import` command ignored the `--http-boot` argument. The nodes failed to deploy. Now the `openstack overcloud node import` command responds correctly to the `http-boot` argument and the nodes are deployed as expected.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-14 12:15:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeremy Freudberg 2020-01-20 20:55:53 UTC
Description of problem:
Some revised functionality of ``openstack overcloud node import`` hard-codes a folder path rather than respecting a CLI arg, with no ill effect (and arguably intentional) in the ipxe_enabled=True case, but overcloud nodes are not successfully created in the ipxe_enabled=False case, as when deploying ppc64le nodes

Version-Release number of selected component (if applicable): python-tripleoclient >= 12.1.0

How reproducible: every time

Steps to Reproduce:
1. Set ipxe_enabled=False in undercloud.conf
2. In accordance with that option, use --http-boot /var/lib/ironic/tftpboot for the various ``openstack overcloud ...`` commands that expect it, including ``openstack overcloud image upload `` and ``openstack overcloud node import``
3. Kickoff overcloud deploy

Actual results: Nodes cannot be deployed, as ironic nodes are looking for kernel/ramdisk in /var/lib/ironic/httpboot rather than /var/lib/ironic/tftpboot as instructed

Expected results: Nodes get deployed

Additional info:
This should be fixed ideally in the TripleO CLI itself, i.e. the ``openstack overcloud`` commands should just do the right thing.
The following workaround is possible...
for node_uuid in $( openstack baremetal node list -f value -c UUID ) ; do
    dk_old=$(openstack baremetal node show $node_uuid -f json | jq -r " .driver_info.deploy_kernel")
    dr_old=$(openstack baremetal node show $node_uuid -f json | jq -r " .driver_info.deploy_ramdisk")
    rk_old=$(openstack baremetal node show $node_uuid -f json | jq -r " .driver_info.rescue_kernel")
    rr_old=$(openstack baremetal node show $node_uuid -f json | jq -r " .driver_info.rescue_ramdisk")
    openstack baremetal node set $node_uuid --driver-info deploy_kernel="${dk_old/httpboot/tftpboot}"
    openstack baremetal node set $node_uuid --driver-info deploy_ramdisk="${dr_old/httpboot/tftpboot}"
    openstack baremetal node set $node_uuid --driver-info rescue_kernel="${rk_old/httpboot/tftpboot}"
    openstack baremetal node set $node_uuid --driver-info rescue_ramdisk="${rr_old/httpboot/tftpboot}"
done

Comment 2 Bob Fournier 2020-01-29 15:36:24 UTC
Looks like an issue, on import the driver_info is not configured to the http-boot setting.

$ openstack overcloud node import instackenv-hp-test.json --http-boot /tmp/images

$ openstack baremetal node show hp-dl360-g9-03 | grep driver_info
| driver_info            | {'deploy_kernel': 'file:///var/lib/ironic/httpboot/agent.kernel', 'rescue_kernel': 'file:///var/lib/ironic/httpboot/agent.kernel', 'deploy_ramdisk': 'file:///var/lib/ironic/httpboot/agent.ramdisk', 'rescue_ramdisk': 'file:///var/lib/ironic/httpboot/agent.ramdisk', 'ipmi_password': '******', 'ipmi_username': 'Administrator', 'ipmi_address': '10.9.103.29'} |

Comment 4 midavies 2020-02-10 05:22:46 UTC
I've pushed a fix for this upstream for consideration by the community.  Please see https://review.opendev.org/706735

Comment 5 midavies 2020-02-11 21:01:04 UTC
And the upstream fix has merged.

Comment 6 midavies 2020-02-13 02:22:01 UTC
Backport proposed to stable/train https://review.opendev.org/#/c/707518/

Comment 7 midavies 2020-02-27 01:56:09 UTC
(In reply to midavies from comment #6)
> Backport proposed to stable/train https://review.opendev.org/#/c/707518/

And this has merged into stable/train

Comment 8 Jeremy Freudberg 2020-03-05 20:38:07 UTC
revised doc text to describe a resolution rather than an unfixed issue

Comment 16 Bob Fournier 2020-04-23 14:27:39 UTC
Verified with OSP-16z2, compose 4/6/2020. RPM python3-tripleoclient-12.3.2-0.20200405044622.fdce01f.el8ost.noarch

We can see that httpboot is being used now.
$ openstack overcloud node import --http-boot /tmp/images instackenv-hp-only.json

$ openstack baremetal node show hp-dl360-g9-02 | grep driver_info
| driver_info            | {'deploy_kernel': 'file:///tmp/images/agent.kernel', 'rescue_kernel': 'file:///tmp/images/agent.kernel', 'deploy_ramdisk': 'file:///tmp/images/agent.ramdisk', 'rescue_ramdisk': 'file:///tmp/images/agent.ramdisk', 'ipmi_password': '******', 'ipmi_username': 'Administrator', 'ipmi_address': '10.9.103.29'} |

Comment 20 errata-xmlrpc 2020-05-14 12:15:29 UTC
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-2020:2114