action #174451
openQA (public) - coordination #162890: [saga][epic] feature discoverability
coordination #162896: [epic] Job triggering on jobless openQA instances
openQA-in-openQA tests can get stuck with an inconsistent repository size:S
0%
Description
Observation¶
After #167395 openQA-in-openQA tests use devel:openQA:testing which is a snapshot of devel:openQA created before triggering tests. Unfortunately this snapshot can be created at a bad time where the repository is inconsistent. At least that's how it looks like on https://openqa.opensuse.org/tests/4704845#step/openqa_worker/1 where the installation of openQA-worker fails with The to be installed openQA-worker-4.6.17… requires 'openqa-common = 4.6.17… … but this requirement cannot be provided. Then it suggests do downgrade to packages from openSUSE.
The tests retries the installation but because devel:openQA:testing is snapshotted after #167395 this is in vain now.
I checked the video and it looks like the test really only adds devel:openQA:testing (and not e.g. devel:openQA in addition). So I think an inconsistent snapshot of devel:openQA:testing is the most likely explanation.
Acceptance criteria¶
- AC1: Tests are only triggered from a consistent snapshot of
devel:openQA
Suggestions¶
- Familiarize yourself with https://github.com/os-autoinst/scripts/blob/master/trigger-openqa_in_openqa and https://github.com/os-autoinst/scripts/blob/master/os-autoinst-obs-auto-submit and http://jenkins.qa.suse.de/job/submit-openQA-TW-to-oS_Fctry/ to understand the current pipeline and the involved scripts / #167395
- Ensure that the repository
devel:openQAis "consistent" (supposedly everything is in the published state) before "releasing" it ondevel:openQA:testing. - After the releasing has been done, check whether a consistent state has been released. (All split packages have the same version.)
- Ask on OBS channels about this problem of the release command and how it is usually dealt with.
Updated by mkittler about 1 month ago
- Related to action #167395: Ensure only the tested revision of devel:openQA packages are submitted to openSUSE:Factory size:M added
Updated by okurz about 1 month ago
- Tags set to reactive work
- Category set to Regressions/Crashes
- Target version set to Ready
Updated by livdywan about 1 month ago
- Subject changed from openQA-in-openQA tests can get stuck with an inconsistent repository to openQA-in-openQA tests can get stuck with an inconsistent repository size:S
- Description updated (diff)
- Status changed from New to Workable
Updated by jbaier_cz 4 days ago
A quick and dirty hack would be something like https://github.com/os-autoinst/scripts/pull/365; it does not however solve the entire issue as it still is not an atomic operation. If we want dig more into this, the correct procedure would probably be by creating submit requests from devel:openQA into devel:openQA:testing, let it build inside this request and then check for consistency and approve or reject if there are mismatches. That's probably the most reasonable way to have an atomic operation.
As we are probably still trying to do that without the rebuild, I will introduce a second quick hack and will try to check the versions after the release is done and delete the packages if the version is not consistent. That should solve the original issue (at the cost of delaying the tests until next iteration).
Updated by openqa_review 3 days ago
- Due date set to 2025-01-31
Setting due date based on mean cycle time of SUSE QE Tools