action #129727
closed[qe-core]test fails in sssd_389ds_functional. container is trying to access the repo from host
0%
Description
Observation¶
openQA test in scenario sle-15-SP5-Online-x86_64-extra_tests_textmode@64bit fails in
sssd_389ds_functional
Test suite description¶
Maintainer: QE Core, asmorodskyi,dheidler. Mainly console extratest
Reproducible¶
Fails since (at least) Build 100.1
Expected result¶
Last good: 98.1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by rfan1 11 months ago
Please refer to https://suse.slack.com/archives/C02AF8LALDA/p1684831751088179 for more detail information.
Updated by rfan1 11 months ago
The issue might be caused by: https://github.com/SUSE/container-suseconnect
The issue starts to show up after we remove BETA=1 job setting in GMC phase.
At this time, we still register the system to proxy scc. but we will not use development BCI image and switch to default one:
'registry.suse.com/suse/sle15:15.3'
And now from container, it tries to find non existed repos like:
[container-suseconnect-zypp:SLE-Module-Server-Applications15-SP3-Pool|http://openqa.suse.de/assets/repo/SLE-15-SP3-Module-Server-Applications-POOL-x86_64-Build102.1-Media1/] Valid metadata not found at specified URL
The repo name are combined with SLE15SP3 and SLE15SP5 repos here then cause problem.
Seems we can't do much from our test code. Good news is that no such issue on QEM tests:
QEM
I have some comments on this issue:
- Seems container tries to access the repos along with the registration from host, can we use it's own ones?
- If we test published BCI images during development phase for SLES product. how can we deal with it?
Updated by rfan1 11 months ago
- Copied to action #129778: [qe-core][qe-security] use new sle15sp4 container image in sssd_389ds test since sle15sp3 is in LTSS added