-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spec/status stabilization #518
Comments
We discussed this in a realtime meeting, no super strong feelings either way. I'm leaning towards adding the config files and dropping |
For us, as long as the basic concepts stay mostly the same, we'll be more than happy:
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. |
We're not going to break that. I'll make sure gating tests are added for it. |
In preparation for us changing the default output of `bootc status` in the future (cc containers#518 ) add `--format-version` that people can start using now to explicitly request the current version. It's possible that instead of a hard break we still support outputting the current format for a while. Signed-off-by: Colin Walters <walters@verbum.org>
Following up here...there's just fortunately/unfortunately a few too many things parsing the existing #703 relates to this. |
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 runningbootc 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.The text was updated successfully, but these errors were encountered: