action #46019
open[opensuse] Providing salt-autoinstaller openQA tests
0%
Description
I am working on a new project, salt-autoinstaller, that aims to do the same job that autoyast is doing, but using only salt. The idea is to build a piece (the installer) that can be integrated in other projects that use salt and take care of a full provisioning without other dependencies.
There is a more detailed description of the project here:
http://mailman.suse.de/mlarch/SuSE/salt/2019/salt.2019.01/msg00008.html
We reach a point where the project is getting features that make time-consuming to test. For example, I am supporting legal bios, gpt devices, uefi and secure boot configurations, with kexec or snapper as optional extra parameter. IMHO testing the combinations of configurations make a perfect job for openQA.
I would like to ask for help to integrate openQA tests into salt-auntoinstaller. I can take care or the maintenance of the needles, but for sure I will need some assistance to bootstrap the project, including some initial tests and configuration.
Currently I have a kiwi image with the salt-minion. In my local machine I have a salt-master and the pillar and states that the installer needs. To avoid the requirement of the second machine, I can update the kiwi image to include the master, and create a package for salt-auntoinstaller that will contain the states and pillars.
I will love to explore a way to launch the tests under demand.
Updated by okurz almost 6 years ago
- Category set to New test
Hi, can you provide a link to a feature request which we can use to understand the business case and motivation?
I guess it would be a good start to trigger tests based on existing openQA tests on openqa.opensuse.org with the assets from https://download.opensuse.org/repositories/home:/aplanas:/Images/images/ . What would you consider better to start with, boot the qcow images or the iso?
Updated by aplanas almost 6 years ago
okurz wrote:
Hi, can you provide a link to a feature request which we can use to understand the business case and motivation?
I cannot, as is not under any FATE. This started as a PoC and we are still evaluating if is feasible.
I guess it would be a good start to trigger tests based on existing openQA tests on openqa.opensuse.org with the assets from https://download.opensuse.org/repositories/home:/aplanas:/Images/images/ . What would you consider better to start with, boot the qcow images or the iso?
The image is
https://build.opensuse.org/package/show/home:aplanas:Images/test-image-iso
Booting from there as an USB or as a DVD would make sense. I would need to add into the image the salt-master and the salt states, that are living in github.
Updated by okurz almost 6 years ago
- Status changed from New to In Progress
- Assignee set to okurz
Let's see what we can do with the ISO:
BUILD=29.33 VERSION=1.42.3 ARCH=x86_64 BASE_DISTRI=Tumbleweed; openqa-clone-job --skip-download --skip-chained-deps --from https://openqa.opensuse.org --host https://openqa.opensuse.org 829119 ISO= ISO_URL=https://download.opensuse.org/repositories/home:/aplanas:/Images/images/iso/ISO-openSUSE-$BASE_DISTRI.$ARCH-$VERSION-Build$BUILD.iso _GROUP="Development Tumbleweed" TEST=textmode+salt-auto VERSION=$VERSION BUILD=$BUILD
-> Created job #829483: opensuse-Tumbleweed-DVD-x86_64-Build20190110-textmode@64bit -> https://openqa.opensuse.org/t829483
Failed not finding the ISO, let's try to specify the ISO with ISO still even though it should be a downloadable asset:
BUILD=29.33 VERSION=1.42.3 ARCH=x86_64 BASE_DISTRI=Tumbleweed ISO=ISO-openSUSE-$BASE_DISTRI.$ARCH-$VERSION-Build$BUILD.iso ; openqa-clone-job --skip-download --skip-chained-deps --from https://openqa.opensuse.org --host https://openqa.opensuse.org 829119 ISO=$ISO ISO_URL=https://download.opensuse.org/repositories/home:/aplanas:/Images/images/iso/$ISO _GROUP="Development Tumbleweed" TEST=textmode+salt-auto VERSION=$VERSION BUILD=$BUILD EXCLUDE_MODULES=isosize
-> Created job #829491: opensuse-Tumbleweed-DVD-x86_64-Build20190110-textmode@64bit -> https://openqa.opensuse.org/t829491
Created one needle for the boot menu, then it automatically (after timeout) selected the first entry and booted. https://openqa.opensuse.org/tests/829493#step/bootloader/3 is as far as we got: A login prompt. I would call this a success :)
For the qcow2:
BUILD=12.3 VERSION=Tumbleweed ARCH=x86_64 BASE_DISTRI=Tumbleweed HDD=openSUSE-$BASE_DISTRI-JeOS.$ARCH-$VERSION-kvm-and-xen-Build$BUILD.qcow2 ; openqa-clone-job --skip-download --skip-chained-deps --from https://openqa.opensuse.org --host https://openqa.opensuse.org 829119 ISO= HDD_1=$HDD HDD_1_URL=https://download.opensuse.org/repositories/home:/aplanas:/Images/images/$HDD _GROUP="Development Tumbleweed" TEST=boot+salt-auto VERSION=$VERSION BUILD=$BUILD BOOT_HDD_IMAGE=1 BOOTFROM=d
-> Created job #829495: opensuse-Tumbleweed-DVD-x86_64-Build20190110-textmode@64bit -> https://openqa.opensuse.org/t829497
also reaching a login prompt.
So, where to go from there?
Updated by mgriessmeier almost 6 years ago
- Subject changed from Providing salt-autoinstaller openQA tests to [tools] Providing salt-autoinstaller openQA tests
Updated by okurz over 5 years ago
@aplanas care to revisit the idea? I think we are not far from success :) What are your plans and expectations?
Updated by aplanas over 5 years ago
okurz wrote:
@aplanas care to revisit the idea?
I just create a RPM for the salt formula. I plan to add it into the ISO
I think we are not far from success :)
I think that you are right.
What are your plans and expectations?
My plan is to have a self contained image. Once that I have that I can report it here.
After that I need to write a test that will execute this: 'salt-call -l debug state.hightstate', or a variant of it (maybe with some --local parameter). This will produce a lot of STDERR / STDOUT output that I can use to see if there is a problem.
Another option is to remove the '-l debug' and take only the final STDOUT salt report, where shows the number of failed states. I would expected 0 here.
Is there a way for me to start playing with openQA and make a prototype of the test? Do I need to install openQA locally for doing that?
Updated by okurz over 5 years ago
aplanas wrote:
Is there a way for me to start playing with openQA and make a prototype of the test? Do I need to install openQA locally for doing that?
Installation got pretty easy following http://open.qa/docs/#_openqa_quick_bootstrap however you do not necessarily need a local installation to try that out. http://open.qa/docs/#_triggering_tests_based_on_an_any_remote_git_refspec_or_open_github_pull_request describes how you can trigger tests on our production instances with your own custom test code easily.
Updated by okurz over 5 years ago
- Assignee changed from okurz to aplanas
Talked with aplanas in person: He presented me how yomi works and where the code as well as the live systems live. Based on this we discussed how to bring yomi into openQA. As the project is an openSUSE project including source on github and live system built in OBS we chose openqa.opensuse.org as the right openQA target instance. As yomi so far relies on a remote salt-master we need a controlling instance with the salt-master next to the target system running the salt-minion. For this I see two ways, using a multi-machine test on o3 or nested-virt as we for example already do for the openqa_in_openqa test or the openqa-bootstrap test. For now we cloned the openqa-bootstrap test and forked os-autoinst-distri-opensuse for aplanas to get accustomed with and extend from there.
Updated by okurz almost 5 years ago
- Subject changed from [tools] Providing salt-autoinstaller openQA tests to [opensuse] Providing salt-autoinstaller openQA tests
not worked on by "tools" team.
Updated by okurz about 3 years ago
This ticket was set to "Normal" priority but was not updated within the SLO period for "Normal" tickets (365 days) as described on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives . Please consider picking up this ticket within the next 365 days or just set the ticket to the next lower priority of "Low" (no SLO related time period). This update was done as agreed within the SUSE QE Sync call 2021-09-01
Updated by slo-gin about 2 years ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.
Updated by slo-gin 8 months ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.