[openstack-dev] [Neutron] Core/Vendor code decomposition

Kevin Benton blak111 at gmail.com
Wed Dec 10 16:40:00 UTC 2014


>Remove everything out of tree, and leave only Neutron API framework as integration
platform, would lower the attractions of the whole Openstack Project.
Without a default "good enough" reference backend from community, customers
have to depends on packagers to fully test all backends for them.

That's not what's being proposed. Please read the spec.
There will still be a tested reference implementation from the community
that gates all changes. Where the code lives has no impact on customers.

On Wed, Dec 10, 2014 at 12:32 AM, loy wolfe <loywolfe at gmail.com> wrote:

> Remove everything out of tree, and leave only Neutron API framework as
> integration platform, would lower the attractions of the whole
> Openstack Project. Without a default "good enough" reference backend
> from community, customers have to depends on packagers to fully test
> all backends for them. Can we image nova without kvm, glance without
> swift? Cinder is weak because of default lvm backend, if in the future
> Ceph became the default it would be much better.
>
> If the goal of this decomposition is eventually moving default
> reference driver out, and the in-tree OVS backend is an eyesore, then
> it's better to split the Neutron core with base repo and vendor repo.
> They only share common base API/DB model, each vendor can extend their
> API, DB model freely, using a shim proxy to delegate all the service
> logic to their backend controller. They can choose to keep out of
> tree, or in tree (vendor repo) with the previous policy that
> contribute code reviewing for their code being reviewed by other
> vendors.
>
> _______________________________________________
> 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/20141210/08770297/attachment.html>


More information about the OpenStack-dev mailing list