Stack instances all get set with the same hostname

Bug #1164400 reported by Dave Johnston on 2013-04-04
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Heat
Steven Hardy

Bug Description

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



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) wrote :


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.

Steven Hardy (shardy) on 2013-04-22
Changed in heat:
status: New → Triaged
importance: Undecided → Medium
milestone: none → havana-1
Thomas Herve (therve) wrote :

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) wrote :

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) wrote :

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

Seeing this with Fedora 17 using the following image: 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) wrote :

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

[root@wordpress3 sysconfig]# hostname
[root@wordpress3 sysconfig]# cat /etc/sysconfig/network
# Generated by anaconda

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) wrote :

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

[ec2-user@wordpress182wikidatabasenovalocal ~]$ rpm -q cloud-init

[ec2-user@wordpress182wikidatabasenovalocal ~]$ hostname

[ec2-user@wordpress182wikidatabasenovalocal ~]$curl

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

Steven Hardy (shardy) wrote :

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

Steven Hardy (shardy) on 2013-05-14
Changed in heat:
assignee: nobody → Steven Hardy (shardy)
Steven Hardy (shardy) wrote :

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.

Changed in heat:
status: Triaged → Invalid
milestone: havana-1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers