[Openstack] [Quantum] Running plugin tests with tox

2012-08-24 Thread Maru Newby
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?

Thanks,


Maru

On 2012-08-24, at 2:56 PM, Salvatore Orlando (Code Review) wrote:

 Salvatore Orlando has uploaded a new change for review.
 
 Change subject: Enable tox to run OVS plugin unit tests
 ..
 
 Enable tox to run OVS plugin unit tests
 
 Fix bug 1029142
 
 Unit tests have been moved into /quantum/tests/unit
 
 Change-Id: I5d0fa84826f62a86e4ab04c3e1958869f24a1fcf
 ---
 D quantum/plugins/openvswitch/run_tests.py
 D quantum/plugins/openvswitch/tests/__init__.py
 D quantum/plugins/openvswitch/tests/unit/__init__.py
 R quantum/tests/unit/test_ovs_db.py
 R quantum/tests/unit/test_ovs_defaults.py
 R quantum/tests/unit/test_ovs_rpcapi.py
 R quantum/tests/unit/test_ovs_tunnel.py
 7 files changed, 0 insertions(+), 72 deletions(-)
 
 
  git pull ssh://review.openstack.org:29418/openstack/quantum 
 refs/changes/22/11922/1
 --
 To view, visit https://review.openstack.org/11922
 To unsubscribe, visit https://review.openstack.org/settings
 
 Gerrit-MessageType: newchange
 Gerrit-Change-Id: I5d0fa84826f62a86e4ab04c3e1958869f24a1fcf
 Gerrit-PatchSet: 1
 Gerrit-Project: openstack/quantum
 Gerrit-Branch: master
 Gerrit-Owner: Salvatore Orlando salv.orla...@gmail.com


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] [Quantum] Running plugin tests with tox

2012-08-24 Thread Salvatore Orlando
Hi Maru,

whether plugins should be packaged or not with the main quantum service is
a recurrent question on this mailing list - and I am afraid I don't have
answer to it!
Pro and cons of separating the plugins from the main repository have been
discussed on the mailing list and on the IRC channels; I hope some final
deciscion/action will be agreed at the next Openstack summit. However, so
far nothing has been done in this direction.

As concerns testing, our goal is to ensure that plugins too are covered by
unit tests just like the quantum service. This can be achieved in two ways:
1) moving all tests in the same tree, so that  a single tox run can run
them all, or
2) modifying the unit testing script on the openstack jenkins to run tox in
the main tests directory and into each plugin's test dir.

The approach I am following so far is the first, which seem consistent with
what nova does for its virt drivers; however if we (and the openstack-ci
team) believe we should do it differently, we could have a tox.ini and a
test-requires into each plugin folder, and execute a tox run for each
plugin (plus a tox run for the quantum service)

Salvatore


On 24 August 2012 17:35, Maru Newby mne...@internap.com wrote:

 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?

 Thanks,


 Maru

 On 2012-08-24, at 2:56 PM, Salvatore Orlando (Code Review) wrote:

  Salvatore Orlando has uploaded a new change for review.
 
  Change subject: Enable tox to run OVS plugin unit tests
  ..
 
  Enable tox to run OVS plugin unit tests
 
  Fix bug 1029142
 
  Unit tests have been moved into /quantum/tests/unit
 
  Change-Id: I5d0fa84826f62a86e4ab04c3e1958869f24a1fcf
  ---
  D quantum/plugins/openvswitch/run_tests.py
  D quantum/plugins/openvswitch/tests/__init__.py
  D quantum/plugins/openvswitch/tests/unit/__init__.py
  R quantum/tests/unit/test_ovs_db.py
  R quantum/tests/unit/test_ovs_defaults.py
  R quantum/tests/unit/test_ovs_rpcapi.py
  R quantum/tests/unit/test_ovs_tunnel.py
  7 files changed, 0 insertions(+), 72 deletions(-)
 
 
   git pull 
  ssh://review.openstack.org:29418/openstack/quantumrefs/changes/22/11922/1
  --
  To view, visit https://review.openstack.org/11922
  To unsubscribe, visit https://review.openstack.org/settings
 
  Gerrit-MessageType: newchange
  Gerrit-Change-Id: I5d0fa84826f62a86e4ab04c3e1958869f24a1fcf
  Gerrit-PatchSet: 1
  Gerrit-Project: openstack/quantum
  Gerrit-Branch: master
  Gerrit-Owner: Salvatore Orlando salv.orla...@gmail.com


 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] [Quantum] Running plugin tests with tox

2012-08-24 Thread James E. Blair
Maru Newby mne...@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.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp