Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

I agree with Armando that at the end of the day user requirements should drive these decisions. I think you did a good job in listing what are the pro and the cons of choosing standalone plugin rather than a ML2 driver. The most important point you made, in my opinion, concerns the ability of

Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

On 22 January 2016 at 10:35, Neil Jerram wrote: > * Why change from ML2 to core plugin? > > - It could be seen as resolving a conceptual mismatch. > networking-calico uses > IP routing to provide L3 connectivity between VMs, whereas ML2 is > ostensibly > all about

Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

On 22 January 2016 at 10:35, Neil Jerram wrote: > networking-calico [1] is currently implemented as an ML2 mechanism > driver, but > I'm wondering if it might be better as its own core plugin, and I'm > looking for > input about the implications of that, or for

[openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

networking-calico [1] is currently implemented as an ML2 mechanism driver, but I'm wondering if it might be better as its own core plugin, and I'm looking for input about the implications of that, or for experience with that kind of change; and also for experience and understanding of hybrid ML2