Does deploy action have such as "deploy-namespace" to indicate to use previous deploy images?
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? 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? I guess if deploy action have such as "deploy-namespace" to indicate previous deploy,then phase2 deploy process can be pass.
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
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. I think it should have a mechnism that optimize phase2 deploy action not be excuted. Imagine a design as "deploy-namespace:"
# Your first LAVA JOB definition for arm device_type: arm9 job_name: arm9 pipeline, first job
timeouts: job: minutes: 565 action: minutes: 50 connection: minutes: 5 priority: medium visibility: public context: arch: arm64
# ACTION_BLOCK 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 method: u-boot commands: nfs auto_login: login_prompt: "login:" username: root prompts: - root@~# timeout: minutes: 5
- test: namespace: t1 timeout: minutes: 580 definitions: - repository: os: - debian run: steps: - lava-test-case pwd1 --shell pwd
- 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/
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 pwd
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?
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/
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/
On Tue, 18 Sep 2018 at 13:27, john zhang laojianghusz@163.com wrote:
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.
You need to take permanence into account. There are problems with reusing the filesystem from the first deploy. As NFS, it has been modified by the previous test and the LAVA test scripts are created to be able to run that first test action, not the second. Adding the scripts to the NFS happens in the deploy stage.
https://master.lavasoftware.org/static/docs/v2/connections.html#persistence
Speed of the test must not take priority over reliability of the test results themselves. Persistence undermines reproducibility and it can cause false test results. This must be avoided.
Invest in the network & worker hardware to minimise the time required to download and unpack the NFS. Reusing files modified by previous actions is always a bad choice.
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/
You need to take permanence into account. There are problems with reusing the filesystem from the first deploy. As NFS, it has been modified by the previous test and the LAVA test scripts are created to be able to run that first test action, not the second. Adding the scripts to the NFS happens in the deploy stage.
Could you give a document or link that descripe "how to reusing the filesystem from the first deploy"?
At 2018-09-18 22:22:12, "Neil Williams" neil.williams@linaro.org wrote:
On Tue, 18 Sep 2018 at 13:27, john zhang laojianghusz@163.com wrote:
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.
You need to take permanence into account. There are problems with reusing the filesystem from the first deploy. As NFS, it has been modified by the previous test and the LAVA test scripts are created to be able to run that first test action, not the second. Adding the scripts to the NFS happens in the deploy stage.
https://master.lavasoftware.org/static/docs/v2/connections.html#persistence
Speed of the test must not take priority over reliability of the test results themselves. Persistence undermines reproducibility and it can cause false test results. This must be avoided.
Invest in the network & worker hardware to minimise the time required to download and unpack the NFS. Reusing files modified by previous actions is always a bad choice.
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/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Fri, 12 Oct 2018 at 12:56, john zhang laojianghusz@163.com wrote:
You need to take permanence into account. There are problems with reusing the filesystem from the first deploy. As NFS, it has been modified by the previous test and the LAVA test scripts are created to be able to run that first test action, not the second. Adding the scripts to the NFS happens in the deploy stage.
Could you give a document or link that descripe "how to reusing the filesystem from the first deploy"?
I already did, in the previous message about persistence. Do not reuse the filesystem from the first deploy, it is known to cause problems.
https://master.lavasoftware.org/static/docs/v2/connections.html#persistence
Speed of execution is not a good enough reason to reuse storage because that is known to reduce reliability.
Reboots need to be handled inside LAVA as explicit boot actions. Split up the test job so that you do a fresh deploy and a fresh boot.
At 2018-09-18 22:22:12, "Neil Williams" neil.williams@linaro.org wrote:
On Tue, 18 Sep 2018 at 13:27, john zhang laojianghusz@163.com wrote:
Why do you want this second deploy & boot in the first place?
Exactly what device(s) are you working with here? What is the bootloader? What is the deployment type and boot method? What is the storage on device (if any)?
This cannot be solved generically for all devices, the range is just too broad. So far everything has assumed you are using TFTP.
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.
It has been considered and rejected because there needs to be a fresh deploy stage to achieve reliability.
Many devices need careful handling to get back into the test image, so a simple reboot will not work. Depending on the device, a reboot may or may not clear the deployment from the DUT so the files need to be re-deployed. There is no support for caching downloaded files for a second run - make sure your network is fast enough and simply redo the download. Speed of execution is not a valid use case here.
You need to take permanence into account. There are problems with reusing the filesystem from the first deploy. As NFS, it has been modified by the previous test and the LAVA test scripts are created to be able to run that first test action, not the second. Adding the scripts to the NFS happens in the deploy stage.
https://master.lavasoftware.org/static/docs/v2/connections.html#persistence
Speed of the test must not take priority over reliability of the test results themselves. Persistence undermines reproducibility and it can cause false test results. This must be avoided.
Invest in the network & worker hardware to minimise the time required to download and unpack the NFS. Reusing files modified by previous actions is always a bad choice.
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/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
-
john zhang -
Neil Williams