taskotron / libtaskotron

#44 Move reporting routines from clients to server
Closed: Invalid Opened by jskladan.

Closed: Invalid
Reopen Issue

The more I work on both Bodhi and ResultsDB reporting, the more it seems like the client-side is not the best choice for reporting. IMHO it would make more sense to move the reporting to the server side. If I remember correctly, it was even the initial idea, and the reason why we were trying to choose a standardized format for results representation.
The main reason, which re-occurs regularly, is getting URLs for the "shortlogs" - i.e. URLs pointing to log files respective for each result. This can (I guess) be done the same way it was in AutoQA, by creating the log files on clients in a specific directory, and passing a root URL from server to clients, so the final URLs can be divided during client's runtime. But the more I think about it, the more it seems like a nasty hack, which would not at all be necessary, should we decide to do the reporting on the server-side.
I believe that the pieces come together better this way. We have the standardized format for results representation (TAP13), the server side can easily create the URLs without any hacks, etc.
Also, one of the AutoQA-ish approach's flaws is, that since the reporting is done from clients, before the logs are actually stored on the server. The links pointing to the respective urls will be non-existent. This might seem like a minor drawback, but for some tests (and if e.g. Bodhi decides to be slow) the gap can be quite large (for bigger updates like Gnome, for example, it can take tens of minutes according to @kparal). If we take into consideration, that we want to spawn FedMSG notifications on new results, I believe that the maintainer/result consumer should be able to access the results at the time the notification is produced.
This can, of course, be somehow done from the client side, but once again, it seems a bit like unnecessary overcomplicating it.
Thoughts?

I think I understand what you're saying but I'm not sure that moving reporting to "server side" is going to be quite that simple. At this point, we still have a few things to iron out and I think it's going to be difficult to say what is or isn't practical until we have more of the system up and running at the same time.

I'm having some difficulty understanding exactly what you think isn't going to work well. IIRC, buildbot's logs are available from the buildmaster in near-real-time instead of the "copy to master on cleanup" process that autotest used. With the build number (buildbot's terminology for the job/task uuid), it shouldn't be a problem to generate working links to the logs from the client. I'm working on getting a new deployment set up and will look into that, though.

Do you think it would be unreasonable to keep going with client-side reporting for the time being and re-evaluate whether or not that's a good idea once we have something working?

IIRC, buildbot's logs are available from the buildmaster in near-real-time instead of the "copy to master on cleanup" process that autotest used.

That's very interesting, I didn't know. Does that apply only to the main task log (i.e. stdout of the spawned process), or can we handle even newly created files this way? Because we will need to save the shortlogs to separate files, and yes, we can do that on the client, but can they be immediately copied to the server?

The problem with AutoQA was this:
1. Upgradepath runs for 100 pending updates.
2. At the end, the "pretty logs" (shortlogs) are generated as files on the client.
3. Upgradepath reports the results to Bodhi.
4. The generated files are copied to the server when the task is completely finished.

Between 3) and 4) it could easily take 30 minutes or more. When Bodhi was slow, querying for an update and adding a comment could have taken a minute or so. So sometimes maintainers contacted me "I've just received an AutoQA result to Bodhi, but it links to 404 Not Found". And I had to reply "please wait 30 minutes until the job is completely finished, then the logs will be available".

If we can avoid it in buildbot by realtime data copy, that's great. Can we?

Of course, this is not an essential feature and we can get by with just client reporting, if it's much easier to implement at the moment. Just thinking ahead.

Yeah, I know that there were some issues with the way that AutoQA did logs and notifications.

Of course, this is not an essential feature and we can get by with just client reporting, if it's much easier to implement at the moment. Just thinking ahead.

Unless I'm missing something major, I think that reporting client-side is going to be significantly easier than doing anything server-side. I understand the concerns but I'd rather have something working before we worry too much about optimization.
Metadata
None
None
None
None
Low
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.