the l3-agent only pushes down some of the DNAT rules for metadata mapping
if there is a gateway set on a router. However, the nova-api server could
itself be running in the local router namespace (or on the same box as
the quantum-l3-agent in the case were namespaces are disabled. In fact,
with namespaces disabled, this is the likely setup for a simple
environment). Thus, we should simply always push down the metadata nat
rules for a router, router than waiting until a gateway is added.
This patch also refactors the actions taken by the l3-agent when a router
is added or removed into a separate function for improved readability,
as add/removing the nat rules made these code segments even longer.
Reviewed: https:/ /review. openstack. org/13096 github. com/openstack/ quantum/ commit/ f6e9158d6ff5afe ae2712cf4d8c2e0 de4dc500b0
Committed: http://
Submitter: Jenkins
Branch: master
commit f6e9158d6ff5afe ae2712cf4d8c2e0 de4dc500b0
Author: Dan Wendlandt <email address hidden>
Date: Mon Sep 17 09:29:35 2012 -0700
always push down metadata rules for router, not just if gateway exists
bug 1051842
the l3-agent only pushes down some of the DNAT rules for metadata mapping
if there is a gateway set on a router. However, the nova-api server could
itself be running in the local router namespace (or on the same box as
the quantum-l3-agent in the case were namespaces are disabled. In fact,
with namespaces disabled, this is the likely setup for a simple
environment). Thus, we should simply always push down the metadata nat
rules for a router, router than waiting until a gateway is added.
This patch also refactors the actions taken by the l3-agent when a router
is added or removed into a separate function for improved readability,
as add/removing the nat rules made these code segments even longer.
Change-Id: I3c6eb35b51df3b abf747dbcff7f94 3b850e69838