Migrate L3 router service from mixin to plugin
Currently, the L3 router and floatingip functionality is essentially implemented as two components; a server-side piece, which is essentially the L3_NAT_db_mixin class that is inherited by all core plugins, and an L3 agent (L3NATAgent class) where the actual routing is done (using Linux namespaces, the kernel IP forwarding functionality and IP tables).
Suppose one would like to replace (or complement) that router implementation with something else, e.g., use a hardware-based router or add additional features like VRRP to the implementation. As long as the changes can be contained within the L3 agent (while honoring the normal interface), it is fairly simple to just replace the default one with the extended l3 agent in the deployment. However, if the desired functionality requires changes to the "server side", i.e., the L3_NAT_db_mixin class, the situation gets much more tricky since the mixin is essentially baked into the core plugin.
A way around this problem could be to provide the L3 routing functionality as a separate plugin. This should be done analogous to how advanced services like LBaaS, FW, will be implemented as separate plugins as targeted in this blueprint:
https:/
Blueprint information
- Status:
- Complete
- Approver:
- Mark McClain
- Priority:
- Medium
- Drafter:
- Bob Melander
- Direction:
- Approved
- Assignee:
- Bob Melander
- Definition:
- Discussion
- Series goal:
- Accepted for havana
- Implementation:
-
Implemented
- Milestone target:
-
2013.2
- Started by
- Bob Melander
- Completed by
- Bob Melander
Related branches
Related bugs
Sprints
Whiteboard
16-Jul: Moving to H3 since this will not make the H2 cutoff.
Could we get some use cases for this blueprint ?
----
Well, the main motivation is to make L3 routing/gateway functionality more "pluggable" just as core L2 functionality is "pluggable". By pluggable I here mean the possibility for the cloud provider to choose (L2/Core) plugin by simply setting values appropriately in some configuration files.
With L3 router/gateway as a service plugin it will be easier for vendors (and others) to create additional router/gateway service implementations (software only or for hardware routers) and to expose additional functionality through extensions.
The primary use case, if one can call it that, is the the cloud provider can choose to use a core plugin A with a L3 plugin B or some other combination; like core plugin A with L3 plugin C etc.
An additional note:
Even with a refactoring so that it becomes possible to provide L3 router/gateway as a plugin, nothing should prevent a core plugin to provide that L3 functionality as is the case today.
---
danwent: the key motivation, I believe, is to be able to choose an L3 implementation "strategy" independent of the L2/IPAM implementation. Currently, choosing a "core" plugin determines both the L2, IPAM, and L3 "strategy".
This change may be too disruptive to introduce in G-3, but accepting it for grizzly so we can have the discusion.
---
This patch requires a modification of Devstack to the openvswitch plugin. The BP for that modification is found in the dependency tree.
Gerrit topic: https:/
Addressed by: https:/
Adds support for L3 routing functionality to be provided as a service plugin
---
Update 2013-05-27
Retargeting to H-2 as a few more cycles are needed
Work Items
Dependency tree
* Blueprints in grey have been implemented.
