On 01/08/2010 04:01 PM, Marian Csontos wrote:
Hi Bill,
rhts uses "late binding" - it uploads a file and only then would say
it was resultLog.
I would like to avoid caching files in backends,
and I would like to go on (at least for a while) with original
rhts-devel-test-env and submit all patches upstream. At least while it
will be used by the two systems.
Fortunately rhts is under our control and the change is simple enough
- requires only to change report_log function in rhts-db-submit-result:
+ bkr = beaker()
+ if bkr:
+ resp = session.results.resultLog(log_type, result_id,
prettyname)
rhts.uploadWrapper(session,log_name,recipetestid, prettyname)
- resp = session.results.resultLog(log_type, result_id, prettyname)
+ if not bkr:
+ resp = session.results.resultLog(log_type, result_id,
prettyname)
...and...
+def beaker():
+ return os.environ.get('FROM_BEAH')
Any advice on this particular solution?
I'm fine making the above change. But
I want to clarify how things
currently work in rhts and how beaker works.
Report a result(s) in rhts.
# Submit the result
result_id = results.result(testname, parent_string, result,
resultvalue, testversion, recipetestid)
# Upload TESTOUT.log
rhts.uploadWrapper(session,log_name,recipetestid, prettyname)
results.resultLog(log_type, result_id, prettyname)
Three xmlrpc calls (possibly many more since uploadWrapper sends the
pieces up in chunks)
Report a result in Beaker
result_id =
task_result(self,task_id,result_type,result_path=None,result_score=None,result_summary=None)
result_upload_file(self,result_id,path,name,size,md5sum,offset,data)
So in Beaker were doing one less call and the first time into
result_upload_file we associate the file with the result (remember, we
can still have multiple calls if the file is large, uploaded in
chunks). Like I said above, I could provide a generic upload_file
method but we need some id no matter what to keep from colliding with
similar log names.
Maybe I don't understand fully yet.
However, we might run into situation, where it will not be that easy.
Do you think it would be possible to change server in such case?
I would like to suggest a change on server: I see no need to
differentiate between {task,recipe,result}_upload_file - it is just a
file. What really matters is "linking" i.e. what we link the uploaded
file to. In these cases we could create link from {recipe,task,result}
as appropriate. IMO it would make sense keeping these in DB.
Yes, but I need to keep the logs in separate dirs or we could have a
file collision. So at a minimum we need to keep logs in a separate task
directory. If we make your change we go to 2 calls and we still need to
specify the recipe/task/result id during file upload.
The same applies to any other kind of objects. At the moment there is
not much of them. But I would like to introduce sections as I
mentioned before. A large part of beakerlib tries to handle this.
Moreover, at the moment we accept only single task at the time and
single "event-stream" for a task. I think it would make sense having
multiple streams and multiple tasks/processes running in parallel and
we would need to identify these. And we would want to link fork and
wait points, may be synchronization points for easier log analysis.
Without linking we might end up with a big mess.
Any of these stream could have child streams, results or log messages
(debug, warning, error) attached.
IMO table display would be the most natural way to display these -
vertical axe for time and horizontal for particular streams.
This does not look like something to be done by end of January, may be
2011, but let's make it possible.
Cheers,
-- Marian