WEB_PAGES:
Introduction:
As a qa-automation tester in Product QA for SLES and SUSE-Manager, the SUTs I test (system under test) (like SLE-12-SP2-beta-etc) are changing every day (new packages, patches are merged to SP2, files changes and so on).
Problem: we don't have a tool that give us metadata about the system, like machinery well do.
machinery inspect SUT
machinery show SUT
Problem : what changed from system SLE12-SP-BUILD 8000 from to 8400 ? ( oh, i lost the mail from release manager ! )
machinery compare
Problem : i found a regression with systemd-tests-suite on SLEnkins:
the testsuite fail on BUILD 7400 , but build 7399 is still OK.
what exactly has changed for the package, but also for the system? -> Machinery
Problem: As QA i found a BUG on NFS. I have to report a bug.
Machinery can help me to fill the bug, giving me exact information about really different systems (SLES-12-SP1, openSUSE), etc, what has changed with NFS ? Or Fedora side?
RESULTS
First i want to thank the machinery team, especially Mauro and Manuel that supported me. On this hackweek, have integrated machinery for qa-automation on the library https://github.com/okirch/susetest, and in the SLEnkins automation Framwork.
This work really nice, for scanning systems under test. (SLES, openSUSE)
For qa-automation, machinery works nice and i achieved what i was expecting ! :)
I can scan, compare systems. This could be a FEDORA, DEBIAN, ArchLinux whatever against a openSUSE or a SLES.
In QA and Development, and even Relase Management Perspective this is awesome.
NEW HACK ! :
Revolutionar Perspective for QAAUTOTESTING with Machinery
I'm really glad, i can show you this :
https://slenkins.suse.de/jenkins/job/suite-machinery/32/console
In this example, i compare a SLES-12-SP2-LATEST, with 3-4 builds before.
RESULTS is amazing
With machinery i achieved to compare differents builds from SLES-12-SP2, thanks to the scope, i can see exactly was has changed and was not. I can compare a SLE_12-SP2-GNOME with a SLE-12-SP2-Default, and tracks perfectly changes.
Concrete examples are here :
Scan of a system With console log for machinery ( after the tests are executed) https://slenkins.suse.de/jenkins/view/Test%20suites/job/suite-machinery/13/console
Or with the inspect command redirect to a file.txt to workspace jenkins:
``` setup() machinery_sut = machinery(sut)
try: sometest(sut) machinerysut.inspect() machinerysut.show("tests-machinery") machinerysut.compare("SLE-12-SP2-BUILDXXX-GNOME") ```
Looking for hackers with the skills:
This project is part of:
Hack Week 14
Activity
Comments
-
over 9 years ago by e_bischoff | Reply
For point 2), snapshots would be an alternative. Which does not mean that using machinery to do that is not interesting - on the contrary!
-
Similar Projects
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles: https://linux-system-roles.github.io/