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?

On Tue, 24 Jan 2012 12:27:14 +0100, 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.

I agree its worth thinking about whether the division into components we currently have is right. I do think that it's a much more subtle question than just mashing the code bases together though!

For me the advantages outweigh the disadvantages:

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!)

Well. Maybe. The thing here is that currently the job file we give to the scheduler and on to the dispatcher specifies the dashboard to submit to -- we don't *know* if it is submitting jobs to the same dashboard as we are hosting! If we don't want to support this, we shouldn't allow it, by overwriting/validating/inserting the server portion of the job json file before giving to the dispatcher.

• 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

• Easier workflow, one less component to release ;-)
• We get to clean up dashboard_app and rename it to lava-*

Cons:

• We may need to do a flag day when we have one big migration that

will rename tables, etc

• This will break sql-based reports (but I don't think that we really

care about them anymore)

• I'm not sure what we'd do with the lava-dashboard, lava-scheduler

projects on launchpad

You're missing the biggest con IMHO which is the conceptual separation. Currently the scheduler is about getting the jobs run and the dashboard is about displaying the results of said jobs. I like this distinction, and would generally like to preserve it. You know the slogan "loosly coupled but tightly integrated"?

PS: We could move this a step forward and consider merging with lava-server (at the source code repo level) where we''d have clear separation from the core (server,scheduler,dashboard) and extensions that build on the core.

Cheers, mwh