Hi Neil,
Thanks for your explanation, also sorry if I've somewhat misused the terms job, shell and test. Trying to piece everything together, I've made a small test definition to see how this would all work in practice. Here's a run:
https://lava.collabora.co.uk/scheduler/job/590857#L798
On 28/04/17 09:38, Neil Williams wrote:
On 28 April 2017 at 09:28, Neil Williams neil.williams@linaro.org wrote:
On 28 April 2017 at 08:34, Guillaume Tucker guillaume.tucker@collabora.com wrote:
In this case, "sudo su" is needed to open a regular user session and inherit the user's environment while also having root privileges.
That is test shell dependent, not device or test job. Some test shells will be quite happy to run without needing root and if such a test shell needs packages installed, that is up to the test writer to arrange, not LAVA. There is no actual requirement for LAVA to deliver a root shell on the DUT, it is convention.
On the topic of installing packages, adding this to the test definition fails if the user is not root:
install: deps: - wget
as can be seen with this run:
https://lava.collabora.co.uk/scheduler/job/590859#L786
I've searched through the Linaro test-definitions but couldn't find one which did something to gain root privilege before the package installer gets invoked. Could you please advise how to achieve this?
Once V2 delivers the test writer at a shell the job of V2 is only to execute the scripts to start the portable test scripts.
This change goes against that flow.
V2 does have explicit support for handling the environment within the test shell, where this is necessary.
In LAVA v2, there isn't the possibility to do anything like this directly. One could define a test with inline commands, but this is not ideal. The login commands are not a test but part of how the job sets up the environment in which the tests are run - i.e. it's part of the initial conditions.
sudo su is not a login command. username and password are the login commands. Anything after that is no longer handled by the login itself but by whatever shell the test job has configured.
Right, so I think this should work for us (from the job I linked):
run: steps: - lava-test-case hello-user --shell ./hello.sh - lava-test-case hello-root --shell sudo ./hello.sh
That is to say, putting sudo in the step that calls a script.
The test writer also has the ability to modify the submitted image to ensure that whatever users are preferred are available in advance. Note: It is not an objective for LAVA V2 to test production images without alterations because many production images have security features which prevent automation. Some level of alteration is expected.
Also it's quite a convoluted and lengthy way of running some commands, and it relies on the side effects of that "login commands test" to persist when running subsequent tests.
Lots of test definitions include persistent actions (like udhcpc or ifup eth0). It is up to the test writer to construct test definitions which do setup and tear down where appropriate.
OK, it seems fair enough to define set-up and tear-down commands in the test definition. My point was rather that set-up and tear-down should not be defined as two extra tests within a job, but that was just me trying to recreate the login_commands v1 feature in v2 with a separate test action inside the job.
Any thoughts? Would it make sense to add this feature or maybe implement it differently?
Take the opportunity provided by V2 to migrate your test shell definition files to portable scripts. Add a check for whether lava-test-case exists in $PATH to determine whether to use the remaining LAVA helpers or not and do everything else in the scripts. The ideal is to not have any install: section and make the script do all the setup it would need.
Does this mean directly running things like "sudo apt install -y wget" in the test definition?
We've tried to indicate this direction in the docs:
https://staging.validation.linaro.org/static/docs/v2/writing-tests.html#best...
Let us know if those guidelines can be expanded or clarified.
Essentially, anything a developer would need to do outside LAVA to be able to run the scripts used in your LAVA tests should be within the scripts themselves. LAVA needs to provide certain pieces of data and some handlers to report test cases but apart from that, the drive is towards portability and away from hidden steps being done by LAVA.
OK, I think I generally understand this. One part I'm not too sure of is claiming that LAVA test scripts should be portable on one hand, and on the other hand that LAVA should not be involved with how test scripts actually manage to run on a system. It sounds to me that it's rather making portability the user's problem, and LAVA will happily schedule any job that can be successfully submitted regardless of whether the test scripts involved would also manage to run on any other system.
Guillaume