Creating a play-level variable from ouput of a task

Get Help
1

Is there a way to create a play-level variable (not a host-specific variable) from output of a task.

Let me first clarify on what i mean by play-level and host-specific . Consider the following example:
inv.yml

ungrouped:
  hosts:
    127.0.0.1:
      x: "host-specific-x"

play.yml

- name: Does not matter
  hosts: ungrouped
  gather_facts: false

  tasks:

  - name: Print play-level
    vars:
      x: 'task-specific-x'
    debug:
      msg: "{{ x }}"


  - name: Print host-specific
    debug:
      msg: "{{ x }}"

the output of running play.yml is

PLAY [Does not matter] *****************************************************************************************************************************************************************

TASK [Print play-level] ****************************************************************************************************************************************************************
ok: [127.0.0.1] => {
    "msg": "play-specific-x"
}

TASK [Print host-specific] *************************************************************************************************************************************************************
ok: [127.0.0.1] => {
    "msg": "host-specific-x"
}

seting x in play-level (to be more specific setting it as a task variable ) does not effect varialbe x which is set in inv.yml.

My question is, is there a way to imitate this behaviour when capturing output of a task. If i use register it will change the host-specific variable with the same name. Is there a way to capture output of a task using a play-level variable, which then only will be accessible for the rest of the play and will not effect the host-specific variable with the same name.

2

Can you clarify your use case / problem a bit more?

But it think the answer you are looking for is run_once:

Boolean that will bypass the host loop, forcing the task to attempt to execute on the first host available and afterward apply any results and facts to all active hosts in the same batch.

For example:

- hosts: all
  gather_facts: false
  tasks:

    - ansible.builtin.ping:
        data: "{{ inventory_hostname }}"
      register: ping_result
      run_once: true
      
    - ansible.builtin.debug:
        msg: "{{ ping_result.ping }}"

The debug prints the very first hostname for all the hosts due to the use of run_once.

1 Like
3

Hi, thanks for the reply.

consider the example below:

- name: Play one
  hosts: ungrouped
  gather_facts: false

  tasks:

  - name: Print some messge
    debug:
      msg: 1
    register: num

  - name: Increament by 1
    set_fact:
      num: '{{num.msg + 1}}'

  - name: print new value
    debug:
      msg: '{{ num }}'

in this example i just need the variable num only in the scope of this play and not anywhere else. In this case if i had another variable specific to this host, for example in my inventory.yml as follow

ungrouped:
  hosts:
    127.0.0.0.1:
      ansible_user: user
      ansible_ssh_pass: pass
      num: 99

the play would change the value 99 to 2. So every time when i want to register a value to a variable i should first check if the variable already exist somewhere else or not so i would not accidentally override a variable.

as you can see in my original question it seems play-variables and host-specific variables are living in two different space, and setting a play-varialbe is not overriding the host-specific variable with the same name. i want to know is there a way to capture output of a task without worrying if it would override the value of a host-specific variable with the same name or not?

4

If you are talking about when you’re writing your Ansible, then your statement is correct: you definitely should ensure the variable you are registering doesn’t mask another variable you may need later. (Unless that’s your intention of course.)

But if you are talking about at run-time, then, no, you should not somehow dynamically check for variable name collisions. Even if that were practical, what would you do? Halt the play? Pick a random variable name that the rest of your play would have to discover somehow?

The answer to your question is two fold. The first part is that variables come from many different places with defined but nuanced precedence. The guideline I was given years ago was to use the smallest subset of variable sources that still allows you to solve your problem, thus avoiding unwelcome surprises — particularly from variable precedence.

The second part is to use naming conventions. They don’t have to be hard and fast rules that cover every single case. It’s sufficient to have soft guidelines to avoid confusing yourself and those who come after you. But, if you can’t tell at a glance where a variable came from — and if it matters for the task at hand — then you need to rename either the host variables, your registered variables, or both.

There’s no built-in mechanism to avoid the issue you’ve described. One isn’t needed. Because what you’re trying to avoid may be exactly what someone else needs to do. In practice, clear variable names (in contrast to “num”) and naming conventions make this issue moot.

5

Thanks for the reply. As you mentioned the proper naming was the one reasonable solution that had crossed my mind. i was just curious is there any other solution or not.