[Openstack-operators] cloud-init:169.254.169.254 to time out / refuse connections
trapni at gmail.com
Tue May 29 12:47:44 UTC 2012
This 169.254.169.254 is driving me crazy. I read a few things already about
that suspcisious IP address, however,
I always get either a few:
2012-05-29 12:22:40,831 - util.py[WARNING]: '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [50/120s]:
url error [timed out]
or I'll get tons of:
2012-05-29 12:19:38,049 - util.py[WARNING]: '
http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [113/120s]:
url error [[Errno 111] Connection refused]
when instantiating a new VM.
My setup is as follows:
"production" network: 10.10.40.0/21
management network (physical nodes, switches, PDUs, ...) 10.10.0.0/19
nova-network: (we're not in multi_host mode)
- eth0: 10.10.30.4
controller (api, scheduler, etc, also compute-1 node):
- eth0: 10.10.30.190
- eth0: 10.10.30.191
- eth0: 10.10.30.192
Now, since the 169.254.169.254 is just an artificial IP, to be NAT'ed to
the right host via iptables, I did a quick check,
and tcp/80 seems to redirect to the nova-api instance at port 8775.
So here's my question:
On which physical nodes is this iptables rule expected, Just nova-network
or on every compute node? (and how to fix my above situation?)
I'm asking because I found the DNAT rule on the dedicated network node but
also compute-1 node (which is also the controller node, with api,
scheduler, etc) but not on compute-3 nor on compute-3 node - regardless of
my issue, this doesn't feel right.
Does anyone have a hint on what's going on/wrong here?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openstack-operators