spec/status stabilization

[cgwalters]

When this project was created, I was trying to more strongly link with the Kubernetes ecosystem by exposing an API that follows the Kubernetes API conventions - and instead of having a lot of imperative verbs, we'd expose a general bootc edit that allowed changing the spec.

Today, the contents of the spec basically just boil down to a fancy container image reference.

(The status is more extensive)

I wouldn't say this is wrong, but it does feel...novel or unusual at the least. As I like to say 90% of configuring a Linux system boils down to writing a file or running a command which writes a file, and this is actually different.

(Incidentally today the bootc source is written to an ostree origin file, which is somewhat obscure and hard to understand)

So...maybe we should just have /etc/bootc.d and e.g. /etc/bootc.d/image.conf say be a (pick config format here) file.

Then one would just need to invoke bootc upgrade to apply the changes. Or in other words, bootc switch would just become sugar for writing to /etc/bootc.d/image.conf and running bootc upgrade.

But in the future if we expand our "desired state" into things like configmaps we'd have /etc/bootc.d/config01.conf which would reference an external configmap, and get merged with the image spec, etc.

[cgwalters]

We discussed this in a realtime meeting, no super strong feelings either way. I'm leaning towards adding the config files and dropping bootc edit. We'd keep bootc status --json though as an API, but probably change bootc status to be human-readable by default.

[p5]

For us, as long as the basic concepts stay mostly the same, we'll be more than happy:

• Derive a custom image from one of the base images
• Bootc uses the container helpers (for auth) from /etc/containers/registries.conf.d
• Bootc updates automatically pulls and schedules the update

We're at the point where we either go down the bootc route, or setup advanced pipelines and automation with Packer, and I'd much rather use bootc 😆

When we do start to build additional observability tooling around bootc, it would be useful if all read-only commands had a machine-parsable output (preferably json), but are perfectly okay with pushing fixes if these defaults do change.

The main thing we would like stability on is how the upgrades happen, as it would be slightly annoying if a machine refuses to update because of a breaking change.

[cgwalters]

The main thing we would like stability on is how the upgrades happen, as it would be slightly annoying if a machine refuses to update because of a breaking change.

We're not going to break that. I'll make sure gating tests are added for it.

[cgwalters]

Following up here...there's just fortunately/unfortunately a few too many things parsing the existing bootc status to just say we're going to break all of it. So...leaning towards basically stabilizing what we have.

#703 relates to this.