Added by AndreasStieger almost 7 years ago. Updated almost 7 years ago.
0%
Description
No new tests are fired for the Leap 42.2 aggregated tests:
https://openqa.opensuse.org/group_overview/26
New updates were released, and new updates appeared and disappeared in the aggregated repository.
http://download.opensuse.org/update/leap/42.2-test/
The 42.3 equivalent works fine.
bot sais:
DEBUG:openqa-maintenance.py:incident tests for request 516928 are done, but need to wait for test repo
DEBUG:openqa-maintenance.py:incident tests for request 516930 are done, but need to wait for test repo
The results match up with the scenario of the 42.2 aggregated jobs not being regularly scheduled, looking..
A bot was stuck in distri=opensuse version=42.2 build=20170811-5
openqa_client jobs/466020/cancel post
works now, new test triggered and reviews processed
@Ettore, the one job https://openqa.opensuse.org/tests/466020# was in state "assigned". The web ui did not even give any information when this job was scheduled. https://github.com/os-autoinst/openQA/blob/master/docs/GettingStarted.asciidoc#jobs does not describe anything about the state "assigned" which I assume you added. Could you please fix the docs? Also, I am not sure if this issue would be fixed by more recent changes by you or if there is still something missing which can reappear as a problem.
There is no description, because the work on that it was still in progress, but due to more urgent problems #20378 had to be merged. The assigned state is a very recent change, as long as i'm finished with writing full unit tests for the scheduler, along with the changes needed to deal with that new state, will update the docs.
Now it's in cancelled state. But still i do not see how this is related to the issue. For now you have to restart the worker to get it back from the assigned state.
EDiGiacinto wrote:
Now it's in cancelled state. But still i do not see how this is related to the issue. For now you have to restart the worker to get it back from the assigned state.
Yes, it's in cancelled state because I forced it from assigned to cancelled using an API request. The webUI does not offer a cancel button, it does not state when it was created or which worker it is assigned to. So "restart the worker" is not so easy when one does not know which worker.
I assigned the ticket to you to make sure this is not forgotten. If you say all of the issues I mentioned are covered by #20378 go ahead and reopen it and close the current ticket as "Resolved". IMHO just unassigning this ticket is not helping because who else should then ever pick up that ticket?
If it goes to assigned state, it will have a worker assigned - if doesn't, it means something wrong happened in the DB side.
The ticket is regarding a specific set of tests, not at the problem in general, this is why should be closed. When you feel something is wrong wrt scheduler, please add it to the tracker or will get lost anyway : #20378
Edit: this is also another form of #23320