That hash syntax I find around the include is pretty uncommon for the way most people write playbooks. While we do accept arbitrary YAML, I'd suggest you standardize.
Using "tags" to mean something other than ansible tags is also confusing, especially as "tags" in Ansible does not take a hash/dictionary. In any case, there is no include+with_items. Removing such a feature has made not explaining how it works and where it does not INFINITELY better on the mailing list, as it was a 50 questions a day sort of thing. I'm not up for bringing it back. The solution is to utilize the loop inside your playbook, or where you already have a loop, change to a nested loop using "with_nested". On Tue, May 27, 2014 at 2:22 PM, Stephen Gargan <[email protected]>wrote: > Not to flog a dead horse as there are numerous threads about not allowing > with_items and includes, but I have a narrower use case that I could really > use this for and hopefully someone can help me here. > > I have a script that I use to spin up new cloud vm instances, the > variables specific to the instance are passed in at runtime, something > along the lines of > > - hosts: localhost > connection: local > gather_facts: True > > - {include: playbooks/create_instance.yml, > instance_type: 'c3.xlarge', > tags: { > hostname: 'xyz-server', > cluster_name: '{{cluster_name}}', > ansible_names: ['xyz-server1'] > }, > } > > I'd like to be able to add a with_sequence to this so I could spin up more > than one at a time. Something along the lines of > > - hosts: localhost > connection: local > gather_facts: True > > - {include: playbooks/create_instance.yml, > instance_type: 'c3.xlarge', > tags: { > hostname: 'xyz-server{{item}}', > cluster_name: '{{cluster_name}}', > dns_names: ['xyz-server{{item}}'] > }, > with_sequence: start={{start}} end={{end}} > } > > Unfortunately I get the deprecated warning > > ERROR: [DEPRECATED]: include + with_items is a removed deprecated feature. > Please update your playbooks. > > I realize that its easy to get burned with this, but in this case there is > only a single host so no danger of the variables resolving differently on > different hosts. > > A workaround mentions pushing the loop down into the playbook, but that > playbook is pretty modular and calls other playbooks so would require > pushing the loop code into each of these. > > Any suggestions of how this could be handled? I'm about to resort to a > shell script to repeatedly call my playbook but it seems wrong. > > Instead of outright vetoing it, might a 'caveat emptor' approach be more > appropriate, a warning outlining the danger but ultimately letting it > execute? If I burn myself I'll only have myself to blame > > thanks > > Steve. > > -- > 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/a4c3e42f-d8f5-472a-9f2d-0c3f841baa9f%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/a4c3e42f-d8f5-472a-9f2d-0c3f841baa9f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CA%2BnsWgz3un%3DwFgESSf7ZAwo%2Baf8RQJ9PZMkpQBhb6E-YJwZUPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
