This patch implements the new network HA boolean field API extension.
This field is an input only parameter for POST operations (creation).
By default is "False". When enabled, the Neutron server will create
a ``ha_router_networks`` register in the same transaction of the
network creation.
If by any circumstance (a race condition, for example), another
``ha_router_networks`` exists in the same project, a
``DBDuplicateEntry`` exception will be raised and the transaction
will be rolled back.
Partial-Bug: #2016198
Change-Id: Ie42c13ecbe4abcad9229b71f6942e393fd0f2e4e
This option was deprecated since couple of releases already.
In Stein we removed 'external_network_bridge' option from L3 agent's
config so now it's time to remove also this one.
There is also new upgrade check introduced to check and warn
users if gateway_external_network_id was used in the deployment.
This patch also removes method _check_router_needs_rescheduling() from
neutron/db/l3_db.py module as it is not needed anymore.
This patch also removes unit tests:
test_update_gateway_agent_exists_supporting_network
test_update_gateway_agent_exists_supporting_multiple_network
test_router_update_gateway_no_eligible_l3_agent
from neutron/tests/unit/extensions/test_l3.py module as those
tests are not needed when there is no "gateway_external_network_id"
config option anymore.
Change-Id: Id01571cd42cfe9c5ce91e90159917c7d3c963878
The router_ids argument to auto_schedule_routers() is
unused, and was marked for deprecation in Queens.
Change-Id: Ie97b1ad05e294b5fe763ae8d7319800eb16ea3dc
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.
Change-Id: I1861448cec303725b30cef8f42029f467f9e03a3
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.
Related-Blueprint: neutron-lib
Change-Id: I128cfda773d5f9597df9cd61261fdc05f2a174aa
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
Change-Id: I5ab6b92b67e6d3b461fd118ef0a26d6f6b6992c4
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 <manjeet.s.bhatia@intel.com>
Co-Authored-By: Victor Morales <victor.morales@intel.com>
Change-Id: Iad609f72945b84df7881b43d1fdf9a188e5816bc
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
The option was deprecated [1] for removal in Newton
and is being removed in Ocata.
[1] Deprecated in patch with Gerrit Change-Id of:
I8a5fc74a96c784d474aefe2d9b27eeb66521ca82
DocImpact remove all references to the option.
Change-Id: I3a9195ff6fd18fad9f85cec03a632e7e52d954e7
Closes-Bug: #1555042
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.
Closes-Bug: #1609738
Change-Id: Ib04e08df13ef4e6b94bd588854a5795163e2a617
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.
Closes-Bug: #1633042
Change-Id: I228b0084a8e7c48e78bc2ea6a3fccf7437210e73
This patch will relocate external network db models
and separate it from mixins for OVO implementation.
Change-Id: I83e2c7bbab3bd59cc9d2af71c66c0662c7724ecc
Partial-Bug: #1597913
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).
Closes-Bug: #1535557
Change-Id: I3447ea5bcb7c57365c6f50efe12a1671e86588b3
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
neutron-lib constants.
Co-Authored By: Henry Gessau <gessau@gmail.com>
Co-Authored By: Gary Kotton <gkotton@vmware.com>
Change-Id: Ib0e8ff5c3e23677c1009241a1818cbc8a3430c38
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
internal details.
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.
TrivialFix
Change-Id: I7bd036ac3df7e7f4c678356d0a793e7d38599dda
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
the agents.
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 <akamyshnikova@mirantis.com>
Co-Authored-By: John Schwarz <jschwarz@redhat.com>
APIImpact
Closes-Bug: #1550886
Related-bug: #1499647
Change-Id: I22ff5a5a74527366da8f82982232d4e70e455570
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.
Change-Id: I94d6654631b3cd66dfd469b1230c3ec20d0c0369
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 <xiaohhui@cn.ibm.com>
Closes-Bug: #1513825
Change-Id: Icea06dc81344e1120bdf986a97a6b1094bbb765e
Depends-On: I31022e9230fc5404c6a94edabbb08d2b079c3a09
Depends-On: Iea3f014ef17a1e1b755cd2efe99afd1a36ebbc6a
Depends-On: I604602d023e0cbf7f6591149f914d73217d7a574
The issue was introduced by commit with change ID:
Ic4df299bac83c80abf0890a81d2dd36d15993b33
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.
Change-Id: I2b7d2f6ccd5fe18e322e70b4e376db23d76b9092
Closes-Bug: #1478273
Legacy mode agents considered.
Following test cases are added:
Common scenarios:
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-Id: Ic4df299bac83c80abf0890a81d2dd36d15993b33
yatinkarel
Rodolfo Alonso Hernandez