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 [[email protected]]
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 <[email protected]<mailto:[email protected]>> 
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
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to