>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-device-dictionary
>> >
>> >> 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-0
>> >and https://master.lavasoftware.org/static/docs/v2/standard-qemu-stretch.html#test
>> >
>> >>
>> >> - 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/