Open Stack

In the wake of the recent discussion about service insertion, which seems to have landed in a decision to make each type of service (like LBaaS, FW, …) a separate plugin, I want to raise the issue whether this approach shouldn't also be adopted for L3 router functionality. This is not the case now, where instead the server side is implemented as a L3_NAT_db_mixin class that basically each plugin inherits. The actual routing is implemented through the separate L3 agent (L3NATagent class) that relies on linux namespaces, the kernel IP forwarding functionality and IP tables.


My concern about this is the following: Suppose one would like to replace (or complement) that router implementation with something else, e.g., use a separate 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, just as there will be separate plugins for LBaaS, FW, etc. With L3 routing also as a separate plugin, it seems to me it would be simpler to provide different such implementations, largely independent of (L2) core plugin but also to introduce additional L3 specific extensions.


What is your view on this?

/ Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121108/9d0db5e0/attachment.html>