action #127286
closedcoordination #127031: [saga][epic] openQA for SUSE customers
coordination #127028: [epic] openQA on SLE+packagehub
Run openQA (webUI+worker) based on SLE+packagehub size:M
0%
Description
Updated by okurz over 1 year ago
- Copied from action #127034: [spike][timeboxed:20h] Run openQA (webUI+worker) based on SLE to find out problems size:M added
Updated by livdywan over 1 year ago
- Status changed from New to Blocked
- Assignee set to livdywan
Also blocking on the spike solution
Updated by okurz over 1 year ago
- Copied to action #127757: Cover SLE in openQA docs added
Updated by okurz over 1 year ago
- Description updated (diff)
- Status changed from Blocked to New
- Assignee deleted (
livdywan)
#127034 resolved. openQA in an older version can be installed just fine from SLE+packagehub. So we can think about a test procedure to ensure that in the future, e.g. covering in openQA-in-openQA tests, extending existing SLE openQA tests on openqa.suse.de or similar.
Updated by mkittler over 1 year ago
- Subject changed from Run openQA (webUI+worker) based on SLE+packagehub to Run openQA (webUI+worker) based on SLE+packagehub size:M
- Description updated (diff)
Updated by mkittler over 1 year ago
I guess the next step for this ticket would be the same as #127541#note-15.
Updated by okurz over 1 year ago
mkittler wrote:
I guess the next step for this ticket would be the same as #127541#note-15.
Not necessarily. IMHO the next distinct task is a testing approach. How about os-autoinst-distri-openQA on SLE15SP4+PackageHub within SLE maintenance tests?
Updated by jbaier_cz over 1 year ago
- Status changed from Workable to In Progress
How about os-autoinst-distri-openQA on SLE15SP4+PackageHub within SLE maintenance tests?
I can try to make that.
Updated by openqa_review over 1 year ago
- Due date set to 2023-06-16
Setting due date based on mean cycle time of SUSE QE Tools
Updated by jbaier_cz over 1 year ago
So far it seems that the best approach is to reuse openqa tests from distri-opensuse (running distri-openQA on SLE hard drive would introduce a lot of code tweaks inside the distribution). The current bootstrap script does unfortunately not work right away so I am tweaking that. The installation seems to work (at least for 15-SP4, we are missing some packages for 15-SP5). Next step would be to create/adjust appropriate needles to pass the test.
Updated by jbaier_cz over 1 year ago
- Related to action #130369: [spike][timeboxed:20h] Reduce duplication of openQA-in-openQA tests in os-autoinst-distri-opensuse and os-autoinst-distri-openQA size:S added
Updated by jbaier_cz over 1 year ago
So it seems that it is possible to run openQA pretty nicely on SLE+PackageHub and devel:openQA (plus the Leap variant); it is also possible to run it completely without external repositories with just the versions from SLE+PackageHub with a minor drawback, it is not possible to run tests from os-autoinst-distri-openSUSE anymore as the version in 15-SP4 is too old and does not provide all test dependencies. We might want to switch to test something more lightweight instead (maybe #127622 can be reused here?).
I drafted https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17216 with modifications needed to install the test. It somehow introduces more duplication as that overlaps with the repository version installation from os-autoinst-distri-openQA. I suggest to block this issue for now and wait for #130369 before continuing further.
@okurz, do you agree with that approach?
Updated by okurz over 1 year ago
jbaier_cz wrote:
So it seems that it is possible to run openQA pretty nicely on SLE+PackageHub and devel:openQA (plus the Leap variant); it is also possible to run it completely without external repositories with just the versions from SLE+PackageHub with a minor drawback, it is not possible to run tests from os-autoinst-distri-openSUSE anymore as the version in 15-SP4 is too old and does not provide all test dependencies. We might want to switch to test something more lightweight instead (maybe #127622 can be reused here?).
Well, it is actually good that we can show with an automated test that dependencies in "clean SLE+PackageHub" are too old so at best we can have both, tests with os-autoinst-distri-example as the lightweight "openQA works" test as well as a proof that os-autoinst-distri-opensuse can work after someone updated dependencies for the corresponding SLE version(s).
I drafted https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17216 with modifications needed to install the test. It somehow introduces more duplication as that overlaps with the repository version installation from os-autoinst-distri-openQA. I suggest to block this issue for now and wait for #130369 before continuing further.
@okurz, do you agree with that approach?
Yes, I agree. We can easily block on tickets we have in the backlog
Updated by jbaier_cz over 1 year ago
- Due date deleted (
2023-06-16) - Status changed from In Progress to Blocked
We will benefit from doing the deduplication first, blocked on #130369
Updated by livdywan about 1 year ago
This is effectively blocked by #135632 - runner up for highest blockchain ;-)
Updated by okurz about 1 year ago
- Target version changed from Ready to Tools - Next
Updated by okurz 18 days ago
- Status changed from Blocked to Rejected
- Assignee changed from jbaier_cz to okurz
- Target version changed from Tools - Next to Ready
As clarified in a meeting with mkittler, hrommel, jstehlik, hsehic, okurz 2024-09-24 (private minutes in #165683-36) we should use SLFO as a base instead of SLE for a potential SUSE offering hence for now no further follow-up is planned here. Further work is conducted as part of #129313