Open Stack

Hi Jim,

Thank you for the insight.  Breaking the plugins out of the main tree makes no sense given the packaging constraint.  Even breaking out the dependencies for each would seem to be an impossibility.  Though multiple dependency files could be handled in testing easily enough, there would be no good way to handle the for packaging.  So long as the plugins have to remain in the repo (and that's my understanding), they'll have to be remain in the main tree.  Oh well, it was a nice thought.

Cheers,


Maru 

On 2012-08-24, at 5:26 PM, James E. Blair wrote:

> Maru Newby <mnewby at internap.com> writes:
> 
>> Hi Salvatore,
>> 
>> I see you're working on getting plugins testable with tox:
>> 
>> https://review.openstack.org/#/c/11922/
>> 
>> What about keeping the plugins isolated for testing purposes?  I have
>> been unable to work on it yet, but I was thinking it might be a good
>> idea to move the plugins out of the main tree (but still in the same
>> repo) for ease of maintenance, testing and deployment.  The thought
>> was:
>> 
>> - relocate all plugins outside of main quantum tree (plugins/ dir in the repo root)
>> - give each plugin 
>>  - its own python root-level package (e.g. quantum_ovs)
>>  - its own tox.ini
>>  - its own tools/*-requires
>> 
>> So the layout would be something like:
>> 
>> plugins/quantum_ovs/tox.ini
>> plugins/quantum_ovs/quantum_ovs/__init__.py
>> plugins/quantum_ovs/tests/__init__.py
>> plugins/quanum_ovs/tools/pip-requires
>> ....
>> plugins/quantum_linuxbridge/tox.ini
>> ...
>> 
>> The tests for each plugin could then be executed via an independent tox run.
>> 
>> Is there any merit to this, now or in the future?
> 
> I don't think we should do that -- it's fine to organize the tree
> however you see fit, of course, but a while back we implemented the
> Project Testing Interface:
> 
>  http://wiki.openstack.org/ProjectTestingInterface
> 
> where we expect each project to have just one tox.ini, one set of
> dependencies, and run one set of tests.  We automatically manage 239
> Jenkins jobs (and counting) based on that interface which would not be
> possible if we had to customize the jobs for each project.  Also, keep
> in mind that we use tox to generate tarballs, so splitting that up means
> multiple release artifacts for a single repo, which is also something we
> want to avoid.
> 
> If the plugins are truly independent enough that they should be tested,
> packaged, and released separately from quantum, we may want to consider
> making separate projects for them.  Otherwise, if they should continue
> to live in the quantum project itself, it would be great if we stuck
> with the established interface.
> 
> -Jim
> 
> PS, This seems more like an openstack-dev discussion, let's move it to
> that list.