Monolithic OS delivery is popular
{width=”400”
height=”275”}I actually had this post in my drafts for some while. Now it’s more of a reminder than a full post.
We do it, Atomic does it, the systemd-cabal does it, OpenWRT also does it - Delivering the OS or parts of it’s - in bigger chunks. We and OpenWrt ship images, atomic trees, and the systemd cabal is also thinking about images.
The projects got in common that due to the similar concepts of delivery, we also share a common set of problems. One problem we all share is, how the state of a system instance - how the system specific configuration - is persisted/kept, between the (image/tree) based updates.
This can seen pragramatically, like it’s the defautl way with rpm: The old configuration is not overwritten. But: rpm also has postlets (%post, and others) to apply some logic to files when an rpm is updated. This mechanism is used to i.e. convert files if they need some special handling between version upgrades (db schema migration, binary file conversion, …). So in the package based scenario, necessary changes to configuration files are done during the package update. The same thing needs to happen with images.
And so all of us, who do a “monolithic os delivery” are facing the same issue: How do we “migrate” the configuration files between image updates
- or: How do we persist the state of the system between upgrades.
Besides the technical differences in the solutions to this problem, there is one aspect that is unique^1{.footnote-ref}^ to systemd: They try to solve conceptual problems.
OpenWRT’s luci might be an interestnig approach to persistence; maybe it’s more about re-configuration than persistence.
::: {.footnotes role=”doc-endnotes”}
- ::: {#fn:andatomic} For this specific example - persisting the configuration - the atomic people are also quite involved as far as I can tell. ↩︎{.footnote-backref} ::: :::
::: {#footer} [ December 2nd, 2014 11:01pm ]{#timestamp} [ovirt]{.tag} [node]{.tag} [reminder]{.tag} [imgbased]{.tag} [imgbase]{.tag} :::