Dispatcher transition plan for LAVA Core

01:40 < mwhudson> 1) fast model support integrated into demo-2 code
01:40 < mwhudson> 2) remaining lava-dispatcher features integrated into demo-2 code
01:41 < mwhudson> 3) scheduler changes to support multiple 'dispatcher' commands
01:41 < mwhudson> 4) communicating this plan to the rest of the team
01:41 < zyga> 2 - do you mean android or things like coalesced bundle?
01:41 < mwhudson> zyga: i mean everything
01:41 < zyga> mwhudson: well there's a difference
01:42 < zyga> mwhudson: as time frame wise it's easy to get all of VMs on lava-core and all the boards on lava-dispatcher this month
01:42 < zyga> mwhudson: while I don't intend to just start working on something else and finishing this is my top priority
01:42 < zyga> 3 - I think we already had that, no?
01:42 < mwhudson> i don't think so?
01:43 < mwhudson> well, you can give each daemon a different dispatcher to run
01:43 < mwhudson> but nothing around saying that jobs for this device should get this dispatcher or whatever
01:43 < zyga> right
01:43 < mwhudson> i don't expect this to be a massive piece of work, but it needs to be done
01:43 < zyga> I think we can just do a small hack that chooses lava core for devices of a particular type
01:44 < zyga> 4 - I'm not sure how to do this effectively

I guess this blueprint will solve 4

<mwhudson> zyga: i agree that the focus this month should probably be vms on lava-core, boards on lava-dispatcher
<mwhudson> but that's not a position i want to be in for very long
<zyga> I think that we can get board support quickly
<zyga> only a handful of methods need to be changed between devices now, hopefully
<zyga> I'm sure I'm missing something though
<zyga> like partition shuffling
<mwhudson> well that's why i said
<zyga> I will probably do things differently than before
<mwhudson> <mwhudson> zyga: we need to have a list of features of the current code that we can check off
<zyga> no crazy netcat + server
<zyga> ah
<zyga> true
<zyga> another thing we should support is the kernel matrix feature
<mwhudson> the things i know about now are 1) missing actions (kind of obvious) 2) the 'lava' test run 3) timeouts everywhere
<zyga> I'll start with 2
<zyga> how good were we with 3 before?

(discussion on timeout handling follows, we need both internal and external global timeout monitoring)

Existing actions:

add_apt_repository
android_install_binaries
boot_linaro_android_image
boot_linaro_image
boot_master_image
deploy_linaro_android_image
deploy_linaro_image
lava_android_test_install
lava_android_test_run
lava_android_test_run_custom
lava_test_install
lava_test_run
submit_results
submit_results_on_host

Work items:
Land demo branch into trunk of lp:lava-core: INPROGRESS
Add support for creating the special 'lava' test run: TODO
Inspect global timeout tracking options: TODO
Track agent session duration and raise timeouts: TODO
(meta work item) master image board support: TODO
(meta work item) android support (via existing lava-android-test): TODO
(R&D) agent watchdog for places that technically expect a timeout but it does not make sense (agent IO): TODO
add any other missing actions: TODO