Open Stack

Hi,

As Dan said, the mixin approach was mainly adopted for quickly achieving a
solution for providing L3 forwarding, plus SNAT and DNAT capabilities in
order to get closer to parity with nova network. This approach, despite
being easy to implement and understand, comes with several drawbacks. Most
importantly it increases the complexity of the resulting plugin, which will
have to manage plenty of features, and also makes it harder to support
different technologies.

I think it makes sense, during the Grizzly timeframe, to split the l3
functionality in its own plugin. I will be happy to do this during the
Grizzly-2 milestone, leveraging the work Eugene is doing for the Grizzly-1
milestone. As I have dealt with Quantum API and DB layers in the past, I
should comfortable enough in doing this change. The current Quantum L3
agent will be able to keep working as it is doing now, even if L3 feature
is moved into a separate plugin.

As a note, methods such as process_l3_create, process_l3_update, or
filter_nets_l3, are needed for allowing the core L2 plugin to deal with
extensions to the L2 API resources introduced by the L3 plugin. We are
already aware that they are not very nice in the overall architecture, as
ideally one would like extensions to process the resource they're extending
a pipeline-like fashion. Bob Kukura was aiming at doing some work in this
direction.

Also, I would like to mention that we are moving L3 APIs into the 'core'.
Just to be clear - the 'core API' is different from the 'core' plugin. We
regard as 'core API' the minimum set of APIs that every Quantum deployment
needs to provide. Everything else is an extension. The implications on the
plugin layer, if we split L2 and L3 plugin, is that each deployment should
have at least two plugins.

Salvatore


On 9 November 2012 12:42, Bob Melander (bmelande) <bmelande at cisco.com>wrote:

>  Ok, I'm willing to work on this and I've created a blueprint to kick it
> off (
> https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin)
>
>  I too think VRRP (and some other features) would be nice to add.
> However, the first steps would be to take the inherited mixin and transform
> that into a plugin. That ought to be possible with fairly limited effort.
> Though there are some dependencies that need to be sorted out. In
> particular, core plugin methods like  create_network(…)make calls to
> mixin functions such as _process_l3_create(…),
> _extend_network_dict_l3(…), _process_l3_update(…):
>
>
>  self._process_l3_create(context, network['network'], net['id'])
>
> …
>
> self._extend_network_dict_l3(context, net)
>
>  This does not immediately map to the service insertion schematic:
>
> [image: ServiceIntegration.jpg]
>  / Bob
>
>
>
>
>   From: Dan Wendlandt <dan at nicira.com>
> Reply-To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> Date: torsdag 8 november 2012 21:03
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
>
> Subject: Re: [openstack-dev] Quantum L3 router, mixin or plugin?
>
>  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:
>
>  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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> 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/20121109/0ac7e8df/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2E546006-960D-4222-A4CA-EE7A5E73431B.png
Type: image/png
Size: 131787 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121109/0ac7e8df/attachment.png>