[openstack-dev] Quantum L3 router, mixin or plugin?

Gary Kotton gkotton at redhat.com
Thu Nov 8 14:01:34 UTC 2012


On 11/08/2012 03:33 PM, Bob Melander (bmelande) 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.
>

Yay! VRRP will save endless amount of problems with the HA that we have 
the with the layer 3 agents. It would be great if we could add an open 
source solution and it would be beneficial for OpenStack as a whole.

> 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.
>

Agreed. This is just a matter of implementing the API's and this could 
be done today.

> 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.
>

I think that we need to discuss this further and see how we can provide 
a generic base to build upon.

>
> 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.
>

It is a nice idea. We just need to ensure that we support the current l3 
functionality.

>
> 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

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


More information about the OpenStack-dev mailing list