The table "router_extra_attributes" is a child of "router" table.
Each register contains extra information that completes the router
description. When using ML2/OVS mechanism driver, the methods that
create and populate the "router_extra_attributes" register are always
called from the L3 DVR, L3 HA and availability zones extensions.
When using ML2/OVN, those extensions are not loaded and therefore the
"router_extra_attributes" register is not created.
Despite this register is currently not used in ML2/OVN (it will be in
future features), there are some project expecting the
"router_extra_attributes" register to be always created (for example,
neutron-dynamic-routing [1]).
This patch enforces the child register creating always when a router is
created. This register is populated with the default values. This new
register does not affect any current operation related to ML2/OVN nor
ML2/OVS.
There is a 1:1 relationship between "routers" and
"router_extra_attributes". The child register is deleted by the database
engine when the "routers" register is deleted (ondelete="CASCADE").
[1]https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/863713
Closes-Bug: #1995974
Change-Id: Ic546e40513402fa101c9687acce382cd6b84356c
We moved all our code to the new enginefacade already so we don't use
nested transactions at all thus we don't need that check anymore.
Partially-Implements blueprint: enginefacade-switch
Change-Id: I957151a7cac4285926864029c844efd76b052c5b
The _resource_extend module is already rehomed into neutron-lib and is
shimmed in neutron. This patch removes the module as no active
consumers are using it.
NeutronLibImpact
Change-Id: I1550075fa5fa2aa2f1a88ee7189d311a1fe78391
As ExtraAttributesMixin.set_extra_attr_value() is assumed to be called
by callback of PRECOMMIT. So there is no point to start nested
transaction. So don't start transaction and check if transaction is
already started.
Change-Id: I0e2707222b1f91199cf466c997c0e691679fd3a4
Partial-bug: #1745633
Commit I81748aa0e48b1275df3e1ea41b1d36a117d0097d added the l3 extension
API definition to neutron-lib and commit
I2324a3a02789c798248cab41c278a2d9981d24be rehomed the l3 exceptions,
while Ifd79eb1a92853e49bd4ef028e7a7bd89811c6957 shims the l3
exceptions.
This patch consumes the l3 api def by:
- Removing the code from neutron that's now in lib.
- Using lib's version of the code where applicable.
- Tidying up the related unit tests as now that the l3 api def from lib
is used the necessary fixture is already setup in the parent chain when
setting up the unit test class.
NeutronLibImpact
Change-Id: If2e66e06b83e15ee2851ea2bc3b64ad366e675dd
Commit I1d4ded9959c05c65b04b118b1c31b8e6db652e67 rehomed the
availability zone extension's API definition into neutron-lib. This
patch consumes it, removing the rehomed logic in neutron and switching
over to lib's version of it.
NeutronLibImpact
Change-Id: I761381de0d6e26a0380386700e7921b824991669
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
Move the model query hook registration and resource extend funcs
registration methods out of the CommonDbMixin class and make them
regular utility functions.
This is a step in refactoring the CommonDbMixin class.
Change-Id: Iec1bb7f7098c83640ae695fd7cf2f4736f414ad2
Those were moved under neutron.db.models start of Ocata. We should be
able to clean them up now.
NeutronLibImpact
Change-Id: Iadbf44d52ee8e30712807384152a29ce1a8b8f72
This adjusts the extra router attributes mixin to add
a new function to explicitly set the value of an extra
attribute. The mixins that depend on extra attrs
now explicitly call this instead of depending on a big
inheritance chain of calling _process_extra_attr_router_create.
This will allow the router_az, DVR and HA modules to eventually
be separated from the L3 plugin class inheritance entirely.
Related: blueprint multi-l3-backends
Change-Id: If44bfef9428f43dd82758928bf46786b70e5e11c
As there would be issue of cyclic imports while the implementation
of Oslo-versioned Objects for Router Extra Attributes which has DB
models definition in same file, this patch will move Router Extra
Attributes model.
Change-Id: I8c90e35ef08ef74fb5309707673796e587a7289e
Partial-Bug: #1597913
This patch ensures that models_v2 and the router db module
import the agent binding modules so their models are defined
in the sqlalchemy metadata. Otherwise, using an agentless
core/L3 plugin may result in a failure to initialize if nothing
imported the agent module.
Change-Id: I77240462b618d6e95c7c5862441d6d179e371f4f
Closes-Bug: #1529022
This patch adds the availability_zone support for router.
APIImpact
DocImpact: Make router scheduler availability zone aware. If multiple
availability zones are used, set router_scheduler_driver =
neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler. This scheduler
selects agent depends on LeastRoutersScheduler logic within an availability
zone so that considers the weight of agent.
Change-Id: Id26d9494b9a5b459767e93a850f47a3b014b11bb
Co-Authored-By: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Partially-implements: blueprint add-availability-zone
Add L3 HA base classes on the plugin side. A new admin-only ha
attribute is added to the API router resource. Conversion from
or to HA router is possible. Each tenant gets a single network
used for HA traffic. The tenant_id for that network is set to
'' so that it isn't visible via the CLI or GUI. A new table
is added to map a tenant to its HA network. Specific HA
attributes are added to the extra router attributes table.
Finally, each HA router gets a port on the HA network, per
l3 agent it is scheduled on. A new table is added to track
these bindings. A new table is added in order to track
VRID allocations.
DVR integration is not expected to work. Any issues will
be reported as bugs and handled after the feature merges.
Migrating a router to HA or from HA works server side
but is not expected to work (Yet) agent side. This will be
dealt with as a bug in the future.
DocImpact
Partially-implements: blueprint l3-high-availability
Change-Id: I9d935cf5e0c231e8cb7af5f61b9a9fc552c3521e
Co-Authored-By: Assaf Muller <amuller@redhat.com>
This is done by adopting the router_extra_attributes
models. However, the NSX 'distributed' extension is
slightly different in that it is visible to tenants
and prevents router conversion (allow_put=false).
PUT requests are made return the correct HTTP code;
The access control misalignments will need to be
adjusted via rules in policy.json. This will be
properly documented.
DocImpact
Supports-blueprint: neutron-ovs-dvr
Change-Id: I35a4b54318d8169eb2c73be77ca2f30bbee08b46
Ensure that extension attributes are always used to
override the chosen defaults. This was not working
in the case of default boolean True, as the testing
condition was wrong.
Closes-bug: #1348479
Change-Id: I22bce82c6078a96c0eb4a67e6decb6e9205721a8
This patch introduces the model and extension
framework for implementing distributed virtual
routing on top of Open vSwitch.
A new admin-only 'distributed' (as opposed to a
'centralized' or legacy-mode) attribute is added
to the API router resource. It is possible to convert
an existing (centralized) router to a distributed
one; the opposite conversion, even though allowed by
the API, may not be honored by the underlying
plugin implementation and an appropriate error will
be reported.
When creating a router (regardless of the user role),
Neutron will rely on a system wide configuration, whose
default currently allows to create 'centralized' routers.
Tests are added for basic unit coverage; when the first
building blocks for neutron-testing-refactor
are complete, functional testing will be added.
This is because we should be moving away from how
extension tests have been done up until now.
Partially-implements: blueprint neutron-ovs-dvr
DocImpact
Change-Id: I7227fbe2718eba6665a5afb5dcaaaa77b341091f
Authored-by: Swaminathan Vasudevan <swaminathan.vasudevan@hp.com>
Co-Authored-By: Armando Migliaccio <armamig@gmail.com>
Dmitrii Shcherbakov