On Fri, 31 May 2013 15:50:54 +0100 James Tunnicliffe james.tunnicliffe@linaro.org wrote:
On 31 May 2013 14:22, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Wed, 29 May 2013 17:11:11 +0100 James Tunnicliffe james.tunnicliffe@linaro.org wrote:
Issues raised in http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/tr...
This is very similar to what the Multi-Node parent <-> child communication may need.
Getting a token: I see this as the service that starts the job has some secret allowing it to request the token, which is then passed onto the job.
Precisely as the Multi-Node setup could use. I'm thinking the token could be added as part of the jobdata in lava-dispatcher, commands.py: job = LavaTestJob(jobdata, oob_file, config, self.args.output_dir)
My expectation for this Multi-Node support would be that the token would be written to the test environment and the test would use that to get the list of other clients for this multi-node job. Once each client has booted and "called home" to the parent using the token, clients could get the IP address and role of other clients. This then allows Multi-Node tests to make calls between clients to test their own protocols and other requirements.
I already have a protocol designed to do the file update thing (server has old file, client has new one but not old one) for a pet project that I was going to open source, but it is just a bit of fun and hasn't been tested, so even having got that far I would still tell other people to use rsync.
publish --token=<token> --type=<build_type> --strip=<strip> <build_id> <glob_pattern>...
This seems like a reasonable starting point. Lets make sure that it uses a configuration file to specify what to do with those build types etc. Preferably one that it can update from a public location so we don't have to re-spin the tool to add a new build type (though I guess we normally check it out of VCS as we go, so that works too).
Well, on client side, it's ideally just a single file which just handle obvious filtering options (like <glob_pattern> or --strip=) locally and passes the rest to API/service. Server-side can handle the options in any way it wants, note that options above don't require much "configuration", for example --type= just maps to top-level download dir.
Just wondering how much overlap there could be between publishing for CI and publishing IP addresses between clients running a Multi-Node job.
I've only done the briefest look at the Multi-Node aspects so far, there's a PDF I've shared with some rough flow ideas for Parent-Child-Communication.