I’m trying my playbooks with Ansible 2.0, and ran into a few minor issues:
The Ansible upgrade guide says “Using variables for task parameters is unsafe and will be removed in a future version.” What does this mean exactly? I use variables in task parameters all the time – this seems fundamental to Ansible. Can you clarify this? Is it only when you define variables and use them in the same task, like in the example?
When my source and destination boxes are Linux, and I deployed a template with Windows line endings, they used to be converted to Unix line endings (in Ansible 1.9). Now the Windows line endings are preserved, but I didn’t see this in the changelog.
The upgrade guide says I should receive a deprecation warning in this case: “Bare variables in with_ loops should instead use the “{{var}}” syntax, which helps eliminate ambiguity.” But I’m not getting that warning for things like “with_items: some_variable”.
This is, in our opinion, very unsafe - especially when that variable may come from something like a fact. It has not been disabled, but will be removed after 2 major versions.
I was unaware of any feature where we silently converted Windows line endings to POSIX-compliant versions, but you can open an issue in Github for this.
Finally, this may be an oversight, or a bug in which the deprecation message for bare variables in loops is not being triggered correctly. This is fairly minor, but we can look into that as well.
To make this work in the future, we’d have to redefine the default value of login_host for the test2 item in percona_dbs_to_create. That’s not bad for a small example like this, but gets out of hand quickly when dealing with larger data sets that contain a lot more options.
Is there another way to address this situation that I’m missing?
suppose I have many such git repositories and want to centralize the declaration of their parameters for ease of auditing (as in some_project1, some_project2, …). Suppose I hit an edge case when I add a some_projectN repository and discover that I actually need to pass in a value of the accept_hotkey parameter as an argument when checking out that repository. I hadn’t been specifying this value for all the other repo’s. For example suppose I discover I need to allow invalid hostkeys with the accept_hotkey parameter. I need to either –
(1) go back and specify a value for this parameter for all the similar uses of the git module, then also go to all occurrences of the tasks and add this new parameter
(2) override the task call site associated with some_projectN and add in the additional accept_hotkey parameter (losing the auditing ease of declaring all these magic git properties together in one place and requiring special case knowledge at each task call site)
I think this is a pretty unhelpful change – especially without introduction of a good alternative …
Yeah this is pretty concerning. I’m not sure I understand the safety concern in cases where facts are not being used, since variable data is being provided by the administrator, and is pretty trustworthy. This is a feature with valid use cases that’s being blown away for some very elusive reasons… Is anyone on the core development team able to recommend a pattern which would solve the problems presented by the previously mentioned use cases?
Removing the function because usage of it is dangerous is like stop using cars because they are dangerous.
It’s much better to write documentation about the dangerous ways of using it and keep the tool because it useful for many other reasons. User should take a decision what tools to use.