Comment 5 for bug 1164400

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