Support systemd-nspawn/podman as runtime

[emansom]

Is this feature request related to a problem? If so, please describe it.

I would like to run peridot on a single many-core Rocky system (e.g. EPYC Bergamo) without much hassle: boot, SSH in, run peridot build el9. Without dependency on Kubernetes and other NIH vendor lock.

Describe the solution you'd like to see

systemd supports running OCI containers via nspawn. This mechanism is used by some build tools Fedora made/uses and could be leveraged for peridot.

Have you considered alternative solutions/features? If so, please describe them.

Kubernetes is pretty much a no-go for me. I really dislike unnecessary overcomplication.

Version and Build Information

Irrelevant.

Additional Context

I would like to be able to maintain a 1:1 local copy of Rocky without the over-engineering that comes with "cloud native".

[mstg]

Hi, I can give some feedback on this.
Many of the decisions made for Peridot definitely "locked" it into running it in an environment that was very focused on the RESF/Rocky Linux itself. We definitely realized it a while ago, but moving the needle for v1 hasn't been easy, or very desired as the system was from bottom up making a lot of assumptions.

These days we have made a lot of progress of a v2 storage service, that we will try to integrate into v1 while we continue to work on v2 as a whole. It has mostly been a initiative on the side, but it requires careful consideration as we still need to be able to migrate the current state with all the build logs, artifacts, keys etc.

The good news is that what is in the works is mostly what you're asking for. It tries to make as few assumptions as possible. You can either deploy the storage part only, storage+build part separate or all in one binary. Whether you choose systemd or Kubernetes is personal preference. Build workers are also not going to be tied to Kubernetes but rather configurable directly in the Web UI. So we're definitely working towards a much more configurable and much more logically grouped project. We're hoping it'll simplify development, as well as deployment in different environments than what we officially support.

Unfortunately though I don't have much public progress to give, as I said I personally will be focusing on the storage part and try to figure out the best way forward compared to yumrepofs v1. After that comes the build part of v2.

I'll keep this issue open and will try to give updates regarding design docs and plans moving forward. I'm hoping we'll see more activity for v2 around summer.