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-2019:2811
Comment 18Red Hat Bugzilla
2023-09-14 05:42:34 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
In rocky, we updated the image for the overcloud running: openstack overcloud external-update run --debug --tags container_image_prepare In stein that command has no impact: PLAY [External update steps] *************************************************** PLAY [External deploy steps] *************************************************** PLAY RECAP ********************************************************************* compute-0 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 compute-1 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 controller-0 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 controller-1 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 controller-2 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 undercloud : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Thursday 08 August 2019 10:24:21 -0400 (0:00:00.551) 0:00:05.981 ******* =============================================================================== external_update_steps is empty so no worries there, but external_deploy_steps_tasks.yaml isn't and contains the container_image_prepare tag. But it's not run. doing: sudo podman exec -it mistral_executor bash and adding external to the list of tags to the run command, giving that: ansible-playbook-3 -vvv /var/lib/mistral/e2e16aca-291b-49a8-bfc1-2a8a1f2f4e40/external_update_steps_playbook.yaml --limit all --module-path /usr/share/ansible-modules --become --become-user root --inventory-file /var/lib/mistral/e2e16aca-291b-49a8-bfc1-2a8a1f2f4e40/inventory.yaml --tags external,container_image_prepare "$@" in /var/lib/mistral/config-download-latest/ansible-playbook-command.sh does trigger a run of the container_image_prepare associated tasks. Problem is with that change I8b3bf3ba3d7c2cfbe1187218c51f619e65efe0e5 When we switched from include to include_tasks we change the tags behavior. Here's an example: (undercloud) [stack@undercloud-0 ~]$ cat test.yaml --- - hosts: all gather_facts: no tasks: - name: "Include tasks file" include: tasks.yml - name: "Include_tasks tasks file" include_tasks: tasks1.yml (undercloud) [stack@undercloud-0 ~]$ cat tasks.yml - name: "Debug tag1" debug: msg: "init" tags: - tag1 (undercloud) [stack@undercloud-0 ~]$ cat tasks1.yml - name: "Debug tag1" debug: msg: "init1" tags: - tag1 now running: (undercloud) [stack@undercloud-0 ~]$ ansible-playbook -i my-inventory.yml ./test.yaml -t tag1 PLAY [all] ********************************************************************************************************************************************************************************************************** TASK [Debug tag1] *************************************************************************************************************************************************************************************************** ok: [undercloud] => { "msg": "init" } ok: [controller-0] => { "msg": "init" } ok: [controller-1] => { "msg": "init" } ok: [controller-2] => { "msg": "init" } ok: [compute-0] => { "msg": "init" } ok: [compute-1] => { "msg": "init" } PLAY RECAP ********************************************************************************************************************************************************************************************************** compute-0 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 compute-1 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 controller-0 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 controller-1 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 controller-2 : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 undercloud : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 we can see that only the "include" tasks are really included. The include_tasks has a different behavior, it doesn't look into the tasks for the tags there.