Description of problem:
Client is doing a FFU.
At the command "upgrade run" it fails with the following:
2024-03-13 19:00:38.495328 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did not deploy successfully: 11 ~~~~~~~~~~~~~~~~~
^[[0;31m2024-03-13 19:00:38.495959 | The following node(s) had failures: computedpdksl-12, computedpdksl-13, computedpdksl-14, computedpdksl-15, computedpdksl-16, computedpdksl-17, computesl-13, computesl-14, computesl-15, computesl-9, undercloud^[[0m
2024-03-13 19:00:38.496609 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But those nodes were previously deleted:
2021-10-01 10:50:17.096502 overcloud-node-delete nodes=['computesl-0', 'computesl-1', 'computesl-2', 'computesl-3', 'computesl-4', 'computesl-5', 'computesl-6', 'computesl-7', 'computesl-8', 'computesl-9'],
The inventory file /home/stack/overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml is good
but the one in /home/stack/overcloud-deploy/overcloud/config-download/overcloud is wrong.
It gets recreated when the run command is ran.
I ask them for the index of the role computesl and got the following:
(heat) [stack@undercloud ~]$ openstack stack resource show 8659c656-e258-4f27-ade6-b7eae7ae28b7 9 --fit
~~~
| attributes | {'hostname_map': {'storage': 'computesl-9 ...
| creation_time | 2024-03-13T20:30:48Z
~~~
Can I trust this value of creation time ?
Because just before that time I see the prepare command was run:
2024-03-13 20:28:54.245842 overcloud-upgrade-prepare
In my lab it looks valid.
Now the question becomes why/how those old index appear suddenly.
We need your help to identify what is causing this here.
Thank you!
Version-Release number of selected component (if applicable):
OSP17.1.2
How reproducible:
100% here.
Steps to Reproduce:
1. Create OSP16.2 env
2. Delete nodes
3. Try FFU
4. Fail at run step.
Actual results:
FFU is failing because old nodes appear in the inventory file.
Expected results:
We should not have old nodes in there.
Additional info:
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 (Red Hat OpenStack Platform 17.1.3 bug fix and enhancement 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-2024:2741
Description of problem: Client is doing a FFU. At the command "upgrade run" it fails with the following: 2024-03-13 19:00:38.495328 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did not deploy successfully: 11 ~~~~~~~~~~~~~~~~~ ^[[0;31m2024-03-13 19:00:38.495959 | The following node(s) had failures: computedpdksl-12, computedpdksl-13, computedpdksl-14, computedpdksl-15, computedpdksl-16, computedpdksl-17, computesl-13, computesl-14, computesl-15, computesl-9, undercloud^[[0m 2024-03-13 19:00:38.496609 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But those nodes were previously deleted: 2021-10-01 10:50:17.096502 overcloud-node-delete nodes=['computesl-0', 'computesl-1', 'computesl-2', 'computesl-3', 'computesl-4', 'computesl-5', 'computesl-6', 'computesl-7', 'computesl-8', 'computesl-9'], The inventory file /home/stack/overcloud-deploy/overcloud/tripleo-ansible-inventory.yaml is good but the one in /home/stack/overcloud-deploy/overcloud/config-download/overcloud is wrong. It gets recreated when the run command is ran. I ask them for the index of the role computesl and got the following: (heat) [stack@undercloud ~]$ openstack stack resource show 8659c656-e258-4f27-ade6-b7eae7ae28b7 9 --fit ~~~ | attributes | {'hostname_map': {'storage': 'computesl-9 ... | creation_time | 2024-03-13T20:30:48Z ~~~ Can I trust this value of creation time ? Because just before that time I see the prepare command was run: 2024-03-13 20:28:54.245842 overcloud-upgrade-prepare In my lab it looks valid. Now the question becomes why/how those old index appear suddenly. We need your help to identify what is causing this here. Thank you! Version-Release number of selected component (if applicable): OSP17.1.2 How reproducible: 100% here. Steps to Reproduce: 1. Create OSP16.2 env 2. Delete nodes 3. Try FFU 4. Fail at run step. Actual results: FFU is failing because old nodes appear in the inventory file. Expected results: We should not have old nodes in there. Additional info: