Open Stack

On 01.10.2013 17:55, Jonathan Proulx wrote:
> On Tue, Oct 01, 2013 at 12:01:24PM +0300, Ilkka Tengvall wrote:
> I'm not using the quantum metadata service.  I can get away with this
> becasue I have relatively few networks and are all more or less in the
> same administrative domain.
>
> I'm running the nova metadata service on the controler node and have
> interfaces on the contorller on all the networks I want metadata on.

This would work only if you don't use namespaces. Once you enable 
namespaces, you have overlapping ip ranges (possibly), and then you need 
quantum-metadata-proxy. That beast takes care of the overlapping ip's 
before the stuff gets to nova-metadata.

So without namespaces you should be safe. See here if you want further 
know about the issue:

http://techbackground.blogspot.fi/2013/06/metadata-via-quantum-router.html
http://techbackground.blogspot.ie/2013/06/metadata-via-dhcp-namespace.html

Anyway as a feedback to my own original question, we solved (fingers 
crossed :)) the issue by:

1. adding a port with given ip into network,
    which is different than the physical gateway
2. create a router with given port (this will
    create NAT rules for quantum metadata)
3. Tell the subnet to have default gw via the physical router
4. Tell the subnet to advertice route to 169.254.169.254 via the
    quantum router port made at step 1.

The issue found here is that grizzly quantumclient is not able to create 
quantum router with given port (backport, anyone ;)), you need to do it 
via API (e.g. curl), or use the neutronclient from havana to do it, 
where it's fixed.

I hope this helps someone else running into the same situation with 
provider networks, external router and metadata, it sure would've helped 
us, along with the info that vlans on bond are broken in Red Hat (any 
kernel < 3.3):

http://openstack.redhat.com/forum/discussion/598/dhcp-responces-get-lost-with-ovs-provider-vlans#Item_8

BR,

Ilkka