GNOME Bugzilla – Bug 767977
live updates design
Last modified: 2018-08-17 18:58:57 UTC
Now that package layering is really happening in rpm-ostree and I'm using it, I find I really want to take the next step and support live updates. I think a good chunk of the infrastructure could (and should) live at the ostree level. In the case where we're just *adding* new packages, particularly e.g. command line tools that just drop a new binary in /usr/bin, I assert there is effectively zero risk to a live update. Furthermore - I now believe that the original ostree design was too conservative. We can gain a lot of safety by simply cloning the current deployment and pushing it as a rollback target. So here's an implementation flow: - Begin transaction - Generate new deployment and .origin file - Push rollback - Update current .origin file to denote target status - we're trying a live update - Add all new files from the new deployment to the current one - Update .origin file to say live update is done - Commit transaction If we're interrupted in the middle, we need to resynchronize the current deployment. There's actually no restrictions on this that require *just* new files - we could easily do a full diff and live upgrade components too, but I think let's start with a design that accomodates new packages only initially.
Hacking on stuff in https://github.com/cgwalters/ostree/commits/apply-live but likely to change.
One thing about this is that with rpm-ostree at least, every single change is going to require updating the rpmdb. Hence, the design needs not only to support unioning new files, but atomic directory replacement. I think in an ideal world, rpm would open /usr/share/rpm as a dfd, and do all further operations relative to that. We aren't in that world today, although we could teach it to do so. And telling application authors to do that in order to correctly handle updates of their data directories seems sustainable. Anyways, this code should be careful to do something like writing /usr/share/rpm.new, populating it fully, and then doing a renameat2(RENAME_EXCHANGE).
OSTree has moved to Github a while ago. Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org. If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you! Closing this report as WONTFIX as part of Bugzilla Housekeeping.