networking comes up before hostname is set

Bug #1739516 reported by Michael Hudson-Doyle on 2017-12-21
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Unassigned

Bug Description

When boot with libvirt a disk image that has been installed with subiquity which has the workaround for bug 1737630 applied, i.e. networkd starts automatically, I cannot ping the VM by hostname from the host.

I think this is because the networking has come up before the hostname is set, so the hostname is not sent along with the DHCP request to libvirt's dnsmasq and so that dnsmasq cannot answer lookups for the hostname. If I run "netplan apply" on the vm, enough things are apparently restarted that DHCP happens again and I can ping the vm by hostname from the host.

I'm not completely sure I have diagnosed this correctly and certainly don't know how to fix it.

Scott Moser (smoser) on 2017-12-21
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Medium
Scott Moser (smoser) wrote :

This is true that hostname is not set before networking comes up.
I would like to fix this, but there are a couple things to consider
a.) network datasources
   currently there are some datasources that run only after networking comes up. As it is right now it is "too late"to read the hostname from the network metadata service and then update the system hostname before dhcp would run.

b.) systemd-networkd's dhcp client seems to actually be listening for hostname getting set and updating its lease information on that event. we saw this in azure when we were removing the old 'bounce the network' code that served the purpose of publishing the

c.) relying on the guest to populate dns information via dhcp is kind of garbage anyway. as a "cloud" solution anyway.

d.) cloud-init allows setting hostname in user-data (in addition to meta-data).
the user-data provided by the user could be in a '#include' url, which might not be available until all networking is up. Thus, even if we moved network datasources to pull their information 'pre-network' (the way that the digital ocean md service does) we can't consume all the user-data at that point.

'd' might be a reasonable limitation. the other things are acheivable.

Michael Hudson-Doyle (mwhudson) wrote :

For a and d, sure if finding out what the hostname needs to be involves having the network up, there's nothing that can be done to avoid this.

For c, yes, this is kind of garbage. Utah depends on this though :/ Maybe I can get it to edit the libvirt network config to map the MAC address to a particular IP address instead, that would definitely be less fragile...

And finally for b, it would make sense that a hostname change triggers a refresh of the DHCP lease but I see nothing in the code to do this and my experiments don't seem to indicate it happening either.

Birger Schmidt (bs-ubo) wrote :

I just stumbled over this bug as well.

Reading all the cases (a,b,c...) I do not see the downside in just setting the hostname in the init-local stage as well.

This can be done as an additional step only if the info is already there (i.e. mounted via iso). To check that would not take long and neither would setting the hostname take long.

Please consider adding this functionality and in case you decide against it please tell us what you think the downside of this would be.

As a side note: A similar request can be solved at the same time. See here https://bugs.launchpad.net/cloud-init/+bug/1643688.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers