Open Stack

Yes, being able to implement the L3 stuff independent of the core plugin
(rather than as a mixin, tightly bound to the core plugin) was always the
plan.  We did it as a mix-in for Folsom, as we didn't have time for the
multi-service framework, but wanted to deliver L3 capabilities.  You can
see the blueprint for this, which is targeted at G-1:
https://blueprints.launchpad.net/quantum/+spec/quantum-service-framework

I don't think anyone has signed up to do the work to port the L3 API to
this new framework, so feel free to create a blueprint and add a dependency
to the above blueprint.

dan

On Thu, Nov 8, 2012 at 5:33 AM, Bob Melander (bmelande)
<bmelande at cisco.com>wrote:

>  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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121108/4926ca1c/attachment.html>