[openstack-dev] [Openstack] [Quantum] Running plugin tests with tox

James E. Blair corvus at inaugust.com
Fri Aug 24 16:26:37 UTC 2012


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.



More information about the OpenStack-dev mailing list