So this is the outcome of our conversation this morning about the
task_history, order and code database fields.
* Richard and Paul have a problem with the label 'skipped' as a prebuilt
task outcome, because it is already used within the project in the context
of recipes. Paul has suggested the label 'covered' instead, but has asked
me to run it past Richard
* Order: change the task_number field name to 'order' (Paul also suggested
'sequence')
* Task history
1. Existing tasks
1.1 The stamp file itself has no interest. So I just need to
know that a stamp file was found. That is covered by the task_type field.
1.2 I however might want to look at the task that generated that
stamp file, so the interface needs to provide a link to such task. To
identify it we'll use the state_checksum field
2. Covered tasks
2.1 The task history will show which task is covering the covered task and
link to it. To identify the covering task, we need a new field to store
the BitBake task ID (task_id).
2.2 This will require changes to BitBake to generate an event that
provides the information about covering / covered tasks
3. Sstate and executed tasks:
3.1 For executed tasks, the task history will show the output of the
bitbake-diffsigs command, but we have not discussed yet how we are going
to store this
3.2 For executed tasks, the task history will show if a reuse from sstate
was tried but generated a miss or a fail. For that we'll add a
sstate_result field that has 4 possible values: not applicable (the task
does not qualify for reuse, for example, do_fetch), missed (packages were
not found), failed (packages were found, but could not be restored) and
restored (this is a 'prebuilt' task with outcome 'sstate').
* Code
1. For both py and shell tasks, we'll be showing the path to the relevant
file and the initial line number. This means we'll need to replace the
code field in the database with two new fields:
1.1 One for storing the file path
1.2 One for storing the line number
Or something along these lines. Calin will suggest something
2. We have decided not to store or show the content of the run file for
the time being. However, this feature was covered by the high level
design, so in order to make sure we don't forget about it I've opened a
feature in Bugzilla marked as 'future'
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4624)
* Delete:
1. It looks like we are going to need delete functionality to allow
users to delete information from the web hob database.
2. The minimum unit of deletion is a build (you can not delete part
of the information for a build), and it was also suggested to provide
date-based deletion (delete data for builds started / completed between
this day and this day).
3. The question was raised of what's deleted: the information in the
database only, or the build output as well? We don't have an answer yet.
4. A feature request is open, with milestone 1.5M4
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4625). Feel free to
change it if needed.
Belen
On 06/06/2013 13:54, "Paul Eggleton" <[email protected]> wrote:
>On Thursday 06 June 2013 11:06:39 Barros Pena, Belen wrote:
>> On Thursday, 6 June 2013 10:27, Calin Dragomir wrote:
>> > On 05.06.2013 20:14, Paul Eggleton wrote:
>> > > * I understand task_history is meant to capture where BitBake could
>>have
>> > > accelerated the task using sstate but was unable to for some
>>reason. Can
>> > > we have a choice field which indicates this directly (e.g.
>>sstate_result
>> > > - not applicable, unavailable, failed, restored)?
>>
>> > I will change this task_history field into a CharField with only
>>those 4
>> > possible choices and will name it sstate_result. Belen, are you ok
>>with
>> > this? Can you please update the info in the task table based on this?
>>
>> BELEN: Mmm, the question is that the history field will not only show
>> sstate-related outcomes. It is meant to tell "the story of the task",
>>i.e
>> reveal the process BitBake followed to determine how to handle the task.
>> So, for example, for an "existing" task, it will tell me that BitBake
>>found
>> a stamp file in location xyz, and that's why the task was not executed.
>
>Right, so we can infer that based upon the value of the task_type field.
>
>> For an "executed" task, it might tell me that the checksum indicates
>>task
>> inputs have changed and therefore the task needs to be executed, and it
>> will also show me the output of the bitbake-diffsigs command so that I
>>can
>> check what changed in those inputs. For a "skipped" task, it will show
>>me
>> which task brings in the skipped task, and so on. So I don't think the
>>4
>> choices identified by Paul cover all the cases.
>
>I think that it does. The value of my proposed field should be filled in
>for
>both sstate and executed tasks, so we can know what happened during the
>sstate
>phase. I don't want to track this separately in a free-format text field
>because it's effectively another specialised event log that won't be easy
>to
>search/filter on and I don't think that's what we need.
>
>> > > * I agree we want to have a sequence number to allow us to easily
>>show
>> > > the order tasks ran in within the UI where needed (is that
>>task_number
>> > > in the current model? If so do we need the order field which is also
>> > > listed?)
>> >
>> > This is actually a question I had earlier. Task_number isn't listed
>>in the
>> > table from bug #4275. We should drop on one of the task_number and
>>order
>> > fields. I think order should be renamed as task_number in the table,
>>and I
>> > will drop order in the Django model. Belen, do you agree ?
>>
>> BELEN: Happy with that. The label used in the UI for task_number should
>> still be 'order' though.
>
>Since the model definition is not set in stone perhaps we would be better
>advised to use the same terminology in the model definition as the UI;
>i.e. if
>"order" is preferred in the UI then let's use that in the model as well.
>
>> * What is the "code" field?
>>
>> On the agency page here (
>>
>>http://www.yoctoproject.org/webhob/phase3_final_web_prototype/project-bui
>>ld
>> -tasks-task.html) under the Code section I see a block of code, and
>>this is
>> why I have put a TextField there.
>>
>> On the other hand, going through the tasks tabel v4 , I see that
>>depending
>> on the script type, we have a path for shell and a path , function and
>>line
>> number for python code. Belen, what is desired here exactly?
>>
>> BELEN: For shell tasks, the path to the shell script. For Python tasks,
>>the
>> path to the shell script, the function(s) called and the start line for
>> each of those functions. The idea of showing code was specific to failed
>> executed tasks. For those, the idea was showing the code lines that
>>threw
>> the error. Can we identify those? If the answer is yes, I need to add a
>>new
>> information item to the list: "error code" or something like that.
>
>"error code" won't really work, since that would normally imply an error
>result code (number). In any case think we need to collect this
>information
>regardless of whether the task failed or not, so that the user can
>inspect it.
>Let's keep it simple and always collect the file and starting line number
>for
>both python and shell tasks (i.e. we need extra fields for this); for
>shell
>tasks we can also collect the run.do_xyz file and place its contents in
>this
>"code" field.
>
>Cheers,
>Paul
>
>--
>
>Paul Eggleton
>Intel Open Source Technology Centre
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
webhob mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/webhob
