/etc/hosts data is not properly mapped

[Aman Kumar Sinha]

If we use manage_etc_host: true in cloud.cfg , this will enable update_etc_host module which go and update /etc/hosts file.

Right now the what happen is the dns resolvable name mapped to the local host ip (127.0.0.1 / ::1)
This makes sense in case of a VM deployed with private IP, where we can ping the hostname from the VM itself.
But when we deploy a VM with public IP, in that case also the FQDN is mapped against localhost IP, which doesn't make much sense. Ideally it should be FQDN should be mapped the public IP.

/etc/host content in
Private IP [2]
Public IP [3]

I even raised a concern on this in the IRC channel, but was not able to resolve the query
IRC chat: [1]

[1] https://irclogs.ubuntu.com/2020/11/11/%23cloud-init.html
[2] http://paste.openstack.org/show/799931/
[3] http://paste.openstack.org/show/799923/

[Dan Watkins (oddbloke)]

Hi Aman,

Thanks for the bug report! Configuring the FQDN to point at the loopback address has been cloud-init's behaviour since 2011 on Ubuntu (https://github.com/canonical/cloud-init/commit/6d25c040ee566f6ef85352d7b52eb5947230f78a) and 2012 on Red Hat (https://github.com/canonical/cloud-init/commit/09f6384ac5694be18bef4872c9f19b9601b48f8b). This suggests to me that this is a reasonable default. Given this, and that people are likely relying on this default behaviour, I don't think we want to change the default behaviour here.

cloud-init does have some ways of modifying this behaviour already. If you can give a few more details about the problem you're trying to solve, we can see if any of those fit, or if we need to dig into perhaps making this behaviour more configurable.

(Once you've responded, please move this back to New. :)

Thanks!

Dan

[Launchpad Janitor (janitor)]

[Expired for cloud-init (Ubuntu) because there has been no activity for 60 days.]