On Tue, Jan 24, 2012 at 12:27 PM, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Hi.
This a brainstorm message. I'd like to hear your pros and cons on merging the scheduler and dashboard. For me the advantages outweigh the disadvantages:
This feels like quite a big project and I wonder if such refactoring is really important enough to spend the effort on :).
Pros:
- A simple model for tracking a result back to a job, without having
to jump through javascript hoops and hard synchronization/availability issues (and back!)
On IRC I asked about a backlink from a bundle to the job that submitted it and was pointed at this mail :)...
I don't think that merging dashboard and scheduler is the only answer to my problem. A simpler way would be to extend the bundle to include an optional origin field linking back to the submitter, like:
1. scheduler job backlink for lava result bundles 2. build job backlink for build result bundles 3. merge job backlink for auto merge result bundles, etc. 4. other service job for other service result bunldes... 5. user profile of submitter backlink for manually submitted bundles
- A stronger case that lava-{dashboard,scheduler} has all the key
models - devices, tests, results - all in one place. Easier for extension developers to target as their backend.
- Less fuss for extension developers that don't really consider the
implications of this distributed system
I understand that there are a few potential developer roles:
1. test developer 2. dashboard view developer 3. scheduler extension developer??? what's that?
Why would an extension developer need to target scheduler and dashboard at the same time? How would merging both make it easier for the extension developer? Do we support any way of extending the scheduler at all?