In job defintion file the description of the related device is only the "device_type", why is not "device"?
Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/. The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device. When the dispatcher submits job, a job should be submited to a concrete device.But In job defintion file,the description of the related device is only the "device_type" but no "device", why is not "device"? for example: # Your first LAVA JOB definition for arm device_type: arm job_name: arm pipeline, first job ## why not as: # Your first LAVA JOB definition for arm device: arm01 job_name: arm pipeline, first job
On Wed, 10 Oct 2018 at 12:27, john zhang laojianghusz@163.com wrote:
Before test job,we need to add a "device_type" .jinja2 file to directory / etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/. The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher- config/devices/) defines a concrete device. When the dispatcher submits job, a job should be submited to a concrete device.
No, that is a misunderstanding. The scheduler assigns the test job to the first available device of the requested device-type. All devices of that device-type are deemed to be equally suitable for the test job, unless device-tags are used.
See the naming convention page for the reasons: https://master.lavasoftware.org/static/docs/v2/naming-conventions.html#namin...
What you call a "concrete device" is a "board" - what exists in the database for the scheduler to use is a "device". Boards can and are routinely replaced and have no direct correlation with a device. e.g. the second beaglebone-black on a shelf might be beaglebone-black-01 but then something happens to it and it gets replaced by a newly purchased beaglebone-black - that new board is still the beaglebone-black-01 device. Or admins could decide to put the details from the first beaglebone-black on the shelf into the device dictionary as beaglebone-black-01 and the new one goes into -02 - it is entirely arbitrary.
If one board has peripherals attached which test writers want to use, then the device can have a device tag created and assigned - test writers can then specify that device tag in test jobs which need to use that peripheral - otherwise if no device tags are in the test job submission, the test job will run on whichever device is available at the time, irrespective of the device tags.
I basically understood. Thank you.
在 2018-10-10 19:57:03，"Neil Williams" neil.williams@linaro.org 写道：
On Wed, 10 Oct 2018 at 12:27, john zhang laojianghusz@163.com wrote:
Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/. The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device. When the dispatcher submits job, a job should be submited to a concrete device.
No, that is a misunderstanding. The scheduler assigns the test job to the first available device of the requested device-type. All devices of that device-type are deemed to be equally suitable for the test job, unless device-tags are used.
See the naming convention page for the reasons: https://master.lavasoftware.org/static/docs/v2/naming-conventions.html#namin...
What you call a "concrete device" is a "board" - what exists in the database for the scheduler to use is a "device". Boards can and are routinely replaced and have no direct correlation with a device. e.g. the second beaglebone-black on a shelf might be beaglebone-black-01 but then something happens to it and it gets replaced by a newly purchased beaglebone-black - that new board is still the beaglebone-black-01 device. Or admins could decide to put the details from the first beaglebone-black on the shelf into the device dictionary as beaglebone-black-01 and the new one goes into -02 - it is entirely arbitrary.
If one board has peripherals attached which test writers want to use, then the device can have a device tag created and assigned - test writers can then specify that device tag in test jobs which need to use that peripheral - otherwise if no device tags are in the test job submission, the test job will run on whichever device is available at the time, irrespective of the device tags.
--
Neil Williams ============= neil.williams@linaro.org http://www.linux.codehelp.co.uk/
another question:
The scheduler assigns the test job to the first available device of the requested device-type.
Does that mean the scheduler select only one device to run the test job, other devices with same device-type are not run this job even though in idle status? Is there a method that all devices with same device-type can run the same job as long as available? That is to say, a job is executed "simultaneously" by multiple boards.
在 2018-10-10 19:57:03，"Neil Williams" neil.williams@linaro.org 写道：
On Wed, 10 Oct 2018 at 12:27, john zhang laojianghusz@163.com wrote:
Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/. The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device. When the dispatcher submits job, a job should be submited to a concrete device.
No, that is a misunderstanding. The scheduler assigns the test job to the first available device of the requested device-type. All devices of that device-type are deemed to be equally suitable for the test job, unless device-tags are used.
See the naming convention page for the reasons: https://master.lavasoftware.org/static/docs/v2/naming-conventions.html#namin...
What you call a "concrete device" is a "board" - what exists in the database for the scheduler to use is a "device". Boards can and are routinely replaced and have no direct correlation with a device. e.g. the second beaglebone-black on a shelf might be beaglebone-black-01 but then something happens to it and it gets replaced by a newly purchased beaglebone-black - that new board is still the beaglebone-black-01 device. Or admins could decide to put the details from the first beaglebone-black on the shelf into the device dictionary as beaglebone-black-01 and the new one goes into -02 - it is entirely arbitrary.
If one board has peripherals attached which test writers want to use, then the device can have a device tag created and assigned - test writers can then specify that device tag in test jobs which need to use that peripheral - otherwise if no device tags are in the test job submission, the test job will run on whichever device is available at the time, irrespective of the device tags.
--
Neil Williams ============= neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Thu, 11 Oct 2018 at 13:17, john zhang laojianghusz@163.com wrote:
another question:
The scheduler assigns the test job to the first available device of the requested device-type.
Does that mean the scheduler select only one device to run the test job, other devices with same device-type are not run this job even though in idle status? Is there a method that all devices with same device-type can run the same job as long as available? That is to say, a job is executed "simultaneously" by multiple boards.
do you mean sharding or exact copy of the same job? LAVA doesn't support sharding because it's not aware of the test suite that is supposed to be executed. If you want exact copy, just submit as many identical jobs as you have devices. You can get the number of available devices through API.
Out of curiosity, why would you want to execute the same test job on multiple devices simultaneously?
milosz
For example, to test a quality of hardware peripheral on the board, If multiple boards are involved in the test from same job at the same time, the error rate can be quickly obtained.
At 2018-10-11 20:34:26, "Milosz Wasilewski" milosz.wasilewski@linaro.org wrote:
On Thu, 11 Oct 2018 at 13:17, john zhang laojianghusz@163.com wrote:
another question:
The scheduler assigns the test job to the first available device of the requested device-type.
Does that mean the scheduler select only one device to run the test job, other devices with same device-type are not run this job even though in idle status? Is there a method that all devices with same device-type can run the same job as long as available? That is to say, a job is executed "simultaneously" by multiple boards.
do you mean sharding or exact copy of the same job? LAVA doesn't support sharding because it's not aware of the test suite that is supposed to be executed. If you want exact copy, just submit as many identical jobs as you have devices. You can get the number of available devices through API.
Out of curiosity, why would you want to execute the same test job on multiple devices simultaneously?
milosz
On Thu, 11 Oct 2018 at 13:50, john zhang laojianghusz@163.com wrote:
For example, to test a quality of hardware peripheral on the board, If multiple boards are involved in the test from same job at the same time, the error rate can be quickly obtained.
You will need to manage that in the client doing the submissions using XML-RPC calls to determine how many devices of the device-type(s) you want are Idle at the time.
However, it is actually more efficient to just submit as many test jobs as you need and let the queue sort it out.
At 2018-10-11 20:34:26, "Milosz Wasilewski" milosz.wasilewski@linaro.org wrote:
On Thu, 11 Oct 2018 at 13:17, john zhang laojianghusz@163.com wrote:
another question:
The scheduler assigns the test job to the first available device of the requested device-type.
Does that mean the scheduler select only one device to run the test job, other devices with same device-type are not run this job even though in idle status? Is there a method that all devices with same device-type can run the same job as long as available? That is to say, a job is executed "simultaneously" by multiple boards.
do you mean sharding or exact copy of the same job? LAVA doesn't support sharding because it's not aware of the test suite that is supposed to be executed. If you want exact copy, just submit as many identical jobs as you have devices. You can get the number of available devices through API.
Out of curiosity, why would you want to execute the same test job on multiple devices simultaneously?
milosz
-
john zhang -
Milosz Wasilewski -
Neil Williams