QA » openQA Project » openQA Tests

https://openqa.opensuse.org/admin/test_suites

no

If we keep an image with updates from latest build, that will cause the problem of having an image with the updates that a user will not have, because they are not release.
It would require too much manual work to keep a qcow2 that has updates from released repositories.

The best approach I can think is to keep GM qcow2 (we already have it under /var/lib/openqa/share/factory/hdd/fixed/), creating a new test suite that performs an update with official repositores, then execute upgrade tests after it.
I also propose to change the current confusing name of upgrade tests from update_* to upgrade_*.

Renaming is a good idea.

I guess a single manually triggered installation+update openqa run and saving the qcow image would suffice. Based on experience with the migration tests as well as qam ones I recommend not to install all updates for every test run as this takes long and is not perfectly stable

SLindoMansilla wrote:

okurz wrote:

Renaming is a good idea.

Ok, I will prepare the test suite with name upgrade_* in the development job group.

If you rather rename the existing ones most likely the scenario will be still considered the same and even label carry over should work. Just inform the openSUSE RMs as usual upfront and you should be good to go.

I guess a single manually triggered installation+update openqa run and saving the qcow image would suffice.

I think that would be too much manual work. Since we cannot be sure to have the last updated packages, we will end up manually running the update test suite for each new build,

As I was writing a single manually triggered run, not for every few builds, especially for 42.3 which is EOL and does not receive any updates anymore. Do it once and not ever again :)

so, why not let isos post trigger the job?

because the jobs would take really long to install the very same updates again and again for every build.

Based on experience with the migration tests as well as qam ones I recommend not to install all updates for every test run as this takes long and is not perfectly stable

Yes, I didn't mean to add it as a module to any upgrade test suute, but to START_AFTER_TEST, so it will only be executed one time.

That's still the same what QAM does. They do have it as a module but only because they run it for different scenarios, e.g. SLES/SLED/with addons/without/gnome/kde. You would have the same problem. The biggest time impact is reinstalling the updates at a time when a new build for new products is triggered however the updates are released way before and at a different schedule. I already discussed this point for improvement very often with multiple persons, unfortunately whenever I explained that to someone from QA SLE Migration he shortly afterwards left SUSE, don't know if that is a coincidence ;)

If you prefer we can talk about this topic in person next week.

From Tumbleweed's job group overview https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensuse&version=Tumbleweed&build=20190917&groupid=1

I can find 4 upgrade scenarios from Leap 42.3 to Tumbleweed:

• upgrade_Leap_42.3_cryptlvm
• upgrade_Leap_42.3_cryptlvm@uefi
• upgrade_Leap_42.3_gnome
• upgrade_Leap_42.3_kde

Disk images generated:

• 9.8G opensuse-42.3-x86_64-GM-latest-updates-cryptlvm@64bit.qcow2
• 9.0G opensuse-42.3-x86_64-GM-latest-updates-cryptlvm@uefi.qcow2
• 3.3G opensuse-42.3-x86_64-GM-latest-updates-gnome@64bit.qcow2
• 4.0G opensuse-42.3-x86_64-GM-latest-updates-kde@64bit.qcow2

There is not enough free space on ariel:/var/lib/openqa/share/factory/hdd/fixed

SLindoMansilla wrote:

There is not enough free space on ariel:/var/lib/openqa/share/factory/hdd/fixed

how did you come to this conclusion? There is currently 962GB available.

okurz wrote:

how did you come to this conclusion? There is currently 962GB available.

oh, true.
I did only df -h and didn't check mounted directories.

As a temporary upload location I can recommend /space/upload/ . Better don't try to "/tmp" or you will fill up / rather quickly :)

The 4 qcow2 images are now under ariel:/var/lib/openqa/share/factory/hdd/fixed

Verification runs

• upgrade_Leap_42.3_cryptlvm (first_boot fails to close the opensuse welcome popup because the updates made the disk almost full)
• upgrade_Leap_42.3_cryptlvm@uefi (The current GM disk image in used doesn't have a separate /usr nor /home partition)
• upgrade_Leap_42.3_gnome OK
• upgrade_Leap_42.3_kde OK

The disks were created with 20GB size. qcow2 images used in PROD are 40GB.
Maybe it should be better to increase the images size by 20GB.
The problem is that the installer proposed a separate partition for /home which leaves less space for /: http://openqa.slindomansilla-vm.qa.suse.de/tests/1691#step/encrypt_lvm/7
But, yast2 sw_single didn't expect the combination " / + /boot + /home". So, the test fails and needs to be adapted.

New test suites added in Tumbleweed development job group: https://openqa.opensuse.org/admin/job_templates/38

• poo39305-upgrade_Leap_42.3_cryptlvm@64bit (coming soon)
• poo39305-upgrade_Leap_42.3_cryptlvm@uefi (coming soon)
• poo39305-upgrade_Leap_42.3_gnome@64bit Test suite updated in main job group
• poo39305-upgrade_Leap_42.3_kde@64bit Test suite updated in main job group
• poo39305-upgrade_Leap_42.3_kde+system_performance@64bit Test suite updated in main job group

New needle created: yast2_i-yast2-sw_single-disk_usage-with_sep_home_and_sep_boot-20191010

Waiting for verification run: https://openqa.opensuse.org/tests/1053392

With 50GB it works as expected:

• http://openqa.slindomansilla-vm.qa.suse.de/tests/1709
• https://openqa.opensuse.org/tests/1058471