Removed E125 (continuation line does not distinguish itself
from next logical line) from the ignore list and fixed all
the indentation issues. Didn't think it was going to be
close to 100 files when I started.
The functionality within neutron.db.common_db_mixin is available via
neutron-lib APIs. This patch removes common_db_mixin and updates any
uses of it to use neutron-lib instead.
The well known service type constants are in
neutron_lib.plugins.constants, but for legacy reasons a few still exist
and are referenced from neutron_lib.constants that we'd like to remove.
This patch switches references over to neutron_lib's plugin constants.
By registering functions directly we cut off the dependency of the
"resource extend" functions on the plugin. This is a step towards
the goal of removing the CommonDbMixin mixin class.
Also, we register all "resource extend" functions at plugin create
(in __new__) instead of in the class definition (which caused the
hooks to be registered on import). This ensures the "resource
extend" functions are only registered for the plugins/mixins that
are actually used.
Note that decorators are used to register "resource extend" methods,
similar to the callback receiver decorators.
This eliminates the mixin references in DVRResourceOperationHandler
to prepare for it to be used by the DVR service provider and to be
removed from the main L3 plugin mixin.
Related: blueprint multi-l3-backends
Neutron-lib 1.1.0 is now out and contains the provider
network API definition (as per commit ). This patch
moves neutron references over to the neutron-lib
- Consumers using the public constants within neutron's
providernet API extension must now use the values
This patch introduces and implements Olso-Versioned Objects for
network extension External Networks.
There were joined performed to order the fetching of external
networks by standard attribute which seems useless because,
in networks/services/auto_allocated/db.py while fetching
external networks it logs error when multiple networks are
returned. Expected default external network there is one, so
ordering does not make much sense.
Co-Authored-By: Manjeet Singh Bhatia <email@example.com>
Co-Authored-By: Victor Morales <firstname.lastname@example.org>
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
The option was deprecated  for removal in Newton
and is being removed in Ocata.
 Deprecated in patch with Gerrit Change-Id of:
