Thanks, both of these responses are very helpful. I've restructured my 
playbooks a bit as per Serge's suggestions and also added this extra fail 
check for extra protection. Note that you can do some limited wildcard 
matching using the Jinja2 "in" expression:
- fail: msg="Don't accidentally run this on any of my mailservers" 
  when: "'mail' in inventory_hostname" 

This should match hostnames "mail", "emailserver", "mail0", etc.

On Friday, 6 December 2013 14:41:36 UTC-6, Kahlil Hodgson wrote:
>
> Serge's suggestion is more elegant, but if you are paranoid, you can 
> also add an early check to a task list: 
>
> --- 
> - fail: msg="Don't accidentally run this on my mailserver" 
>   when: inventory_hostname == 'mailserver' 
>
> - ... other tasks 
>
> just in case you inadvertently include the task list without checking 
> at a higher level. 
>
> K 
>
> Kahlil (Kal) Hodgson                       GPG: C9A02289 
> Head of Technology                         (m) +61 (0) 4 2573 0382 
> DealMax Pty Ltd                            (w) +61 (0) 3 9008 5281 
>
> Suite 1415 
> 401 Docklands Drive 
> Docklands VIC 3008 Australia 
>
> "All parts should go together without forcing.  You must remember that 
> the parts you are reassembling were disassembled by you.  Therefore, 
> if you can't get them together again, there must be a reason.  By all 
> means, do not use a hammer."  -- IBM maintenance manual, 1925 
>
>
>
> On 7 December 2013 07:12, Serge van Ginderachter 
> <[email protected] <javascript:>> wrote: 
> > 
> > On 6 December 2013 20:56, Andrew Martin <[email protected]<javascript:>> 
> wrote: 
> >> 
> >> Okay, so the only way to exclude a host is at the play level, not the 
> role 
> >> level? 
> > 
> > 
> > Yes. Roles are basically just some automation around a set of tasks. 
> > 
> >> It would be more ideal for my setup to exclude at the role level, that 
> way 
> >> I can ensure that any new play that is written that includes a 
> particular 
> >> role won't run it against blacklisted hosts. 
> > 
> > 
> > If you really want to be sure, add a conditional to the role tasks: 
> > 
> >    when: inventory_hostname != mailserver 
> > 
> >> Moreover, having hosts excluded at the play level means that entire 
> play 
> >> will be skipped on blacklisted hosts, but perhaps only 1 of the roles 
> in the 
> >> play is blacklisted, 
> > 
> > 
> > Yes, that is by design. You need to model playbooks to include roles and 
> > target a particular set of hosts. 
> >> 
> >> and so if the blacklist/exclusion happened at the role level then the 
> play 
> >> would run on the blacklisted host and just complete all of the roles 
> that 
> >> were allowed. 
> >> 
> >> For example, say I have a play called common.yml which sets up several 
> >> common features on hosts. It is defined as follows: 
> >>   roles: 
> >>     - ntp 
> >>     - postfix 
> >>     - smartmontools 
> >> 
> >> It would be nice to be able to just run the common.yml play against all 
> >> hosts, and have it configure ntp and smartmontools on all hosts but 
> only 
> >> postfix on the hosts which aren't mailservers. 
> > 
> > 
> > Then you need to split this up in multiple plays. Take the postfix role 
> out 
> > of 'common', as it is not common to all your hosts. 
> >> 
> >> Is this possible? If I add "- hosts: !mailserver" to common.yml, then 
> the 
> >> complete play will be skipped on "mailserver". 
> > 
> > 
> > should be   hosts: all:!mailserver   but yes 
> > 
> > 
> > Serge 
> > 
> > 
> > -- 
> > 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] <javascript:>. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>

-- 
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].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to