hwpack/rootfs date is required
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LAVA Scheduler (deprecated) |
Won't Fix
|
Wishlist
|
Unassigned |
Bug Description
Each time when I want to run test on LAVA farm I have to choose type of machine (panda, beaglexm, origen etc) and give exact url to hwpack and rootfs. So when I am lazy I will just use one version for long time and only update it when bugs will required it.
What would be nice to have is ability to tell which type of hwpack/rootfs has to be used and let LAVA take care of using latest version. So instead of:
{
"command": "deploy_
"parameters": {
"hwpack": "http://
"rootfs": "http://
},
"metadata": {
"hwpack.build": "0",
"hwpack.date": "20120115",
"hwpack.type": "panda-oneiric",
"rootfs.date": "20120115",
"rootfs.type": "linaro-
"rootfs.build": "0"
}
},
I would be able to use:
{
"command": "deploy_
"parameters": {
"hwpack": "hwpack_
"rootfs": "linaro-
},
"metadata": {
"hwpack.build": "latest",
"rootfs.date": "latest",
}
},
And not have to worry about versions.
Changed in lava-scheduler: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
Changed in lava-scheduler: | |
status: | Triaged → Won't Fix |
Another thought about this, is that it could be handled in the UI rather than the job definition. One thing that has been discussed, but never as a huge priority, is a web UI for scheduling jobs. This could scan snapshots.l.o and at the very least, make it trivial to pick the latest build. IMHO, having this feature in the scheduler based on something like this in the job definition introduces ambiguity. The same job submitted could have a totally different meaning seconds later. If you go back to look at what was intended to run in the job, it's not always clear.