Open Stack

On Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton <blak111 at gmail.com> wrote:

>
> > Maybe I missed something, but what's the solution?
>
> There isn't one yet. That's why it's going to be discussed at the summit.
>
So my suggestion is remove all vendors' plugins and drivers except
opensource as built-in.
By leaving open source plugins and drivers in the tree , we can resolve
such problems:
  1)release a workable and COMPLETE version
  2)user experience(especially for beginners)
  3)provide code example to learn for new contributors and vendors
  4)develop and verify new features

>
>
> > I think we should release a workable version.
>
> Definitely. But that doesn't have anything to do with it living in the
> same repository. By putting it in a different repo, it provides smaller
> code bases to learn for new contributors wanting to become a core developer
> in addition to a clear separation between plugins and core code.
>
Why do we need a different repo to store vendors' codes? That's not the
community business.
I think only a proper architecture and normal NB&SB API can bring "a clear
separation between plugins(or drivers) and core code", not a different repo.
Of course, if the community provides a wiki page for vendors to add
hyperlink of their codes, I think it's perfect.

>
> > Besides of user experience, the open source drivers are also used for
> developing and verifying new features, even small-scale case.
>
> Sure, but this also isn't affected by the code being in a separate repo.
>
See comments above.

>
> > The community should and just need focus on the Neutron core and provide
> framework for vendors' devices.
>
> I agree, but without the open source drivers being separated as well, it's
> very difficult for the framework for external drivers to be stable enough
> to be useful.
>
Architecture and API. The community should ensure core and API stable
enough and high quality. Vendors for external drivers.
Who provides, who maintains(including development, storage, distribution,
quality, etc).

>
> On Thu, Sep 11, 2014 at 7:24 PM, Germy Lure <germy.lure at gmail.com> wrote:
>
>> Some comments inline.
>>
>> BR,
>> Germy
>>
>> On Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton <blak111 at gmail.com> wrote:
>>
>>> This has been brought up several times already and I believe is going to
>>> be discussed at the Kilo summit.
>>>
>> Maybe I missed something, but what's the solution?
>>
>>
>>> I agree that reviewing third party patches eats community time. However,
>>> claiming that the community pays 46% of it's energy to maintain
>>> vendor-specific code doesn't make any sense. LOC in the repo has very
>>> little to do with ongoing required maintenance. Assuming the APIs for the
>>> plugins stay consistent, there should be few 'maintenance' changes required
>>> to a plugin once it's in the tree. If there are that many changes to
>>> plugins just to keep them operational, that means Neutron is far too
>>> unstable to support drivers living outside of the tree anyway.
>>>
>> Yes, you are right. "Neutron is far too unstable to support drivers
>> living outside of the tree anyway". So I think this is really our important
>> point.
>> The community should focus on standardizing NB&SB API, introducing and
>> improving new features NOT wasting energy to introduce and maintain
>> vendor-specific codes.
>>
>>>
>>> On a related note, if we are going to pull plugins/drivers out of
>>> Neutron, I think all of them should be removed, including the OVS and
>>> LinuxBridge ones. There is no reason for them to be there if Neutron has
>>> stable enough internal APIs to eject the 3rd party plugins from the repo.
>>> They should be able to live in a separate neutron-opensource-drivers repo
>>> or something along those lines. This will free up significant amounts of
>>> developer/reviewer cycles for neutron to work on the API refactor, task
>>> based workflows, performance improvements for the DB operations, etc.
>>>
>> I think we should release a workable version. User can experience the
>> functions powered by built-in components. And they can replace them with
>> the release of those vendors who cooperate with them. The community
>> should not work for vendor's codes.
>>
>>>
>>> If the open source drivers stay in the tree and the others are removed,
>>> there is little incentive to keep the internal APIs stable and 3rd party
>>> drivers sitting outside of the tree will break on every refactor or data
>>> structure change. If that's the way we want to treat external driver
>>> developers, let's be explicit about it and just post warnings that 3rd
>>> party drivers can break at any point and that the onus is on the external
>>> developers to learn what changed an react to it. At some point they will
>>> stop bothering with Neutron completely in their deployments and mimic its
>>> public API.
>>>
>> Besides of user experience, the open source drivers are also used for
>> developing and verifying new features, even small-scale case.
>>
>>>
>>> A clear separation of the open source drivers/plugins and core Neutron
>>> would give a much better model for 3rd party driver developers to follow
>>> and would enforce a stable internal API in the Neutron core.
>>>
>> The community should and just need focus on the Neutron core and provide
>> framework for vendors' devices. Vendors just need adapt Neutron API and
>> focus on their codes' quality. If not, I think the architecture is not
>> proper. Everyone should only carry their own monkey.
>>
>>>
>>>
>>>
>>> On Thu, Sep 11, 2014 at 1:54 AM, Germy Lure <germy.lure at gmail.com>
>>> wrote:
>>>
>>>> Hi stackers,
>>>>
>>>> According to my statistics(J2), the LOC of vendors' plugin and driver
>>>> is about 102K, while the whole under neutron is 220K.
>>>> That is to say the community has paid and is paying over 46% energy to
>>>> maintain vendors' code. If we take mails, bugs,
>>>> BPs  and so on into consideration, this percentage will be more.
>>>>
>>>> Most of these codes are just plugins and drivers implementing
>>>> almost  the same functions. Every vendor submits a plugin,
>>>> and the community only do the same thing, repeat and repeat.
>>>> Meaningless.I think it's time to move them out.
>>>> Let's focus on improving those exist but still weak features, on
>>>> introducing important and interesting new features.
>>>>
>>>> My suggestions now:
>>>> 1.monopolized plugins
>>>>   1)The community only standards NB API and keeps built-ins, such as
>>>> ML2, OVS and Linux bridge plugins.
>>>>   2)Vendors maintain their plugins locally.
>>>>   3)Users get neutron from community and plugin from some vendor on
>>>> demand.
>>>> 2.service plugins
>>>>   1)The community standards SB API and keeps open source
>>>> driver(iptables, openSwan and etc.) as built-in.
>>>>   2)Vendors only provide drivers not plugin. And those drivers also
>>>> need not deliver to community.
>>>>   3)Like above, Users can get code on demand from vendors or just use
>>>> open source.
>>>> 3.ML2 plugin
>>>>   1)Like service and monopolized plugin, the community just keep open
>>>> source implementations as built-in.
>>>>   2)L2-population should be kept.
>>>>
>>>> I am very happy to discuss this further.
>>>>
>>>> vendors' code stat. table(excluding built-in plugins and drivers)
>>>> ------------------------------------------------------------
>>>> Path                                                     Size
>>>> neutron-master\neutron\plugins\    63170
>>>> neutron-master\neutron\services\     4052
>>>> neutron-master\neutron\tests\             35756
>>>>
>>>> BR,
>>>> Germy
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Kevin Benton
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> _______________________________________________
> 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/20140912/7faffbe9/attachment.html>