# Making "hosts: all" the default for playbooks?

**URL:** <https://forum.ansible.com/t/making-hosts-all-the-default-for-playbooks/12230>\
**Category:** Ansible Project\
**Created:** [January 22, 2013, 4:32am UTC](https://forum.ansible.com/t/making-hosts-all-the-default-for-playbooks/12230 "2013-01-22T04:32:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nolan\_Darilek](https://avatars.discourse-cdn.com/v4/letter/n/919ad9/32.png) [@Nolan\_Darilek](https://forum.ansible.com/u/Nolan_Darilek)\
**Post date:** [January 22, 2013, 4:32am UTC](https://forum.ansible.com/t/making-hosts-all-the-default-for-playbooks/12230/1 "2013-01-22T04:32:19Z")

</div>

I am steadily evolving my understanding of Ansible. I came to Ansible before Puppet or Chef, so am slowly learning how I should be using it vs. what I thought I should be doing a few months ago. That said, I don't know if what I'm requesting makes sense or doesn't.

Initially I thought of playbooks as things I'd build to perform certain complex tasks, but my understanding has evolved to "things ranging from complex tasks to entire system configurations." Currently I have one playbook that includes a number of other playbooks/tasks to build up an app server with my preferred stack. I have another playbook that calls other tasks/playbooks to install Redmine, Jenkins, SCM-Manager and other apps that I use to develop other software.

So I find myself using playbooks to define server roles, and tasks/task includes to define actions I'd run on a number of servers regardless of what role they'd fill. I don't use host groups in inventory files at all. I understand the need, but for the apps I build at the scale I operate, a single server can run everything, and I don't need an app/database server for a single app. It's nice to know that I can grow into that, but for now it's just extra complexity and ceremony I don't need.

Instead of having to specify "hosts: all" in half a dozen playbooks, could we make that the default? I don't discount the need for tying a specific playbook to a specific group of hosts, but defaulting to all would seem to make the simplest cases even simpler. Assume that if I don't specify a series of hosts, then I mean everything. I've been testing playbooks enough on Vagrant to know that you're not likely to run a playbook on production servers without testing it. So why not make the extra complexity opt-in, rather than making it opt-out for those of us lucky enough to have simple use cases?

Thanks.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [January 22, 2013, 12:44pm UTC](https://forum.ansible.com/t/making-hosts-all-the-default-for-playbooks/12230/2 "2013-01-22T12:44:37Z")

</div>

> Instead of having to specify "hosts: all" in half a dozen playbooks, could  
> we make that the default? I don't discount the need for tying a specific  
> playbook to a specific group of hosts, but defaulting to all would seem to  
> make the simplest cases even simpler. Assume that if I don't specify a  
> series of hosts, then I mean everything. I've been testing playbooks enough  
> on Vagrant to know that you're not likely to run a playbook on production  
> servers without testing it. So why not make the extra complexity opt-in,  
> rather than making it opt-out for those of us lucky enough to have simple  
> use cases?

Nope. Those that have exactly one type of server are in the minority.

Making someone consciously make that decision is quite important in  
both documentation and safety. Playbooks are meant to be AUDITABLE  
and contain the description of what they do and  
where. They are not meant to be accidentally run on the wrong boxes.

The entire definition of a play is to map policy to a particular  
subset of hosts.

For saving you a single line we'd be causing a lot of potential  
damage, and reducing the ability for things to be easily skimmed to  
find out what they do... and where.
