srbala/os-autoinst-distri-fedora
1
0
Fork 0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-12-29 13:43:08 +00:00
Code Issues Releases Activity
3,483 Commits 270 Branches 0 Tags 1.2 GiB
5335016adc
Commit Graph

6 Commits

Author SHA1 Message Date
Adam Williamson
6ae2e05484 Be a bit more defensive when setting admin pw in zezere server 
Signed-off-by: Adam Williamson <awilliam@redhat.com>
 2023-03-29 15:45:17 -07:00
Adam Williamson
989bfd22db zezere: change secure cookie setting to 'no' 
We don't use https in this test (no valid cert), so this has to
be 'no'.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
 2023-03-03 19:05:26 -08:00
Adam Williamson
0b2053b842 zezere: add expected 'secure_cookie' value to config file 
Signed-off-by: Adam Williamson <awilliam@redhat.com>
 2023-03-02 12:53:33 -08:00
Adam Williamson
1a65993d36 Add a perltidy check and apply it to the entire codebase 
Signed-off-by: Adam Williamson <awilliam@redhat.com>
 2022-07-28 14:38:38 -07:00
Adam Williamson
940848b628 Use 'test.openqa.fedoraproject.org' not 'domain.local' 
Using .local is apparently Bad Form because it's reserved for
mDNS. However there doesn't appear to be any particularly Good
Form for what to call a test domain you never want to exist
outside of a closed system, apparently. Sigh. Let's try this.
Includes a bump to disk_ks version because the kickstarts on
that image also need to have this change applied.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
 2020-12-15 14:40:30 -08:00
Adam Williamson
aa41fe4e4e 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-23 18:01:06 -07:00