On Fri, 31 May 2013 15:50:54 +0100 James Tunnicliffe <james.tunnicli...@linaro.org> wrote:
> On 31 May 2013 14:22, Paul Sokolovsky <paul.sokolov...@linaro.org> wrote: > > On Wed, 29 May 2013 17:11:11 +0100 > > James Tunnicliffe <james.tunnicli...@linaro.org> wrote: > > > >> Issues raised in > >> http://bazaar.launchpad.net/~linaro-automation/linaro-android-build-tools/trunk/view/head:/utils/new-publish/README 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. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpTAY27WdF8G.pgp
Description: PGP signature
_______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
