action #27955
closedaction #20526: [tools][openqa][research] Research on Federated openQA
coordination #25278: [epic]Refactor worker_bridge for federated openQA support
Allow the worker_bridge to sync job status from a slaveUI to a masterUI
0%
Description
AC 3 of parent task:
worker_bridge will report back job results to the masterUI job results once the job on the slaveUI has any new status to report (once job is set to done, regadless of the state)
This should be done in an independant manner, so that poo#14580 can be addressed too.
Updated by szarate about 7 years ago
- Related to action #14580: Add ability to backup selected jobs/tests results outside of o.s.d/o.o.o added
Updated by szarate about 7 years ago
- Target version changed from Ready to Current Sprint
Carry over to sprint 201712.1, assigning to "Current Sprint".
Updated by szarate almost 7 years ago
- Blocked by action #17788: [tools]Uploading images chksum check relies on global /var/lib/openqa/share added
Updated by szarate almost 7 years ago
- Target version changed from Current Sprint to Ready
Updated by sebchlad over 6 years ago
@szarate: the subject is misleading. "Sprint 201711.2" I assume this isn't correct, is it?
In the description for now you are saying: "AC 3 of parent task"
I would appreciate a pointer to the parent task, otherwise this is really confusing.
Updated by szarate over 6 years ago
- Subject changed from [tools][Sprint 201711.2] Allow the worker_bridge to sync job status from a slaveUI to a masterUI to Allow the worker_bridge to sync job status from a slaveUI to a masterUI
- Assignee deleted (
szarate)
The idea for the implementation of this was:
Have the slaveUI check for jobs with FEDERATED_URL != '' that don't have a backend_info field in the databse with something like "already_updated". (That field is supposed to be not currently used, but can be used to store json information for example.). This is/would be for the startup of the worker.
For the normal execution of the worker, the bridge would simply monitor for job_done event, and the same condition of FEDERATED_URL not being empty and backend_info property being not set, then simply add the job to a queue (possibly a minion job?) and start the upload. Once job is sucessfully uploaded to the remoteUI, "already_updated" property would be set.
Jobs being restarted, is still unclear, but for the time being they simply refresh on the remote UI.
Updated by coolo about 5 years ago
- Status changed from New to Rejected
Let's declare the idea of federated UI as failed