Build an ISO for each bootc image under releases

[randomlygeneratedname1]

Hi

Would you consider having a prebuilt Anaconda ISO for the bootc versions under releases. That would make it very easy to install an atomic version of MicroShift.

Thanks!

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• /etc/microshift/lvmd.yaml ignored by bootc based install #179
• Develop a quick install script for RPM installation of MicroShift #136

👤 Suggested Assignees

• randomlygeneratedname1
• ggiguash

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[ggiguash]

@randomlygeneratedname1 , thank you for the suggestions.

Can you explain a bit more about your installation workflow? What do you mean by "olm version of the bootc images"?

P.S. Building an Anaconda ISO is certainly a possibility.

[randomlygeneratedname1]

@ggiguash, thanks for the quick reply!

I build an Anaconda ISO using bootc-image-builder. I then use that ISO to install on bare metal or VM. I much prefer atomic/image based versions of OSes! (and it would be more in-line with regular OKD/OpenShift wouldn't it?)

If you prebuilt an Anaconda ISO of the bootc image, it would lower the bar for new users to get MicroShift up and running. And the installed system could just pull patch level (Z) updates directly from ghcr.io from the regular bootc image.

How I built the Anaconda ISO (my config.toml I excluded here for obvious reasons):
sudo podman run \ --rm \ -it \ --privileged \ --pull=newer \ --security-opt label=type:unconfined_t \ -v ./config.toml:/config.toml:ro \ -v ./output:/output \ -v /var/lib/containers/storage:/var/lib/containers/storage \ quay.io/centos-bootc/bootc-image-builder:latest \ --type anaconda-iso \ --use-librepo=True \ ghcr.io/microshift-io/microshift:release-4.20-4.20.0-okd-scos.9

By OLM version, I mean an bootc image built by you that includes microshift-olm (Operator Lifecycle Manager).

[ggiguash]

@randomlygeneratedname1 , OK, so these are two different requests.
I'm converting the current one to a request to build an ISO.

Could you please open another issue with a request to include OLM operator into the image by default?

[ggiguash]

@randomlygeneratedname1 , can you look at #181 and share your feedback if this is what you had in mind?

Note that the PR is still missing the ISO build and publish steps as part of the release workflow. I'm planning to work on this next.

[pmtk]

Maybe we should make it easier (like document) to install it?
I personally find method of bootc container image + simple kickstart with bootable fedora or centos ISO (see basic.ks example residing on http server (inst.ks=https://IP/kickstart.ks)) much leaner approach, and possibly more scalable.

If we find that generating ISO still is useful, then I would think if we really want to publish them - maybe providing tools for building them by users is sufficient enough? Then, they could provide their own customizations without us imposing decisions on them (like user/password/ssh key, disk configuration, etc.).

[ggiguash]

@pmtk , let me create a sample release of the current proposal and decide if this is feasible to support.

[ggiguash]

Looking at this log, it turns out that we need to split the ISO into a few chunks due to its large size.

While this is not a problem to implement, it kind of diminishes the value to the published ISO files. Users would have to download the chunks and reconstruct them before use. Moreover, I'm concerned about the quality of the released ISO files because it's not possible to easily test them in GitHub runners.

@randomlygeneratedname1 , having gone through this process, I tend to agree with @pmtk that installing using a stock ISO + kickstart + bootc seems to be a more convenient compromise (see this example).

What I suggest is to keep the make iso command, in case users want to create a local ISO and change the docs to follow the mentioned technique.

WDYT?