Technical Spec, better upgrade/rollback control

[Colin Walters]

On Fri, Feb 21, 2014 at 12:46 AM, Chris Murphy 
<lists at colorremedies.com> wrote:
> 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:
> 

There's also OSTree - it's a more invasive vision, as it forces *every 
upgrade* to be atomic, and at present, you need to reboot.  But on the 
plus side, every upgrade is atomic =)  And by virtue of being 
constantly used, it's also constantly tested in real world scenarios.

A lot of "rollback" tools as below badly suffer from the fact that 
they're only used "in anger" when something went wrong.

I haven't talked much here about using OSTree for the traditional 
user-owns-machine "workstation" case - as it's near the end of my 
multi-year plan.  It requires rpm/dnf to be aware of OSTree underneath.

Currently though, I think OSTree works very well for replication-based 
workstation deployments. This is the case where you run a corporate IT 
shop, and you have a "corporate standard build" of the OS preloaded 
with apps, and no ability for users to install apps individually, or 
change the OS.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140221/42266359/attachment.html>