Differential D861

add base_services_start test for ARM
ClosedPublic
Actions

Authored by garretraziel on May 24 2016, 11:54 AM.

Details

Reviewers
adamwill
jskladan
Commits
rOPENQATESTS802c9298fd58: add base_services_start test for ARM
Summary

This adds base_services_start test for ARM. We cannot use boot_to_login_screen
on ARM, because wait_still_screen fires too soon (for first minute or so screen of ARM
VM is completely blank). It also uses rather ugly hack of misusing HDD_ and NUMDISK,
see D860 and https://github.com/os-autoinst/openQA/issues/684.

Test Plan

Try to run base_services_start on ARM.

Diff Detail

Repository
rOPENQATESTS os-autoinst-distri-fedora
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
garretraziel retitled this revision from to add base_services_start test for ARM.May 24 2016, 11:54 AM
garretraziel updated this object.
garretraziel edited the test plan for this revision. (Show Details)
garretraziel added reviewers: adamwill, jskladan.
adamwill requested changes to this revision.May 24 2016, 2:56 PM

I think you may be able to use boot_to_login_screen. See comment.

templates
1579

The comment is incorrect here, isn't it? Shouldn't it only be in the other one?

tests/base_services_start.pm
8

The timeout for boot_to_login_screen is configurable. It's the third parameter.

This revision now requires changes to proceed.May 24 2016, 2:56 PM
garretraziel added inline comments.May 25 2016, 7:22 AM
templates
1579

It's correct for both cases. We don't want to connect HDD_2 at all, neither in this test, nor in the other. Trigger is setting HDD_2_DECOMPRESS_URL during test scheduling (by POSTing it), so it is actually set for all ARM tests - that was the problem when I tried to use HDD_1_DECOMPRESS_URL.

We set HDD_1=HDD_2 in first test (so we could use downloaded disk), and HDD_1=disk_%FLAVOR%_%MACHINE%.qcow2 for second (so it uses disk from previous test), but in neither case we want HDD_2 to be really connected to VM.

tests/base_services_start.pm
8

Problem isn't with timeout, problem is that wait_still_screen fires prematurely. During ARM boot it is normal for screen not to move for 30 seconds (so wait_still_screen 30 returns prematurely). Actually, because VT is initialized only halfway during the boot, it shows blank screen for tens of seconds. I could set higher stilltime_sec, but it means that it would take much longer before it realizes that system actually booted - and that would be also true for other architectures (would I removed get_var("ARCH") eq "arm"). I was thinking about changing boot_to_login_screen, but I couldn't find solution that would be general (architecture independent).

garretraziel marked 2 inline comments as done.May 25 2016, 7:22 AM
adamwill accepted this revision.May 25 2016, 2:32 PM
adamwill added inline comments.
templates
1579

I guess I just mean that there's no *need* to have the comment here as nothing in this test's settings references HDD_2 in any way...but it's not a problem.

tests/base_services_start.pm
8

ah, I see. Fair enough, then.

This revision is now accepted and ready to land.May 25 2016, 2:32 PM
Closed by commit rOPENQATESTS802c9298fd58: add base_services_start test for ARM (authored by garretraziel). · Explain WhyMay 27 2016, 11:10 AM
This revision was automatically updated to reflect the committed changes.

Revision Contents

PathPackages
Mtemplates (24 lines)
Mtests/base_services_start.pm (9 lines)

Diff 2232

View Options

templates

