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/bbbb03a0-7bb4-43fc-8074-70bd8b4024e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
