New host module: how it should behave.

Hi

I refactored the host module and want to explain how it behaves and I am very interested in your opinions and feedback.

You can find and test the pull request here https://github.com/ansible/ansible/pull/5065.

I wanted the host module to be simple with no much magic.

Primary Keys:

There are 2 primary keys:

  • 1st IP
  • 2nd hostname

But the IP is now separated by IPv (IPv4 and IPv6). This means:

  • you can have the same hostname twice (for each IPv).

  • host module will not switch IPv, so an IPv4 entry will not become an IPv6 entry.

Loopback IPs:

Loopback IPs e.g. 127/8 and ::1 (maybe we could extend this to link local networks too).

They are often special entries. Most of the time you just want to “do not touch them unless I say so!” So I implemented the following behaviour:

  • If you specify he IP in the task (e.g IP=127.0.0.1) they are handled (like you would expect).
  • If you specify the task based on hostname, like “host: hostname=localhost state=absent”. This would not remove entries having 127/8 or ::1.
    You have to force it using “ignore_loopback=no”. So you know what you are doing right?

Aliases:
Aliases are handled very simple currently.

You just set the entry to be like you say based on the keys (hostname and IP).

create them:

host: ip=10.10.10.10 hostname=example.com aliases=www.example.com,web01.example.com

change them:

host: ip=10.10.10.10 hostname=example.com aliases=web01.example.com,www.example.com

remove them:

host: ip=10.10.10.10 hostname=example.com

keep_aliases:
I implemented a feature named “keep_aliases” so you can “cut of” the hostname of the entry so the first alias becomes the new hostname. But I realized there are use cases which results in inconsistency. Removing it. Never mind.

Question:
To the question https://github.com/ansible/ansible/pull/5065#issuecomment-29339021 of you Michael:

What happens if you have an exisitng entry like:

10.10.10.10 www.example.com web01.example.com

and having a task like:

host: ip=192.168.123.123 hostname=web01.example.com

Currently the exising entry will not be touched (as there is no primary key matching). So the result will end in web01.example.com as hostname and as alias with different IP:

10.10.10.10 www.example.com web01.example.com
192.168.123.123 web01.example.com

But I could think about a behaviour like result in this:

10.10.10.10 www.example.com
192.168.123.123 web01.example.com

Also think about, what would happen with this behaviour if you task would look like:

host: ip=10.10.10.10 hostname=www.example.com aliases=web01.example.com
host: ip=192.168.123.123 hostname=web01.example.com aliases=www.example.com

10.10.10.10 www.example.com
192.168.123.123 web01.example.com

Kind of like this. What do you think?

It seems focusing on the primary key method seems best.

Though I’m also thinking maybe only the first alias should be the primary key? Not sure.

Thoughts welcome.

We had also discussed an “append mode”, where aliases are appended to the list of existing aliases. I believe by default in the previous implementation the list of aliases was replaced.

Hi James

So perhaps maybe the IP alone should be the primary key, and the other fields are treated as aliases and mapped and unmapped, and not thinking of it as a line by line structure.