Comment 8 for bug 1746455

> - This causes a new VM to be provisioned on VMware. Juju
> creates/uploads/deploys a vmdk file which is used to deploy the new
> VM. This VMDK appears to be cached and is not generated everytime a
> host is provisioned for speed, so it must contain a static hostname.

The OVF disk contains a hostname... this is very much the platform
telling cloud-init what the hostname should be.

Lets call this 'platform-provided hostname'

> The third step is where this breaks, because for some reason every VM on
> boot has the hostname ubuntu, even though juju is passing the correct
> hostname to cloud-init during boot, so the DNS server has a ton of IP
> address entries for 'ubuntu' all relating to different hosts.

I assume that juju is sending this in cloud-config inside user-data,
the key being essentially:
  #cloud-config
  hostname: foo

Lets call this 'user-provided hostname' as it comes in user-data.

every VM has the hostname 'ubuntu' in /etc/hostname. Cloud-init does
not change this until after the that initial dhcp is done. As you've
found a reboot (or "bounce" of the network device) would have dhcp
re-read the hostname and update the dns records.

The user-provided should (and does) override the platform-provided
hostname.

We have basically 3 possible sources of hostname information:
a.) platform-provided (meta-data)
b.) direct user-provided user-data
c.) indirect user-provided hostname.
I assume juju doesn't do this, but it could provide user-data that
consisted of:
  #include http://some.resource/some/path
  #include http://some.other.resource/some/path

where one of the the urls there contains:
   #cloud-config
   hostname: foo

cloud-init doesn't currently process *any* user-data until after
networking is configured.

We have a fairly straight forward plan to fix 'a' with some re-factoring.
Fixing 'b' requires more re-factoring, essentially "peeking" at user-data
before all network resources are up.
Fixing 'c' is more work, and would probably involve cloud-init somehow
bouncing interfaces, or some other mechanism for convincing dhcp to
update its lease information.