Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
use base "installedtest";
|
|
|
|
|
use strict;
|
|
|
|
|
use lockapi;
|
|
|
|
|
use testapi;
|
|
|
|
|
use utils;
|
|
|
|
|
|
|
|
|
|
sub run {
|
|
|
|
|
my $self = shift;
|
|
|
|
|
# set up an ssh key
|
|
|
|
|
type_string "ssh-keygen\n";
|
|
|
|
|
sleep 2;
|
|
|
|
|
# confirm directory
|
|
|
|
|
send_key "ret";
|
|
|
|
|
sleep 2;
|
|
|
|
|
# empty passphrase
|
|
|
|
|
send_key "ret";
|
|
|
|
|
sleep 2;
|
|
|
|
|
# confirm empty passphrase
|
|
|
|
|
send_key "ret";
|
|
|
|
|
my $sshpub = script_output "cat /root/.ssh/id_rsa.pub";
|
|
|
|
|
# launch Firefox
|
|
|
|
|
type_string "startx /usr/bin/firefox -width 1024 -height 768 http://172.16.2.118\n";
|
|
|
|
|
# log in as admin
|
|
|
|
|
assert_screen "zezere_login";
|
|
|
|
|
type_string "admin";
|
|
|
|
|
send_key "tab";
|
|
|
|
|
type_string "weakpassword\n";
|
2021-04-08 19:28:17 +00:00
|
|
|
# allow for UI to stabilize
|
|
|
|
|
wait_still_screen 10;
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
# add our ssh key
|
|
|
|
|
assert_and_click "zezere_ssh_key";
|
|
|
|
|
assert_and_click "zezere_ssh_key_contents";
|
|
|
|
|
type_string "$sshpub";
|
|
|
|
|
send_key "tab";
|
|
|
|
|
send_key "ret";
|
2024-03-14 15:32:25 +00:00
|
|
|
wait_still_screen 3;
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
# claim the device
|
|
|
|
|
assert_and_click "zezere_claim_unowned";
|
|
|
|
|
assert_and_click "zezere_claim_button";
|
|
|
|
|
# provision it
|
|
|
|
|
assert_and_click "zezere_device_management";
|
|
|
|
|
assert_and_click "zezere_submit_provision";
|
|
|
|
|
assert_and_click "zezere_provision_menu";
|
2023-03-02 23:00:31 +00:00
|
|
|
send_key_until_needlematch("zezere_provision_installed", "down", 3, 3);
|
|
|
|
|
send_key "ret";
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
assert_and_click "zezere_provision_schedule";
|
|
|
|
|
# exit
|
|
|
|
|
quit_firefox;
|
2020-08-21 22:02:01 +00:00
|
|
|
# time before the provision request goes through is kinda hard to
|
|
|
|
|
# predict, so we'll just try over and over for up to 10 minutes
|
|
|
|
|
# and bail as soon as it works
|
2020-08-21 23:03:14 +00:00
|
|
|
assert_script_run 'until ssh -o StrictHostKeyChecking=no -o PasswordAuthentication=no root@172.16.2.119 touch /tmp/zezerekeyfile; do sleep 10; done', 600;
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sub test_flags {
|
2022-07-28 20:32:57 +00:00
|
|
|
return {fatal => 1};
|
Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
1;
|
|
|
|
|
|
|
|
|
|
# vim: set sw=4 et:
|
