[openstack-dev] [Neutron][Architecture]Suggestions for the third vendors' plugin and driver

Kevin Benton blak111 at gmail.com
Thu Sep 11 09:47:11 UTC 2014


This has been brought up several times already and I believe is going to be
discussed at the Kilo summit.

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.

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.

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.

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.



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/f9704478/attachment.html>


More information about the OpenStack-dev mailing list