Open Stack

On 02/12/2015 07:49 AM, Gary Kotton wrote:
> 
> 
> On 2/12/15, 1:33 PM, "Chmouel Boudjnah" <chmouel at enovance.com> wrote:
> 
>> Jaume Devesa <devvesa at 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