Intrigued by the question as we might have a similar use case I simply tried the hostless job from UI.
It appears to work exactly as you might want: there is no interaction with client and control file is simply executed on the server. You do get results/logs under "hostless" directory. Of course you can do whatever is suitable in the control file. Cursory look at the scheduler code appears to support the idea that it was put in place for such use cases. Rpc interface create_job supports hostless parameter so it would be rather easy to enable it in the CLI. Lucas - what do you think? Julius -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Vadim Bendebury Sent: Monday, February 04, 2013 2:10 PM To: Lucas Meneghel Rodrigues Cc: [email protected] Subject: Re: [Autotest] An autotest running exclusively on the server On Mon, Feb 4, 2013 at 8:12 AM, Lucas Meneghel Rodrigues <[email protected]> wrote: > On 01/29/2013 07:08 PM, Vadim Bendebury wrote: >> >> On Tue, Jan 29, 2013 at 12:27 PM, Lucas Meneghel Rodrigues >> <[email protected]> wrote: >>> >>> On 01/29/2013 04:44 PM, Vadim Bendebury wrote: >>>> >>>> >>>> guys, I need to write an autotest which would do something with the >>>> DUT, but will not require any DUT activity, in fact the DUT could >>>> be down while this test is running. >>> >>> >>> >>> Interesting, never faced such a situation before. >>> >>> For people not familiar with the terminology, DUT is an acronym for >>> Device Under Test. >>> >>> >>>> I can hack up some changes which prevent attempts to install on the >>>> client and the test succeeds, but before going much further I am >>>> wondering: is there maybe a suggested/approved way of doing it? >>> >>> >>> >>> I remember you can create hostless jobs with the autotest server, >>> but I'm not sure if that's what you want. Is it possible to share >>> some more details on what this test does? >>> >> >> yes, basically this test re-images the DUT's firmware. The firmware >> rolls hot off the build farm, sometimes it is defective and the DUT >> is bricked after reimaging. So, there is some special external >> hardware which allows to take control of the DUT and program the >> firmware image "externally". >> >> "hostless" seems exactly the right name for this mode, are there some >> docs or examples of this? >> >> I concocted some changes to suppress attempts to connect/copy stuff >> to the client (they kick in if client_down=True is added to >> job.run_test() arguments in the control file) : >> >> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >> diff --git a/server/test.py b/server/test.py index 221962d..ad625ad >> 100644 >> --- a/server/test.py >> +++ b/server/test.py >> @@ -55,6 +55,9 @@ job.record('GOOD', '', 'sysinfo.iteration.%s') >> >> def install_autotest_and_run(func): >> def wrapper(self, mytest): >> + if self.client_down: >> + return >> + >> host, at, outputdir = self._install() >> try: >> host.erase_dir_contents(outputdir) >> @@ -69,9 +72,10 @@ def install_autotest_and_run(func): >> >> >> class _sysinfo_logger(object): >> - def __init__(self, job): >> + def __init__(self, job, client_down=False): >> self.job = job >> self.pickle = None >> + self.client_down = client_down >> >> # for now support a single host >> self.host = None >> @@ -230,7 +234,8 @@ class _sysinfo_logger(object): >> >> def runtest(job, url, tag, args, dargs): >> if not dargs.pop('disable_sysinfo', False): >> - logger = _sysinfo_logger(job) >> + logger = _sysinfo_logger( >> + job, client_down=dargs.get('client_down', False)) >> logging_args = [logger.before_hook, logger.after_hook, >> logger.before_iteration_hook, >> logger.after_iteration_hook] >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> and it actually allows the test to run to completion, but then in the >> end it throws this error: >> >> 13:01:13 INFO | Failed to copy /var/log/messages at startup: command >> execution error >> * Command: >> /usr/bin/ssh -a -x -o StrictHostKeyChecking=no -o >> UserKnownHostsFile=/dev/null -o BatchMode=yes -o ConnectTimeout=30 -o >> ServerAliveInterval=180 -o ServerAliveCountMax=3 -o >> ConnectionAttempts=4 >> -o Protocol=2 -l root -p 22 192.168.1.4 "export >> LIBC_FATAL_STDERR_=1; rm >> -f /var/tmp/messages.autotest_start" >> Exit status: 255 >> Duration: 12.0129139423 >> >> stderr: >> ssh: connect to host 192.168.1.4 port 22: No route to host >> >> >> which I am sure could also be avoided, but I don't want to reinvent >> another wheel :) > > > Sure, I was searching for docs on how to use hostless jobs, but, alas, > there's none whatsoever :( I know that you can select Hostless Job on > a checkbox on the create job tab of the web UI, but I can't seem to > figure how to use that from a control file, for example :( > > Sorry for keeping you waiting, it's just that I really wanted to find > out and be more helpful, but I just couldn't :( > Lucas, thank you very much for looking into this and checking. So, what do you think of the patch I sent earlier - it prevents attempts to ssh/scp before the test starts. The post test access is still attempted (to copy the logs which are not there actually), but it works in my case, because after this particular test (fiomware reimaging) the DUT is up and running again. As an alternative I can also look into what's necessary to prevent that last access as well. cheers, /vb > Lucas _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel
