Major version upgrade capability
Summary
Support clean upgrades via lvm and/or btrfs snapshots. Only upgrades from the immediate previous release will be supported.
Owner
- Name: TBD
Current status
- Targeted release: Fedora 17
- Last updated: 07-Jul-2011
- Percentage of completion: 0%
Detailed Description
For users not performing an N+1 version upgrade, support an alternate upgrade method in anaconda that sets them up for data and configuration file migration. An idea that has been suggested is to detect if the version you are trying to upgrade is older than N and then:
- Create a new / filesystem for the new release, install there.
- Set up previous root filesystem to mount as /old or something similar.
- Reinstall the boot loader on the existing /boot volume, but maintain an entry to boot the previous release.
Prefer upgrades via snapshot capabilities of btrfs and lvm:
- snapshots should allow us to offer rollbacks to the previous release if the upgrade fails
- btrfs may allow more flexibility than lvm
- lvm snapshot capabilities?
- use libstorage as generic interface to snapshots
Benefit to Fedora
Not all users perform ugprades at each release. By allowing another way for users to upgrade, we can set them up for data and configuration file migration without mandating that the RPM transaction set complete perfectly in an rpm -Uvh sense.
Scope
Given that this feature is new, we should really only concentrate on the most previous release and upgrades from it. Updates via snapshots with LVM since almost all users will be using LVM.
It is also important that anaconda not gain any knowledge about configuration file formats or other specific details. Package maintainers need to ensure the RPMs can be upgraded cleanly from release to release. The goal of upgrades in anaconda is to allow users to drive the main "yum upgrade" transaction via anaconda.