Snapshotting for rollback after updates was[ Re: Drawing lessons from fatal SELinux bug #1054350]
simo at redhat.com
Sun Jan 26 18:41:42 UTC 2014
On Sat, 2014-01-25 at 15:04 -0500, Colin Walters wrote:
> Hi Simo,
> On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote:
> > The reason is simple: lot's of software *changes* data as part of its
> > normal functioning, including and often in rollback-incompatible ways.
> I wrote and maintain a system that has been doing continuous deployment
> of GNOME. It's been running for over a year, and is nearing it's
> 10000th build.
> I have "rolled" back many times - both on the server side, and on the
> client side. Here's one I *just did* a few minutes ago because vala git
> master broke the build of gnome-calculator:
> That's me telling the system "please stop building git master, and
> freeze to this specific commit". All clients get that change when they
> upgrade - OSTree cares not at all for version numbers.
> The vala maintainers continue to work out the issue in git master, and I
> continue to ship a working system. Double win.
> Now it's true, programs in GNOME do sometimes make the type of data
> format transition you're talking about. Evolution has done it at least
> But you know what? My real world experience has been that having the
> ability to roll back has *far* *far* *far* outweighed the downsides when
> applications do format transitions. It's comparatively rare.
> Far more people are bit by things like hardware-specific issues where
> gnome-shell fails to render on this particular card - and rollback works
> beautifully for that.
I never said it won't work in absolute, it probably will work ok in many
cases, just to cause incredible issues in others.
It is a fine tool in the hands of an expert that knows how to check
whether reverting to a snapshot is safe.
It is not going to be a good solution for non-expert users though
*unless* you provide system APIs that *all* applications use to signal
when they are doing irreversible changes so that the user can be warned
about potential data loss right when he asks the system to revert a
Simo Sorce * Red Hat, Inc * New York
More information about the devel