Workflows allow AAP, AWX, and Ascender to visually connect playbooks together. This works great…until you try and pass variables from one job template(playbook and required parts in Ascender) to another. That’s where the set_stats module comes in. It has the ability to pass between workflow jobs, but the documentation doesn’t fully explain how it works, and some much needed functionality doesn’t exist…so this blog post will show you how to work around these limitations!

Video

set_fact Vs set_stats

set_fact

If you are to the point in your automation journey where you are playing with workflows I’m going to go out on a limb and say you’ve already used the set_fact module. In short, it allows you to create and/or set the contents of a variable. Here’s an example:

1
2
3

- name: What am I having for lunch?
  ansible.builtin.set_fact: 
    lunch: tacos

This works a treat unless you want to pass this variable to another job template in a workflow…these variables are scoped to the individual job template only, but there is a workaround.

set_stats

The set_stats module looks pretty similar to set_fact…so for example:

1
2
3
4

- name: What am I having for lunch?
  ansible.builtin.set_stats: 
    data:
      lunch: tacos

The only real difference I see here beyond a different module name, is an option called “data” and then my new variables. So it should feel fairly familiar. One of its key features is that set_stats variables(depending on how I create them) can be passed to another job template in a workflow! Its operation, however, is quite different.

Functional Differences

By default set_facts will instantiate a “lunch” variable(lunch as in the variable name from the above example) for each host, and each host can have different contents of the “lunch” variable.

As for set_stats, by default it does not do per host and the information is aggregated. This means if I have 10 hosts, there is only 1 set_stats, and when I set new information in the variable it will just start smashing it all together.

Playbooks And Examples

You can find my playbooks here in my ansbile-misc repository.

First is the playbook doing collection(set-stats-test.yml) and I’ve got a second playbook that displays all of the information(set-stats-test2.yml). They are in two playbooks so that I can build a workflow. I’m only going to cover the collection playbook, though.

I’ll show one or two tasks and then results from the second playbook to give you an idea of what each does.

Per Host Stats

1
2
3
4
5
6
7
8
9
10
11
12

  - name: per_host true and aggregate true
    ansible.builtin.set_stats:
      data:
        dist_ver_per_host_true_agg_true: "{{ ansible_facts.distribution_version }}"
      per_host: true
 
  - name: per_host true and aggregate false
    ansible.builtin.set_stats:
      data:
        dist_ver_per_host_true_agg_false: "{{ ansible_facts.distribution_version }}"
      per_host: true
      aggregate: false

These two tasks both set the per_host option to true, but one has aggregation enabled. The results in the second job template for these variables are:

1
2

    "dist_ver_per_host_true_agg_true = not set",
    "dist_ver_per_host_true_agg_false = not set",

As you can see, neither option actually made it to the second job template…odd, huh? This is because workflows don’t pass per host stats. The stats info is passed as extra vars to the rest of the playbooks, which is why it won’t do per host information.

Not Per Host

1
2
3
4
5
6
7
8
9
10
11
12

  - name: per_host false and aggregate true- default behavior
    ansible.builtin.set_stats:
      data:
        dist_ver_per_host_false_agg_true: "{{ ansible_facts.distribution_version }}"
      per_host: false
 
  - name: per_host false and aggregate false
    ansible.builtin.set_stats:
      data:
        dist_ver_per_host_false_agg_false: "{{ ansible_facts.distribution_version }}"
      per_host: false
      aggregate: false

These two tasks don’t do per host, so their info should be passed. One is using aggregation and one is not. By default set_stats has per_host false and aggregate: true. Here are the results:

1
2

    "dist_ver_per_host_false_agg_true = 8.68.8",
    "dist_ver_per_host_false_agg_false = 8.8"

So the two hosts I’m running this against return different info; one passes back 8.6 and the other passes 8.8.
As you can see the default action will just start smashing together all of the returned information, which, generally, isn’t that helpful, unless you are really just passing over simple information.

The second task with aggregation turned off simply returns the value of the very last host processed…which also isn’t always that useful in certain situations.

Per Host Stats Workaround

There is a workaround for passing per host information!

1
2
3
4
5
6
7
8
9
10
11

  - name: per host collection and aggregate false via a workaround
    ansible.builtin.set_stats:
      data:
        dist_ver_per_host_agg_false: "{{ dist_ver_per_host_agg_false | default({}) | combine({ inventory_hostname : { 'ver' : ansible_facts.distribution_version}}) }}"
      aggregate: false
 
  - name: per host collection and aggregate true via a workaround
    ansible.builtin.set_stats:
      data:
        dist_ver_per_host_agg_true: "{{ dist_ver_per_host_agg_true | default({}) | combine({ inventory_hostname : { 'ver' : ansible_facts.distribution_version}}) }}"
      aggregate: true

Looking at both tasks, there is a lot going on in a single line…let’s break it down:

1

        dist_ver_per_host_agg_false: "{{ dist_ver_per_host_agg_false | default({}) | combine({ inventory_hostname : { 'ver' : ansible_facts.distribution_version}}) }}"

This is actually one long line(even if there is word wrap on it).
It takes the existing variable and builds on it.
default({}) sets the variable to empty if it doesn’t exist(it’s really a way around causing an error).
combine joins two dictionaries together(which is what we are creating). This one builds the variable out with the additional information.

Here are the results when run:
First task

1
2
3

  "dist_ver_per_host_agg_false": {
    "greg-rocky86nonlts": {
      "ver": "8.8"

Second task

1
2
3
4
5
6
7

  "dist_ver_per_host_agg_true": {
    "greg-rocky86lts": {
      "ver": "8.6"
    },
    "greg-rocky86nonlts": {
      "ver": "8.8"
    }

You can see the first task has aggregate turned off, so it only shows whatever host was processed last…which means it’s not really per host!

The second task returns information for all of my hosts! This means that I can collect and pass per host information from one job template to another in a playbook!

Just to bring it all home, here’s the variables section for the second job template(shows variables passed as “extra vars”):

Conclusion

While it’s not always necessary, it is beyond useful to pass per host information in your workflows, and how you have a solid method to do so! If you have any tweaks or tunes you’d make to this, please let me know.

Good luck, and happy automating!