download ARM images and schedule tests for them
ClosedPublic

Authored by garretraziel on Apr 1 2016, 12:00 PM.

Details

Summary

This DR revisits my older code in D729. It uses Pungi4
and doesn't download disk image by itself, it let's GRU to do
it. It now also downloads vmlinuz and initrd so that it wouldn't
have to extract them from disk image.

Pull request from https://github.com/os-autoinst/openQA/pull/627
is needed, because _URL isn't enough by itself - disk images are
compressed, so I've added possibility to append _URL_EXTRACT to
parameter and it then extracts downloaded image.

Test Plan

add correct medium type in UI (Flavor=Minimal-raw_xz-raw.xz
and arch=arm), add new ARM machine and observe that disk image gets
downloaded and test gets scheduled.

Diff Detail

Repository
rOPENQA fedora_openqa
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
garretraziel retitled this revision from to download ARM images and schedule tests for them.Apr 1 2016, 12:00 PM
garretraziel updated this object.
garretraziel edited the test plan for this revision. (Show Details)
garretraziel added reviewers: adamwill, jskladan.

Thanks for this! So those are my comments on a first cut just reading the diff, I'll take a look at it in an editor later. Another thing to be going on with, as a thought experiment - it's an open question, I don't have an answer - imagine we want to write a test for direct kernel boot on x86_64. How does that slot into this design? Would we wind up with awkward logic flow or duplication?

scheduler/fedora_openqa_schedule/schedule.py
95

Only one 'l' in "unfortunately". But in fact this is not true, the locations *are* in metadata - just not the Pungi metadata. They're in .treeinfo. It's a toss-up whether it's worth parsing that, though, or just go with hardcoding.

217

Why this conflict between openQA arch and Fedora arch? Is it not reconcilable? Does 'arm' have special meaning in openQA somewhere? In general I'd like to keep arch specifiers the same everywhere as much as possible, i386 / i686 is enough of a mess...

239–240

I'm not sure I'm a fan of just blindly skipping this check for non-ISO tests. Why is it OK to duplicate ARM tests without force? Shouldn't we write an equivalent check?

garretraziel added inline comments.Apr 4 2016, 12:54 PM
scheduler/fedora_openqa_schedule/schedule.py
217

os-autoinst detects ARCH == arm and it adds some needed arguments to QEMU. We could send patches though.

239–240

I don't think that's okay, but I tried to query jobs with openQA-python-client and it worked only with iso param.

  • remove untrue statement in comment
garretraziel updated this revision to Diff 2057.Apr 7 2016, 9:34 AM
  • remove untrue statement in comment
  • use correct parameter for decompressing
adamwill added inline comments.Apr 8 2016, 8:25 PM
scheduler/fedora_openqa_schedule/schedule.py
239–240

Ooh, busted =) I'll have a look at that, then. You could always file an issue on github ;)

239–240

So I checked this and the python client is pretty generic, I don't see anything that would prevent this working. Could you give a bit more detail on what you tried and what happened? Thanks!

adamwill added inline comments.Apr 8 2016, 8:35 PM
scheduler/fedora_openqa_schedule/schedule.py
239–240

Oh, actually, now I see the problem. It's pretty obvious. It's not my fault, it's the openQA web API: it only exposes 'iso' for querying, you can't query on hdds.

I've filed an upstream ticket: https://github.com/os-autoinst/openQA/issues/636 . If you want to try a fix, you're gonna need to touch lib/OpenQA/WebAPI/Controller/API/V1/Job.pm and lib/OpenQA/Scheduler/Scheduler.pm subroutine query_jobs at least. And remember to write tests =)

garretraziel added inline comments.Apr 12 2016, 12:23 PM
scheduler/fedora_openqa_schedule/schedule.py
239–240

OK, since this should be fixed before we will merge this DR, I'll look into it now.

  • use correct parameter for decompressing
  • don't schedule ARM jobs when they were already run

So with this patch, it should skip also ARM tests when they were already run.

Sorry, I didn't notice this go by on Wednesday! I'll take another look at it on Monday.

So I took another look at this. Overall, it's fine, I guess. It's easy to pick nits but fundamentally I'm not sure I see an obviously cleaner way to do it.

