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

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