Open Stack

> 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 <lars at seas.harvard.edu>       |
Senior Technologist                                | http://ac.seas.harvard.edu/
Academic Computing                                 | http://code.seas.harvard.edu/
Harvard School of Engineering and Applied Sciences |