By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members.
While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important.
Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide:
It does suggest that one needs an FQDN in /etc/hosts.
However cloud-init should only set the addresss if it cannot be determined.
cloud-init should first try gethostbyname() on the FQDN. If it resolves, *do not write FQDN to /etc/hosts*. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts.
By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members.
While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important.
Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide:
http:// www.debian. org/doc/ manuals/ debian- reference/ ch05.en. html
Point 5.1.2 specifically.
It does suggest that one needs an FQDN in /etc/hosts.
However cloud-init should only set the addresss if it cannot be determined.
cloud-init should first try gethostbyname() on the FQDN. If it resolves, *do not write FQDN to /etc/hosts*. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts.