This should be merged only after https://github.com/os-autoinst/openQA/pull/920
gets into production.
Details
Schedule ARM tests, observe that they downloaded into {composeid}.vmlinuz and
{composeid}.initrd.img.
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.
Um - what about the existing code to do this, that's there but commented out?
# add KERNEL and INITRD arguments when needed # TODO: this will not work until https://github.com/os-autoinst/openQA/pull/673 gets merged # if 'KERNEL_URL' in params: # params['KERNEL'] = "vmlinuz.{0}".format(build) # if 'INITRD_URL' in params: # params['INITRD'] = "initrd.img.{0}".format(build)
it's around lines 214-219.
oh, and yeah, I noticed that the upstream fix had been merged, I'll get it built downstream and running on the official hosts ASAP.
http://koji.fedoraproject.org/koji/taskinfo?taskID=15977110 is a scratch openQA build with the fix included, it's live on staging ATM, I'll send it to prod in a couple of days if it seems OK on staging.
I've tested it and scratchbuild works for me. I'll wait until it'll be in production with merge.
Hmm, you are right. I can either uncomment this (and remove changes in this diff), or remove this comment. What do you think is better to do?
Change in this diff is better in that it has all special-case ARM-handling in one place. OTOH, existing commented code would work even when we would schedule direct kernel boot test for non-ARM system (I think that in that case, we should also put architecture into the filename). It looks like it boils down into whether we are counting on using DKB with other architectures.
So current code makes direct kernel boot more general, we are now able to use direct kernel boot even with other architectures. It also means that we can remove almost all ARM-specific hardcoding.
This looks pretty good to me aside from the in-line notes, didn't try it yet but on an eyeball I'm OK with it. I'll ack it for now, I'm also doing an official build of openqa package with the necessary upstream fix and will roll it out to prod (staging has been working fine). thanks.
scheduler/fedora_openqa_schedule/schedule.py | ||
---|---|---|
78 | this feels a bit messy to me now, we might be able to redesign it to be a bit nicer somehow? but I don't think it's worth blocking on. I might look into it if I get the motivation. | |
211 | is losing this going to be a problem? |
I'll merge it once openQA with bugfix will be in stable.
scheduler/fedora_openqa_schedule/schedule.py | ||
---|---|---|
211 | I have checked and FAMILY isn't really used anywhere. I was planning to use it for START_AFTER with ARM (have START_AFTER=default_install_%FAMILY%, move current default_install to default_install_x86 and have default_install_arm that does only initial setup), but then I have simply duplicated all jobs we want to run on ARM. |
this feels a bit messy to me now, we might be able to redesign it to be a bit nicer somehow? but I don't think it's worth blocking on. I might look into it if I get the motivation.