checkbox-dev team mailing list archive

[Ara Pulido <ara.pulido@xxxxxxxxxxxxx>]

On 28/02/14 03:04, Zygmunt Krynicki wrote:
> 
> On Thu, Feb 27, 2014 at 5:20 PM, Sylvain Pineau
> <sylvain.pineau@xxxxxxxxxxxxx <mailto: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

I wouldn't like to make this more complex if it is not fully needed.
What's the problem in copying udev_resource (i.e.) in the target?

Thanks,
Ara.

> 
> This would effectively run: "adb -s $target shell foo | bar", or  "ssh
> $target shell foo | bar"
> 
> What do you think?
> 
> Thanks
> ZK
> 
>