DocImpact remove all references to the option.
This reverts commit 9c3c19f07c.
Following the merge of Ie98d5e3760cdb17450aea546f4b61f5ba14baf1c, the
creation of new router uses RouterL3AgentBinding and its' new
binding_index attribute to ensure correctness of the resources. As such,
the ALLOCATING state (which was used to do just that) is no longer
needed and can be removed.
Change I3447ea5bcb7c57365c6f50efe12a1671e86588b3 added a binding_index
to the RouterL3AgentBinding table. In certain (concurrent) cases, a row
with the same binding_index might be used twice, which will raise
DBDuplicateEntry. However, that change didn't retry on this case at all
code-paths, so this patch rectifies this issue.
The patch proposes adding a new binding_index to the
RouterL3AgentBinding table, with an additional Unique Constraint that
enforces a single <router_id, binding_id> per router. This goes a long
way into fixing 2 issues:
1. When scheduling a non-HA router, we only use binding_index=1. This
means that only a single row containing that router_id can be
committed into the database. This in fact prevents over-scheduling of
non-HA routers. Note that for the HA router case, the binding_index
is simply copied from the L3HARouterAgentPortBinding (since they are
always created together they should always match).
2. This sets the ground-work for a refactor of the l3 scheduler - by
using this binding and db-based limitation, we can schedule a router
to agents using the RouterL3AgentBinding, while postponing the
creation of L3HARouterAgentPortBinding objects for the agents until
they ask for it (using sync_routers). This will be a major
improvement over todays "everything can create
L3HARouterAgentPortBinding" way of things).
Remove deprecation warnings for various constants
and exceptions that have moved to neutron_lib.
Fix miscellaneous other deprecations.
Uses constants instead of l3_constants when importing
Co-Authored By: Henry Gessau <email@example.com>
Co-Authored By: Gary Kotton <firstname.lastname@example.org>
In routed provider networks, a network can be divided by segments and
each segment will have its own DHCP agent. AutoScheduling for networks
exists. This patchset is for enabling auto scheduling for routed
Partially-implements: blueprint routed-networks
Stevedore documentation suggest that full import paths are not supposed
to be user visible. Since unit tests emulate users when configuring
oslo.config, we better off relying on well known plugin aliases than
For in-tree that may be not a big deal, but with it we set a bad example
for third parties that may later find their tests broken eg. when we
decide to move code around.
There is a bug in pep8, when 'select' used, it omits all default checks
and runs only those specified by 'select'. We got hit by this issue
since I2d26534230ffe5d01aa0aab6ec902f81cfba774d was merged which lead to
almost no static checks in pep8 job.
Also note that off_by_default decorator has no effect for now because
factory in hacking is triggered after ignored checks are collected.
There will be a follow-up patch for that in order to make pep8 doing
its job quickly.
This patch set is for breaking the circular dependency between
Agent/NetworkDhcpAgentBinding. The goal of this is to implement
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
This patch adds a new ALLOCATING status to routers
to indicate that the routers are still being built on the
Neutron server. Any routers in this state are excluded in
router retrievals by the L3 agent since they are not yet
ready to be wired up.
This is necessary when a router is made up of several
distinct Neutron resources that cannot all be put
into a single transaction. This patch applies this new
state to HA routers while their internal HA ports and
networks are being created/deleted so the L3 HA agent
will never retrieve a partially formed HA router. It's
important to note that the ALLOCATING status carries over
until after the scheduling is done, which ensures that
routers that weren't fully scheduled will not be sent to
An HA router is placed in this state only when it is being
created or converted to/from the HA state since this is
disruptive to the dataplane.
This patch also reverts the changes introduced in
Iadb5a69d4cbc2515fb112867c525676cadea002b since they will
be handled by the ALLOCATING logic instead.
Co-Authored-By: Ann Kamyshnikova <email@example.com>
Co-Authored-By: John Schwarz <firstname.lastname@example.org>
Test cases listed below are to run for Chance and Least-routers scheduler,
for both auto and explicit scheduling.
1. Legacy router scheduled on dvr_snat agent.
2. Distributed router not scheduled on legacy agent.
3. Distributed router not scheduled on dvr agent.
4. Distributed router scheduled on dvr_snat agent.
5. Already hosted legacy router not scheduled on dvr agent.
6. Already hosted legacy router not scheduled on dvr_snat agent.
7. Already hosted distributed router not scheduled on legacy agent.
8. Already hosted distributed router not scheduled on dvr agent.
9. Already hosted distributed router not scheduled on dvr_snat agent.
10. Already hosted legacy router not scheduled on additional dvr agent.
11. Distributed router not scheduled if it is on a different external
network than the dvr_snat agent.
Currently neutron DCHP scheduler assumes that that every server running
a dhcp-agent can reach every network. Typically the scheduler can
wrongly schedule a vlan network on a dhcp-agent that has no reachability
to the network it's supposed to serve (ex: network's physical_network
Typically such usecase can append if:
* physical_networks are dedicated to a specific service and we don't
want to mix dnsmasqs related to different services (for
* physical_networks are dedicated to a specific rack (see example
diagram http://i.imgur.com/NTBxRxk.png), the rack interconnection can
be handled outside of neutron or inside when routed-networks will be
This change makes the DHCP scheduler network reachability aware by
querying plugin's filter_hosts_with_network_access method.
This change provides an implementation for ML2 plugin delegating host
filtering to its mechanism drivers: it aggregates the filtering done by
each mechanism or disables filtering if any mechanism doesn't overload
default mechanism implementation (for backward compatibility with
out-of-tree mechanisms). Every in-tree mechanism overloads the default
implementation: OVS/LB/SRIOV mechanisms use their agent mapping to filter
hosts, l2pop/test/logger ones return empty set (they provide to "L2
This change provides a default implementation for other plugins
filtering nothing (for backward compatibility), they can overload it to
provide their own implementation.
Such host filtering has some limitations if a dhcp-agent is on a host
handled by multiple l2 mechanisms with one mechanism claiming network
reachability but not the one handling dhcp-agent ports. Indeed the
host is able to reach the network but not dhcp-agent ports! Such
limitation will be handled in a follow-up change using host+vif_type
Co-Authored-By: Cedric Brandily <email@example.com>
The check of the tenant done in the method _get_tenant_id_for_create()
is already did by the Neutron Controller in prepare_request_body(),
with a call to attributes.populate_tenant_id().
Moreover, when the Controller processes a "create" requests, it
will add the 'tenant_id' to the resource dict.
Thus, _get_tenant_id_for_create() can be deleted.
Calls to this method are replaced by the res['tenant_id'].
Changes have to be done in UT to explicitly add the tenant_id while
creating resources, since the UT framework is bypassing the controller code
that automatically adds the tenant_id to the resource.
Co-Authored-By: Hong Hui Xiao <firstname.lastname@example.org>
This patch adds the availability_zone support for network.
Co-Authored-By: IWAMOTO Toshihiro <email@example.com>
Partially-implements: blueprint add-availability-zone
The issue was introduced by commit with change ID:
In Neutron-speak we define the 'core plugin' as something like ML2, while
service plugins examples are L3, VPNaaS, etc. The code was initializing
the L3 service plugin as the core plugin, which is unexpected behavior.
The code will now use the DB core plugin base class as the core plugin,
and not initialize the service plugins. The tests will manually and locally
instantiate a L3 service plugin instance and use it.
The functional test for auto_schedule_networks passes even if the
method does nothing. This patch changes the test so it checks that
each expected hosted network is in hosted_net_ids.
Legacy mode agents considered.
Following test cases are added:
1. No routers scheduled if no agents are present
2. No routers scheduled if it is already hosted
3. No routers scheduled if all agents are down
4. Router scheduled to the agent if router is not yet hosted
5. Router scheduled to the agent even if it already hosts a router
Following scenario specific to least routers scheduler is added:
1. Router is scheduled to agent hosting least routers
For each of Chance and Least Router schedulers auto scheduling is also verified.
A total of 22 test cases are added.
* Change helpers.register_agent to use a slimmed down version
of a plugin that knows how to register an agent. This allows
the helper to be used with tests that do not register a core
In this blueprint, we also propose to write a generic scheduler
framework which can be used to schedule a new resource on
selected least loaded agents.
Currently dhcp_load_type will be fetched from neutron.conf file
and corresponding load is obtained by the agent report state.
The obtained load will be populated in the "load" column of the
During scheduling, agent will be selected based on sorting all
the agents of particular type based on load column.
Example dhcp_load_type is networks
Implements: blueprint dhcpservice-loadbalancing
Author: Shivakumar M <firstname.lastname@example.org>
Co-Authored-By: Praveen Kumar SM <email@example.com>
Co-Authored-By: Benjamin GRASSART <firstname.lastname@example.org>
Co-Authored-By: Sourabh Patwardhan <email@example.com>
This patch adds few unit test cases and functional test cases
for schedule() and auto_schedule_networks() of DHCP agent