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

diff --git a/neutron/db/l3_dvrscheduler_db.py b/neutron/db/l3_dvrscheduler_db.py
index 41fb244846de3385047f301efbb2bdaa649e20e6..78fe3f0d053c4fd6ce18687490fd8aa9668e30c0 100644 (file)
--- 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 8da4ed7d599c9ccc7c39b397553b9ca49dcfbb65..260c801686ad10bd5649e13203e22c399997a737 100644 (file)
--- 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