action #129727
closed
[qe-core]test fails in sssd_389ds_functional. container is trying to access the repo from host
Added by rfan1 over 1 year ago.
Updated over 1 year ago.
Category:
Bugs in existing tests
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
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?
- Status changed from New to In Progress
- Assignee set to rfan1
- Copied to action #129778: [qe-core][qe-security] use new sle15sp4 container image in sssd_389ds test since sle15sp3 is in LTSS added
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
Also available in: Atom
PDF