Comment 9 for bug 1375252

This turned out to be something of an involved change, which I'm still working on.

Essentially, the cloud-init Azure data source will _always_ set the hostname to that provided by the fabric, even before the configuration modules that would normally do it (i.e. set_hostname and update_hostname). It does this so that the virtual IP address will be assigned correctly (by renewing the DHCP lease), but does this on every boot.

It has to set the hostname and bounce DHCP on every boot, because we can't know if this is the first boot of an instance until we have got our instance ID from SharedConfig.xml. We can't get SharedConfig.xml without network. We can't have network (on first boot) until we have performed the bounce[0]. Very Ouroborian.

My change sounds simple: after we have performed the DHCP bounce and walinuxagent has fetched SharedConfig.xml, we will set the hostname back to what it was before, to allow the regular cloud-init modules to perform hostname changing.

Unfortunately, this has lead to fairly major restructuring of the code in question, so this won't make it in to vivid's cloud-init (as we are releasing in just over a week). But we are making good progress!

[0] We also can't try to get SharedConfig.xml and then do the bounce if we fail, because this will add about a minute on to first boot times.