linaro-ci-dashboard

Merge lp://qastaging/~milo/linaro-ci-dashboard/lava-data-model into lp://qastaging/linaro-ci-dashboard

lava-data-model
Merge into trunk

Proposed by Milo Casagrande on 2012-09-19

Status:	Merged
Merged at revision:	67
Proposed branch:	lp://qastaging/~milo/linaro-ci-dashboard/lava-data-model
Merge into:	lp://qastaging/linaro-ci-dashboard
Diff against target:	1083 lines (+865/-7) (has conflicts) 22 files modified Makefile (+2/-0) dashboard/frontend/forms/loop_form.py (+6/-3) dashboard/frontend/migrations/0007_auto__add_field_loopbuild_lava_test_status.py (+52/-0) dashboard/frontend/migrations/0008_auto__add_field_loop_lava_tests.py (+53/-0) dashboard/frontend/models/loop.py (+1/-0) dashboard/frontend/models/loop_build.py (+3/-0) dashboard/frontend/templates/loop_detail.html (+2/-2) dashboard/js/lava/lava_test_select.js (+28/-0) dashboard/lava/lib/lavalib.py (+249/-0) dashboard/lava/migrations/0001_initial.py (+65/-0) dashboard/lava/models/__init__.py (+1/-0) dashboard/lava/models/lava.py (+37/-0) dashboard/lava/templates/lava_select.html (+66/-0) dashboard/lava/templates/tests_list.html (+7/-0) dashboard/lava/tests/__init__.py (+23/-0) dashboard/lava/tests/test_lavalib.py (+70/-0) dashboard/lava/urls.py (+29/-0) dashboard/lava/views/lava_select_test_names.py (+58/-0) dashboard/lava/views/lava_select_view.py (+46/-0) dashboard/lava/widgets/lava_test_select_widget.py (+54/-0) dashboard/settings.py (+8/-0) dashboard/urls.py (+5/-2) Text conflict in dashboard/settings.py
To merge this branch:	bzr merge lp://qastaging/~milo/linaro-ci-dashboard/lava-data-model
Related bugs:	Link a bug report

Reviewer	Review Type	Date Requested	Status
Stevan Radaković		2012-09-19	Pending
Review via email: mp+125162@code.qastaging.launchpad.net

Description of the change

Merge proposal to keep track and discuss the LAVA model and other implementation details.

Discussin with Danilo we thought about creating a separate app for the ci-dashboard, more or less as jenkinsserver.
In this first implmentation there is the structure of the app, initial implementation for the model, and a lib subdirectory ofr a library to interact with LAVA XML-RPC.

lp://qastaging/~milo/linaro-ci-dashboard/lava-data-model updated on 2012-09-19

53. By Milo Casagrande on 2012-09-19: Merged from trunk.

Revision history for this message

Stevan Radaković (stevanr) wrote on 2012-09-19:

This looks OK for now.
I guess you already have these things in mind, but I'm going to list additional things to be extended here:
1. Extend the test status to match all available status results as in LAVA and move the status choices list to i.e. settings so it can be used in both loop_build and lavatest classes.
2. Add the unit tests for lava library.
3. I noticed in LAVA that each test contain multiple entries (i don't know what entity is this you can see in https://validation.linaro.org/lava-server/dashboard/tests/lava/ ) which that have Total results and total failures and stuff like that. So how do we plan to cover this, or do we want to do it at all?

Revision history for this message

Milo Casagrande (milo) wrote on 2012-09-19:

On Wed, Sep 19, 2012 at 3:46 PM, Stevan Radaković
<email address hidden> wrote:
> This looks OK for now.
> I guess you already have these things in mind, but I'm going to list additional things to be extended here:
> 1. Extend the test status to match all available status results as in LAVA and move the status choices list to i.e. settings so it can be used in both loop_build and lavatest classes.

Yeah, I was thinking where to move those values, and settings.py is a
good place to store the all for both of them.

> 2. Add the unit tests for lava library.

Sure, that is way needed. Didn't insert it at the moment, need to
clear some things out first.

> 3. I noticed in LAVA that each test contain multiple entries (i don't know what entity is this you can see in https://validation.linaro.org/lava-server/dashboard/tests/lava/ ) which that have Total results and total failures and stuff like that. So how do we plan to cover this, or do we want to do it at all?

I think we might not cover that at the moment. That is the total
number of runs for that test. Indipendently of the
board/build/whatever. It is just a big total of how many times that
test has been used, not really relevant to what we are doing.

The other thing I'm looking into, is how to best retrieve information
out from LAVA, even server side in an asynchronous way, without having
to deal with cron job. I was thinking about using RabbitMQ/Celery for
this: schedule the necessary tasks, and let the queue handle them. But
those are two new dependencies we have to deal with (maybe good to
start discussion on the mailing list).

Thanks for taking a look!

--
Milo Casagrande
Infrastructure Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs

lp://qastaging/~milo/linaro-ci-dashboard/lava-data-model updated on 2012-09-21

54. By Milo Casagrande on 2012-09-20: Added initial tests selection view.
55. By Milo Casagrande on 2012-09-20: Added field to store list of tests for each loop, needs custom widget.
56. By Milo Casagrande on 2012-09-21: Added LAVA widget for test selection.
57. By Milo Casagrande on 2012-09-21: Merged from trunk.
58. By Milo Casagrande on 2012-09-21: Added OK button to dialog.
59. By Milo Casagrande on 2012-09-21: Clean up and fixes.
60. By Milo Casagrande on 2012-09-21: Added hard-coded test names.
61. By Milo Casagrande on 2012-09-21: Added lavalib tests, started porting of linaro-android-tools.
62. By Milo Casagrande on 2012-09-21: Added placeholder for new method.