On Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton <blak...@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.l...@gmail.com> wrote: > >> Some comments inline. >> >> BR, >> Germy >> >> On Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton <blak...@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.l...@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@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Kevin Benton >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev