Implement a 'whitelist' for running non-critpath update tests
ClosedPublic

Authored by adamwill on Apr 27 2017, 12:54 AM.

Details

Summary

We want to be able to selectively run the update tests for
non-critpath updates. This implements a system for doing so:
a whitelist where we can indicate that some or all of the
update tests should be run for specific package names. For any
given package we can specify an iterable of flavors to run the
tests for, or just indicate "run all the update tests".

The whitelist is implemented much like the WANTED list: there's
a default whitelist in config.py which can be overridden if
desired by a JSON-formatted config file.

The whitelist is parsed by the fedmsg consumer that automatically
schedules update jobs. Of course, we can still manually trigger
the tests for *any* update we like via the CLI.

Test Plan

The new feature should be covered pretty well in the
test suite. Otherwise, you have to just deploy this on an instance
with the fedmsg listening stuff set up, and wait for or replay
a message for an update that's on the whitelist. I am going to
deploy this to staging so we can check it works properly.

Diff Detail

Repository
rOPENQA fedora_openqa
Branch
update-whitelist (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 1131
Build 1131: arc lint + arc unit
adamwill created this revision.Apr 27 2017, 12:54 AM
adamwill updated this revision to Diff 3024.Apr 27 2017, 12:56 AM

Add a couple more packages to the whitelist (thanks sgallagh)

This seems to be working - I deployed it to staging, and made a trivial edit to the description of https://bodhi.fedoraproject.org/updates/postgresql-9.5.6-1.fc24 in order to test it. The code worked exactly as intended:

Apr 27 03:11:22 openqa-stg01.qa.fedoraproject.org fedmsg-hub[15097]: [2017-04-27 03:11:22][    fedmsg    INFO] OpenQAProductionScheduler: Running update tests for flavors server for whitelisted update FEDORA-2017-4c304f889b
Apr 27 03:11:23 openqa-stg01.qa.fedoraproject.org fedmsg-hub[15097]: [2017-04-27 03:11:23][    fedmsg    INFO] OpenQAProductionScheduler: openQA jobs run on update FEDORA-2017-4c304f889b: 102873 102874 102875 102876 102877 102878 102879 102880 102881 102882 102883 102884

and the jobs are running: https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=24&build=Update-FEDORA-2017-4c304f889b&groupid=2 .

jsedlak accepted this revision.Apr 28 2017, 10:22 AM

Hmm, I don't particularly like having flavors = None for expressing "run on all flavors", but I don't know a better way. Doing flavors = 'all' would mess things up, because string is iterable and also it wouldn't work with schedule.jobs_from_update, so this is OK, I guess.

Still, I find

if flavors:
    ...
elif flavors == []:
    ...
    return
# here flavors is either list or None, but not empty list

rather confusing.

This revision is now accepted and ready to land.Apr 28 2017, 10:22 AM

This seems to be working - I deployed it to staging, and made a trivial edit to the description of https://bodhi.fedoraproject.org/updates/postgresql-9.5.6-1.fc24 in order to test it. The code worked exactly as intended:

Apr 27 03:11:22 openqa-stg01.qa.fedoraproject.org fedmsg-hub[15097]: [2017-04-27 03:11:22][    fedmsg    INFO] OpenQAProductionScheduler: Running update tests for flavors server for whitelisted update FEDORA-2017-4c304f889b
Apr 27 03:11:23 openqa-stg01.qa.fedoraproject.org fedmsg-hub[15097]: [2017-04-27 03:11:23][    fedmsg    INFO] OpenQAProductionScheduler: openQA jobs run on update FEDORA-2017-4c304f889b: 102873 102874 102875 102876 102877 102878 102879 102880 102881 102882 102883 102884

and the jobs are running: https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=24&build=Update-FEDORA-2017-4c304f889b&groupid=2 .

Why aren't those openQA test runs shown in Bodhi in "Automated Tests"?

@jsedlak I have the exact same gut reaction to the flavors stuff, but I just couldn't think of anything obviously better :/ please do suggest something if you can, I'd love to see it look less weird. I'll have another look at it in a day or two with fresh eyes and see if I can come up with anything.

The results don't show up in staging Bodhi because there's actually a bug in the staging openQA setup somewhere; I haven't looked into it in detail but there's some kind of bug somewhere along the whole chain of fedmsg emitters and consumers which means, at least, that staging openQA results never make it to staging ResultsDB (though in theory they're supposed to). It's never been that important before so I never bothered looking into it much, but now we've got this kind of use case, maybe we should sort it out. I'll try and take a look at it. I think the issue might be that we don't actually emit fedmsgs from staging openQA to the staging fedmsg properly, and/or the staging openQA server isn't properly configured to listen to both the staging and production fedmsg buses (which it would have to).

adamwill closed this revision.Apr 28 2017, 4:44 PM