This is one of a semi-regular "rollup"/"highlights" post of what's happening in the rpm-ostree project, used by Fedora Atomic Host, as well as Silverblue[1], and planned to be used by the converged [Fedora CoreOS](https://coreos.fedoraproject.org/) We release approximately once a month. The last post here in February[2] was for 2018.3. We just released 2018.6: https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.6 Releases happen approximately once a month, and quite a lot has happened since Feburary. One of the major aims is to fully flesh out support for automatic updates. The biggest work item actually landed in libostree, called "deployment staging". https://github.com/ostreedev/ostree/pull/1503 Here's a recent blog post about it in relation to Silverblue: https://miabbott.github.io/2018/06/13/rpm-ostree-automatic-updates.html But this will all obviously apply as well to the converged Fedora CoreOS, although one of our primary targets for Fedora CoreOS is Kubernetes-based systems, and we have an "operator" for managing host updates and reboots: https://github.com/ashcrow/container-linux-update-operator/tree/spike that uses the rpm-ostree DBus API, and we will likely aim to polish (and turn into a real operator[3]) as part of Fedora CoreOS. For this audience in particular, I want to highlight that in 2018.5 we finally fixed using `rpm-ostree override replace` with both kernel.rpm and systemd.rpm among others: https://github.com/projectatomic/rpm-ostree/releases/tag/v2018.5 This means rpm-ostree based systems are now much nicer for doing development of the OS itself - install a custom kernel, systemd, podman, docker, NetworkManager, glibc or whatever, and know that you always have the "base tree" available offline and can reliably boot into a previous bootloader entry if something goes wrong, and from there reset things back to the base. 2018.6 also marks the first introduction of Rust code into the rpm-ostree codebase, for an optional feature of using YAML for treefiles. We are testing the waters there; if things work out well it's likely we'll pursue a path of gradual "oxidation"[4]. A lot is happening in the libostree project as well, which also releases on an approximately monthly cadence. (Remember, libostree is independent of RPM, it's used by a variety of distributions in different ways. Think "LVM for bootable filesystem trees with a shared library API"). libostree's latest release: https://github.com/ostreedev/ostree/releases/tag/v2018.6 The biggest change there is definitely the "staged deployment" work: https://github.com/ostreedev/ostree/pull/1503 Which was mentioned above as a fundamental prerequisite for automatic updates. But there's lots more, from peer-to-peer updates, improved repository locking, improved ability to repair corrupted trees, "deployment pinning" to control having more than 2 bootable trees, etc. Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f0a73dfbf4 [1] https://community.teamsilverblue.org/ [2] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/64SROINRZDKHY4ADCUERMH3VQUYZWCMN/ [3] https://github.com/operator-framework/operator-sdk/ [4] https://wiki.mozilla.org/Oxidation _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/5PPQYJV72TUKW2OAUUWHRPFEURRS2F4N/
