Description of problem: Newton -> Queens FFU upgrade: upgrade_steps_playbook.yaml fails: The error was: error while evaluating conditional ((cinder_api_apache.rc == 0) and (step|int == 2)): 'dict object' has no attribute 'rc' This is the playbook output: TASK [Stop and disable cinder_api service (pre-upgrade not under httpd)] ********************************************************************************************************************************************************************** skipping: [192.168.24.9] TASK [check for cinder_api running under apache (post upgrade)] ******************************************************************************************************************************************************************************* skipping: [192.168.24.9] TASK [Stop and disable cinder_api service] **************************************************************************************************************************************************************************************************** fatal: [192.168.24.9]: FAILED! => {"failed": true, "msg": "The conditional check '(cinder_api_apache.rc == 0) and (step|int == 2)' failed. The error was: error while evaluating conditional ((cinder_api_apache.rc == 0) and (step|int == 2)): 'dict object' has no attribute 'rc'\n\nThe error appears to have been in '/home/stack/tripleo-40rIhX-config/Controller/upgrade_tasks.yaml': line 302, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n when: step|int == 2\n- name: Stop and disable cinder_api service\n ^ here\n"} The 'Stop and disable cinder_api service' in https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/cinder-api.yaml#L220-L222 uses the cinder_api_apache.rc in the when conditional but the cinder_api_apache var only gets registered at step2 https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/cinder-api.yaml#L215-L219 hence the 'Stop and disable cinder_api service' task fails at any other step different than 2 because the cinder_api_apache var is not defined. This is the content of the generated upgrade playbook(with workaround for bug 1743758 to run the common tasks first): http://paste.openstack.org/show/646501/
Clarifications: * there is a valid bug for OSP 12->13 *upgrade_tasks* here... as per comment #0 the upgrade_steps_playbook.yaml fails and the referenced tripleo-heat-templates links identify the problem. I think the fix in https://review.openstack.org/#/c/536851/ is relevant here, which puts the "step" as the first conditional to be evaluated. * I am not sure how/why you are running the upgrade_steps_playbook for ffu; yes we will run it eventually, but after all the ffu tasks first. In which case, should we update this BZ title and make it about OSP12->13 upgrade? Marking triaged for now and adding /#/c/536851/ to trackers (and changing assignee to the owner of that review). I'll ask mcornea to clarify ^^^ and possibly update the title if it makes sense to do so.
(In reply to Marios Andreou from comment #1) > Clarifications: > > * there is a valid bug for OSP 12->13 *upgrade_tasks* here... as per > comment #0 the upgrade_steps_playbook.yaml fails and the referenced > tripleo-heat-templates links identify the problem. I think the fix in > https://review.openstack.org/#/c/536851/ is relevant here, which puts the > "step" as the first conditional to be evaluated. > > * I am not sure how/why you are running the upgrade_steps_playbook for ffu; > yes we will run it eventually, but after all the ffu tasks first. In which > case, should we update this BZ title and make it about OSP12->13 upgrade? It's very possible that the same issue affects OSP12->13 upgrade but I hit the issue reported initially during the FFU upgrade, while running the upgrade_steps_playbook according to the instructions in https://blog.yarwood.me.uk/2017/12/01/openstack_fastforward_tripleo_nova/#uc-ffu-and-upgrade-plays > Marking triaged for now and adding /#/c/536851/ to trackers (and changing > assignee to the owner of that review). I'll ask mcornea to clarify ^^^ and > possibly update the title if it makes sense to do so.
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-2018:2086