'changed_when' is not a valid attribute for a IncludeRole

Bug #1829795 reported by John Dennis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Triaged
Medium
wes hayutin

Bug Description

This error occurs in triplo-quickstart when running against Ansible 2.8

changed_when is clearly not a member of include_role. More recent versions of Ansible have been more aggressive about reporting invalid parameters. My guess is that this was previously a nn-op and was silently ignored but now it's a hard error.

I believe the solution is simple, simply delete the changed_when line. To the best of my knowledge the include_* Ansible commands were never meant to generate notifications, instead the content being included is responsible for notifications.

Here is the error:

TASK [setup/undercloud : include_tasks] ****************************************
task path: /home/jdennis/src/openstack/tripleo-quickstart/roles/libvirt/setup/undercloud/tasks/main.yml:44
Monday 20 May 2019 14:20:52 -0400 (0:00:03.198) 0:40:10.716 ************
fatal: [warp]: FAILED! => {
    "reason": "'changed_when' is not a valid attribute for a IncludeRole\n\nThe error appears to be in '/home/jdennis/src/openstack/tripleo-quickstart/roles/libvirt/setup/undercloud/tasks/inject_repos.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: upload repos on the images\n ^ here\n"
}

Tags: ci
Revision history for this message
wes hayutin (weshayutin) wrote :

Yes, ansible versions support various features.
We are working to bring support up to 2.7.x then will get to 2.8

For now you will have to use the version in the requirments.txt. Sorry for that.

tags: added: ci
Changed in tripleo:
status: New → Opinion
status: Opinion → Triaged
importance: Undecided → Medium
milestone: none → train-2
assignee: nobody → wes hayutin (weshayutin)
Revision history for this message
Sorin Sbarnea (ssbarnea) wrote :

Maybe we should add a test with ansible version that triggers a fail, to avoid this. I am 100% sure that our code would not work with Ansbile 2.8 so is better to add a fail when we know it, a fail that would be removed when we fix it.

PS. I am not in favor of a generic fail which would fail on new version by default, only when we know not to work.

Revision history for this message
John Dennis (jdennis-a) wrote :

I don't think the situation with Ansible 2.8 is as bad as you are imagining. I've been developing a new role for tripleo-quickstart-extras and it needed a feature in Ansible 2.7, I discovered only one issue related to Ansible 2.7 and filed this bug #1823787.

In a new development tree pip ended up installing Ansible 2.8 instead of 2.7 and I discovered the issue described here.

So far, moving from 2.6 to 2.7 and then to 2.8 only 2 minor issues have come to light (there might be more waiting to be discovered because I haven't fully exercised a full deployment yet) but my general take is newer versions of Ansible are not packed with land mines waiting to explode. (Of course that doesn't address the non-fatal warnings that show up, only the hard failures).

Changed in tripleo:
milestone: train-2 → train-3
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.