action #27955
closed
action #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
Added by szarate over 6 years ago.
Updated over 4 years ago.
Category:
Feature requests
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.
- Related to action #14580: Add ability to backup selected jobs/tests results outside of o.s.d/o.o.o added
- Target version changed from Ready to Current Sprint
Carry over to sprint 201712.1, assigning to "Current Sprint".
- Blocked by action #17788: [tools]Uploading images chksum check relies on global /var/lib/openqa/share added
- Target version changed from Current Sprint to Ready
@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.
- 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.
- Category changed from 132 to Feature requests
- Status changed from New to Rejected
Let's declare the idea of federated UI as failed
Also available in: Atom
PDF