Marian Csontos wrote:
Bill Peck wrote:
>
> Hello,
>
> I've finally implemented some of the XMLRPC methods for reporting
> results into the scheduler.
>
> recipes.Abort(recipe_id, msg)
> recipes.Cancel(recipe_id, msg)
> recipes.tasks.Start(task_id)
> recipes.tasks.Stop(task_id)
> recipes.tasks.Pass(task_id, path, score, summary)
> recipes.tasks.Warn(task_id, path, score, summary)
> recipes.tasks.Fail(task_id, path, score, summary)
> recipes.tasks.Panic(task_id, path, score, summary)
> recipes.tasks.Abort(task_id, msg)
> recipes.tasks.Cancel(task_id, msg)
>
> Any status or result reported will propagate the status and result
> with the highest severity to the top.
> Here are the current Status and the matching severity.
>
> New 10
> Processed 20
> Queued 30
> Scheduled 40
> Running 80
> Completed 50
> Cancelled 60
> Aborted 70
>
> And Results are as follows:
>
> New 10
> Pass 20
> Warn 30
> Fail 40
> Panic 50
>
> I was thinking it would be nice to have a
> recipes.tasks.StdOut(task_id, offset, length, data) method that would
> take the StdOut from the running test as its running. We would
> capture StdErr as well and possibly mux them together by default or
> allow for separate viewing?
>
>
Bill, forget what I said about using single function for
Pass,Warn,Fail: these are not only used for statistics, but have
special meaning - e.g. for reporting... I think it is fine they are
distinctive functions.
What I thought of is different functionality: logging.
*Logging*
Runtime logging to server - not used for job statistics, only
auxiliary data.
Note: This could be used for streaming stdout/stderr as well.
recipes.tasks.Log(task_id, log_id, debug_level, message)
* log_id: multiple tasks logging into single log OR
single task using multiple logs
* _TODO_ string or number ??? I prefer strings: no need to allocate/use
some magic numbers in tests.
* in case of numbers: by convention reserve 1 for stdout and 2 for
stderr
If you use strings then I think it should be called log_handle instead.
I tend of think _id as a number thing.
* debug_level in [FATAL, CRITICAL, ERROR, WARNING, INFO, DEBUG1,
DEBUG2, DEBUG3].
I see. I think that makes sense.
* used for filtering only
*File Uploads*
I would mention uploads as well. Are we going to use XMLRPC for these?
recipes.tasks.Upload(task_id, file_name, file_handler, message, data)
* file_name - path to display. Mandatory.
* Note: Not necessarily the real pathname of file, e.g.
"~/.mozilla/firefox/_PROFILE_.default/cookies.sqlite".
* Should be same for same stage of two different tests,
e.g. for comparative workflow
* file_handler - type of data. Default: "binary".
* Usage: used for post-processing or further analyse.
* e.g. for producing HTML view(s)
* Examples: e.g. "dmesg" or "gcc_out"
* Allows filters: e.g. for timestamped gcc output use
"timestamp|gcc_out"
* message: describe content of file. One file can be uploaded many times
under same file_name. Default: ""
* e.g. config files before and after running config scripts
* data - _TODO_ No idea what xmlrpc format is appropriate for binary
data transfers.
Normally the data is broken into chunks and those chunks are
uuencoded.
So we need to have an offset field and possibly an md5 field to verify
the data.
So one file upload would cause multiple xmlrpc calls until all chunks
were uploaded. We could also use this to upload a growing log file as
its being written.
>