# New host module: how it should behave. **URL:** \ **Category:** Ansible Developer\ **Created:** [November 27, 2013, 12:52pm UTC](https://forum.ansible.com/t/new-host-module-how-it-should-behave/14014 "2013-11-27T12:52:25Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Rene\_Moser](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@Rene\_Moser](https://forum.ansible.com/u/Rene_Moser)\ **Post date:** [November 27, 2013, 12:52pm UTC](https://forum.ansible.com/t/new-host-module-how-it-should-behave/14014/1 "2013-11-27T12:52:25Z")
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](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](http://hostname=example.com) [aliases=www.example.com](http://aliases=www.example.com),[web01.example.com](http://web01.example.com) change them: host: ip=10.10.10.10 [hostname=example.com](http://hostname=example.com) [aliases=web01.example.com](http://aliases=web01.example.com),[www.example.com](http://www.example.com) remove them: host: ip=10.10.10.10 [hostname=example.com](http://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](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](http://www.example.com) [web01.example.com](http://web01.example.com) and having a task like: host: ip=192.168.123.123 [hostname=web01.example.com](http://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](http://web01.example.com) as hostname and as alias with different IP: 10.10.10.10 [www.example.com](http://www.example.com) [web01.example.com](http://web01.example.com) 192.168.123.123 [web01.example.com](http://web01.example.com) But I could think about a behaviour like result in this: 10.10.10.10 [www.example.com](http://www.example.com) 192.168.123.123 [web01.example.com](http://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](http://hostname=www.example.com) [aliases=web01.example.com](http://aliases=web01.example.com) host: ip=192.168.123.123 [hostname=web01.example.com](http://hostname=web01.example.com) [aliases=www.example.com](http://aliases=www.example.com) 10.10.10.10 [www.example.com](http://www.example.com) 192.168.123.123 [web01.example.com](http://web01.example.com) Kind of like this. What do you think? ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [November 27, 2013, 1:03pm UTC](https://forum.ansible.com/t/new-host-module-how-it-should-behave/14014/2 "2013-11-27T13:03:52Z")
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. ---
**Author:** ![James\_Cammarata1](https://avatars.discourse-cdn.com/v4/letter/j/d26b3c/32.png) [@James\_Cammarata1](https://forum.ansible.com/u/James_Cammarata1)\ **Post date:** [November 27, 2013, 3:05pm UTC](https://forum.ansible.com/t/new-host-module-how-it-should-behave/14014/3 "2013-11-27T15:05:07Z")
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. ---
**Author:** ![Rene\_Moser](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@Rene\_Moser](https://forum.ansible.com/u/Rene_Moser)\ **Post date:** [November 27, 2013, 7:03pm UTC](https://forum.ansible.com/t/new-host-module-how-it-should-behave/14014/4 "2013-11-27T19:03:30Z")
Hi James ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [November 27, 2013, 7:09pm UTC](https://forum.ansible.com/t/new-host-module-how-it-should-behave/14014/5 "2013-11-27T19:09:38Z")
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.