Today the LAVA team was discussing how we could make LAVA aware of known-good images for each device type. The use case is: when learning LAVA, engineers will often not know exactly which images to use, and they usually don't care much as they want first to learn how to use LAVA itself.
To solve this problem, we came up with the following proposal.
The LAVA admin should be able to configure the URL of a mini-database of know good images for each of its device types. The proposed format is a very simple YAML hash like this:
----------------8<----------------8<----------------8<----------------- kvm: action: deploy_linaro_image parameters: image: "http://url.to/kvm.img" kvm-arm: action: deploy_linaro_kernel parameters: kernel: "http://url.to/zImage" rootfs: "http://url.to/rootfs" dtb: "http://url.to/dtb" arndale: action: deploy_linaro_image parameters: image: "http://url.to/arndale.img" ----------------8<----------------8<----------------8<-----------------
LAVA will just poll this database from time to time, but won't care how it is kept up to date. LAVA admins can make the generation of this database part of their automation.
In Linaro, we should probably generate this data from releases.linaro.org. Fathi, can we generate this as part of the release process? If not, can we at least have a MANIFEST of the full contents of each release, so that we can generate that database on our side? Assuming the directory strutcure of releases is stable, the output of `find .` inside the release directory should be good enough.
Hi,
On 6 May 2014 23:08, Antonio Terceiro antonio.terceiro@linaro.org wrote:
Today the LAVA team was discussing how we could make LAVA aware of known-good images for each device type. The use case is: when learning LAVA, engineers will often not know exactly which images to use, and they usually don't care much as they want first to learn how to use LAVA itself.
known-good image = successfully boot tested with a known working kernel and minimal/nano rootfs?
or do you expect all rootfs variants to be tested, including pre-built image.
To solve this problem, we came up with the following proposal.
The LAVA admin should be able to configure the URL of a mini-database of know good images for each of its device types. The proposed format is a very simple YAML hash like this:
----------------8<----------------8<----------------8<----------------- kvm: action: deploy_linaro_image parameters: image: "http://url.to/kvm.img" kvm-arm: action: deploy_linaro_kernel parameters: kernel: "http://url.to/zImage" rootfs: "http://url.to/rootfs" dtb: "http://url.to/dtb" arndale: action: deploy_linaro_image parameters: image: "http://url.to/arndale.img" ----------------8<----------------8<----------------8<-----------------
LAVA will just poll this database from time to time, but won't care how it is kept up to date. LAVA admins can make the generation of this database part of their automation.
In Linaro, we should probably generate this data from releases.linaro.org. Fathi, can we generate this as part of the release process? If not, can we at least have a MANIFEST of the full contents of each release, so that we can generate that database on our side? Assuming the directory strutcure of releases is stable, the output of `find .` inside the release directory should be good enough.
Per definition, released material is boot tested. It's safe to use releases.linaro.org to populate the database.
We can take care of updating the db as part of the CI loop: 1. submit a job to LAVA 2. get LAVA results 3. update the database if the image submitted is successfully booted
-- Antonio Terceiro Software Engineer - Linaro http://www.linaro.org
On Wed, May 07, 2014 at 01:43:36PM +0300, Fathi Boudra wrote:
Hi,
On 6 May 2014 23:08, Antonio Terceiro antonio.terceiro@linaro.org wrote:
Today the LAVA team was discussing how we could make LAVA aware of known-good images for each device type. The use case is: when learning LAVA, engineers will often not know exactly which images to use, and they usually don't care much as they want first to learn how to use LAVA itself.
known-good image = successfully boot tested with a known working kernel and minimal/nano rootfs?
or do you expect all rootfs variants to be tested, including pre-built image.
Usually pre-built images are faster to boot since LAVA does not have to do the whole l-m-c dance with separate image parts, so they would be the ideal. But IMO any set of files that we know would work should do the trick, and that will vary per device type (e.g. for some we don't have pre-build images at all).
To solve this problem, we came up with the following proposal.
The LAVA admin should be able to configure the URL of a mini-database of know good images for each of its device types. The proposed format is a very simple YAML hash like this:
----------------8<----------------8<----------------8<----------------- kvm: action: deploy_linaro_image parameters: image: "http://url.to/kvm.img" kvm-arm: action: deploy_linaro_kernel parameters: kernel: "http://url.to/zImage" rootfs: "http://url.to/rootfs" dtb: "http://url.to/dtb" arndale: action: deploy_linaro_image parameters: image: "http://url.to/arndale.img" ----------------8<----------------8<----------------8<-----------------
LAVA will just poll this database from time to time, but won't care how it is kept up to date. LAVA admins can make the generation of this database part of their automation.
In Linaro, we should probably generate this data from releases.linaro.org. Fathi, can we generate this as part of the release process? If not, can we at least have a MANIFEST of the full contents of each release, so that we can generate that database on our side? Assuming the directory strutcure of releases is stable, the output of `find .` inside the release directory should be good enough.
Per definition, released material is boot tested. It's safe to use releases.linaro.org to populate the database.
We can take care of updating the db as part of the CI loop:
- submit a job to LAVA
- get LAVA results
- update the database if the image submitted is successfully booted
That would be awesome. Thanks!
linaro-validation@lists.linaro.org
-
Antonio Terceiro -
Fathi Boudra