maas installs need to configure cloud-init with 'manage_etc_hosts: localhost'

[Scott Moser]

In the QA lab, we were running into an issue where a charm would use 'unit-get private-address' or 'unit-get public-address'.
Either one would result in 'hostname -f' being called from juju/unit/address.py , which would raise an error.

hostname -f was failing because the hostname provided to the system by maas in the metadata service was something like 'node-d4bed9a8461f'. That address was not resolvable via DNS or 'resolver(3)', so 'hostname -f' would return failure.

In EC2, the hostname is set to the shortname of the 'local-hostname' that is provided to the node via metadata service.
'hostname -f' then resolves on normal DNS lookup. (Also note in EC2UnitAddress of address.py, it explicitly uses
   private-address as http://169.254.169.254/latest/meta-data/local-hostname and public-address as the contents of http://169.254.169.254/latest/meta-data/public-hostname ). Ie, these values are obtained definitively and directly from the cloud provider.

The right thing to do, then is to:
 a.) make maas contain definitive information for 'public-address' and 'private-address'
 b.) make the MAASUnitAddress reference the information from 'a' in one way or another

However, that is complicated due to the possibility/likelhood that MAAS does not control DNS.

One work around, that happens to work in our QA lab is to configure cloud-init with:
  manage_etc_hosts: localhost

What this does is tells cloud-init to basically write the content of 'local-hostname' from the Metadata Service into /etc/hosts in a line like:
   127.0.1.1 node-d4bed9a8461f.local node-d4bed9a8461f

Doing this, means that:
  $ hostname --fqdn
  node-d4bed9a8461f.local

Thus, the 'MAASUnitAddress' will end up (indirectly) passing back the 'local-hostname' to the unit-get request.

Additionally, this is actually OK, because while 'node-d4bed9a8461f' is not resolvable via 'resolver' (which would be required for hostname --fqdn to work), 'node-d4bed9a8461f.local' *is*. Thats because /etc/nsswitch.conf has
  hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

and that address is resolvable via mdns4.

So, the result is that:
 * indirectly, we're passing the 'local-hostname' as provided by MAAS through to 'unit-get private-address', which is consistent with what happens on EC2
 * also indirectly, MAAS ends up being the definitive source.
 * in a more realistic environment (that did not rely on avahi for name resolution), 'hostname --fqdn' would/could still return the 'node-xxxxx.local' which would be resolveable by DNS.

So, in short, its not *terrible* for us to have MAAS feed cloud-init the following snippet of cloud-config:
  manage_etc_hosts: localhost