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
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
