+1 on Michael's suggestion to use dummy_deploy
I've had some conversions with Kevin about his use requirements for LAVA, and here is a summary:
* For kernel testing, the kernel binary + ramdisk is provided over tftp. I think he has figured out how to override the boot_cmds so this is not an issue. * Would like to utilize lava-test-shell however lava-test-shell makes assumptions about the rootfs. His idea is provide all the lava-test-shell support scripts in the ramdisk. All his existing tests are already included on this ramdisk.
Perhaps we can create another "type" for deployment data called "vanilla"
"actions": [ { "command": "dummy_deploy", "parameters": { "type": "vanilla" } }, { "command": "boot_linaro_image" } ]
Target.vanilla_deployment_data['distro'] = 'vanilla' Target.vanilla_deployment_data['lava_test_sh_cmd'] = '/bin/bash' Target.vanilla_deployment_data['lava_test_dir'] = '???' Target.vanilla_deployment_data['lava_test_results_part_attr'] = '???'
This "vanilla" target could carry the assumption that the lava-test-shell support scripts are already on the target...somewhere.
On 2 May 2013 15:29, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Kevin Hilman khilman@linaro.org writes:
Hi LAVA folks,
I'm working on using LAVA to boot boards in my own board farm, and for starters, am trying to use a job without a 'deploy' step (so I can use the existing on-board u-boot, and control it via boot_cmds.)
Currently, the dispatcher assumes that a 'deploy' step has happened before a 'boot_linaro_image' step, which is not needed for my case, so here's a patch to set some defaults so a deploy step is not needed:
FWIW, there is a dummy_deploy action for this use case:
"actions": [ { "command": "dummy_deploy", "parameters": { "type": "ubuntu" } }, { "command": "boot_linaro_image" } ]
Cheers, mwh
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation