coordination #42764
closed
[functional][y][epic][smt] revisit smt testing strategy
Added by riafarov over 5 years ago.
Updated over 3 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 24
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
- Related to action #28465: [sle][rmt] Implement disconnect RMT on SLES15([SLE][migration][sle15sp1]) added
- Subject changed from [functional][smt] revisit smt testing strategy to [functional][y][smt] revisit smt testing strategy
Till the decision is made, gnome_install_smt is moved to Development job group.
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.
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
- Status changed from New to Feedback
- Assignee set to okurz
- Target version set to Milestone 21+
waiting for feedback from sunyan or weihua :)
- 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
- Status changed from Workable to Blocked
- Assignee set to okurz
- Target version changed from Milestone 21+ to Milestone 23
- Due date set to 2019-03-26
- 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
- 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!
- Tracker changed from action to coordination
Also available in: Atom
PDF