> We are having problems with connectivity from the instance to our
> OpenStack controller (particularly the metadata service)...
zynzel on #openstack suggested that the metadata api service is
supposed to run alongside the compute service, so I've modified our
configuration accordingly to start nova-api-metadata on our compute
node.
nova-network is now attaching the 169.254.169.254 address to the
loopback interface:
host# ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet 169.254.169.254/32 scope link lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
...and at this point, explicit access to the metadata port from the
isntance works as expected:
instance# curl http://169.254.169.254:8775/
1.0
2007-01-19
.
.
.
2009-04-04
Nova also adds the following rule to the nat PREROUTING chain:
-A nova-network-PREROUTING -d 169.254.169.254/32
-p tcp -m tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8775
This does *not* appear to work as expected. While packets to
169.254.168.254:80 clearly match this rule, they never make it to the
metadata server. Replacing this rule with a REDIRECT rule does the
right thing:
host# iptables -t nat -I nova-network-PREROUTING 1 \
-d 169.254.169.254/32 -p tcp -m tcp \
--dport 80 -j REDIRECT --to-ports 8775
Now on the instance I can access http://169.254.169.254/.
Is the DNAT rule expected to work? Does linux_net.py need a special
case for when the metadata address is on the local host?
Thanks,
--
Lars Kellogg-Stedman <l...@seas.harvard.edu> |
Senior Technologist | http://ac.seas.harvard.edu/
Academic Computing |
http://code.seas.harvard.edu/
Harvard School of Engineering and Applied Sciences |
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
