ansible version available as fact?

Archives Ansible Project
1

I have a task that works on devel but not on 1.5.4. I assume it’s because of https://github.com/ansible/ansible/commit/2a976a

  • authorized_key: user={{ item|basename }} key=“{{ lookup(‘file’, item) }}”
    with_fileglob:
  • “…/…/…/…/keys/*”

We have ansible installed on all our production machines so we can do -c local deploys. I don’t want to upgrade those machines off of a “stable” version – if we’ve gotten far enough to run a -c local, at least some of the keys have been installed and we can skip the step.

So I figured I’d just gate the task on ansible_version or some such. However, there doesn’t appear to be such a variable, and I can’t find anything like that in -m setup.

Is there some way of figuring out if we’re running 1.5 or 1.6 or later and using that in a task?

Alternatively, is there a way of making my task work on 1.5? It worked on 1.2 and 1.3 (with a different path).

thanks,
Bryan

2

Not quite yet. Have a look at https://github.com/ansible/ansible/pull/6619

3

​For now I guess you could work around with a pipe lookup running ansible
--version​

​In the mean time also https://github.com/ansible/ansible/pull/6835 was
merged, ​which gives you a version_compare filter.

   Serge

4

I’ve got a role that works in 1.6 but crashes in 1.5. (My guess is that this fixes it: https://github.com/ansible/ansible/commit/2a976a)

The crashing task is this:

  • authorized_key: user={{ item|basename }} key=“{{ lookup(‘file’, item) }}”
    with_fileglob:
  • “…/…/…/…/keys/*”

The role is one that I’m happy running manually for now, so I thought I’d gate it with something like:

roles:

  • { role: ‘users’, when: ‘ansible_version is defined’ }

(this assumes https://github.com/ansible/ansible/pull/6619 will land soon. For now, I’m just using -e)

This skips the role, but it’s still being parsed and crashing ansible.

Suggestions?

5

If you would ever like to report a crash, including the “result” of the crash is needed to understand the context.

Can you please paste the result you are receiving?

6

I’m not sure why you want the backtrace; it’s already fixed in 1.6 by https://github.com/ansible/ansible/commit/2a976a. I’ve attached the backtrace at the end of this email.

The actual crash is not my concern. There are several different ways that you can crash ansible on skipped roles. Another way to do it is via

with_sequence: start=1 end={{ numFoo }}

where numFoo is 0. That obviously should be an error when the task is run. What is surprising that ansible still crashes with “can’t count backwards” even if you tell it to skip the role containing the task:

  • { role: ‘foo’, when: ‘numFoo > 0’ }

This can be worked around through judicious use of the default filter. It’s just annoying. My original email in this thread outlined a situation where I couldn’t find a workaround, and asks for one. I can run ansible 1.6 locally, but I need my playbook to be compatible with 1.5. It’s OK if it skips problematic plays.

thanks,
Bryan

7

If you would ever like to report a crash, including the "result" of the

crash is

needed to understand the context.

Can you please paste the result you are receiving?

I'm not sure why you want the backtrace; it's already fixed in 1.6 by
https://github.com/ansible/ansible/commit/2a976a. I've attached the
backtrace at the end of this email.

It's entirely because you send an email reporting a crash :slight_smile:

The actual crash is not my concern.

Should have probably indicated that in the first email :slight_smile:

There are several different ways that you can crash ansible on skipped
roles. Another way to do it is via

    with_sequence: start=1 end={{ numFoo }}

where numFoo is 0. That obviously should be an error when the task is
run. What is surprising that ansible still crashes with "can't count
backwards" even if you tell it to skip the role containing the task:

Conditionals are applied per loop step, not before the loop is evaluated.