getfqdn overrides user provided hostname

[ykakarap]

The data source here always overrides the metadata's hostname and local-hostname fields using the socket.getfqdn(). Refer to the following lines:

• https://github.com/vmware/cloud-init-vmware-guestinfo/blob/master/DataSourceVMwareGuestInfo.py#L398-L401
• https://github.com/vmware/cloud-init-vmware-guestinfo/blob/master/DataSourceVMwareGuestInfo.py#L138

Because of the above-mentioned, the user cannot set the hostname using metadata. The value of getfqdn is always set as the hostname.

This is creating a problem in projects like CAPV where CAPV expects to set the hostname but is unable to.

[ykakarap]

/cc @akutz

[akutz]

Good catch!

[akutz]

Hi @ykakarap,

I thought more about this, and I'm not sure this is a bug. The user does provide a hostname in the metadata, but that gets applied when the networking configuration is applied at the end of the local stage. The bit you referenced happens after the network is supposed to be online, and so the hostname returned by socket.getfqdn should be the correct value. Have you tested that this is an actual concern and just something you saw in the code?

[bsord]

I've run into an issue with this.. I have metadata that sets the hostname. The new vm from template boots up with the 'templatename' as the hostname initially and gets an address from dhcp with the template name. Then cloud-init runs and sets the hostname to the metadata specified name, but a few seconds later it sets it back because it gets the original template name back from dhcp reverse lookup.. Maybe my cloud-init isn't running before network initializes like it should?

[akutz]

This issue is being closed because this datasource has been merged into cloud-init (canonical/cloud-init#953):

Component	Source	Tests
Datasource	DataSourceVMware.py	test_vmware.py
Identification	ds-identify	test_ds_identify.py
Documentation	vmware.rst

In order to participate in the growth of this datasource moving forward, please:

• Ask a question in the #cloud-init IRC channel on Libera
• Search the cloud-init mailing list archive
• Join the cloud-init mailing list
• Report issues with Launchpad

Once again, many thanks to the wonderful community that has grown around this datasource, and I look forward to seeing everyone in the new cloud-init forums!