[openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing

Gary Kotton gkotton at vmware.com
Thu Feb 12 12:49:13 UTC 2015



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)
>
>Chmouel
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list