[functional][y][epic][smt] revisit smt testing strategy
We don't own SMT, and it requires maintenance. As there is a requirement for SMT test for QSF, we should address it in a way that we have control over the test.
We could use MM test, for example.
openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-gnome_install_smt@64bit fails in
- Installation tests using smt/rmt work reliably
- No external dependencies are used
Fails since (at least) Build 20.3
Always latest result in this scenario: latest
#5 Updated by okurz about 4 years ago
Discussed with sunyan, riafarov and mawerner:
- In general SMT should be considered stable and not an object for testing anymore
- QA SLE migration takes the responsibility to cover RMT testing in general
- Any SMT/RMT tests withing the domain of QSF-y should focus on connecting+registering the current SLE versions under test against a stable SMT or RMT instance, not relying on correct repo content, e.g. no development builds are synced to any SMT/RMT server, just stable released products
#7 Updated by okurz about 4 years ago
- Subject changed from [functional][y][smt] revisit smt testing strategy to [functional][y][epic][smt] revisit smt testing strategy
- Status changed from Feedback to Workable
- Assignee deleted (
Answer from Weihua:
Currently we are maintaining following SMT and RMT server: SMT server: * smt.suse.asia 10.67.1.56 * migration-smt.qa.suse.de 10.162.0.27 RMT server: * openqa-rmt.suse.de 10.160.2.15
#11 Updated by riafarov over 3 years ago
- Status changed from Workable to Resolved
- Assignee set to riafarov
I believe we can resolve this one. So we agreed on following:
registration against smt and rmt is covered by migration team.
QSF-Y covers YaST modules for smt and rmt configuration.
In such setup we don't have blocking or overlapping parts. Thanks all!
#13 Updated by szarate about 2 years ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html