"My main problem there is that I have x hosts with y application instances on each; in it's current incarnation there is no way to 'limit' on a set/single application instance(s). The only way I can think of doing this is by also writing it all out such as:"
Can't say I have time to review all your playbooks but --limit hostname exists and is a thing. On Wed, Jul 16, 2014 at 2:19 AM, Nico K. <[email protected]> wrote: > OK, but any advice on my initial post in this thread? > My main problem there is that I have x hosts with y application instances > on each; in it's current incarnation there is no way to 'limit' on a > set/single application instance(s). The only way I can think of doing this > is by also writing it all out such as: > > name: update application server 1 on host x > action: whatever > tags: update-application-server-1 > > Which in my case would result in more than 90 of these blocks. > > Op dinsdag 15 juli 2014 17:34:56 UTC+2 schreef Michael DeHaan: >> >> You can't do what you ask above. >> >> You should pass a variable into the role as a role parameter and have >> loops on the individual task steps. >> >> >> On Tue, Jul 15, 2014 at 5:16 AM, Nico K. <[email protected]> wrote: >> >>> I've also been playing with the idea of doing the following: >>> >>> - include: x.yml var={{item}} >>> with_sequence: ... >>> >>> Sadly, includes are no longer allowed to be used in conjunction with >>> 'with_items'. >>> Same goes on playbook level, invoking a role multiple times in a loop >>> isn't allowed either. >>> >>> Now I know that the best practice supposedly is to use loops within >>> tasks, but for me that really doesn't work since this role consists of like >>> 30 tasks that would all require the same loop around them, to me it makes >>> much more sense if I can define the loop before including the file instead >>> of having to write the same loop 30 times. >>> >>> Anyway, I'm still having the feeling that I should aim at a different >>> approach; surely there must be other people who have servers with multiple >>> instances of an application on it? >>> >>> -- >>> 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/89e9a9e7-01c8-45df-9228- >>> 634626504d3e%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/89e9a9e7-01c8-45df-9228-634626504d3e%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/54396c20-ab5a-46b6-94fa-bf0de8e4de7b%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/54396c20-ab5a-46b6-94fa-bf0de8e4de7b%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%2BnsWgzoJfAvwm4-VDWdhLHjUit31SSc_LzCDaeCJgoGYCc7Yw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
