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.
On Monday, June 27, 2016 at 3:28:40 PM UTC+3, James Lott wrote:
>
> 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?
>
> On Wednesday, February 17, 2016 at 8:10:52 PM UTC-5, breatheoften wrote:
>>
>> I echo Adam Brown. I use this pattern a lot. I'd really like a good
>> alternative if this is going away ...
>>
>> Here's another real-world example that is generating these deprecation
>> warnings from my current in-use code:
>>
>> (inside a var file)
>> some_project:
>> git:
>> repo: "git://..."
>> dest: "{{ some_magic_path }}"
>> force: yes
>> version: "5.1"
>> recursive: no
>>
>> some_project2:
>> git:
>> repo: "git://..."
>> dest: "{{ some_magic_path }}"
>> force: yes
>> version: "5.1"
>> recursive: no
>> ...
>>
>> (inside some playbook)
>> tasks:
>> - name: "Ensure correct version of some source code fetched into a
>> magic place via git"
>> action: git
>> args: "{{ some_project.git }}"
>> tags:
>> - fetch_some_project
>>
>> Thanks to this deprecation I'll have to use this much more verbose
>> pattern (or is there a better way)?
>>
>> tasks:
>> - name: "Ensure correct version of some source code fetched into
>> magic place via git"
>> git:
>> repo: "{{ some_project.git.repo }}"
>> dest: "{{ some_project.git.dest }}"
>> force: "{{ some_project.git.force }}"
>> version: "{{ some_project.git.version }}"
>> recursive: "{{ some_project.git.recursive }}"
>>
>> This second approach is worse for a few reasons:
>>
>> - its more verbose and repetitive
>> - 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 ...
>>
>> On Thursday, January 28, 2016 at 6:48:12 AM UTC-8, Adam Brown wrote:
>>>
>>> We currently use this pattern a lot to pass asymmetrical data into a
>>> module, like so:
>>>
>>> - hosts: localhost
>>> vars:
>>> percona_dbs_to_create:
>>> - name: test1
>>> encoding: utf8
>>> collation: utf8_general_ci
>>> login_host: 192.168.222.2
>>>
>>> - name: test2
>>> encoding: utf8
>>> collation: utf8_general_ci
>>>
>>> tasks:
>>> - name: Create databases
>>> action: mysql_db
>>> args: "{{ item }}"
>>> with_items: percona_dbs_to_create
>>>
>>> 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?
>>>
>>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/7f1424cd-ffe6-429c-86ca-6a73007d46ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
