Description of problem: Cloud-init blocks the booting of instance about 2 minutes, spitting following errors to log. 20130613 12:59:00,910 url_helper.py[WARNING]: Calling 'http://169.254.169.254/20090404/metadata/instanceid' failed [3/120s]: url error [[Errno 113] No route to host note there is a bug about missing dashes from log 20130613 12:59:00,910 url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]: url error [[Errno 113] No route to host Note that after login is available, there is no route to 169.254.169.254 in ip r, but curl http://169.254.169.254/2009-04-04/meta-data/instance-id returns the instance id, no problem. This is because the default route will deliver the packets to the router, where the port gets translated to some quantum-proxy port, which should proxy it to nova. Version-Release number of selected component (if applicable): cloud-init-0.7.1-2.el6.noarch openstack-quantum-2013.1.1-10.el6ost.noarch openstack-nova-common-2013.1.1-4.el6ost.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Also note that during the time the cloud-init has problems, claiming "no route to host", the instance is pingable.
The problem is that cloud-init adds temporary routing rule, saying that the 169.254.0.0/16 is local, therefore the packets are not routed to gateway from the sending machine, but ARP requests are being sent: 13:53:02.634932 ARP, Request who-has 169.254.169.254 tell 10.34.64.7, length 28 Nothing replies since there is no such listener (there is only NAT rule on the controller). The sender than realizes there is no route to host. I believe this problem is not present when using nova-network, but I would need confirmation.
I think I had some problem in my deployment.