Hi Ben,
So there are 2 options
1) write a provider script, which does loop: - contact compass-ci scheduler to get the job - convert it to LAVA job - lava-run the job to DUT
2) add LAVA server to the loop, too
I'm not sure how exactly (2) will work out. It looks like will add some unnecessary indirection and complexity comparing to (1).
Further our meeting regarding CompassCI and LAVA integration. As you are aware, we recommended the use of the LAVA Server. The reason for this is so you do not need to reinvent the wheel. You can, of course use LAVA dispatcher directly, but LAVA server deals with:
- Scheduling jobs This is done per user/tags/priority and device health. CompassCI can schedule jobs into lava's scheduler, and LAVA server can be left dealing with all the embedded queuing. This means you can focus on the job conversion over integrating compass-ci to deal with what LAVA server currently does.
IMHO 2 schedulers brings more complexity than convenience.
The compass-ci scheduler will also have those scheduling capabilities. User/priority is already working. As for tags, some generized HW select/matching mechanism is in our TODO list.
- Health checks Regular health checks to devices will happen regularly, and once failed LAVA server will deal with taking the device offline accordingly. An external scheduler would have to keep track of this otherwise.
Since compass-ci works in PULL mode, its scheduler does not rely on health checks. It just waits for connection from live testboxes (or providers on behalf of them).
It's trivial to routinely send health check jobs in compass-ci, if some high level logic needs it.
- Easy to control and supported hardware Ability to easily use PDU's. reset boards.
It seems the LAVA dispatcher handle power reset by itself.
We may also write a general agent to power reset a LAVA DUT based on command/messages sent by other compass-ci entities for more complete integration.
Thanks, Fengguang