On 02/12/2015 07:49 AM, Gary Kotton wrote: > > > On 2/12/15, 1:33 PM, "Chmouel Boudjnah" <chmo...@enovance.com> wrote: > >> Jaume Devesa <devv...@gmail.com> writes: >> >>> Following the conversation... >>> >>> We have seen that glusterfs[1] and ec2api[2] use different approach >>> when it comes to repository managing: whereas glusterfs is a single >>> 'devstack' directory repository, ec2api is a whole project with a >>> 'devstack' directory on it. >>> >>> We plan to migrate 'python-neutron-plugin-midonet'[3] project to >>> Stackforge too. It makes sense to add the 'devstack' directory on it? >>> Or do you recommend us to have two different repositories in >>> Stackforge: one for the neutron plugin and the other one for the >>> devstack plugin? >> >> as you stated I don't think there is a clear advantage or disadvantage >> but IMO having too many repositories is not very user friendly and I would >> recommend to have the plugin directly in the repo. >> >> For things like glusterfs which is not a native openstack project it >> makes sense that the plugin is hosted externally of the project. > > I am in favor of having these in the devstack reop. I think that keeping > everything under the same umbrella is the healthiest model. Moving things > to different repos is a a challenge and leads to endless problems (that is > my two cents)
I believe the question was really should the devstack plugin be in 'python-neutron-plugin-midonet' repo or in an additional 'python-neutron-plugin-midonet-devstack' repo. Being in the main devstack tree was never on the table. I -1ed that review and sent them down this path. The Long Term Evolution for Devstack is external plugins for most things - https://github.com/openstack-dev/devstack/blob/master/FUTURE.rst I'm going to be -1ing most new or substantially redone drivers at this point. External plugins are a better model for those. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
