Revision as of 09:30, 31 January 2017

Anaconda LVM RAID

Summary

Use LVM RAID instead of LVM of top of MD RAID in the Anaconda installer.

Owner

Name: Vratislav Podzimek (Anaconda/Blivet)
Email: vpodzime@redhat.com
Name: Heinz Mauelshagen (LVM)
Email: heinzm@redhat.com
Release notes owner:

Current status

Targeted release: Fedora 26
Last updated: 2017-01-31
Tracker bug: <will be assigned by the Wrangler>

Detailed Description

In the current situation when a user chooses LVM partitioning in the Custom Spoke and then sets RAID level for the VG Anaconda (and Blivet) create an MD RAID device which is used as a PV for the VG. With this change we are going to use LVM RAID directly instead. That means that all the LVs in that VG will be RAID LVs with the specified RAID level. LVM RAID provides same functionality as MD RAID (it shares the same kernel code) with better flexibility and additional features expected in future.

Benefit to Fedora

Using a new promising solution with better flexibility (e.g. using different RAID levels for different LVs, changing RAID levels of existing LVs etc.) and reliability due to ongoing development and maintenance from the LVM team.

Scope

Proposal owners:
- Blivet developers: Support creation of LVM RAID in a similar way as LVM on top of MD RAID. (Creation of RAID LVs is already supported.)
- Anaconda developers: Use the new way to create LVM RAID instead of creating LVM on top of MD RAID.
- LVM developers: LVM RAID already has all features required by this change.

Other developers: N/A (not a System Wide Change)

Release engineering: #Releng issue number (a check of an impact with Release Engeneering is needed)

- List of deliverables: N/A (not a System Wide Change)

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

Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

1. Try LVM installation with some RAID level specified for the newly created VG. 2. Reboot. 3. Check that the newly created LVs have the specified RAID level. (e.g. using "sudo lvs -o +lv_layout")

User Experience

There should be no visible change for non-expert users. Expert users could make use of the new LVM RAID's features.

Dependencies

Anaconda (Blivet) already depends on all packages (lvm2) related to this change.

Contingency Plan

Contingency mechanism: Revert changes in Anaconda and keep using the existing solution
Contingency deadline: Beta (Due to the simple contingency mechanism.)
Blocks release: Yes

Documentation

Documentation will be covered in the Installation Guide.

Release Notes

TBD

@@ Line 24: / Line 24: @@
 == Summary ==
-<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
+Use LVM RAID instead of LVM of top of MD RAID in the Anaconda installer.
 == Owner ==
@@ Line 31: / Line 32: @@
 This should link to your home wiki page so we know who you are.
 -->
-* Name: [[User:vpodzime| Vratislav Podzimek]]
+* Name: [[User:vpodzime| Vratislav Podzimek]] (Anaconda/Blivet)
 * Email: vpodzime@redhat.com
+* Name: Heinz Mauelshagen (LVM)
+* Email: heinzm@redhat.com
 * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
@@ Line 43: / Line 46: @@
 == Detailed Description ==
-<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
+In the current situation when a user chooses LVM partitioning in the Custom Spoke and then sets RAID level for the VG Anaconda (and Blivet) create an MD RAID device which is used as a PV for the VG. With this change we are going to use LVM RAID directly instead. That means that all the LVs in that VG will be RAID LVs with the specified RAID level. LVM RAID provides same functionality as MD RAID (it shares the same kernel code) with better flexibility and additional features expected in future.
 == Benefit to Fedora ==
+Using a new promising solution with better flexibility (e.g. using different RAID levels for different LVs, changing RAID levels of existing LVs etc.) and reliability due to ongoing development and maintenance from the LVM team.
-<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
 == Scope ==
 * Proposal owners:
-<!-- What work do the feature owners 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?-->
+** Blivet developers: Support creation of LVM RAID in a similar way as LVM on top of MD RAID. (Creation of RAID LVs is already supported.)
+** Anaconda developers: Use the new way to create LVM RAID instead of creating LVM on top of MD RAID.
+** LVM developers: LVM RAID already has all features required by this change.
 * Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 92: / Line 95: @@
 -->
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+. Try LVM installation with some RAID level specified for the newly created VG.
-N/A (not a System Wide Change)
+. Reboot.
+. Check that the newly created LVs have the specified RAID level. (e.g. using "sudo lvs -o +lv_layout")
 == User Experience ==
 <!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+There should be no visible change for non-expert users. Expert users could make use of the new LVM RAID's features.
 == Dependencies ==
@@ Line 104: / Line 109: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+Anaconda (Blivet) already depends on all packages (lvm2) related to this change.
 == Contingency Plan ==
 <!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
-* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency mechanism: Revert changes in Anaconda and keep using the existing solution
 <!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
-* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline: Beta (Due to the simple contingency mechanism.)
 <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
-* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release: Yes
-* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 == Documentation ==
@@ Line 120: / Line 125: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+Documentation will be covered in the Installation Guide.
 == Release Notes ==
@@ Line 128: / Line 134: @@
 Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
 -->
+TBD
 [[Category:ChangePageIncomplete]]

Search

Changes/AnacondaLVMRAID: Difference between revisions