Open Stack

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 <blak111 at gmail.com> 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 <luke at tail-f.com> wrote:
>>
>> On 28 April 2015 at 10:14, Duncan Thomas <duncan.thomas at gmail.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Kevin Benton
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
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/20150429/0cdc55c1/attachment.html>