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.