Hi I’m trying to use set_fact but am struggling with extracting it’s contents later in the playbook:
name: set ldap_host
action: set_fact ldap_host=“blah”
name: check ldap_host
fail: msg=“something screwed up”
only_if: “‘{{ansible_facts["my_ldap_host"]}}’ != ‘$ldap_host’”
what am I doing wrong in only_if section?
Can I ask where you learned only_if?
It’s old stuff that I hoped we purged all references to.
I don’t know where you have my_ldap_host set, but it would just look like this:
when: my_ldap_host == ldap_host
I can see it here in the module documentation:
http://www.ansibleworks.com/docs/modules.html/#debug
and fail
http://www.ansibleworks.com/docs/modules.html/#fail
Thanks I am going to file a ticket to remove those!
thanks, changing the code to the above seems to have worked. However I’ve got to ask: does it mean that ansible facts are kind of like “global variables” that are set depending on host processed? I thought access to facts was via complex structures like ansible_* is there a document outlining those fine details about “facts” ?
ansible facts have values that vary per host, so they are not global.
Certain variables like ansible_ssh_host mean something special when set in inventory, and this is useful as an inventory variable, but they are not facts. They are just variables set on each host.
Facts would refer to variable data derived from running the ‘setup’ module (which gets run automatically) or other modules that return an “ansible_facts” dictionary, which are usually refered to as “custom facts modules”
During our Ansible meetup I noted a list of items that are confusing.
One of the items on my list was the differences between facts or variables, their context, the internal data-structure and how they are being 'injected' when they are used/substituted.
Not just because it is often hard to foresee which value a variable/fact may have (given they live in the same namespace) also because it is sometimes unclear/ambiguous how they are being processed.
I think the documentation should make this more clear, and point out the pitfalls.
Things that should be mentioned:
- the different data-structures that 'host' these variables/facts
- where they could come from
- how certain variables (e.g. group variables) may be overriden by other
groups the system is part of (and what the policy here is, last
processed group wins ? how does this mechanism works with multiple
inventory scripts ?)
- play-specific variables are local to the play, other facts or variables
are always global, they outlive the play and exist over playbooks in a
single run ?
Only someone with an intimate knowledge of the internals can do this though.
Also some better way to inspect these different data-structures and/or a mechanism to understand where a value comes from could help here. The obvious goal here is to create awareness as this is not something we can easily fix in the design at this point.
Happy to try to make this more clear…
" - the different data-structures that ‘host’ these variables/facts
Not sure I understand this part, can you elaborate?
I think this is what the precedence section of the “Advanced Playbook” page was written to answer:
http://www.ansibleworks.com/docs/playbooks2.html#understanding-variable-precedence
It’s a fine line to balance between overwhelming someone, making someone know how to use it, and sharing how the code works (which someone should not be expected to understand), but I’m all for making this easier to understand, if we can also make it still remain concise and not too technical.
I don’t think facts are global (they apply only to (or about) the host) so I think we’re having some sort of terminology disconnect. They live beyond a play, yes!