Open Stack

Hi Salvatore,

Thank you very much for your feedback,
I already knew about the 'maintainer' policy, and I saw in the Neutron wiki that: "This may be achieved by having an existing core dev agree to maintain a plugin, or by having one of the developers of the plugin become a member of the core developer team". I am aware of the core-developer's duties as described in the wiki, and if the team agrees I will be really glad to be part of it in order to maintain the plugin and contribute to the project even more :)

The plugin is not exactly a derivative of OVS's, it's designed to work on top of any L2 plugin, provided that the needed support is implemented.
For now, we are only supporting OVS's plugin, but I plan on extending the number of supported plugins as long as the model is approved (or alternatively switch to an Openstack "standard" model :) ).

As you suggested, I'll push the plugin code as a draft soon, which will make it easier to discuss this kind of things.

Thank you,
Ivar.


________________________________
From: Salvatore Orlando [sorlando at nicira.com]
Sent: Wednesday, July 10, 2013 11:17 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron] Embrane's Neutron Plugin

Hi Ivar,

thanks for your interest in Openstack and Neutron.
A few replies inline; I hope you'll find them useful.

Salvatore


On 10 July 2013 02:40, Ivar Lazzaro <ivar at embrane.com<mailto:ivar at embrane.com>> wrote:

Hi,

My name is Ivar Lazzaro, I’m an Italian developer currently employed at Embrane.


Embrane provides L3 to L7 network services, (including routing, load balancing, SSL offloads, firewalls and IPsec VPNs), and we have developed a Neutron plugin that we would like to share and contribute to Openstack[1].

That would be great!
the current policy for Neutron plugins is that each plugin should have a member of the core team which will act as a 'maintainer'; this figure is not required to be an 'expert' of the specific plugin technology. His duties are mainly those of keeping track of bugs/blueprints, review code, and interact with the developers.


My experience with OpenStack started with the Essex edition, which I deployed and managed as a "user". Embrane leverages any existing form of L2 to offer connectivity at L3 and above, and therefore our interest in contributing to OpenStack grew as L3 (and above) capabilities started to be added to Neutron, leading to the realization of a Neutron plugin.


I'd like to talk about it with you before "blindly" requesting a review, and get your feedback and advice in order to improve it at the most!

Sounds a very sensible approach, since we're already halfway through the release cycle, and finding resources for reviewing code might not be the easiest thing.


The idea is to provide L3 connectivity in Openstack through our software platform, called heleos, obviously using a plugin to follow the Neutron workflow.Since we don't provide L2 connectivity (which is part of the core APIs as well) our plugin is going to work together with one of the existing, which will manage L2 connectivity and share all the information needed.


Therefore, whenever a user chooses to use Embrane's Neutron plugin, he specifies one of the supported existing plugins in the configuration file, and L2 connectivity will be provided by that specific choice.

At the current state, for instance, our plugin is able to work with the OpenVSwitch's so that:


-create_network() will call OVS plugin;

-create_port() will call OVS plugin;

-crate_router() will call Embrane's which will use knowledge from the OVS plugin in order to provide L3 connectivity.


It looks like your plugin is pretty much a derivative of the OVS plugin, which replaces the L3 agent with Embrane's heleos.
I think this approach makes some sense, but in the medium/long term you would like to be able to run your plugin on top of any L2 plugin.

There is a Neutron blueprint for that, and that is https://blueprints.launchpad.net/neutron/+spec/quantum-l3-routing-plugin
That blueprint is unfortunately a bit stuck at the moment.
It would be good for the whole community to understand whether we can actually still merge it during the Havana timeframe.


and so forth...

The calls can be asynchronous (using Router "status" in a way similar to the LBaaS extension).


Without going too much into details, that's all about the L3 plugin that we would like to share. We are also interested in sharing a LBaaS service plugin, but I'll do a different blueprint for that one.

I think it won't harm pushing your code as a draft on gerrit.

All your feedback and comments are welcome :)


Thanks,

Ivar.


[1] https://blueprints.launchpad.net/neutron/+spec/embrane-neutron-plugin

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20130710/a3b13340/attachment.html>