Stack instances all get set with the same hostname

[Dave Johnston]

When creating a stack from template with multiple instances, cloud-init will configure all instances to have the same hostname.

The meta-data store contains the hostname in the format:

<stackname>.<instance name>.<domain>

i.e. If I create a stack called 'teststack' with two instances 'instance1' and 'instance2' executing the following on each instance

curl -m 10 -s http://169.254.169.254/latest/meta-data/hostname

returns

teststack.instance1.novalocal
and
teststack.instance2.novalocal

However running 'hostname' on the instance itself returns 'teststack'.

Note that I can manually set the hostname using 'hostname teststack.instance1.novalocal' so not sure why cloud-init is not able to successfully, this maybe a bug with cloud-init rather than heat.

An alternative option maybe to use <stackname>-<instance name>.<domain>

[Dave Johnston (dave-johnston)]

N.B

Looking at this further - a DNS entry seems to be created for each instance in the stack, although again this seems to use the stackname, i.e. So if my instance is called teststack.instance1, running ping teststack resolves to the machines ip address. teststack.instance1 does not resolve to anything.

[Thomas Herve (therve)]

It looks like it might be a bug in cloud-init, which may have been fixed already. Which distro and version did you test on?

[Dave Johnston (dave-johnston)]

Originally it was Folsom on Ubuntu.
I've now seen the same issue with RedHat 6.4 and Grizzly.

I need to check the version of cloud-init.

[Dave Johnston (dave-johnston)]

This behaviour is seen with cloud-init-0.6.3-0.5.bzr532.fc17.noarch.

Seeing this with Fedora 17 using the following image: http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F17-x86_64-cfntools.qcow2 and the Autoscale Template.

i.e. install heat, at the Fedora 17 image, launch stack with the following:
heat-cfn create --template-file=AutoScalingMultiAZSample.template AutoScale --parameters="KeyName=mykey"

[Steven Hardy (shardy)]

Some additional data, I've re-tested using an F18 image, which has cloud-init-0.7.1-4 (the 0.7.1 release with a couple of backported patches)

It seems that we defintely are providing the FQDN correctly, and cloud-init is correctly setting it in /etc/sysconfig/network, however it's then incorrectly re-setting the hostname to the first section of the FQDN, attempting to derive a short hostname:

May 1 11:41:42 localhost [CLOUDINIT] cc_set_hostname.py[DEBUG]: Setting the hostname to wordpress3.wikidatabase.novalocal (wordpress3)
May 1 11:41:42 localhost [CLOUDINIT] util.py[DEBUG]: Reading from /etc/sysconfig/network (quiet=False)
May 1 11:41:42 localhost [CLOUDINIT] util.py[DEBUG]: Read 81 bytes from /etc/sysconfig/network
May 1 11:41:42 localhost [CLOUDINIT] util.py[DEBUG]: Writing to /etc/sysconfig/network - wb: [420] 81 bytes
May 1 11:41:42 localhost [CLOUDINIT] util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network (recursive=False)
May 1 11:41:42 localhost [CLOUDINIT] util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network (recursive=False)
May 1 11:41:42 localhost [CLOUDINIT] __init__.py[DEBUG]: Non-persistently setting the system hostname to wordpress3

[root@wordpress3 sysconfig]# hostname
wordpress3
[root@wordpress3 sysconfig]# cat /etc/sysconfig/network
# Generated by anaconda
NETWORKING=yes
HOSTNAME=wordpress3.wikidatabase.novalocal

So we either have to figure out the cloud-init option which stops it trying to set the short-hostname, or we have to modify our hostname to not be delimited by "."'s

I have a feeling the latest trunk cloud-init may not have this issue, but need to re-test to be sure

[Steven Hardy (shardy)]

Re-tested on recent (not quite latest) trunk cloud-init, behavior is different:

[ec2-user@wordpress182wikidatabasenovalocal ~]$ rpm -q cloud-init
cloud-init-0.7.1-4.bzr809.fc18.noarch

[ec2-user@wordpress182wikidatabasenovalocal ~]$ hostname
wordpress182wikidatabasenovalocal

[ec2-user@wordpress182wikidatabasenovalocal ~]$curl http://169.254.169.254/latest/meta-data/hostname
wordpress182.wikidatabase.novalocal

[ec2-user@wordpress182wikidatabasenovalocal ~]$ cat /etc/sysconfig/network
# Generated by anaconda
NETWORKING=yes

[Steven Hardy (shardy)]

I've proposed an update to F18 cloud-init which fixes this issue:

http://lists.fedoraproject.org/pipermail/cloud/2013-May/002396.html

[Steven Hardy (shardy)]

Update now in F18 updates-testing:

http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/18/x86_64/cloud-init-0.7.2-0.1.bzr809.fc18.noarch.rpm

[Steven Hardy (shardy)]

Ok, so since this is a cloud-init issue, and we've proven that recent cloud-init as now in F18 fixes the issue, I'm going to close this bug invalid, since it turns out this is not really a heat bug.