Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option

2020-09-30 Thread Maurice Meyer
Values can be nulled by setting them to '~', so I don’t see this as a corner case. dick@geant.org schrieb am Mittwoch, 30. September 2020 um 11:59:28 UTC+2: > I can see how this feature would work by overriding nested items by > merging. > But now I think of it again, I had trouble if I

Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option

2020-09-30 Thread Dick Visser
I can see how this feature would work by overriding nested items by merging. But now I think of it again, I had trouble if I wanted to remove/unset a nested item later? IMHO it's this sort of corner cases that make things difficult. On Sun, 27 Sep 2020 at 22:00, Dan Linder wrote: > > I'll second

Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option

2020-09-27 Thread Dan Linder
I'll second ND that the hash_behavior option of "merge" is more usable in my situation - I have hashes of information that get built up in the playbook (one piece sets defaults for a location (i.e. "North America" vs "Europe" vs "Asia"), then a later part sets defaults for different

Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option

2020-09-27 Thread Dick Visser
On Sun, 27 Sep 2020 at 13:44, nd wrote: > Hello, > > is there any documentation on why this was deprecated? According to the docs: This feature is fragile and not portable, leading to continual confusion and misuse -- Sent from a mobile device - please excuse the brevity, spelling and

[ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option

2020-09-27 Thread nd
Hello, is there any documentation on why this was deprecated? This breaks close to all of my ansible roles as well as it results in a full rewrite of the inventory for all organisations where I use ansible. I'm using "hash_behaviour = merge" Most of my inventory resides in dictionaries wich