Learn more about these different git repos.
Other Git URLs
Hello,
In Fedora, there is pungi which is doing bunch of things, but one of them is quite interesting to do on its own - build images which are used for installation of OS. So-called boot.iso.
boot.iso
In very short, right now it is simple runroot task which has -i lorax and huge command line with lorax. Something like:
-i lorax
lorax -p CentOS -v 8 -r 8.1 --variant PXE --nomacboot --noupgrade --noverifyssl -s https://koji.intgdc.com/kojifiles/repos/tools-el8-build/latest/x86_64/ -s https://pulp1.na.intgdc.com/pulp/repos/mirror/hp-spp/develop/8/ ./results
Here's some example of fedora task: https://koji.fedoraproject.org/koji/taskinfo?taskID=42733627
There are already bunch of media tasks support in Koji, which leads me to idea that this might be very useful for anybody who is building their own images for installation of OS.
If you think this can be in koji, I can try to describe flow what should happen inside task(s).
Metadata Update from @tkopecek: - Custom field Size adjusted to None - Issue set to the milestone: 1.22 - Issue tagged with: discussion
@ignatenkobrain How much is it different from #1939? (@jkaluza) I also thought, that there was some other plans for semi-near future (osbuild).
It is very similar indeed, however I'm not interested using pungi.
There was more general idea for "templated runroot" of which is Jan's simplified usecase. That is the one road, other one is to create "proper" builds, which would involve NVRs, etc.
I'd like to have NVRs and archive artifacts properly and so on rather than just templated runroot.
@mikem What is your opinion? I'm not sure, if it should be a plugin or standard task.
Metadata Update from @tkopecek: - Issue set to the milestone: 1.23 (was: 1.22)
What would the resulting builds look like in this case? E.g. what is the file layout? What determines the NVR?
@tkopecek and I talked a bit about this today. Following are some of the items that came up.
At the moment, it is unclear where this fits in our roadmap and priorities. That is to say, this seems like a lot of work, we already have a lot of work, and it's not clear who precisely needs this and how badly.
One key point that came up was this -- you can accomplish this outside of Koji. An external tool could:
While there are certainly some deficiencies to the above approach, it is possible.
When it comes to the question of adding code to Koji for this (whether plugin or patch), I really want to avoid the proliferation of specialized import functions. We have too many gateways for that already and I don't want us to add more. We already have a (mostly) generic import gateway: CGImport. That seems like the way to go, but that also requires deep work in kojihub. Currently there is no good way for builders to use that call.
I suppose you could argue that these builds are images and just use the existing image import calls. That might be ok.
Another idea that came up was extending the runroot plugin to allow it to generate builds. This would also require a lot of significant changes, but it is an interesting idea. It's sort of a lightweight version of the "abstract build interface" that we've been wanting to add for a while.
Metadata Update from @tkopecek: - Issue set to the milestone: None (was: 1.23)
Login to comment on this ticket.