On Wed, 2015-02-18 at 10:59 -0800, Adam Williamson wrote: > On Wed, 2015-02-18 at 05:33 -0500, Josef Skladanka wrote: > > I'd really love to see some more comments in you code, which is > > using the wikitcms/relval internal attributes and so on (it gets > > somewhat wild in places). > > One further note on this, in case it isn't obvious. Now fedfind, > relval, and wikitcms have a unified approach to versioning in all > cases - we always use the 'release, milestone, compose' concept - I > intend for it always to be OK to take a 'release, milestone, > compose' from fedfind and throw it at wikitcms or relval, and vice > versa.
To add another design note here (sorry if I'm boring people to tears): The overall flow of the openqa_fedora_tools/Wikitcms integration is that openqa runs on *images*, then can tell Wikitcms 'hey, I have some results for an image with this release, milestone and compose, can you do something with them?' and it's Wikitcms' job to figure out if it can do anything useful with those results. At present it can only do anything useful if it can find a release validation event whose version matches the image version, but that's not *inevitable*. As I suggested at the meeting this week we could, for instance, invent a new type of result page and hence python-wikitcms 'event', for storing automated test results for non-nominated nightly composes. This means there's a rather funny workflow for the 'current validation event' case: 1. OpenQA asks python-wikitcms to find the 'current validation event' 2. OpenQA asks python-wikitcms for the fedfind Release object that matches the event 2. OpenQA asks fedfind for the images from that 'Release' and tests them 3. OpenQA asks relval to report results for 'the validation event that matches the version of these images I just ran some tests on' 4. python-wikitcms does more or less the reverse of what fedfind did back at step 3, and finds (surprise surprise!) that there is a 'matching' validation event, and reports results for that In most cases the release, milestone, compose attributes for both the python-wikitcms and fedfind objects are actually identical, so they just get thrown around a few times and nothing remarkable happens. But for the special case of Rawhide nightlies, at steps 2 and 3/4, fedfind and python-wikitcms have to twiddle with the version attributes a bit: At step 2, python-wikitcms asks fedfind for a Release object for the ValidationEvent whose version attributes are "release: 22, milestone: Rawhide, compose: 20150207" (for instance). fedfind.release.get_release() translates this to a Release with the version attributes "release: Rawhide, milestone: '', compose: 20150207", which is appropriate for fedfind. The fedfind Image objects inherit those attributes. At step 3, OpenQA uses the fedfind Image version attributes, so it runs : relval report-auto --release "Rawhide" --milestone "" --compose "20150207" ... and python-wikitcms wiki.Wiki.get_validation_page() has to do the opposite of the conversion fedfind did: it converts 'release: Rawhide, milestone: '', compose: 20150207' back to 'release: 22, milestone: Rawhide, compose: 20150207' and finds the correct ValidationEvent. All of this is a bit baroque, but still I think actually the best way to do it given the constraints of the system and the information available: * We don't want circular deps between wikitcms and fedfind so fedfind can find the 'current validation event' itself (and then what? the Image objects for Rawhide nightly composes 'nominated for testing' would have different version attributes from the Image objects for Rawhide nightly composes *not* 'nominated for testing'?) * I don't want to remove openqa's ability to run against non-event images (which would allow us to tie it strongly to *event* versioning rather than *image* versioning). The concept of a 'validation event' is really one that's kind of bound up with manual testing, it's not an appropriate concept to tie an automatic testing system to. * We *could* special case openqa so that when it knows it's running for a specific validation event it uses the event's 'version' as the BUILD, not the image's 'version'. That would avoid the double conversion for Rawhide nightlies. But every time I write it that way, it just seems wrong. And it would mean that if the current validation event was '22 Rawhide 20150207' and you ran: openqa_trigger.py current openqa_trigger.py --release 22 --milestone Rawhide --compose 20150207 then the two sets of jobs would have *different* BUILD identifiers, which seems wrong. * I don't see a way to get openqa to run against TC/RC images using only fedfind, *without* openqa or fedfind asking python-wikitcms to find 'events' for it. It would be pretty ugly to teach fedfind to scrape stage/ so you could ask it for TCs/RCs that currently 'exist'. Unless releng is providing the information in a sanely-consumable format somewhere, Wikitcms is the only sane place I know that acts as a repository of 'what TC/RC composes are there'-type information. The 'ask wikitcms for an event then get the fedfind release that matches it' thing is inelegant but I don't see a way around it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ qa-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/qa-devel
