RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2083410 - storage role raid_level "striped" is not supported
Summary: storage role raid_level "striped" is not supported
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: rhel-system-roles
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 9.1
Assignee: Rich Megginson
QA Contact: Jakub Haruda
Michal Stubna
URL:
Whiteboard: role:storage
Depends On:
Blocks: 2083426 2098223
TreeView+ depends on / blocked
 
Reported: 2022-05-09 23:30 UTC by Rich Megginson
Modified: 2022-11-15 11:24 UTC (History)
8 users (show)

Fixed In Version: rhel-system-roles-1.19.2-1.el9
Doc Type: Bug Fix
Doc Text:
.The `storage` RHEL System Role now correctly supports striped and raid0 levels for LVM volumes The `storage` RHEL System Role previously incorrectly reported RAID levels `striped` and `raid0` as not supported for LVM volumes. This is now fixed and the role can now correctly create LVM volumes of all RAID levels supported by LVM: `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10`, `striped` and `mirror`.
Clone Of:
: 2083426 2098223 (view as bug list)
Environment:
Last Closed: 2022-11-15 10:23:47 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pkettman: needinfo+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github linux-system-roles storage pull 272 0 None open LVM RAID raid0 level support 2022-05-25 22:18:54 UTC
Red Hat Issue Tracker RHELPLAN-121496 0 None None None 2022-05-09 23:31:34 UTC
Red Hat Product Errata RHEA-2022:8117 0 None None None 2022-11-15 10:24:14 UTC

Description Rich Megginson 2022-05-09 23:30:26 UTC 
Description of problem:

The documentation for the storage role lists "striped" as a valid value for the "raid_level" option, but trying to use it gives an error:

blivet.errors.DeviceError: RAID level striped is an invalid value. Must be one of (raid10, raid1, raid4, linear, raid5, raid6, raid0)

We should either remove "striped" from the docs, or make "striped" an alias for "raid0" (if they are indeed the same thing).

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 David Lehman 2022-05-10 01:36:50 UTC 
The 'striped' level is in fact an alias for 'raid0' in blivet, but it is only there because the lvm tools use that as a level descriptor (and is therefore not supported for md raid). My recommendation is to fix the role docs by removing 'striped'. I think 'striped' is supported in blivet, but only for lvm raid, and I don't think there is any value in passing that inconsistency on to the role's users.
Comment 2 Rich Megginson 2022-05-10 14:55:29 UTC 
(In reply to David Lehman from comment #1)
> The 'striped' level is in fact an alias for 'raid0' in blivet, but it is
> only there because the lvm tools use that as a level descriptor (and is
> therefore not supported for md raid). My recommendation is to fix the role
> docs by removing 'striped'. I think 'striped' is supported in blivet, but
> only for lvm raid, and I don't think there is any value in passing that
> inconsistency on to the role's users.

According to Vojtech: https://github.com/linux-system-roles/storage/pull/271#issuecomment-1122031499

LVM supports only 'striped' for raid0 (and 'mirror' for raid1).

This is what the docs currently say: https://github.com/linux-system-roles/storage/#raid_level

"raid_level

When used with type: lvm it manages a volume group with a mdraid array of given level on it. Input disks are in this case used as RAID members. Accepted values are: linear, striped, raid0, raid1, raid4, raid5, raid6, raid10"

Can you use raid_level without `type: lvm`?  I guess we will have different lists of values depending on if the type is lvm or not?

"raid_level

When used with type: lvm it manages a volume group with a mdraid array of given level on it. Input disks are in this case used as RAID members. Accepted values are: linear, striped, mirror, raid4, raid5, raid6, raid10.
Wither other types (what other types?) the accepted values are: raid0, raid1, raid4, raid5, raid6, raid10.
"

or something like that?  I'm not really sure what to put here.
Comment 3 Vojtech Trefny 2022-05-11 07:13:46 UTC 
Looks like my comment on GitHub made it more confusing, sorry. LVM supports both striped/mirror and raid0/raid1. striped and mirror are legacy types and I'm not sure how different is striped from raid0 internally, but LVM still recognizes these as two different types of LVs and allows converting between them (same applies to mirror and raid1). But raid0 and raid1 should be preferred when creating a new LV and I agree with Dave that we should remove striped this from the documentation to make it less complicated for users. The problem is that blivet doesn't support creating "raid0" LVs, but that's an internal issue which needs to be fixed in blivet.
Comment 4 Rich Megginson 2022-05-16 14:32:32 UTC 
So is this all we need to do?


diff --git a/README.md b/README.md
index 04a895d..3565c8e 100644
--- a/README.md
+++ b/README.md
@@ -53,7 +53,7 @@ device node basename (like `sda` or `mpathb`), /dev/disk/ symlink
 ##### `raid_level`
 When used with `type: lvm` it manages a volume group with a mdraid array of given level
 on it. Input `disks` are in this case used as RAID members.
-Accepted values are: `linear`, `striped`, `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10`
+Accepted values are: `linear`, `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10`
 
 ##### `volumes`
 This is a list of volumes that belong to the current pool. It follows the
@@ -135,7 +135,7 @@ Specifies RAID level. LVM RAID can be created as well.
 "Regular" RAID volume requires type to be `raid`.
 LVM RAID needs that volume has `storage_pools` parent with type `lvm`,
 `raid_disks` need to be specified as well.
-Accepted values are: `linear` (N/A for LVM RAID), `striped`, `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10`
+Accepted values are: `linear` (N/A for LVM RAID), `raid0`, `raid1`, `raid4`, `raid5`, `raid6`, `raid10`


?
Comment 6 guazhang@redhat.com 2022-06-07 04:10:02 UTC 
rhel-system-roles-1.19.0-1.el9.noarch
5.14.0-105.el9.x86_64

test pass with tests_create_raid_pool_then_remove.yml
Comment 18 errata-xmlrpc 2022-11-15 10:23:47 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (rhel-system-roles bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:8117
Note You need to log in before you can comment on or make changes to this bug.