Forcing the -l parameter in ansible-playbook

Archives Ansible Project
1

Hi,

we are using a few on-demand playbooks for upgrading, formatting and re-installation purposes. Currently, all of these files use a hosts: all pattern for flexibility. However, this means that we’ll have to be extremely careful to always include an -l SUBSET parameter which specifies the subset we want to act on.
Is there a way to always ensure that a subset has been specified?
I understand that Ansible’s focus is a bit more on the idempotent side of server management, so in that sense there may be no need for this. But it certainly would make me sleep better when those destructive tasks had another security layer before them. :slight_smile:

Cheers
/rike

2

Hi,

W dniu środa, 7 sierpnia 2013 12:51:29 UTC+2 użytkownik Rike-Benjamin Schuppner napisał:

Hi,

we are using a few on-demand playbooks for upgrading, formatting and re-installation purposes. Currently, all of these files use a hosts: all pattern for flexibility. However, this means that we’ll have to be extremely careful to always include an -l SUBSET parameter which specifies the subset we want to act on.
Is there a way to always ensure that a subset has been specified?
I understand that Ansible’s focus is a bit more on the idempotent side of server management, so in that sense there may be no need for this. But it certainly would make me sleep better when those destructive tasks had another security layer before them. :slight_smile:

How about hosts: $host inside playbook and ansible-playbook -e host=foo.example.com destroy-everything.yml?

That should at least fail safe :slight_smile:

Best regards,
Grzegorz Nosek

3

Or for some default values:

hosts: “{{ host | default(‘foo’) }}”

Then you can run:
ansible-playbook play.yml -e host=bar #run on host bar
ansible-playbook play.yml #run on host foo

W dniu środa, 7 sierpnia 2013 12:51:29 UTC+2 użytkownik Rike-Benjamin Schuppner napisał:

4

Thanks. These are great ideas. I thought of using a variable somehow but did’t think of putting it inside the hosts-definition.

5

This is what I do on a few playbooks that would be dangerous to run on "all". Instead of a --limit which could be too greedy, I force my users to specify a : separated host list and only use that.

-jlk