So I have two tasks, that, based on a conditional run a command and register the output to a variable name. It’s only possible to execute one task or the other – not both…
but
since both try to register the same variable name, it appears that both registers still happen… if the 2nd task is the one I’m executing, then everything works fine. If it’s the first task, then it appears that the 2nd task clears the registered variable, and causes subsequent logic to fail.
I’ve seen this behavior on 1.4.4 and HEAD (as of now-ish)
Below is a sample playbook you can run to demonstrate the situation. If you run:
ansible-playbook test.yml -e todo=add
then things work as expected. If you run:
ansible-playbook test.yml -e todo=revoke
then you get an error about “One or more undefined variables: ‘dict object’ has no attribute ‘stdout’”
test.yml:
“then you get an error about “One or more undefined variables: ‘dict object’ has no attribute ‘stdout’””
for which task again?
I’m having difficulty following the purpose of the example.
I will remind the list that I have a pet peeve about “doesn’t work” in which case I don’t know what “doesn’t work” means. What is the failure mode, etc?
Do you mean the example with the “revoke” is the only one that does things?
(Also, I’d suggest --tags over “-e”, makes for clearer playbooks!)
Another tip:
debug: msg=“{{ victimOutput.stdout }}”
debug: var=victimOutput.stdout
The task “success output” would fail, because victimOutput is undefined.
The pasted playbook and commands are light enough to run and demonstrate what I’m talking about.
Okay, I’ve modified the demo playbook to look like this:
rereading this one more time, I see that I still had the when: todo == conditionals still in the playbook. Removing those two lines appear to make the playbook run as expected.
Does that indicate there might be some conflict between “when” and “register” functions?
“The pasted playbook and commands are light enough to run and demonstrate what I’m talking about.”
Yes, but it’s requiring everyone on the mailing list to run them to see what you mean.
It’s like sharing a connect-the-dots picture without the dots connected.
Which, with the amount of time I personally have, is not so good 
It’s registering a null when the task is skipped.
Solution would be to use different variables.
Consider that when running against an array of 500 hosts and keying off, say, the OS type, not all of them may be the same OS type.
Different variables would cause me to handle the success and failure notifications multiple times. I swapped over to using tags, as you suggested, and now avoid the situation all together.
It might be worth noting somewhere that a skipped task can still register a variable. That’s not what I was expecting. I dunno… maybe that’s too esoteric.
It might be worth noting somewhere that a skipped task can still register a variable. That’s not what I was expecting. I dunno… maybe that’s too esoteric.
As a good practice, I set a default value for every registered variable that I expect. i.e.
In my role defaults/main.yml file
my_registered_var.changed: false
A bit tedious, but makes for more independent tasks.
Hmm…
I would not expect people to do this, and also it won’t work for most people unless you are using the “merge hash behavior” config setting, which is non-standard (and often not something you want).