Show First 20 Lines • Show All 221 Lines • ▼ Show 20 Line(s)221 product => {
222 arch => "x86_64", 222​ arch => "x86_64",
223 distri => "fedora", 223​ distri => "fedora",
224 flavor => "KDE-live-iso", 224​ flavor => "KDE-live-iso",
225 version => "*", 225​ version => "*",
226 }, 226​ },
227 test_suite => { name => "base_services_start" }, 227​ test_suite => { name => "base_services_start" },
228 }, 228​ },
229 { 229​ {
230​ machine => { name => "ARM" },
231​ prio => 62,
232​ product => {
233​ arch => "arm",
234​ distri => "fedora",
235​ flavor => "Minimal-raw_xz-raw.xz",
236​ version => "*",
237​ },
238​ test_suite => { name => "base_services_start_arm" },
239​ },
240​ {
230 machine => { name => "64bit" }, 241​ machine => { name => "64bit" },
231 prio => 40, 242​ prio => 40,
232 product => { 243​ product => {
233 arch => "x86_64", 244​ arch => "x86_64",
234 distri => "fedora", 245​ distri => "fedora",
235 flavor => "Workstation-live-iso", 246​ flavor => "Workstation-live-iso",
236 version => "*", 247​ version => "*",
237 }, 248​ },
▲ Show 20 Lines • Show All 978 Lines • ▼ Show 20 Line(s)1226 settings => [
1216 { key => "PACKAGE_SET", value => "default" }, 1227​ { key => "PACKAGE_SET", value => "default" },
1217 { key => "STORE_HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" }, 1228​ { key => "STORE_HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
1218 ], 1229​ ],
1219 }, 1230​ },
1220 { 1231​ {
1221 name => "install_arm_image_deployment_upload", 1232​ name => "install_arm_image_deployment_upload",
1222 settings => [ 1233​ settings => [
1223 { key => "ENTRYPOINT", value => "install_arm_image_deployment" }, 1234​ { key => "ENTRYPOINT", value => "install_arm_image_deployment" },
1235​ # we don't want HDD_2 to be really connected, but we need to use it to download
1236​ # HDD ISO, see https://github.com/os-autoinst/openQA/issues/684
1237​ { key => "NUMDISKS", value => "1" },
1238​ { key => "HDD_1", value => "%HDD_2%" },
1224 { key => "STORE_HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" }, 1239​ { key => "STORE_HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
1225 ], 1240​ ],
1226 }, 1241​ },
1227 { 1242​ {
1228 name => "install_package_set_minimal", 1243​ name => "install_package_set_minimal",
1229 settings => [ 1244​ settings => [
1230 { key => "PACKAGE_SET", value => "minimal" }, 1245​ { key => "PACKAGE_SET", value => "minimal" },
1231 ], 1246​ ],
▲ Show 20 Lines • Show All 319 Lines • ▼ Show 20 Line(s)1564 {
1551 settings => [ 1566​ settings => [
1552 { key => "ENTRYPOINT", value => "base_services_start" }, 1567​ { key => "ENTRYPOINT", value => "base_services_start" },
1553 { key => "START_AFTER_TEST", value => "install_default_upload" }, 1568​ { key => "START_AFTER_TEST", value => "install_default_upload" },
1554 { key => "BOOTFROM", value => "c" }, 1569​ { key => "BOOTFROM", value => "c" },
1555 { key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" }, 1570​ { key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
1556 ], 1571​ ],
1557 }, 1572​ },
1558 { 1573​ {
1574​ name => "base_services_start_arm",
1575​ settings => [
1576​ { key => "ENTRYPOINT", value => "base_services_start" },
1577​ { key => "START_AFTER_TEST", value => "install_arm_image_deployment_upload" },
1578​ { key => "NUMDISKS", value => "1" },
1579​ { key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
adamwillUnsubmitted
Done

The comment is incorrect here, isn't it? Shouldn't it only be in the other one?

garretrazielAuthorUnsubmitted
Not Done

It's correct for both cases. We don't want to connect HDD_2 at all, neither in this test, nor in the other. Trigger is setting HDD_2_DECOMPRESS_URL during test scheduling (by POSTing it), so it is actually set for all ARM tests - that was the problem when I tried to use HDD_1_DECOMPRESS_URL.

We set HDD_1=HDD_2 in first test (so we could use downloaded disk), and HDD_1=disk_%FLAVOR%_%MACHINE%.qcow2 for second (so it uses disk from previous test), but in neither case we want HDD_2 to be really connected to VM.

adamwillUnsubmitted
Not Done

I guess I just mean that there's no *need* to have the comment here as nothing in this test's settings references HDD_2 in any way...but it's not a problem.

1580​ ],
1581​ },
1582​ {
1559 name => "base_service_manipulation", 1583​ name => "base_service_manipulation",
1560 settings => [ 1584​ settings => [
1561 { key => "ENTRYPOINT", value => "base_service_manipulation" }, 1585​ { key => "ENTRYPOINT", value => "base_service_manipulation" },
1562 { key => "START_AFTER_TEST", value => "install_default_upload" }, 1586​ { key => "START_AFTER_TEST", value => "install_default_upload" },
1563 { key => "BOOTFROM", value => "c" }, 1587​ { key => "BOOTFROM", value => "c" },
1564 { key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" }, 1588​ { key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
1565 ], 1589​ ],
1566 }, 1590​ },
▲ Show 20 Lines • Show All 59 Lines • Show Last 20 Lines
View Options

tests/base_services_start.pm

1use base "installedtest"; 1​use base "installedtest";
2use strict; 2​use strict;
3use testapi; 3​use testapi;
4 4​
5sub run { 5​sub run {
6 my $self=shift; 6​ my $self=shift;
7​ if (get_var("ARCH") eq "arm") {
8​ # we cannot use boot_to_login_screen, wait_still_screen is unusable during ARM boot (it shows black screen for first few minutes)
adamwillUnsubmitted
Done

The timeout for boot_to_login_screen is configurable. It's the third parameter.

garretrazielAuthorUnsubmitted
Not Done

Problem isn't with timeout, problem is that wait_still_screen fires prematurely. During ARM boot it is normal for screen not to move for 30 seconds (so wait_still_screen 30 returns prematurely). Actually, because VT is initialized only halfway during the boot, it shows blank screen for tens of seconds. I could set higher stilltime_sec, but it means that it would take much longer before it realizes that system actually booted - and that would be also true for other architectures (would I removed get_var("ARCH") eq "arm"). I was thinking about changing boot_to_login_screen, but I couldn't find solution that would be general (architecture independent).

adamwillUnsubmitted
Not Done

ah, I see. Fair enough, then.

9​ assert_screen "text_console_login", 150;
10​ } else {
7 # wait for boot to complete 11​ # wait for boot to complete
8 $self->boot_to_login_screen("", 30); 12​ $self->boot_to_login_screen("", 30);
13​ }
9 # switch to TTY3 for both, graphical and console tests 14​ # switch to TTY3 for both, graphical and console tests
10 $self->root_console(tty=>3); 15​ $self->root_console(tty=>3);
11 validate_script_output 'systemctl --failed', sub { $_ =~ m/0 loaded units/ }; 16​ validate_script_output 'systemctl --failed', sub { $_ =~ m/0 loaded units/ };
12} 17​}
13 18​
14 19​
15sub test_flags { 20​sub test_flags {
16 # without anything - rollback to 'lastgood' snapshot if failed 21​ # without anything - rollback to 'lastgood' snapshot if failed
Show All 9 Lines