coordination #42764
closed[functional][y][epic][smt] revisit smt testing strategy
0%
Description
Observation¶
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
scc_registration
Acceptance criteria¶
- Installation tests using smt/rmt work reliably
- No external dependencies are used
Reproducible¶
Fails since (at least) Build 20.3
Further details¶
Always latest result in this scenario: latest
Updated by okurz over 5 years ago
- Related to action #28465: [sle][rmt] Implement disconnect RMT on SLES15([SLE][migration][sle15sp1]) added
Updated by okurz over 5 years ago
- Subject changed from [functional][smt] revisit smt testing strategy to [functional][y][smt] revisit smt testing strategy
Updated by riafarov over 5 years ago
Till the decision is made, gnome_install_smt is moved to Development job group.
Updated by maritawerner over 5 years ago
The migration team performs quite some migration tests on SMT and also on RMT and they have both installed. So they should know more about that.
Updated by okurz over 5 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
TODO¶
- Special domains, e.g. the yast module to configure RMT as mentioned in #25800#note-9 should be covered by QSF-y -> #25800
- Open point: Who covers SUSEConnect+RMT
- Open point: Which SMT/RMT instances are there within the domain of QA SLE
- Open point: Who ensures the administration of which instances
Updated by okurz over 5 years ago
- Status changed from New to Feedback
- Assignee set to okurz
- Target version set to Milestone 21+
waiting for feedback from sunyan or weihua :)
Updated by okurz over 5 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 (
okurz)
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
Updated by okurz over 5 years ago
- Status changed from Workable to Blocked
- Assignee set to okurz
- Target version changed from Milestone 21+ to Milestone 23
waiting for #25800 first
Updated by okurz about 5 years ago
- Due date changed from 2019-03-26 to 2019-05-07
- Status changed from Blocked to Workable
- Assignee deleted (
okurz) - Target version changed from Milestone 23 to Milestone 24
Updated by riafarov about 5 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!
Updated by szarate over 3 years ago
- Tracker changed from action to coordination
Updated by szarate over 3 years ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html