Hi,
I've implemented an additional 'interpolate' mode to augment the
existing 'replace' and 'merge' modes of hash_behaviour in Ansible.
- Motivation
An issue that affects our local adoption of Ansible is that it doesn't
allow much flexibility when overriding previous variable definitions
with more specific data. At the moment, the hash_behaviour option
allows a user to globally specify whether data should be replaced or
(hash-wise) merged, but otherwise doesn't provide much functionality.
We have some use-cases where it would be very useful to be able to use
more powerful expressions in vars files in order to allow a user to
specify exactly what replace or merging behaviour they want, case-by-case.
The new 'interpolate' mode I've implemented allows a user to use Jinja2
expressions to do just this.
- Example
To give a minimal example to show the syntax:
[servers] encapsulates the set of all servers, and has the following
variable defined:
Ignoring the code, but focusing on syntax, this is a bit off beaten path from the simplicity that Ansible is intended to create.
In my opinion, the usual complexity and confusion in userland of Ansible arises when people push it to far – when they wish to “code in YAML” rather than take the path of easiest management.
This is the force that we are always trying to resist – for every time we say “yes, we’ll do this too”, we die a small death.
While you say this locally impacts your particular case, the impact of having to explain it, read it, and maintain it – is a cognitive one that makes Ansible each time harder and harder to hold in someone’s mind.
In this case, it’s achievable by just using two variables
higher level
base_users:
group_vars/servers
server_exclude_users:
- alex
server_users: “{{ base_users | difference(server_exclude_users) }}”
One of the hardest things to do in Ansible land is please everyone, but I feel pretty strongly that preservation of things as a minimal framework is vitally important to prevent the need for someone to “re-Ansible Ansible”, and if it gets down that path of too much complexity after just two years, I feel we’ve made a lot of slippery slope decisions along the way.
So if this may exclude you from userland, that may suck – but I’ve had to move beyond the “this will keep me from using Ansible unless” arguments because they intend to something of a very heavy loaded gun. If we cave every time that argument is played, we die a thousand little deaths.
So I’m symptathetic about you wanting to do what you want to do – but in the end, Ansible wants to stay minimal, and in this case there’s another route.
Hi Michael,
I quite understand where you're coming from; indeed, one of the key aspects that makes Ansible attractive to us is that it _doesn't_ try to do everything, and it's possible to adaptably and sensibly extend and compose it with other systems that do their respective jobs well.
I apologise for inadvertently pressuring to accept this patch with an implicit, "Not accepting this patch will keep us from using Ansible"; I didn't mean to suggest that, and indeed, it won't: this was merely a quick experiment to see if this approach was viable. (The experiment was successful: it's not! 
The next obvious step for me is to design and implement some new code to hook into Ansible's dynamic inventory API, and take over variable- and group-management duties for our playbooks.
If I develop anything that I think might be sufficiently general that it might warrant inclusion in the main code-base, I'll be sure to send it up the line for consideration.
In any case, many thanks for the speedy analysis and detailed reply.
Cheers,
David
Yeah that’s all good, I probably read too much into things But yeah it’s a hard balance of when to say yes vs no, and I worry what happens if we do accept everything, what happens long term.
My other thought was “tell David this could be pluggable” - but I really don’t want another plugin here either, really. More cognitive load there too.
You may be in “I know what I want to do so I should write an inventory plugin” territory – indeed that was the idea for inventory, allow people ways to build systems that they like better – not just pull things from external DBs – if they so choose.
Thanks!