Hey all,
I'm currently hitting an interesting issue; We're deploying debian- based images in our tests which have most of / mounted read-only. Unfortunately the default deployment data for Debian indicates that the various lava-test-shell related directories show live in /lava-xxxxx to which in our booted image ofcourse nothing can write.
It would be good to give test writers the freedom to specify a sensible base-path for lava's usage to avoid these types of issues. The option to add a Debian variant to deployment data on our setup is somewhat less attractive as that requires server configuration. (Changing the images to mount / as read-write is not an option as that would defeat the point of the test).
On 23 May 2017 at 13:33, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
Hey all,
I'm currently hitting an interesting issue; We're deploying debian- based images in our tests which have most of / mounted read-only. Unfortunately the default deployment data for Debian indicates that the various lava-test-shell related directories show live in /lava-xxxxx to which in our booted image ofcourse nothing can write.
It would be good to give test writers the freedom to specify a sensible base-path for lava's usage to avoid these types of issues. The option to add a Debian variant to deployment data on our setup is somewhat less attractive as that requires server configuration. (Changing the images to mount / as read-write is not an option as that would defeat the point of the test).
This was (still is) possible in v1 but not documented. Example test action looks like this:
{ "command": "lava_test_shell", "parameters": { "lava_test_dir": "/data/local/tmp/lava/meminfo", "lava_test_results_dir": "/local/tmp/lava/meminfo", "testdef_repos": [ { "git-repo": "git://git.linaro.org/qa/test-definitions.git", "testdef": "android/meminfo.yaml" }], "timeout": 1800 } },
milosz
On Tue, 2017-05-23 at 13:56 +0100, Milosz Wasilewski wrote:
On 23 May 2017 at 13:33, Sjoerd Simons <sjoerd.simons@collabora.co.uk
wrote: Hey all,
I'm currently hitting an interesting issue; We're deploying debian- based images in our tests which have most of / mounted read-only. Unfortunately the default deployment data for Debian indicates that the various lava-test-shell related directories show live in /lava- xxxxx to which in our booted image ofcourse nothing can write.
It would be good to give test writers the freedom to specify a sensible base-path for lava's usage to avoid these types of issues. The option to add a Debian variant to deployment data on our setup is somewhat less attractive as that requires server configuration. (Changing the images to mount / as read-write is not an option as that would defeat the point of the test).
This was (still is) possible in v1 but not documented. Example test action looks like this:
{ "command": "lava_test_shell", "parameters": { "lava_test_dir": "/data/local/tmp/lava/meminfo", "lava_test_results_dir": "/local/tmp/lava/meminfo", "testdef_repos": [ { "git-repo": "git://git.linaro.org/qa/test- definitions.git", "testdef": "android/meminfo.yaml" }], "timeout": 1800 } },
milosz
Sorry i should have said, I'm using v2 (Too used to trying to forget about v1 :p)
This never got ported over to v2 but should be a case of arguments to the deploy step, which also get set in namespace data so the boot/test actions know where to look for the scripts. The deployment_data can still be used as defaults.
On 23 May 2017 at 14:05, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
On Tue, 2017-05-23 at 13:56 +0100, Milosz Wasilewski wrote:
On 23 May 2017 at 13:33, Sjoerd Simons <sjoerd.simons@collabora.co.uk
wrote: Hey all,
I'm currently hitting an interesting issue; We're deploying debian- based images in our tests which have most of / mounted read-only. Unfortunately the default deployment data for Debian indicates that the various lava-test-shell related directories show live in /lava- xxxxx to which in our booted image ofcourse nothing can write.
It would be good to give test writers the freedom to specify a sensible base-path for lava's usage to avoid these types of issues. The option to add a Debian variant to deployment data on our setup is somewhat less attractive as that requires server configuration. (Changing the images to mount / as read-write is not an option as that would defeat the point of the test).
This was (still is) possible in v1 but not documented. Example test action looks like this:
{ "command": "lava_test_shell", "parameters": { "lava_test_dir": "/data/local/tmp/lava/meminfo", "lava_test_results_dir": "/local/tmp/lava/meminfo", "testdef_repos": [ { "git-repo": "git://git.linaro.org/qa/test-
definitions.git", "testdef": "android/meminfo.yaml" }], "timeout": 1800 } },
milosz
Sorry i should have said, I'm using v2 (Too used to trying to forget about v1 :p)
-- Sjoerd Simons Collabora Ltd. _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users