The Python library and CLI for scheduling openQA jobs and forwarding results to Wikitcms and ResultsDB. Contains the fedmsg consumers for doing the above automatically. Git repo: https://pagure.io/fedora-qa/fedora_openqa
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 30 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 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.
This now only relies on one other issue, which isn't really a 'cleanup' or a 'new feature' for the trigger, just a test we don't have covered yet. Is there any need to keep this issue open?
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 6 2017
I was going to have it done already, but couldn't while my web server was down. I'll write one today or tomorrow.
Feb 3 2017
We need a blogpost about this new awesome feature! I see 4 volunteers:
I don't really care who does it, we can even pick randomly!
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 31 2017
D1102 is addressing this, it's almost baked, should be done tomorrow.
Jan 30 2017
This was resolved long ago, we haven't had the JSON stuff in a while and we do have fedmsg scheduling.
This was resolved by D1067 (and we had duplicate tasks for it, apparently...)
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 :-).
Jan 12 2017
This is all done now, with fedfind's help. D1067 implemented it.