Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option
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 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 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 > datacenters, and later a specific subnet might over-ride other settings. > This way I could have all my European systems default to using settings > that applied to the entire zone, but my servers in different datacenters > would get settings specific there (i.e. a Git or NTP server, etc), and > individual subnets might have different NTP servers but still use the > datacenters' Git server. > > > > Merging hashes was a big win for this project. Sadly, we don't have a > "single source of truth", so we had to use multiple Ansible variable files > to build up our "truth" and merging them with each other. Our inventories > were not the source of truth with all the information needed. Without an > external CMDB that could take into account the location, datacenter, and > subnet (to name a few constraints), getting the data consistent would have > been impossible with Ansible. > > > > I'm not a programmer to the level that I can determine a better way to > address this in Ansible, but I'm hoping someone will work through a way to > merge them together and the hash merge behavior can be exposed again. > > > > On Sunday, September 27, 2020 at 9:56:00 AM UTC-5 dick@geant.org > wrote: > >> > >> > >> > >> 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 > punctuation. > > > > -- > > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to ansible-proje...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/b618283e-ef76-44c6-be23-d2e4d7f346a8n%40googlegroups.com > . > > > > -- > Dick Visser > Trust & Identity Service Operations Manager > GÉANT > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8502280a-842d-413f-8c02-a5e9edf7558dn%40googlegroups.com.
Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option
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 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 datacenters, and later > a specific subnet might over-ride other settings. This way I could have all > my European systems default to using settings that applied to the entire > zone, but my servers in different datacenters would get settings specific > there (i.e. a Git or NTP server, etc), and individual subnets might have > different NTP servers but still use the datacenters' Git server. > > Merging hashes was a big win for this project. Sadly, we don't have a > "single source of truth", so we had to use multiple Ansible variable files to > build up our "truth" and merging them with each other. Our inventories were > not the source of truth with all the information needed. Without an external > CMDB that could take into account the location, datacenter, and subnet (to > name a few constraints), getting the data consistent would have been > impossible with Ansible. > > I'm not a programmer to the level that I can determine a better way to > address this in Ansible, but I'm hoping someone will work through a way to > merge them together and the hash merge behavior can be exposed again. > > On Sunday, September 27, 2020 at 9:56:00 AM UTC-5 dick@geant.org wrote: >> >> >> >> 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 >> punctuation. > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ansible-project+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/b618283e-ef76-44c6-be23-d2e4d7f346a8n%40googlegroups.com. -- Dick Visser Trust & Identity Service Operations Manager GÉANT -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAL8fbwNw-277QrfM5vugZ0C%2BTX4bL_VqT%3DpZzSmWVeLzQAY3SQ%40mail.gmail.com.
Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option
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 datacenters, and later a specific subnet might over-ride other settings. This way I could have all my European systems default to using settings that applied to the entire zone, but my servers in different datacenters would get settings specific there (i.e. a Git or NTP server, etc), and individual subnets might have different NTP servers but still use the datacenters' Git server. Merging hashes was a big win for this project. Sadly, we don't have a "single source of truth", so we had to use multiple Ansible variable files to build up our "truth" and merging them with each other. Our inventories were not the source of truth with all the information needed. Without an external CMDB that could take into account the location, datacenter, and subnet (to name a few constraints), getting the data consistent would have been impossible with Ansible. I'm not a programmer to the level that I can determine a better way to address this in Ansible, but I'm hoping someone will work through a way to merge them together and the hash merge behavior can be exposed again. On Sunday, September 27, 2020 at 9:56:00 AM UTC-5 dick@geant.org wrote: > > > 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 > punctuation. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/b618283e-ef76-44c6-be23-d2e4d7f346a8n%40googlegroups.com.
Re: [ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option
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 punctuation. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAL8fbwP0A8CQ3H0RRnr9sbkocJjWCmSvd%2BH-cLaddMHZqSUA7g%40mail.gmail.com.
[ansible-project] deprecation of DEFAULT_HASH_BEHAVIOUR option
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 depend on getting merged on the inventory level. For example I have a "nginx" dictionary with "vhost" key in it. I depend on all vhosts from all groups a host is in to get merged. I have something like this for nearly all my roles. I could rewrite my playbook to merge all dictionaries with a group prefix using the combine filter (or similar workarounds) prior to including any roles. But I think this results in much less readable playbooks and it definitly results in multiple person days of work... The other option I look into is writing a custom inventory plugin to always deep merge dictionaries with the same name, kind of resulting in the current behavior. Anyone else with a similar problem or some insight on why this was changed? I was realy taken by surprise when I saw this message. If i could choose, I'd prefere deepmerge as default over "replace". It results in better split up inventories and more seperation of data in multiple files. "Replace" always seemed kind of useless and less useable to me. Best regards, nd -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/155ef9b6-63b1-4fcd-a71b-817199a54084n%40googlegroups.com.
