walters added a new comment to an issue you are following:
The whole time I've been here I've felt a powerful tension: am I here to work on
an atomic upgrade system for hosts that are otherwise managed "traditionally"
(e.g. Ansible works), or am I here to work on containers? The answer is usually both of
Anyways let me state this up front though: My goal with rpm-ostree is to be a fully
general system, in the same way the Linux kernel and systemd are. We should scale up to
big servers, and scale down "reasonably" (we could do better here but let's
say more than 64MB of RAM). Further, we should work the same for single node systems as
well as fully replicated environments.
This last aspect is where the image/ostree portion becomes particularly interesting; as
I've said a lot, rpm-ostree package layering is IMO absolutely essential for practical
use at the small scale. Using it in particular on my daily driver laptop is a powerful
motivator to fix things. But that *same* system can easily take a custom server-side
build, sharing all of the client side logic.
Let's briefly compare with (nominal) competition in this area:
They're really all about Snap - it seems the push is to make dpkg legacy. rpm-ostree
is the polar opposite in that regard; it works with and augments the RPM ecosystem,
building in image-like updates with ostree.
As I mentioned here:
for me the fact that `rpm-ostree install libvirt` just works is powerful and practical.
But on the other hand, Snap shows where we should be going with system containers IMO.
Circling back to the topic here, an interesting place where things collide on this topic
is - do people doing custom image builds want to use preloaded Docker/OCI images? Do
those stay in sync with the host?
they do seem to support bundling snaps, but they don't seem to encourage changing the
base Ubuntu core image?
There are a number of notable upstream rpm-ostree issues on this in the past, like:
But I hope we can completely revamp the "custom compose" path after jigdo ♲📦
since then managing the "images" is a *lot* simpler.
To reply, visit the link below or just reply to this email