Some of the things brought up in blog have already been discussed and/or are under way, I’ll try to link existing info on those, for others I’m going to comment inline.
One thing we have been planning since 2.0 (but keep delaying) is making it real plugins again: https://github.com/ansible/proposals/issues/41, this opens up to features like a common cache, cache invalidation, common config, etc.
A feature that I was contemplating, after making them all ‘real plugins’, is to state ‘enabled plugins and order’. It would default to ‘dir,script,ini,yaml’ to keep the current behaviour, each plugin requires a state from the target (is dir? is executable? is file?).
On the issue of ‘unrelated/equal depth’ groups variable precedence or ‘deterministic configurable hierarchy’, there is a new variable ‘ansible_group_priority’, introduced in 2.2 but not used yet, which was planned to allow the user to define specific ‘variable merge priority’. I’m hoping to add the merging logic in 2.3 or 2.4, keeping the current group name sorting as the ‘tie breaker’ and default when priorities are absent.
Root/normal/merge groups: I don’t see much use of making this additional classification, I would argue that these already exist and have to do with how users define the groups. I don’t see the need for having a declaration and/or restriction on this.
Constructed/dynamic/pattern groups: this is something I see as very useful and had thought of adding a plugin that would deal with these (group3 = group1:&group2)
Role var spec/discovery
https://github.com/ansible/proposals/issues/39
Role versioning
https://github.com/ansible/proposals/issues/23
As for the variable merging and or scoping to targeted group, I think it is already too complex and that adding more on top is going to make it harder and not easier.
When a machine is a member of 2 groups and you duplicate variables you need to think, do I want the same config to change on the machine if I refer to it as group1 or group2?
This seems counter intuitive to me, that the variable or group classification are incorrectly scoped.
I know plenty of people disagree with me on this one, in my experience most of their group structure was derived from other systems that did not look at the host as a whole but as a partial snapshot from a certain viewpoint, which can cause conflicts or ‘bouncing’ when each viewpoint is ‘executed’. I think the current view from Ansible makes more sense, it looks at the host as a whole and gives you 1 truth for it.
For example, the most common case I get is cluster/master, master machines are part of the cluster and tend to have a subset of settings that need to differ, the easy solution is making the ‘masters’ group a child of cluster, so it inherits the general settings but can override what is needed, the ansible_group_priority mentioned above should solve most other cases that do not fit parent/child. The other is application vs environment (dev/stage/prod) groups, which can be solved teh same way.
That said, I do agree that we need better information on how/where variables are set.