I do have an alternative, but I'm kinda in two minds about whether it's 'better'. Roughly the idea would be that we'd have another key in the image dict in the config, on the same level as score - i.e. it's an element of the scheduler's configuration relating to this image, it's not part of the 'match dict'. Call this key kernelboot or something. It'd be a bool.

jobs_from_compose would call _get_arm_dkboot_urls one time unconditionally (it's cheap, what the heck) and store the result. _get_images would return the kernelboot value for each image as part of its tuple (like it does for score). jobs_from_compose would then cue run_openqa_jobs with the kernelboot boolean somehow - whether by just passing in the URLs and run_openqa_jobs would figure out what to do with them, or by extending extraparams and passing that in, or whatever.

I'm not really sure if that's an improvement on yours, though, it's just where my mind went. It's not HUGELY different, it just tweaks the concept of where the kernel/initramfs URLs fit in a bit (in my design they're associated with the compose, in yours they're kinda associated with the image) and makes the question of when we trigger the direct kernel boot behaviour more clearly an item of configuration than an item of code.

I also have an annoying scenario to consider which neither of these approaches handles well: how do we write an Intel direct kernel boot test? This is actually quite a difficult problem all around, I think it might require another special 'flavor' along the line of 'universal'. But this is something that's in the matrices and which we probably should figure out at some point, so it seems wise to consider it in designing this. Perhaps we actually need a way to add extra parameters based on the flavor, at the point of each post?

Another approach I briefly considered was to use the %VARIABLE% substitution feature of openQA (so we'd just have the new arm-specific base test suites have something like key => "KERNEL_URL", value => "%LOCATION%/Everything/armhfp/whatever"). But the more I thought about it the less I liked it, and in fact it wouldn't work anyway because the downloads get scheduled before the variables are substituted, so forget that one.

Aside from that, I just have a few small notes inline.

adamwill requested changes to this revision.Apr 18 2016, 8:21 PM
adamwill added inline comments.
scheduler/fedora_openqa_schedule/schedule.py
93

For The Future, perhaps we'd prefer to have _get_dkboot_urls(location, arch='armhfp') or something?

151–181

You need to update the doc string, now.

239–240

This little chunk is...not so little any more. At this point perhaps it might be an idea to split it out as a private function just for readability? _find_duplicate_jobs() or whatever.

295–296

Why this change? What use is it to know the image-specific flavor of the ISO we choose for the 'universal' flavor, and how is it related to this diff?

This revision now requires changes to proceed.Apr 18 2016, 8:21 PM
  • separate finding existing jobs in scheduler
garretraziel added inline comments.Apr 20 2016, 11:42 AM
scheduler/fedora_openqa_schedule/schedule.py
295–297

I suppose that this comment should be on line 300. Reason is that I couldn't show for what ISO_URL are universal tests scheduled (I would have to take it from param_urls, but then ISO_URL could be undefined etc etc) so I thought that I'll at least show what flavor's images are used for universal tests. If you think that it doesn't make sense, I'll remove it.

adamwill added inline comments.Apr 20 2016, 2:25 PM
scheduler/fedora_openqa_schedule/schedule.py
295–297

oh, I see. I guess my preference for now would be just to cheat and assume the existence of ISO_URL, maybe with a comment that this is relying on assumption that we only ever run universal tests with ISOs, and if that changes, the code would have to change. For now it seems like a pretty strong assumption. WDYT?

  • use ISO_URL in univ logging again
garretraziel marked 13 inline comments as done.Apr 27 2016, 7:58 AM
  • return force back in place
  • return force back in place, but differently
  • rename variable jobs
adamwill accepted this revision.Apr 27 2016, 8:34 AM

ok, I guess this looks good to go now. If I come up with any improvements I'll send 'em along...

scheduler/fedora_openqa_schedule/schedule.py
295–297

I guess the slightly more sophisticated alternative is something like imagetext = param_urls.get('ISO_URL', flavor) then log using imagetext.

This revision is now accepted and ready to land.Apr 27 2016, 8:34 AM
This revision was automatically updated to reflect the committed changes.