[WIP] Add support for federated webUI #1414
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
foursixnine
changed the title
This allows to be able to use the json api to get not only a job information but also the details if there are any Add tests to get test results from the job json api
In order to allow better filtering and proper grouping of jobs when they belong to an instance in another location, so that bridged worker can query all the jobs available to be "proxied", without extra need for more worker settings and redefinition of worker classes. This allows to use :my_location:our_worker_class
For the federated mode, we require an explicit setting that will allow openQA to know what jobs must run on a separate instance.
Trigger the monitoring of the master WebUI and slave WebUI, and use events to handle new data. Initially being set up as stubs but the bridge should be able to find new items on the WebUI that are scheduled for it, and transfer them to the newer slave, after changing the job settings.
Add proxy_job_monitor as a stub to spawn a new ioloop timer that will monitor the state of a job. Improve logging
To improve and isolate the federation support, a new dedicated api route is needed, given the latest changes to the api and grab job. For now, this is just mimicking the behaviour of job#list
foursixnine
force-pushed
the
worker_bridge
branch
from
064fc32
to
aba358f
Compare
Codecov Report
@@ Coverage Diff @@
## master #1414 +/- ##
===========================================
- Coverage 87.22% 68.75% -18.48%
===========================================
Files 105 95 -10
Lines 7874 7396 -478
===========================================
- Hits 6868 5085 -1783
- Misses 1006 2311 +1305
Continue to review full report at Codecov.
|
foursixnine
commented
Sep 27, 2017
|
|
||
| #We have only one job | ||
| $t->get_ok('/api/v1/jobs/' . $get->tx->res->json->{jobs}[0]{id})->status_is(200); | ||
| $t->json_is( |
There was a problem hiding this comment.
This particular test is failing for now
| for my $key (qw(ISO HDD_1)) { | ||
| # Check if the settings are between the arguments passed via query url | ||
| # they come in lowercase, so mace sure $key is lc'ed | ||
| for my $key (qw(ISO HDD_1 WORKER_CLASS PROXIED)) { |
There was a problem hiding this comment.
currently I'd like to think that one could filter by every job setting... and this list could be dynamically generated by searching for unique job settings.
|
I just noticed I had comments that never made it to public :P |
|
Is there a related progress issue? I'm just wondering what the motivation behind this feature is. |
|
@Martchus I think it's https://progress.opensuse.org/issues/25278 . |
|
@AdamWill Thanks |
|
I'm closing this for now due to inactivity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So, after some digging I've got to a point where I can say that the federation could work.
The approach is simple, have a separate script/app that will check a master webUI for jobs available under a certain worker class, if there are, create the respective jobs on the slave webUI and monitor them.
For this mode, we require an explicit setting that will allow openQA to know what jobs must run on a separate instance. This allows to use WORKER_CLASS=:my_location:our_worker_class
To improve and isolate the federation support, a new dedicated api route is needed, given the latest changes to the API and grab job, thus I added /federation, for now this is just mimicking the behavior of job#list
Add proxy_job_monitor as a stub to spawn a new ioloop timer that will monitor the state of a job, but I'm not 100% sure that this could be efficient, but another idea is to simply have a timer every N seconds and query all jobs's status that have PROXIED=1 in their job settings on the slaveUI
Status PROXIED has also been added, so these jobs can be tagged properly on the masterUI