Technical Spec, better upgrade/rollback control

[Christian Schaller]

----- Original Message -----
> From: "Chris Murphy" <lists at colorremedies.com>
> To: "Discussions about development for the Fedora desktop" <desktop at lists.fedoraproject.org>
> Sent: Friday, February 21, 2014 6:46:01 AM
> Subject: Technical Spec, better upgrade/rollback control
> 
> The Workstation PRD includes "better upgrade/rollback control" under plans &
> policies.
> 
> "• Better upgrade/rollback control
> If there are any problems with an upgrade or an upgrade breaks a
> configuration script we want to offer an easy way for users to roll-back
> such upgrades and changes."
> 
> The Technical Specification doesn't address this requirement. And I'm also
> not finding anything in the list archives about it.
> 
> I'm aware of three possible candidates for implementing snapshots and
> rollbacks:
> 
> a.) Roller Derby Project: It lists a dependency on LVM Thin Provisioning,
> which is a new option in Fedora 20. I'm uncertain if it's considered stable
> for production use or not. Also uncertain is if the project is adaptable for
> Btrfs, although it seems likely.
> https://fedorahosted.org/roller-derby/
> http://fedoraproject.org/wiki/Changes/Rollback
> https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001204.html
> 
> b.) Snapper: Lists a dependency on either LVM Thin Provisioning, or Btrfs.
> Snapper+Btrfs is the most mature and actively maintained option at this
> time. It's presently used in openSUSE, by default when the file system is
> Btrfs, for at least a couple of years.
> https://github.com/openSUSE/snapper/blob/master/README
> http://snapper.io/
> http://snapper.io/faq.html
> 
> c. ) Gnome: Richard Hughes has expressed interest in making this happen
> within Gnome. As far as I know it doesn't yet exist, but is expected to
> depend on either Btrfs or LVM Thin Provisioning snapshots.
> 
> Am I missing any others?
> 
> It seems to me the PRD requirement necessitates some assessment of file
> systems, the various snapshotting/rollback strategies and software, before
> the spec can detail an implementation. Should the facts as they're presently
> known be included in the spec in the meantime, with a TDB status?
> 
I think most times when this feature has been discussed it has been in the context of btrfs.
I think the current text in the technical specification doesn't got deeper on the subject partly
because we are all a little on the fence for at what time we feel confident enough about btrfs to
dare propose it as the default filesystem for the desktop. I spoke with the btrfs developer at Red Hat
during a conference on the US West Coast towards the end of last year, and he thought that btrfs was 
ready for the desktop usecase, although he was not ready to recommend it for server use due to the 
(small) risk of data corruption. The argument being that if lets say you need to rollback to a half 
a day older snapshot due to data corruption once a year on a desktop that is probably fine due to 
desktops local data usually being slow moving, while on a database server is not really an option.
That said, I think this item has stalled a bit due to a feeling of uncertainty if that once a year 
occurrence is really fine. (On the other hand it is not that the current options are 100% risk free either).

Christian