AWX, Ansible 2.19, and set_stats in workflows

Get Help
, , ,
1

Using AWX 24.6.1 and have a Workflow that has one node that finishes with a set_stats of a dictionary that contains some values that are strings with a value of “true”
In AWX we see the artifacts as string values, and in the next node of the workflow we see the extra vars with the dictionary with string values.
When the second node template runs and Ansible 2.18 is in the EE, the dictionary values contain the strings as expected

image
image638×300 12.7 KB

When we upgrade our EE to include Ansible 2.19 and change nothing else, this dictionary variable still shows in AWX Variables as having strings, but at execution time they have been converted to a Boolean value of true

image
image687×261 6.08 KB

Unfortunately, the Azure modules require that values for tags must be string, so this casting change causes the task to fail

image

We are temporarily getting around it by adding a new task to loop through the values and convert each to a string such as

    - name: Use a Jinja loop to create a new dictionary with string values
      ansible.builtin.set_fact:
        stringified_vm_tags: "{{ stringified_vm_tags | default({}) | combine({item.key: item.value | string}) }}"
      loop: "{{ vm_tags | dict2items }}"

Is this an intentional change or something broken with AWX? If I run from the CLI and provide the same extra_vars the strings stay as strings

Note: We had the same issue with a value that was in quotes as a string but contained only numbers and the same thing occurred where it converted it to an Int, which failed as well with the Azure modules that require that tags be strings

2

Hello,
funnily enough, it looks like the exact opposite of a change introduced in ansible 2.19 : (link here : https://github.com/ansible/ansible/blob/v2.19.5/changelogs/CHANGELOG-v2.19.rst#breaking-changes-porting-guide) :

" set_fact - The string values “yes”, “no”, “true” and “false” were previously converted (ignoring case) to boolean values when not using Jinja2 native mode. Since Jinja2 native mode is always used, this conversion no longer occurs. When boolean values are required, native boolean syntax should be used where variables are defined, such as in YAML. When native boolean syntax is not an option, the bool filter can be used to parse string values into booleans".

(yes, it’s about set_fact, not set_stats).

3

I wasn’t expecting this to be the case, but looks like " [No implicit conversion of non-string dict keys]" may be what is causing this

1 Like