Dear Ansible community,
First, I would like to express my thanks for all the work done around Ansible. We are using it each day, and we love it. We even made a whole cluster stack around it! Part is opensource, other parts of this stack are closed and developed by some companies. However, reading news around Ansible future, we found that "*merge*" hash_behavior is expected to be removed. The deprecation of the merge hash_behavior is a major issue for us. A huge part of our stack relies on this feature, we planned many new things relying on it, our modularity comes from it, and such a regression for a flexible tool like Ansible was not expected. I understand this feature can be misused. However, it is explicitly expressed in the documentation and in the configuration file that *merge *is not recommended unless you know what you are doing. I think, personally, that this is system administrator duty to take the risk or not, as long as the risks are clearly detailed. Many Ansible users see Ansible as a production only tool. Users grab Ansible, then grab roles on the web, create a *static *inventory for all of this, and push configuration. And so, I understand developments are going this way. However, in our case, we are doing a *unified stack*, that must *adapt *to all our customers, and so our inventory must be *flexible*, and our roles able to optionally "communicate". We are using Ansible because this is such a great tool, but we are not using it the standard way, and we know that. It would be a pity that some users are blamed and nonstandard usages becomes deprecated in Ansible, because some other users did not take time to understand a "potentially dangerous" feature. If this is due to development efforts, I/we would even be ready to help maintain the merge hash behavior if needed. Some examples of usage: - Multiple teams in our companies are working on different roles. Each team brings its part of the unified inventory with its role. Since we need data to be centralized, team’s rpm packages simply bring new files for the inventory, and we tune them according to customer need. Some central feature (security, high availability, etc) gather part of all these files, using merge, to obtain their final configuration. Simple, flexible, stable. This behavior is clearly due to the fact that we are doing a unified stack: some roles are independent; some offer optional combination capabilities. Again, this is not the "standard" static way, but why not using Ansible for these kind of advanced usage? - Some of our dicts are huge (VERY VERY HUGE), as we have sometime thousands of hosts and complex data. We split them into multiple files, to ease reading, again using merge. - For some groups, we define "default" global parameters in group_vars/all, and each group can override their desired values in their dedicated group_vars. We only add the modified values in the dedicated group_vars, so when someone is reading inventory, it is easy to check what is the global default, and what was modified from this global value for a specific group. This is relying on merge. - Etc. I know we are asking a lot, and asking is easy, since we are not developing it, but would it be possible to reconsider the *merge *deprecation? Combine filter, proposed as an alternative, cannot replace merge, as it assumes you know the inventory, which is not the case when you create roles that must adapt to many inventories. With my best regards Ox -- 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/80b74225-0e7e-43c0-9d84-5074d628206b%40googlegroups.com.
