> - 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.
> - This causes a new VM to be provisioned on VMware. Juju uploads/ deploys a vmdk file which is used to deploy the new
> creates/
> 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: some.resource/ some/path some.other. resource/ some/path
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://
#include http://
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.