Hi,
I am proposing additional functionality be added to the combine filter which would allow for hashes containing lists and sets to be more effectively merged under certain use cases. This change would add a kwargs option to the combine filter named union which is a boolean option. When false, the default, the behaviour is identical to the current implementation, providing full backwards compatibility where this is not the desired behaviour. However, if it is set to true then when a list or set is encountered, the elements contained within are merged similarly to as if they had been combined using the union filter.
I have implemented this as a PoC within a role that I am working on under filter_plugins/smart_combine.py. I have written it in such a way that if this was a feature which would be acceptable for integration into Ansible, I would easily be able to integrate this code and create a PR, obviously adding any appropriate testing and documentation to go with the code.
Currently, the union option is only supported when running recursively and I am trying to determine if this makes sense that it should only work when also running recursively or whether it should support unioning the first level of a hash. If it should be supported I’d then need to think of the best way to allow union to be used without recursion; my current thoughts were to move the recursive option into merge_hash. This would make non-recursive unioning a little less efficient though and so if it is thought that unioning should be supported without having to enable recursion and someone has thoughts to better implement this I’d be happy to hear. My thoughts are that it’s justifiable to argue that unioning doesn’t make sense if not running recursively and that as long as well documented this should not cause a problem. In addition, given the validation restricts the use of union without recursive this functionality could be added in the future without risk of breaking usages of the filter.
I made the decision to only support merging of set and list types as these are the only two data types (from what I can see) that are supported by the YAML parser in which unioning makes sense. collections.Hashable is too broad and includes integers, strings, etc. which unioning would not be desirable for and since tuple types cannot be handled in the YAML parser at present I chose not to include it - additionally, it probably only makes sense for it to act on mutable types.
I look forward to hearing thoughts and feedback on this feature and to finding out if it would be welcome in Ansible.
Thanks,
Fabrizio Lungo