hostname not getting set as per the dns

[Aman Kumar Sinha]

Environment Details:
Management Control Plane : OpenStack (Ussuri Release)
cloud-init version : 19.1 (community)
Data Source : Config Drive
OS/platform of deployed VM : RHEL 8.2

I am using cloud-init v19.1 where the control plane (OpenStack nova service) passes information (data source) via configdrive during VM deployment.

I am using set_hostname and update_hostname module under cloud_init_modules section in [1] file. As per the documentation, I have put preserve_hostname: true in the cfg file and rebooted the system(VM). The hostname is preserved and does not change after multiple reboot. This I believe is working as expected.

When we using preserve_host: false and fqdn: <hostname> in [1], the hostname given as input value to fqdn is assigned as the hostname of the VM.

But when we just give preserve_hostname: false in [1], and deploy the VM, the deployed VM name comes as a hostname.

[root@host cloudinit]# hostname
host

Expectation :

If we give preserve_hostname: false it should set the hostname as per the dns what nslookup gives.

If we use an image where preserve_hostname: false, with no hostname specified in the cfg file) and use set_hostname and update_hostname in [1] modules in the cfg file, and deploy few VMs (say 5 VMs ) with it - how will the hostname get configured to all the deployed VMs ? In this use case, we will want the hostname configured on the VM to DNS resolvable and aligned with the IP address associated with the VM. How can this be achieved ?

[1] /etc/cloud/cloud.cfg

[Chad Smith (chad.smith)]

Maybe I am misunderstanding this bug.

If unspecified, cloud-init defaults preserve_hostname to False.

  When false, cloud-init will take whatever hostname is defined by the cloud metadata and apply it to the system.

You can check what your metadata is providing as local-hostname by running `cloud-init query local_hostname`

 Setting preserve_hostname: true means that cloud-init will do nothing with the hostname, even if cloud meta-data states a valid hostname. So the vm would accept hostname settings as provided by DHCP options.

[Aman Kumar Sinha (amansi26)]

IRC chat regarding this defect: https://irclogs.ubuntu.com/2020/09/08/%23cloud-init.html

[Divya K Konoor (dikonoor)]

Putty summary of information :

1. if preserve_hostname = True, VM hostname is taken as it is from the image.
2. if preserve_hostname = False and fqdn = <hostname> is set in cloud cfg, then <hostname> is used
3. if preserve_hostname = False and fqdn is not set, then hostname is taken from metadata(datasrc)

[Dan Watkins (oddbloke)]

It's not clear to me what the issue here is. Could someone summarise (and then set it back to New), please?

[Aman Kumar Sinha (amansi26)]

If we are using set_hostname module it checks for the preserve_hostname in [1].
If preserve_hostname is True cloud init will maintain the hostname as the name mentioned in [2]
If preserve_hostname is False and fqdn= <hostname> is mentioned in [1] it will set fqdn value as a hostname for the VM
If preserve_hostname is False and fqdn value is not set in [1] it will take hostname from meta_data.json in vopt which we pass at the time of deployment.

Suppose we deploy VM (5 VM's) using same image the hostname provided in the meta_data.json will be name with which the VM is deployed not a Fully Qualified Domain Name.

But ideally it should set the hostname as Fully Qualified Domain Name if preserve_hostname is false and we don't provide any value for fqdn in [1]

[1] /etc/cloud/cloud.cfg
[2] /etc/hosts

[Paride Legovini (paride)]

Hi,

Let's check if I understood correctly.

When preserve_hostname=False and fqdn is not set, then cloud-init takes the hostname from meta_data.json. If the meta_data hostname is:

  myhost.some.domain.com

cloud-init sets the hostname to "myhost" (first chunk before the first dot), while you would like it to be set to the full "myhost.some.domain.com". Is this it?

Paride

[Aman Kumar Sinha (amansi26)]

Hi Paride,

When preserve_hostname=False and fqdn is not set, then cloud-init takes the hostname from meta_data.json. If the meta_data hostname is:

  myhost.some.domain.com

cloud-init sets the hostname to "myhost" (first chunk before the first dot)

>>>> Correct, this meta_data hostname is the name with which we deploy the VM, so it can be anything. It might be same for N number of VMs . Giving the name to the VM is upto user.

while you would like it to be set to the full "myhost.some.domain.com"

>>>> No, we need a dns resolvable name set here. So if we do a nslookup to any public IP it will return the dns resolvable name

like

[root@aman ~]# nslookup 9.104.298.221
221.298.104.9.in-addr.arpa name = aman .

[root@matata ~]# nslookup 9.104.298.201
201.298.104.9.in-addr.arpa name = matata .

Taking above example, dns resolvable name for
 IP 9.104.298.221 is aman and 9.104.298.201 is matata

Even though we deploy both the VMs with anyname which passed as meta_data, irrespective of that the hostname should get configured for
9.104.298.221 as aman and 9.104.298.201 as matata
As these are the dns resolvable name for particular IPs.

Aman

[Paride Legovini (paride)]

Hi again,

so in other words you would like the IP address assigned to the instance to be resolved by a DNS query into a hostname (or fqdn, that depends on the DNS), and the result used to set the instance hostname?

[Aman Kumar Sinha (amansi26)]

Hi Paride,

Yeah that's correct.

[Paride Legovini (paride)]

Hi Aman,

I don't think that's the right way to do it. It is up to OpenStack to provide the hostname for the instances to use as part of the instance metadata; cloud-init's job in this case is just to trust the metadata. Any other logic to chose each instance's hostname belongs to OpenStack.

I think this is a "wontfix" bug, but I'm setting this to Incomplete for the moment just in case I once again misunderstood your report.

[Launchpad Janitor (janitor)]

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

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3782