Yes, ml2 was created since each of the drivers used to be required to do everything themselves and it was decided it would be far better for everyone to share the common bits. Thats what ml2s about. Its not about implementing an sdn
Thanks, Kevin ________________________________ From: loy wolfe Sent: Tuesday, April 28, 2015 6:16:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future? On Wed, Apr 29, 2015 at 2:59 AM, Kevin Benton <[email protected]> wrote: > The concern is that having broken drivers out there that claim to work with > an OpenStack project end up making the project look bad. It's similar to a > first time Linux user experiencing frequent kernel panics because they are > using hardware with terrible drivers. They aren't going to recognize the > distinction and will just assume the project is bad. > I think the focal point is not about device driver for the "real" backend such as OVS/LB or HW TOR, but ML2 vs. external SDN controllers which are also claimed to be backends by some people. Again analogy with Linux, which has socket layer exposing the API, common tcp/ip stack and common netdev & skbuff, and each NIC has its own device driver (real backend). While it make sense to discuss whether those backend device driver should be splitted out of tree, there was no consideration that the common middle stacks should be splitted for "equal footing" with some other external implementations. Things are slimiar with Nova & Cinder. we may have all kinds of virt driver and volume driver, but only one common scheduling & compute/volume manager implementation. For Neutron it is necessary to support hundreds of real backends, but does it really benefit customers to equal footing the ML2 with a bunch of other external SDN controllers? Best Regards > >>I would love to see OpenStack upstream acting more like a resource to >> support users and developers > > I'm not sure what you mean here. The purpose of 3rd party CI requirements is > to signal stability to users and to provide feedback to the developers. > > On Tue, Apr 28, 2015 at 4:18 AM, Luke Gorrie <[email protected]> wrote: >> >> On 28 April 2015 at 10:14, Duncan Thomas <[email protected]> wrote: >>> >>> If we allow third party CI to fail and wait for vendors to fix their >>> stuff, experience has shown that they won't, and there'll be broken or >>> barely functional drivers out there, and no easy way for the community to >>> exert pressure to fix them up. >> >> >> Can't the user community exert pressure on the driver developers directly >> by talking to them, or indirectly by not using their drivers? How come >> OpenStack upstream wants to tell the developers what is needed before the >> users get a chance to take a look? >> >> I would love to see OpenStack upstream acting more like a resource to >> support users and developers (e.g. providing 3rd party CI hooks upon requst) >> and less like gatekeepers with big sticks to wave at people who don't drop >> their own priorities and Follow The Process. >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
