pungi

#1727 RFE: subvariants for ostree_installer and ostree_container phases
Opened by adamwill. Modified

Open
Close Issue

As discussed at https://pagure.io/releng/issue/11965#comment-896666 , it seems to me that the ostree and ostree_installer phases simply weren't designed to handle multiple images per variant like the other phases do at all.

This is now causing a problem, because that ticket is about putting all the "atomic desktop" images under a single variant, rather than each having its own variant. The reporter really just wants them all to show up in the same directory in the compose tree, but that's controlled by the "variant" concept. We can only achieve this if we can produce multiple ostrees and ostree_installer images with different subvariants within a single variant.

For ostree, I don't see the point of subvariants. The ostree repo lives outside of the compose, and isn't mentioned in metadata. It is already possible to configure multiple of them, just replace the inner-most dict in the ostree section with a list of dicts.

OSTree installer needs a bit of schema modification to allow using lists of dicts, and it needs the subvariant field as the images are listed in the metadata. This PR should do it: https://pagure.io/pungi/pull-request/1729
Apparently the code is already capable of handling multiple tasks for one variant and architecture.

The ostree repo lives outside of the compose, and isn't mentioned in metadata. It is already possible to configure multiple of them, just replace the inner-most dict in the ostree section with a list of dicts.

That's good news...but then how do you get the ostree-installer phase to use the correct one, when there are multiple? I guess I was assuming that the subvariant would be the way to "match" them.
Edited by adamwill

The ostree phase configures ostree_repo and ostree_ref, which gets updated with new content. The installer points to that via lorax templates (ostree_install_repo, ostree_install_ref etc.). Technically, you can build the iso from ostree that was not even created in the same compose.

ohhh, right. I knew that! I had to hack it all up to make the openQA ostree installer build test work...:D thanks.

so, we discovered something new here fiddling around with a similar change to the nightly bodhi updates composes: the ostree_container phase also has problems if you try to do multiple images in one variant. They all get named for variant so they overwrite each other, and only the one that finishes last survives.
Edited by adamwill

so...I kinda rediscovered bits of this wrt IoT bootc stuff, and sent a PR that should fix the ostree_container phase - https://pagure.io/pungi/pull-request/1789 . The PR for ostree_installer - https://pagure.io/pungi/pull-request/1729 - has been sitting around for several months because I think we were still trying to figure out what to do about the os/ directory in this case.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/pungi/pungi/issues/1727

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.