From Fedora Project Wiki
(Ready for Wrangler)
(Postponed to next Fedora)
 
(9 intermediate revisions by the same user not shown)
Line 21: Line 21:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Change Proposal Name <!-- The name of your change proposal --> =
= Snapshot and Rollback Tool =
 
Snapshot and Rollback Tool


== Summary ==
== Summary ==
Line 37: Line 35:
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: sgallagh@redhat.com
* Email: sgallagh@redhat.com


* Name: [[User:Walters| Colin Walters]]
* Name: [[User:Walters| Colin Walters]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: sgallagh@redhat.com
* Email: walters@redhat.com
 


* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
Line 50: Line 46:


== Current status ==
== Current status ==
* Targeted release: [[Releases/20 | Fedora 20 ]]  
* Targeted release: [[Releases/Next | Fedora Next ]]  
* Last updated: [[User:Sgallagh|Sgallagh]] ([[User talk:Sgallagh|talk]]) 12:31, 11 July 2013 (UTC)
* Last updated: [[User:Sgallagh|Sgallagh]] ([[User talk:Sgallagh|talk]]) 12:31, 11 July 2013 (UTC)
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 60: Line 56:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=998532 #998532]


== Detailed Description ==
== Detailed Description ==
Line 73: Line 69:


This will provide a major benefit to Fedora developers who tend to run the latest-and-greatest (such as on Rawhide). It will allow them to save the state of their system at a time where everything is working and experiment with newer features with the confidence that if things are seriously broken they will be able to restore to a working state. Additionally, this will be useful for anyone running Fedora as a server, as it provides them with a cleaner guarantee for returning to a working state after an update with regressions than 'yum history' is capable of accomplishing.
This will provide a major benefit to Fedora developers who tend to run the latest-and-greatest (such as on Rawhide). It will allow them to save the state of their system at a time where everything is working and experiment with newer features with the confidence that if things are seriously broken they will be able to restore to a working state. Additionally, this will be useful for anyone running Fedora as a server, as it provides them with a cleaner guarantee for returning to a working state after an update with regressions than 'yum history' is capable of accomplishing.


== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the change in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the developers have to accomplish to complete the change in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


The scope of this project is the completion of the initial release of the roller-derby project and the inclusion of thinly-provisioned LVM as an option in the Anaconda installer (being tracked as a separate Change request; will update this page when that is filed).
The scope of this project is the completion of the initial release of the roller-derby project and the inclusion of [[Changes/InstallerLVMThinProvisioningSupport | thinly-provisioned LVM as an option in the Anaconda installer]].
 


* Proposal owners:
* Proposal owners:
Line 86: Line 80:
We need to complete the roller-derby project. Other than the Anaconda change referenced above, all dependencies are available in Fedora already.
We need to complete the roller-derby project. Other than the Anaconda change referenced above, all dependencies are available in Fedora already.


 
* Other developers: [[Changes/InstallerLVMThinProvisioningSupport | OS Installer Support for LVM Thin Provisioning ]]
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Line 130: Line 123:
* Verify that if we fill up the disk, snapshots are removed from oldest to newest to free up space by the daemon
* Verify that if we fill up the disk, snapshots are removed from oldest to newest to free up space by the daemon
* Use the CLI to tag a snapshot as "known-good" and verify that it is not removed unless it is the last snapshot available when free space is required
* Use the CLI to tag a snapshot as "known-good" and verify that it is not removed unless it is the last snapshot available when free space is required


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 140: Line 132:


Users will now have an additional tool to manage their filesystem state at a fundamental level. See the testing plan for a rough outline of how this experience will look.
Users will now have an additional tool to manage their filesystem state at a fundamental level. See the testing plan for a rough outline of how this experience will look.


== Dependencies ==
== Dependencies ==
Line 146: Line 137:


Completion of the Anaconda option for thinly-provisioned LVM as a filesystem layout is necessary for this feature to be easily usable. Otherwise, this feature will only be usable by users following a custom kickstart to elect thinly-provisioned LVM explicitly.
Completion of the Anaconda option for thinly-provisioned LVM as a filesystem layout is necessary for this feature to be easily usable. Otherwise, this feature will only be usable by users following a custom kickstart to elect thinly-provisioned LVM explicitly.


== Contingency Plan ==
== Contingency Plan ==
Line 157: Line 147:


If this is not completed in time, it will have no impact on the system. The tool will simply not ship and be completed for Fedora 21 instead.
If this is not completed in time, it will have no impact on the system. The tool will simply not ship and be completed for Fedora 21 instead.


== Documentation ==
== Documentation ==
Line 174: Line 163:




[[Category:ChangeReadyForWrangler]]
[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 14:32, 5 November 2013


Snapshot and Rollback Tool

Summary

With the advent of thinly-provisioned LVM pools, it has become possible for us to implement full-system LVM snapshotting for recording rollback points. We are planning to support this for yum updates and eventually fedup upgrades going forwards. This change request notes the addition of new tools provided by the roller-derby project to present an interface and a CLI for managing and initiating rollbacks.

Owner

  • Release notes owner:

Current status

Detailed Description

The roller-derby project will be providing a library and a CLI for creating, labeling and managing LVM snapshots (plus non-LVM backups of /boot), oriented primarily towards rpm-managed data, but useful beyond that. The yum plugin "yum-plugin-fs-snapshot" will be updated to consume this library and save the system state in a compatible format. The roller-derby CLI tool will provide an interactive and scriptable interface for manipulating these snapshots and determining when to remove older ones. It will also allow the tagging of snapshots as "known-good", to be skipped when automatically-trimming for space. The roller-derby project will likely provide a small daemon to keep track of the available space in the LVM pool to proactively clean up snapshots before the system runs out of space.

In order to prevent "loss" of data when rebooting into an snapshot, the roller-derby CLI will allow saving a snapshot of the current state before rolling back and will provide tools to allow mounting of that current state to recover changes that have occurred since the rollback point.

Benefit to Fedora

This will provide a major benefit to Fedora developers who tend to run the latest-and-greatest (such as on Rawhide). It will allow them to save the state of their system at a time where everything is working and experiment with newer features with the confidence that if things are seriously broken they will be able to restore to a working state. Additionally, this will be useful for anyone running Fedora as a server, as it provides them with a cleaner guarantee for returning to a working state after an update with regressions than 'yum history' is capable of accomplishing.

Scope

The scope of this project is the completion of the initial release of the roller-derby project and the inclusion of thinly-provisioned LVM as an option in the Anaconda installer.

  • Proposal owners:

We need to complete the roller-derby project. Other than the Anaconda change referenced above, all dependencies are available in Fedora already.

  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)

Upgrade/compatibility impact

Users upgrading from previous Fedora releases will not be able to take advantage of this functionality unless they were previously running with an LVM thinly-provisioned filesystem. In such cases, this tool will simply not be usable and its presence on the system will not have any impact. This feature will apply to new installations that select the "Thinly-provisioned LVM" option for filesystem layout.

How To Test

Testing of the CLI:

  • Use the CLI to create a snapshot.
  • Use the CLI to view the list of available snapshots
  • Use the CLI to revert to a previous snapshot
  • Use the CLI to mount the reversion point for retrieval of data

Testing of the Yum plugin:

  • Perform a yum upgrade with the plugin enabled.
  • Follow the CLI guide to view and revert to this snapshot

If we have time to implement this part of the feature:

  • Verify that if we fill up the disk, snapshots are removed from oldest to newest to free up space by the daemon
  • Use the CLI to tag a snapshot as "known-good" and verify that it is not removed unless it is the last snapshot available when free space is required

N/A (not a System Wide Change)

User Experience

Users will now have an additional tool to manage their filesystem state at a fundamental level. See the testing plan for a rough outline of how this experience will look.

Dependencies

Completion of the Anaconda option for thinly-provisioned LVM as a filesystem layout is necessary for this feature to be easily usable. Otherwise, this feature will only be usable by users following a custom kickstart to elect thinly-provisioned LVM explicitly.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

If this is not completed in time, it will have no impact on the system. The tool will simply not ship and be completed for Fedora 21 instead.

Documentation

Documentation will be needed but has not yet been written. The upstream project is hosted at https://fedorahosted.org/roller-derby

Release Notes

Fedora now provides tools for saving and restoring the system state of systems using a yum plugin and the roller-derby CLI tool.