RIP --override-hosts, and how to workaround it

Archives Ansible Project
1

Discussion in 3 parts.

(A)

I'm sure this will be slightly unpopular, but --override-hosts needs to go.

As some of you are aware, override hosts was actually broken on devel for a few days. I just spent a few hours trying to fix it and came to an unexpected conclusion.

It's incompatible with the new inventory API if we assume that override hosts should also retain group info and at the same time represent hosts not in inventory. Not incompatible, but it has a code cost that I'd judge "not worth it"

(B)

If you're using this feature, don't panic.

As restricting to certain hosts was a useful use case, I am proposing making the following work instead:

ansible-playbook all --extra-vars="group=stage"

And in the playbook:

hosts: $group

If you have stage_webservers and prod_webservers, this can be two groups. Seems easy enough to me, and if you don't like that, you can pass in any hosts you like. This is universal, it's always going to work, and it's a lot less specialized than --override-hosts.

(C)

The only case it doesn't cover is managing a host NOT in inventory, but having a playbook named 'all' just to make that work is weird. Because if you ran that playbook without --override-hosts it would run against everything, and that's destructive anyway.

So I think adding the playbook to inventory isn't terrible.

If this bothers you, TECHNICALLY, you could wrap ansible-playbook in a really dumb script and achieve exactly what --override-hosts does.

cat hostname > /tmp/inventory
ansible-playbook foo.yml -i /tmp/inventory

Because you can already support multiple inventory files with -i.

--Michael

2

What api and code changes are you making for this?

B/c I need to be able to give ansible arbitrary hosts (independent of
an inventory file) to be able to use it for arbitrary connection for a
number of api-using scripts I'm currently writing.

If you just want to get rid of it o nthe cli, so be it, but if you make
me write out an inventory file just to connect to N hosts then we have
a problem.

-sv

3

What api and code changes are you making for this?

so far:

override_hosts is no longer a parameter.

extra_args which already exists is now usable to replace “hosts”, which doesn’t help your case below

B/c I need to be able to give ansible arbitrary hosts (independent of
an inventory file) to be able to use it for arbitrary connection for a
number of api-using scripts I’m currently writing.

If you just want to get rid of it o nthe cli, so be it, but if you make
me write out an inventory file just to connect to N hosts then we have
a problem.

Hmm. Yeah.

Easiest thing I think is we teach the “host_list” parameter to accept a list again, and if present it uses it versus loading from file.

This means it would be just like this:

host_list=[“a”,“b”,“c:2222”]

This can be done with a small tweak in inventory.py – I’ll see about adding that (back – I think we sorta had it before) tonight.

They would be in the “ungrouped” group.

In this case, no inventory would be loaded at all.

–Michael

4

raaarg.

Not to be too confusing on this, my logical problem with --override hosts was that people wanted it to get data from inventory, that is, operate as a “–restrict-hosts-to” while also operating as “–add-these-hosts-that-dont-exist”. This couldn’t work easily.

Given, add-these-hosts-that-don’t exist is actually useful, I’m suggesting something here that will leave this available on the CLI, but only in the latter form (adding hosts not in inventory and ignoring inventory), and make it clearer that this is being done.

As I want to minimize CLI options, this is probably just going to be:

ansible all -i “host1,host2,host3”

The way we would detect this would be if the inventory list contains commas. So if you had only one:

ansible all -i “host1,”

This is about a two line change to inventory.py and preserves most of the feature. I just wrapped my brain around a rock trying to make the feature do what someone intended in both cases at once.

I’ll make this so.