Python framework for cluster (and other multi-broker) tests.

[Alan Conway <al...@gmail.com>]

I've started a python framework for writing tests that start/stop 
multiple brokers, in particular for cluster tests but could be used for 
federation tests etc.
The framework is in python/qpid/brokertest.py, example of use in 
cpp/src/tests/cluster_tests.py

Features include:
  - separate working dir for each test, named after the test.
  - brokers are named, each broker has own data dir and log files under 
test dir
  - easy to start brokers, clusters and other executables (e.g. the 
cluster_tests use the sender/receiver binaries)
  - unique cluster names, can run multiple instances  on the same subnet
  - kills all started processes during teardown, verifies that status 
matches test expectation (exit ok, exit failure or still running)
  - can register other resources for cleanup on teardown - currently 
anything with a stop() method but we can easily extend that.
  - some convenience methods for declaring queues, sending/receiving 
messages using the new python API, this set will grow

I'll be using this for cluster testing I'll be happy to  help anyone who 
wants to use it for other purposes, contributions welcome!

Cheers,
Alan.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: Python framework for cluster (and other multi-broker) tests.

[Robert Godfrey <ro...@gmail.com>]

2009/11/12 Rafael Schloming <ra...@redhat.com>

> Alan Conway wrote:
>
>> I've started a python framework for writing tests that start/stop multiple
>> brokers, in particular for cluster tests but could be used for federation
>> tests etc.
>> The framework is in python/qpid/brokertest.py, example of use in
>> cpp/src/tests/cluster_tests.py
>>
>> Features include:
>>  - separate working dir for each test, named after the test.
>>  - brokers are named, each broker has own data dir and log files under
>> test dir
>>  - easy to start brokers, clusters and other executables (e.g. the
>> cluster_tests use the sender/receiver binaries)
>>  - unique cluster names, can run multiple instances  on the same subnet
>>  - kills all started processes during teardown, verifies that status
>> matches test expectation (exit ok, exit failure or still running)
>>  - can register other resources for cleanup on teardown - currently
>> anything with a stop() method but we can easily extend that.
>>  - some convenience methods for declaring queues, sending/receiving
>> messages using the new python API, this set will grow
>>
>> I'll be using this for cluster testing I'll be happy to  help anyone who
>> wants to use it for other purposes, contributions welcome!
>>
>
> This sounds like some really useful stuff, and I look forward to playing
> with it, but one issue I think we need to sort out is its location, or
> possibly just the general use of the python/qpid dir.
>
> Unfortunately the python/qpid directory is becoming a bit of a dumping
> ground for anything that happens to be written in python, when really it
> started out as the home of the python AMQP client. This makes it rather
> difficult to generate correct API-docs as random non-public utilities can
> easily slip in. As you can imagine it also makes it difficult to write a
> proper README for the directory.
>
> So I think we need to make a bit of a decision on what the python directory
> is for. If we want to keep it as a place for anything that happens to be
> written in python then I need to move the python client elsewhere, and if we
> want to decide that the python client stays here, then we need to be a bit
> more disciplined about checking in code that isn't directly part of the
> python client.
>
> Personally I think the top level division by language is showing its
> limitations, and we should probably have some additional top level locations
> for generically useful stuff like this to live, e.g. an area for
> project-wide testing stuff that isn't really related to one particular
> language silo.
>
> -


+1  As I've said before, organising things soley by the language something
is written in makes no sense to me...   If I want to look for a utility why
should I need to know what language it is written in...  If I find a need
for some sort of general utility am I likely to hunt through every language
directory to see if such a tool exists already... or just build my own
version in the language I am most familiar with?  Making clearer functional
boundaries in the structure (even if only separating out tools and utilities
from the clients/brokers) can only help us in bringing more re-use and
uniformity to the project IMHO

Cheers,
Rob

-- Rob

Re: Python framework for cluster (and other multi-broker) tests.

[Rafael Schloming <ra...@redhat.com>]

Alan Conway wrote:
> I've started a python framework for writing tests that start/stop 
> multiple brokers, in particular for cluster tests but could be used for 
> federation tests etc.
> The framework is in python/qpid/brokertest.py, example of use in 
> cpp/src/tests/cluster_tests.py
> 
> Features include:
>  - separate working dir for each test, named after the test.
>  - brokers are named, each broker has own data dir and log files under 
> test dir
>  - easy to start brokers, clusters and other executables (e.g. the 
> cluster_tests use the sender/receiver binaries)
>  - unique cluster names, can run multiple instances  on the same subnet
>  - kills all started processes during teardown, verifies that status 
> matches test expectation (exit ok, exit failure or still running)
>  - can register other resources for cleanup on teardown - currently 
> anything with a stop() method but we can easily extend that.
>  - some convenience methods for declaring queues, sending/receiving 
> messages using the new python API, this set will grow
> 
> I'll be using this for cluster testing I'll be happy to  help anyone who 
> wants to use it for other purposes, contributions welcome!

This sounds like some really useful stuff, and I look forward to playing 
with it, but one issue I think we need to sort out is its location, or 
possibly just the general use of the python/qpid dir.

Unfortunately the python/qpid directory is becoming a bit of a dumping 
ground for anything that happens to be written in python, when really it 
started out as the home of the python AMQP client. This makes it rather 
difficult to generate correct API-docs as random non-public utilities 
can easily slip in. As you can imagine it also makes it difficult to 
write a proper README for the directory.

So I think we need to make a bit of a decision on what the python 
directory is for. If we want to keep it as a place for anything that 
happens to be written in python then I need to move the python client 
elsewhere, and if we want to decide that the python client stays here, 
then we need to be a bit more disciplined about checking in code that 
isn't directly part of the python client.

Personally I think the top level division by language is showing its 
limitations, and we should probably have some additional top level 
locations for generically useful stuff like this to live, e.g. an area 
for project-wide testing stuff that isn't really related to one 
particular language silo.

--Rafael

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org