Indirect lookup of facts

Archives Ansible Project
1

Hello,

In 1.8, the ability to reference a fact indirectly (as opposed to having to statically type it out) was broken. This used to give you the fact myFact:

{{ vars[‘myFact’] }}

This capability is very important to me, and I will not be able to continue to progress with Ansible unless this issue is resolved: it’s a very common pattern we see in microservices world to have things like OUR_SQL_SERVER_HOST, OUR_SQL_SERVER_PORT, and my scripts make extensive use of looking up facts with names like this via indirect references (so, depending on my vars, I might ask for OUR_SQL_SERVER_HOST or JANES_SQL_SERVER_HOST). I’m not seeing any traction or sympathy in getting this capability back based on the issue that was filed, #10859 [1], and the basic debugging that I’ve done shows that things in this realm of the codebase got refactored at some point to a really weird place.

I’d really appreciate some TLC being put in on this major regression in functionality.

There’s some argument that this was never intended to be a feature, to which I’d ask: 1) why not, clearly they were present, and it brings parity to what we can do with looking up vars, and 2) I’d say that mdehann should have said it wasn’t a feature when I said I was using it[2]- imo, it was an inject, thus exposed, so clearly it was a feature. This is an important capability, and I believe my use-case does an adequate job of stating where I’m coming from. Please restore vars to working order, such that we can lookup facts, giving us parity with hostvars, or at least provide a feasible new path, such that we’re not here hanging out.

Thanks kindly,
rektide

[1] https://github.com/ansible/ansible/issues/10859
[2] https://github.com/ansible/ansible/issues/5000

2

The supported way to access facts indirectly is {{
hostvars[inventory_hostname]['myFact'] }}, this already gives you the
ability you are asking for.

The refactoring you mention fixed many problems with variables and
exposed many more, this is part of why there is even further
refactoring in v2. Specifically there were a few security issues
caused specifically from facts bleeding into 'trusted' data, which
means there are certain things we cannot really reverse.

In any case, I'm not sure why you need a 2nd way to do so nor why
there should be 2 features with 'parity' which really means the same
feature. As to what was intended and not, 'hostvars' was created
explicitly to allow access, 'vars' is an aftereffect of templating and
how modules were defined, which was getting incorrectly updated in
some scopes.

If vars were the only way to access the data I would agree with you,
but given that there is an explicit method of doing so already, I'm
not inclined to do so.

3

Hostvars cannot access facts:, or at least, they previously could not. I’ll draw up some additional diagnostics on the state of affairs in the gist on #10859 (https://gist.github.com/rektide/c83208ccf4ab84638546) and provide an update with whether there’s inaccessible data or no.

Thanks for the reply, very much hope you are correct. I’m hugely in favor of big changes, big overhauls, and I don’t mind having to update my code at all- so godspeed Ansible, hail hail 2.0!

4

That won't work, hostvars is an object and not a dumpable var, this is
how you access facts through hostvars:

    - debug: msg="{{hostvars[inventory_hostname]['ansible_distribution']}}"