Open Stack

On Wed, Apr 29, 2015 at 12:34 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> 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
>

+1. I totally agree that we should keep the common bits like ML2,
however this is not the same as what the reference implementation
splitting spec suggested. The intention of spec is no common
implementation bits any more, leaving only API/DB.

>
> 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
>
> __________________________________________________________________________
> 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
>