checkbox-dev team mailing list archive

[Zygmunt Krynicki <zygmunt.krynicki@xxxxxxxxxxxxx>]

On Thu, Feb 27, 2014 at 5:20 PM, Sylvain Pineau <
sylvain.pineau@xxxxxxxxxxxxx> wrote:

> On 27/02/2014 17:11, Daniel Manrique wrote:
>
>> On 14-02-26 12:46 PM, Zygmunt Krynicki wrote:
>>
>>>
>>> Execution controllers
>>> ---------------------
>>>
>>> Execution controllers that prepare the environment for each job would
>>> necessarily change. Existing set of controllers can run jobs as the
>>> regular
>>> user, as a root user via sudo or as a root user via
>>> plainbox-trusted-launcher-1.
>>>
>>> In addition to user handing, those controllers handle the task of
>>> configuring
>>> the filesystem for a specific job. The new remote controller would need
>>> to
>>> ensure that provider data associated with the job that is to be executed
>>> is
>>> copied (using rsync or adb push or other similar command).
>>>
>>


> This suggests you will copy only relevant data for each test. Can this be
>> determined reliably without too many hairy heuristics? will we need to
>> add more
>> metadata to jobs or scripts so that a remote environment can be properly
>> configured?
>>
>> Another approach that comes to mind is copying *everything* (where
>> "everything"
>> needs to be determined) when the first remote job executes, so subsequent
>> jobs
>> can count on stuff being there. This would be handled by the execution
>> controller I think.
>>
> One of the execution controller future role will also be to detect
> program/scripts that have to be run locally
> but are part of the job command, e.g: "run_this_on_target |
> parse_output_with_local_parser"
> Several local jobs are using this method taking the output of a remote
> command and doing some magic to
> create jobs with run_template+udev_resource.



This is an interesting point. Technically (currently) that would all run
remotely. We would copy all of the scripts (including udev_resource) and
run that there. I see that we might want to run certain parts locally.
Fortunately that is easy to express (though it would require us to alter
jobs that want the distinction).

id: some-job
command: foo
post-process: bar

This would effectively run: "adb -s $target shell foo | bar", or  "ssh
$target shell foo | bar"

What do you think?

Thanks
ZK