From fb223cc1ebd3dc4d6f968346a2baa671acb6ffa2 Mon Sep 17 00:00:00 2001 From: armando-migliaccio Date: Thu, 21 Aug 2014 12:51:40 -0700 Subject: [PATCH] Do not log WARN messages about lack of L3 agents for DVR routers DVR routers are scheduled only when there is need to: for instance when there's an external gateway associated with it, or when there are interfaces attached to subnets on which VM's are actually being deployed. Therefore, do not log misleading messages that apply only to the centralized case. Closes-bug: 1358998 Change-Id: Ica7f0d25fe576f05a9adf8eb8239704f09c0b0ac --- neutron/db/l3_dvrscheduler_db.py | 40 ++++++++++++++++++++++++- neutron/scheduler/l3_agent_scheduler.py | 7 ++--- 2 files changed, 42 insertions(+), 5 deletions(-) diff --git a/neutron/db/l3_dvrscheduler_db.py b/neutron/db/l3_dvrscheduler_db.py index 41fb24484..78fe3f0d0 100644 --- a/neutron/db/l3_dvrscheduler_db.py +++ b/neutron/db/l3_dvrscheduler_db.py @@ -49,7 +49,45 @@ class CentralizedSnatL3AgentBinding(model_base.BASEV2): class L3_DVRsch_db_mixin(l3agent_sch_db.L3AgentSchedulerDbMixin): - """Mixin class for L3 DVR scheduler.""" + """Mixin class for L3 DVR scheduler. + + DVR currently supports the following use cases: + + - East/West (E/W) traffic between VMs: this is handled in a + distributed manner across Compute Nodes without a centralized element. + This includes E/W traffic between VMs on the same Compute Node. + - North/South traffic for Floating IPs (FIP N/S): this is supported on the + distributed routers on Compute Nodes without any centralized element. + - North/South traffic for SNAT (SNAT N/S): this is supported via a + centralized element that handles the SNAT traffic. + + To support these use cases, DVR routers rely on an L3 agent that runs on a + central node (also known as Network Node or Service Node), as well as, L3 + agents that run individually on each Compute Node of an OpenStack cloud. + + Each L3 agent creates namespaces to route traffic according to the use + cases outlined above. The mechanism adopted for creating and managing + these namespaces is via (Router, Agent) binding and Scheduling in general. + + The main difference between distributed routers and centralized ones is + that in the distributed case, multiple bindings will exist, one for each + of the agents participating in the routed topology for the specific router. + + These bindings are created in the following circumstances: + + - A subnet is added to a router via router-interface-add, and that subnet + has running VM's deployed in it. A binding will be created between the + router and any L3 agent whose Compute Node is hosting the VM(s). + - An external gateway is set to a router via router-gateway-set. A binding + will be created between the router and the L3 agent running centrally + on the Network Node. + + Therefore, any time a router operation occurs (create, update or delete), + scheduling will determine whether the router needs to be associated to an + L3 agent, just like a regular centralized router, with the difference that, + in the distributed case, the bindings required are established based on + the state of the router and the Compute Nodes. + """ def dvr_update_router_addvm(self, context, port): ips = port['fixed_ips'] diff --git a/neutron/scheduler/l3_agent_scheduler.py b/neutron/scheduler/l3_agent_scheduler.py index 8da4ed7d5..260c80168 100644 --- a/neutron/scheduler/l3_agent_scheduler.py +++ b/neutron/scheduler/l3_agent_scheduler.py @@ -166,10 +166,9 @@ class L3Scheduler(object): candidates = list(new_l3agentset - old_l3agentset) else: candidates = new_l3agents - if not candidates: - LOG.warn(_('No L3 agents can host the router %s'), - sync_router['id']) - return + if not candidates: + LOG.warn(_('No L3 agents can host the router %s'), + sync_router['id']) return candidates -- 2.45.2