When conditional bug in Ansible 2.0.0.2 ?

Archives Ansible Project
1

Hi List,

So I got this great thing here:

- name: Copy custom nrpe plugins
template:
src: "{{ item }}"
dest: "{{ nrpe.plugins }}"
mode: 0755
owner: "{{ nrpe.user }}"
group: "{{ nrpe.user }}"
tags: update_nrpe

notify: restart nrpe
with_fileglob: "../templates/plugins/{{ nrpe_scripts }}/*"
when: nrpe_scripts is defined

Works a treat with 1.9, it would be really easy to add service checks for special server cases.

With Ansible 2.0.0.2 this breaks, because 2.0 tries to fill the fileglob before looking at the when: conditional. And since the nrpe_scripts is not defined for most servers, it breaks!

An ugly hack would be to put a general variable in group_vars/all that just makes it look into an empty directory or something.

Is this a bug? or intended?

Thanks,
Mark

2

This is expected. when statements work on each iteration of the with_ loop, and as such the when statements are effectively inspected after with_ loops.

Ansible 1.9 may have allowed this to pass due to a bug in logic, however 2.0 is more strict, and is properly failing.

3

Interesting.

But people would expect a time of “deprecated but works” at the least.
And besides, I find the original way more logical. (Which will be so for more people, necessitating a deprecation warning, not a complete failure)

I’m noticing a lot of stuff gone, sort of broken, changed behavior, between these two ansible versions. Not good for the mindset of people who I just managed to get onboard with Ansible.

Thanks,
Mark

4

The previous exception was ignored in this case, 2.0 does not ignore exceptions, that is the main difference.

5

Understood, we can call it all kinds of things, but companies and/or teams have been building playbooks with these things. They are now breaking.
One team I know is now using it as an excuse to start using puppet again as “Ansible is still a moving target”.

This isn’t a rant. … …well maybe a litte :wink: But it’s also an observation. Ansible really needs to be carefull with these sort of changes. I don’t want people to turn to other things because of things like this.

6

I’m not saying that it is not a problem, just that it is not as easy to mark as ‘deprecated’ when there was no knob to ‘turn off this feature’ but a general tightening on propagating and capturing errors.

7

see if this helps https://github.com/ansible/ansible/pull/14441