Why do you want this second deploy & boot in the first place? Think carefully about what your test plan. If you simply want to run multiple test steps, you can simply combine the steps into a single test: action. What do you gain by causing the DUT to boot a second time?
It is only example.In our test test requirements , some test cases need to reboot kernel to test some reboot behaviors. So I think it can be resolved by static generate two phases (use namespace to distinguish) and phase2 images are same with phase1 images. I think lava should consider this requirement.
At 2018-09-18 19:43:18, "Neil Williams" neil.williams@linaro.org wrote:
On Tue, 18 Sep 2018 at 07:27, john zhang laojianghusz@163.com wrote:
Fellow a job definition. It has two phases (one phase include deploy,boot,test action), the second phase(namespace t2) deploy action images are exactly same with first phase deploy action images.Is there any mechanism to make the phase2 deploy action not be really execute ? So to speed up test time.
No. The only time you'd save is the download and decompression on the worker because this test job uses TFTP. The files need to be downloaded from the worker to the DUT, so a new deploy will still be needed. There is also the overlay to consider. The URLs specified may be the same but the NFS rootfs is modified before being offered to the DUT (to add the LAVA test shell helpers) and during the test job itself. That's the point with NFS, the filesystem from the first boot needs to be thrown away so that the next boot gets a clean rootfs with a different set of test shell helpers for the second test operation.
I think it should have a mechnism that optimize phase2 deploy action not be excuted. Imagine a design as "deploy-namespace:"
You have permanence problems. The files created in the first deploy action are modified by the deploy and by the test.
# Your first LAVA JOB definition for arm device_type: arm9 job_name: arm9 pipeline, first job
timeouts: job: minutes: 565
See below on the timeout - it makes the test job unnecessarily difficult to read if you specify more than 60 minutes - convert to hours.
action: minutes: 50 connection: minutes: 5 priority: medium visibility: public context: arch: arm64
Unless this is a QEMU test job, arch is unnecessary.
actions:
deploy: namespace: t1 timeout: minutes: 5 to: tftp kernel: url: http://192.168.1.20/kernel.bin type: image nfsrootfs: url: http://192.168.1.20/rootfs.tar.bz compression: bz dtb: url: http://192.168.1.20/k.dtb os: debian
boot: namespace: t1 connection: telnet localhost 7000
connection_command needs to go into the device dictionary. It is ignored here.
https://master.lavasoftware.org/static/docs/v2/pipeline-admin.html#create-de...
method: u-boot commands: nfs auto_login: login_prompt: "login:" username: root prompts: - root@~# timeout: minutes: 5
- test: namespace: t1 timeout: minutes: 580
Long timeouts can be problematic. Make sure you use lava-test-raise in your test actions to catch if an early test step fails or the job could just sit there until the timeout.
Also, timeout explicitly supports hours, so just change this to hours: 9 (or hours: 10) to make things clear.
definitions: - repository: os: - debian run: steps: - lava-test-case pwd1 --shell pwdWhy do you want this second deploy & boot in the first place? Think carefully about what your test plan. If you simply want to run multiple test steps, you can simply combine the steps into a single test: action. What do you gain by causing the DUT to boot a second time?
See https://master.lavasoftware.org/static/docs/v2/standard-test-jobs.html#index... and https://master.lavasoftware.org/static/docs/v2/standard-qemu-stretch.html#te...
deploy: namespace: t2 timeout: minutes: 5 to: tftp kernel: url: http://192.168.1.20/kernel.bin type: image nfsrootfs: url: http://192.168.1.20/rootfs.tar.bz compression: bz dtb: url: http://192.168.1.20/k.dtb os: debian
boot: namespace: t2 connection-namespace: t1
method: u-boot commands: nfs auto_login: login_prompt: "login:" username: root prompts: - root@~# timeout: minutes: 5
test: namespace: t2 timeout: minutes: 580 definitions:
repository: os: - debian run: steps: - lava-test-case ifconfig1 --shell ifconfig
from: inline name: apache-server2 path: inline/apache-server2.yaml
At 2018-09-18 00:07:11, "Neil Williams" neil.williams@linaro.org wrote:
On Mon, 17 Sep 2018 at 12:14, john zhang laojianghusz@163.com wrote:
In lava job definition, boot action can use "connection-namespace" to indicate use previous namespace's connection.Does deploy action have such as "deploy-namespace" to indicate to use previous deploy image?
I think you have misunderstood namespaces.
connection-namespace is a specialised feature to reuse serial connections.
For example in an application scenario, it need to sequential execution two phases pipeline(deploy,boot,test), it can be solved by define two namespace in job definiton. When run it executed in serial as : phase1(namespace1) deploy->boot->test -> phase2(namespace2) deploy->boot->test. If phase2 deploy images(kernel,dtb,rootfs) are exactly same as phase2 deploy images,how to speed up phase2 deploy execution?
Namespaces cannot help with that directly. Namespaces are about separating the dynamic data within the test job.
Please attach your current test job definition so that we can describe how to improve it. Depending on how the device integration works, you may be able to simply skip the second deploy step and just do deploy boot test boot test all in a single namespace. This won't work for some deployments like TFTP.
I guess if deploy action have such as "deploy-namespace" to indicate previous deploy,then phase2 deploy process can be pass.
No.
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/