On 28/02/14 03:04, Zygmunt Krynicki wrote: > > On Thu, Feb 27, 2014 at 5:20 PM, Sylvain Pineau > <[email protected] <mailto:[email protected]>> 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 > > -- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
