# 20240209_podman-machine-os

# Podman machine OS requirements

- Vision

- Light-weight, minimal with curated package additions (podman, crun, gvisor-tap-vsock, netavark, aardvark-dns, etc)
- Must work for AppleHV, QEMU on Linux, Windows HyperV, and Windows WSL*

* WSL is currently based on a Fedora (non-FCOS build).

- Management
- Manageable via git repo (i.e. we introduce a new dependency, we can add it there)
- Automated
- Available at Podman release (or nearly thereafter)
- Updatable quickly (new releases, CVEs, etc)
- Verified with CI/CD before release
- Version n-1 maintained (i.e. when podman 5.2 is releases, the podman 5.0 version no longer needs to be updated)
- Upstream podman-machine must not depend on RHEL or CentOS
- Daily development OCI images created only (build main)

- Deliverables
- Available disk images: qcow2, raw, vhdx in aarch64 and x86_64
- Disk images must be stored in an OCI registry and versioned (quay.io/libpod/podman-machine-os:5.X)
- Disk images must have an associated OCI image
- Long-term commitment
- Upgradable

- Other
- Ignition is fine, works for us
- No adding or removal of packages based on Ignition
- Must allow volume mounts to / without chattr’ing

# Notes

Workflow:

terminology - Podman Machine OS Efforts == PMOE

- we create and push quay.io/fedora/fedora-coreos:stable - and other streams testing, next, testing-devel, etc
- PMOE processes:
- pulls FCOS container
- Remove Moby, Replace Podman, Add subscription Manager
- Push to a container registry (call it a staging container registry)
- Does image builds based on that container
- qcow2, vhdx, applehv, raw - aarch64, x86_64
- CI on results
- => Action -> promote when ready

- pushing disk-images to a registry in the format you want
- brent knows how to do this
- versioning of podman machine OS
- No underlying Fedora or Fedora CoreOS attributes in the version
- quay.io/libpod/podman-machine-os:5.0
- quay.io/libpod/podman-machine-os:5.1
- can both be based on the same version of FCOS
- requires both streams to be built continuously
- where are the RPMs built?
- not fully fleshed out, but they do plan to still try to use RPMs built in Fedora's infra proper
- Fedora major rebases - any concerns here?
- More advanced upgrade features
- barriers, deadends, etc..
- FCOS provides a base layer without moby or podman -> that gets fed into PMOE process described above
- Dusty: I consider this to be an optional optimization (i.e. non-blocking 5.0)