This is an attempt to add features desirable for creating
Taskotron base images. It extends the 'release' handling for
virt-install images in several ways to allow requesting of
'branched' and 'rawhide' image creation. It also adds an arg
to request virt-install image creation run in text mode, not
graphical mode. Graphical mode is what we always want for
openQA (so the installed OS doesn't have kernel params intended
for serial console interaction), but for Taskotron purposes,
we want the install run in text mode.
Details
Try creating Rawhide and Branched images through
CLI (Branched for now should just tell you there is no branched,
we cannot test that creation works right now). Try creating
stable release images through CLI (make sure it still works
properly). Try creating Rawhide and Branched images from an
hdds.json file (will have to modify the existing hdds.json a
bit or create a simple test one). Check that creating stable
release images from the current hdds.json still works. Check
that the check feature works properly for both cases (stable
and Branched/Rawhide), including not expecting a Branched image
to exist when there is no Branched. Test using the -t arg to
run the install in text mode, and see if the text output is as
desired.
Diff Detail
- Repository
- rOPENQA fedora_openqa
- Branch
- textinst (branched from develop)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 980 Build 980: arc lint + arc unit
Code works OK. Personally, I don't have a problem doing this in createhdds.py, but you should ask Josef whether it suits his usecase.
Just a quick note on the fedfind usage - current git master fedfind (and the 3.3.0 release, but I'm not shipping packages for that yet as I might want to take some of the features back out again now) caches the collections JSON that's used for get_current_release, so it's essentially free to call it multiple times, which is why I don't worry about doing that here. If you're using a slightly older fedfind it'll do multiple trips.
edit: and on the change to the libosinfo stuff - while thinking about how to handle that for Rawhide I realized the 'fedora-unknown' variant is treated by virt-install as meaning "just use the highest numbered Fedora variant that exists", so we don't need the old code that essentially does the same thing, if we can't find a variant for the actual release number. All we have to do is try to use the 'correct' variant, and if that's not available, use 'fedora-unknown', as that's always going to be the best choice we can make, it does the 'right thing' for Branched, Rawhide, and brand new releases that haven't made it into libvirt / libosinfo yet.
Only strange thing is that when you build image for Rawhide, it's called disk_frawhide_..., but it doesn't matter that much.
Eh, I dunno if I'd call it 'strange'. It's just...correct. The "release" for Rawhide is 'rawhide', it's not '26' or anything like that. We're pretty consistent about that. I guess 'frawhide' looks slightly odder than 'f25', if that's all you meant :)
Transferred to Pagure for the new createhdds project: https://pagure.io/fedora-qa/createhdds/pull-request/1