From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
(→‎Release Notes: https://pagure.io/fesco/issue/1688#comment-430734)
 
(8 intermediate revisions by 2 users not shown)
Line 24: Line 24:


== Summary ==
== 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 ==
== Owner ==
Line 31: Line 32:
This should link to your home wiki page so we know who you are.  
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
* Email: vpodzime@redhat.com
* Name: [[User:mauelsha| Heinz Mauelshagen (LVM)]]
* Email: heinzm@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> -->


== Current status ==
== Current status ==
* Targeted release: [[Releases/26 | Fedora 26 ]]  
* Targeted release: [[Releases/26 | Fedora 26 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1427113 #1427113]


== Detailed Description ==
== 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 (or Thin 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 ==
== 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 ==
== Scope ==
* Proposal owners:
* 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 -->
* 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?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engeneering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: N/A <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 92: Line 94:
-->
-->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
1. Try LVM (or Thin LVM) installation with some RAID level specified for the newly created VG.
N/A (not a System Wide Change)  
 
2. Reboot.
 
3. Check that the newly created LVs have the specified RAID level. (e.g. using "sudo lvs -o +lv_layout")


== User Experience ==
== 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. -->
<!-- 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 -->
<!-- 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 ==
== Dependencies ==
Line 104: Line 110:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- 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 ==
== 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.  -->
<!-- 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. -->
<!-- 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? -->
<!-- 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 ==
== Documentation ==
Line 120: Line 126:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
 
Documentation will be covered in the Installation Guide.


== Release Notes ==
== Release Notes ==
Line 128: Line 135:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
TBD


[[Category:ChangePageIncomplete]]
[[Category:ChangePageIncomplete]]

Latest revision as of 05:38, 17 March 2017


Anaconda LVM RAID

Summary

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

Owner

Current status

Detailed Description

In the current situation when a user chooses LVM (or Thin 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: N/A
  • 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 (or Thin 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

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/AnacondaLVMRAID&oldid=488067"