The os-autoinst 'distri' for Fedora openQA testing: contains the tests themselves and the test templates. Git repo: https://pagure.io/fedora-qa/os-autoinst-distri-fedora
Aug 1 2017
May 31 2017
FYI, only iSCSI is remaining, which is blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1457163.
May 16 2017
Apr 28 2017
OK, now we've got the test cases and matrices adjusted and updating the reporting bits as well, so I think we can close this. I'll try and remember to keep an eye on things when the next validation event happens so we can check it all works as intended.
Apr 20 2017
Apr 18 2017
This is all done now, we got upstream to merge a ignore_failure flag and our relevant tests now use that, since e68e113f76dacd3bd14f94ab84687bc3784c255e .
Apr 5 2017
I've now written and landed the tests. For now, I'm not going to have them report to the wiki, as the test case includes some 'check the artwork and version numbers' requirements that openQA can't really do. I'm going to propose we separate the various artwork and version identification checks out from the test cases they're currently built in to, and make them into one or more separate test cases. That way openQA can report its results for the original test cases.
Mar 31 2017
Hmm, poked at this a bit today and it's really not trivial. The problem is getting a VM to behave anything like a real system under these conditions; they don't, really. nomodeset's effect on the qemu graphics 'devices' and drivers is rather different from how it acts on 'real' hardware and drivers.
Mar 30 2017
Mar 28 2017
Mar 24 2017
No idea. I think their idea is it was kind of an early implementation of 'soft failures' and they prefer the newer stuff that lets you explicitly trigger a soft failure or have a needle match trigger one, so they figured to get rid of a now-'useless' feature.
I still don't understand why have they done it. What was the problem with current behaviour?
Mar 23 2017
Mar 9 2017
Sounds great! We might need to do some documentation updates, in that case, though, to point to the new repo (I had changed our docs which mention Docker to point upstream on the assumption we were gonna upstream the changes). We may also need to send a PR for upstream docs to say 'if you want to run a containerized openQA for testing on Fedora, go here', or so.
I hadn't sent it upstream because their Dockerfiles diverged from ours (looks like they are using it for testing on Travis). I figured out that dockerized openQA on Fedora might be still useful to us from time to time, so I've simplified it as much as possible - removed all those scripts for setting different auth methods (it's meant for testing/development only, so why not use fake auth), got rid of complicated data handling using data volume container and updated it to newest Fedora, created its own repo on Pagure and removed Docker stuff from repo on bitbucket, so I think that we may close this ticket as resolved.
Mar 8 2017
I dealt with openqa_fedora . Could we close this as a dupe of T863 for the remaining work to do on openqa_fedora_tools ?
Mar 6 2017
Don't use a pastebin as a permanent record, it expires :)
Mar 3 2017
The state of openqa_fedora_tools is correct: it still contains something that we can't get rid of yet, and the README correctly explains what. The docker bits in that repo are ahead of the ones upstream, but still a bit out of date. We're waiting for @jsedlak to update them and get the updated versions merged upstream, then we can ditch that repo entirely.
Feb 28 2017
I think I'm gonna call this resolved. We're now running the desktop and server post-install tests on every submission or edit of a critpath update.
Feb 15 2017
This is almost complete now, the only bit remaining in openqa_fedora_tools is the Docker stuff. That only needs re-updating and sending upstream. @jsedlak said he'd take care of that.
Update: I've now moved the scheduler/reporter library/CLI (now called fedora_openqa) and createhdds out of openqa_fedora_tools:
The way createhdds is supposed to work is that *all* the disk images for a given openQA deployment are created on the server for that deployment. So the 'hard coded' arch is appropriate: createhdds should create images for all tested arches, it shouldn't take any notice of the arch of the machine it's running on.
Feb 14 2017
Feb 3 2017
I have a temporary patch in bitbucket (1) to bypass two previous problems.
But next failure is that started qemu process (2) seems to hung at the end of anaconda install
with "Performing post-installation setup tasks" in VNC screen.
Feb 2 2017
tempo local bypass replacing x86_64 by ppc64 in tools/hdds.json
and manually starting the libvirt daemon (with disabled listen_tls) allow to continue execution
but now failing as missing installable distribution:
[root@fenix hdd]# ~/openqa_fedora_tools/tools/createhdds.py support INFO:createhdds:Creating image disk_f25_support_3_ppc64le.img...[1/1] libvirt: QEMU Driver error : Domain not found: no domain with matching name 'createhdds' INFO:createhdds:Install running, connect via VNC to monitor ERROR Error validating install location: Could not find an installable distribution at 'https://download.fedoraproject.org/pub/fedora/linux/releases/25/Everything/ppc64le/os': The URL could not be accessed, maybe you mistyped?
Feb 1 2017
Jan 30 2017
This should be fixed in a946b02e71f1d61e9f08c6dedfc9590a8c061e19 (which we merged without Phab review due to the nick problems of @garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames ...)
Jan 16 2017
Yes, I was thinking whether simple fork & pull-request will cover all our needs (it's still more basic than Phabricator), but I would definitely try.
Jan 13 2017
AFAIK it's all pull requests, yeah. Though you do still have direct push access to the repo so you can land changes yourself (not via the web UI) once reviewed, I think.
I think that moving code reviews to Pagure would open us to external contributors. But question is, how Pagure handles code reviews? Would be all done using fork and pull requests? Even by us? We can try it with something unimportant (docs or whatever) and see how it works :-).
No, I think that everything important was covered.
Jan 12 2017
This is all done now, with fedfind's help. D1067 implemented it.
hmm, we have server DVD default UEFI test now, but not shrinking or upgrades. Still think it's important?
This is pretty much done now, I implemented these tests last year.
So I've done openqa_fedora:
I agree with renaming openqa_fedora to os-autoinst-distri-fedora SUSE's style, but we should probably create pagure.io/fedora-qa/openqa_fedora and redirect it to the new name.