Add Fedora IoT bootc bootable containers [Top Level]

[7flying]

Phase 1 - Container image

• #16
• #17
• #18
• #19

Phase 2 - Disk images

• Create disk images with osbuild to produce disk images (Anaconda, installer etc)

[runcom]

@cgwalters we'll use this to track the proper way of producing and delivering the iot image - as I think I've understood it, we would leverage the fedora infra to either 1) derive directly from the fedora base bootc images or 2) perhaps just derive in a Dockerfile (?) - anything you want to add?

for reference, related to #16 - osbuild is going to produce the iot bootc images but we're gonna work towards getting rid of that in favor of a more container native builds within the fedora infra

[cgwalters]

This is a big complex topic but it certainly seems to me like success here is that IoT's default stance is being a set of reference examples (possibly with pre-built containers) that derives from a common base image by default as a Containerfile indeed.

Now, it is very clear to me that a lot of demanding use cases will want to build their own base images. And we need to make that work well too, which is a thread that crosses all of this.

[runcom]

This is a big complex topic but it certainly seems to me like success here is that IoT's default stance is being a set of reference examples (possibly with pre-built containers) that derives from a common base image by default as a Containerfile indeed.

I believe as long as we have pre-built containers whether we build them as base images or derive and podman build makes sense (I personally have no strong opinion, maybe I like the Containerfile+podman build better as it's simpler too w/o going rpm-ostree).

Now, it is very clear to me that a lot of demanding use cases will want to build their own base images. And we need to make that work well too, which is a thread that crosses all of thi

This is probably gonna be part of some investigation we can do as part of this issue too and understand shortcomings of either approaches to make an informed call on what we need (or fix the toolings to make us do what we need)

[runcom]

cc @travier too

It seems we can follow what other Fedora based spins are doing too - that is, leverage the work done in pungi to re-use the rpm-ostree manifest and just build a base container out of that, leaving us the possiblity to further play with the manifest if needed and until something "cross-fedora" is identified perhaps (?)

[travier]

Yes, this is the path I would follow/recommend. Containerfile based builds are good for derivatives, but base images are better composed directly by rpm-ostree compose image.