createhdds: allow text installs, branched and rawhide installs
ClosedPublic

Authored by adamwill on Jan 25 2017, 11:20 AM.

Details

Summary

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.

Test Plan

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
adamwill retitled this revision from to createhdds: allow text installs, branched and rawhide installs.Jan 25 2017, 11:20 AM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)

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.

adamwill updated this revision to Diff 2787.Jan 25 2017, 1:24 PM

Simplify Branched handling

adamwill added a comment.EditedJan 25 2017, 1:28 PM

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.

This revision is now accepted and ready to land.Jan 25 2017, 3:10 PM

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 :)

adamwill closed this revision.Feb 15 2017, 1:44 AM

Transferred to Pagure for the new createhdds project: https://pagure.io/fedora-qa/createhdds/pull-request/1