sure and thanks a lot Lucas
I will explore all this, appreciate your help
Regards, Mitts
On Fri, Mar 16, 2012 at 6:11 AM, Lucas Meneghel Rodrigues
<l...@redhat.com>wrote:
> On 03/15/2012 07:20 PM, mitts daki wrote:
>
>> Thanks lot Lucas,
>>
>> This helps let me try this but have another question
>>
>> is there a way can I have resource control on this? is it possible?
>>
>
> It's possible, certainly. I was thinking, you could create a multiple
> machine test abstraction that knows the number of machines needed to
> run it, and keeps a list of the machines already gathered so far. It'd
> be something roughly along the lines:
>
> class TestMM(object):
> """
> Shell class for a test that might run in multiple machines.
> """
> def __init__(self, name, machines_required):
> self.name = name
> self.machines_required = machines_required
> self.hosts = []
> self.lock = open("/tmp/test-mm-lock", "w+")
>
> def host_checkin(self, host):
> return_value = False
>
> fcntl.lockf(self.lock, fcntl.LOCK_EX)
> if not self.ready_to_execute():
> self.hosts.append(host)
> return_value = True
> fcntl.lockf(lockfile, fcntl.LOCK_UN)
> return return_value
>
>
> def ready_to_execute(self):
> return not len(self.hosts) < self.machines_required
>
>
> class TestPool(object):
> def __init__(self):
> self.available_tests = [ list with 2000 TestMM class instances ]
> self.lock = open("/tmp/test-pool-lock", "w+")
>
> def get_test():
> fcntl.lockf(self.lock, fcntl.LOCK_EX)
> test = self.available_tests.pop()
> fcntl.lockf(self.lock, fcntl.LOCK_UN)
>
> return test
>
>
> test_pool = TestPool()
>
> TIME_WAIT = 10
>
>
> def run(machine):
> host = hosts.create_host(machine)
> at = autotest_remote.Autotest(host)
> while test_pool.available_tests:
> t = test_pool.get_test()
> if not t.host_checkin(host):
> continue
>
> while not t.ready_to_execute():
> sleep TIME_WAIT
> at.run_test(t.name)
>
> job.parallel_simple(run, machines)
>
> Again, this is not working code. You still have things to figure out and
> adjust, this is just an idea based on the requirements you've given me. I
> figured out it was better than explaining things in abstract terms. You'll
> have to study better:
>
> * Mechanisms to sync test threads, such as barriers
> * Interfaces of functions such as at.run_test
> * How to turn your 2000 functional tests into tests runnable by autotest
> * Deal with the stupid bugs that might be lurking around on this sketch I
> wrote and I did not notice :)
>
> I hope this all was useful,
>
> Lucas
>
_______________________________________________
Autotest mailing list
Autotest@test.kernel.org
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
