[openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

Henry henry4hly at gmail.com
Tue Dec 16 12:56:28 UTC 2014



Sent from my iPad

On 2014-12-16, at 下午2:54, "Armando M." <armamig at gmail.com> wrote:

> 
> 
> Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
> Who will be responsible for these drivers?
> 
> Excellent question. In my opinion, 'technology' specific but not vendor specific MD (like SRIOV) should not be maintained by specific vendor. It should be accessible for all interested parties for contribution.
> 
> I don't think that anyone is making the suggestion of making these drivers develop in silos, but instead one of the objective is to allow them to evolve more rapidly, and in the open, where anyone can participate.
>  
> 
> The OVS driver is maintained by Neutron community, vendor specific hardware driver by vendor, SDN controllers driver by their own community or vendor. But there are also other drivers like SRIOV, which are general for a lot of vendor agonitsc backends, and can't be maintained by a certain vendor/community.
> 
> Certain technologies, like the ones mentioned above may require specific hardware; even though they may not be particularly associated with a specific vendor, some sort of vendor support is indeed required, like 3rd party CI. So, grouping them together under an hw-accelerated umbrella, or whichever other name that sticks, may make sense long term should the number of drivers really ramp up as hinted below.

There are also MD not related with hardware, like via-tap, vif-vhostuser. Even for sriov, a stub agent for testing is enough, no need for real hardware.

All these MD should be very thin, only handle port binding.

>  
> 
> So, it would be better to keep some "general backend" MD in tree besides SRIOV. There are also vif-type-tap, vif-type-vhostuser, hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base MD that only handle "vif bind" which is backend agonitsc, then backend provider is free to implement their own service logic, either by an backend agent, or by a driver derived from the base MD for agentless scenery.
> 
> Keeping general backend MDs in tree sounds reasonable.
> Regards
> 
> > Many thanks,
> >      Neil
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> 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/20141216/8914ec6a/attachment.html>


More information about the OpenStack-dev mailing list