[skip-ci] machine images

[lsm5]

Does this PR introduce a user-facing change?

None

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cevich]

Lokesh, since you're touching secrets here the secret scanner is going to continue barfing. When this gets closer to being ready to merge, you'll need to open a separate PR to add the findings to the baseline (it's documented in the .gitleaks README.md). Poke me if you need help.

[lsm5]

Ignore all packit notifications above.

[jlebon]

We shouldn't need cosa for this.

So here's how I think this would go roughly:

• Based on some trigger (e.g. polling new RPMs out of COPR, or there's a new quay.io/fedora/fedora-coreos:stable image published), start this job
• Do a podman build of an image that does FROM: quay.io/fedora/fedora-coreos:stable, and e.g. removes moby, adds the podman RPMs, adds subscription manager, etc...
• Run osbuild to convert the container image into disk images using the same manifests we use (these are currently hosted e.g. here and here, but I think the goal is to move them out). This requires running on a system with full root privileges. For aarch64, GHA was planning to add runners but it's not clear if that has happened yet. Alternatively, you can have a self-hosted runner on e.g. AWS. Nested virt shouldn't be required AIUI since osbuild uses loopbacks instead.
• Bundle up the disk images into container images and push to the registry

For the triggering, probably the simplest is polling and comparing the latest versions of the RPMs and base FCOS image against the latest pushed podman machine images (e.g. you can store the versioning in labels).

[jlebon]

/cc @dustymabe @baude

[dustymabe]

I wrote this today for @baude: https://github.com/dustymabe/build-podman-machine-os-disks/blob/56ecb7dc0437c1abcbaf6d6a7a806d96edcdab6f/build-podman-machine-os-disks.sh#L4-L25

[dustymabe]

so basically step 3 turns into "run this script" in an environment that can run OSBuild (i.e. run as root, selinux permissive, some osbuild RPMs installed).

[lsm5]

We shouldn't need cosa for this.

Ack

• Based on some trigger (e.g. polling new RPMs out of COPR, or there's a new quay.io/fedora/fedora-coreos:stable image published), start this job
• Do a podman build of an image that does FROM: quay.io/fedora/fedora-coreos:stable, and e.g. removes moby, adds the podman RPMs, adds subscription manager, etc...

These two steps are pretty much happening already using https://github.com/containers/podman/blob/main/contrib/podman-next/fcos-podmanimage/Containerfile . This was taken from https://github.com/coreos/layering-examples/tree/main/podman-next .

subscription-manager addition isn't being done yet, I'll defer to @baude on that.

The container images built are pushed to https://quay.io/repository/podman/fcos?tab=tags .

• Run osbuild to convert the container image into disk images using the same manifests we use (these are currently hosted e.g. here and here, but I think the goal is to move them out). This requires running on a system with full root privileges. For aarch64, GHA was planning to add runners but it's not clear if that has happened yet. Alternatively, you can have a self-hosted runner on e.g. AWS. Nested virt shouldn't be required AIUI since osbuild uses loopbacks instead.

• Bundle up the disk images into container images and push to the registry

Ack, thanks. I'll look into these two.

For the triggering, probably the simplest is polling and comparing the latest versions of the RPMs and base FCOS image against the latest pushed podman machine images (e.g. you can store the versioning in labels).

Ack. The trigger for the existing action right now is a commit to the main branch of podman followed by a successful rpm build at the podman-next COPR. This is done using https://github.com/packit/wait-for-copr.git . So far, we haven't been checking for image updates at quay.io/fedora/fedora-coreos:stable though IIUC that's part of upcoming work.

[lsm5]

obsoleted by coreos/fedora-coreos-pipeline#968 . Closing..