Bug 1898690

Summary: parameter "crypt_type" should not be unique
Product: Red Hat Enterprise Linux 8 Reporter: Corey Marthaler <cmarthal>
Component: resource-agentsAssignee: Oyvind Albrigtsen <oalbrigt>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.4CC: agk, cfeist, cluster-maint, fdinitto
Target Milestone: rcKeywords: Triaged
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: resource-agents-4.1.1-76.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 15:11:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Corey Marthaler 2020-11-17 20:27:20 UTC
Description of problem:
I attempted to create a second crypt resource and got this error. I'm curious if we shouldn't just be defaulting to luks2 anyways. Are we really supporting the luks1 format in a cluster? Anyways, it certainly shouldn't be a unique attr.


From the resource-agent:
<parameter name="crypt_type" unique="1" required="1">
<longdesc lang="en">
Encryption (device) type (e.g. "luks" or "luks2").


[root@host-093 ~]# pcs resource create crypt2 --force --group HA_STSRHTS130852 ocf:heartbeat:crypt crypt_dev="luks_lv2" crypt_type=luks2 key_file=/etc/luks_key_file encrypted_dev=d58f7a61-18bb-47aa-84fe-d82998cfc930

Warning: Value 'luks2' of option 'crypt_type' is not unique across 'ocf:heartbeat:crypt' resources. Following resources are configured with the same value of the instance attribute: 'crypt1'


Version-Release number of selected component (if applicable):
Name        : resource-agents
Version     : 4.1.1
Release     : 74.el8
Architecture: x86_64
Install Date: Tue 17 Nov 2020 09:43:50 AM CST
Group       : System Environment/Base
Size        : 1506675
License     : GPLv2+ and LGPLv2+
Signature   : (none)
Source RPM  : resource-agents-4.1.1-74.el8.src.rpm
Build Date  : Wed 11 Nov 2020 03:03:44 AM CST

Comment 1 Oyvind Albrigtsen 2020-11-24 11:28:48 UTC
https://github.com/ClusterLabs/resource-agents/pull/1584

Comment 4 Corey Marthaler 2020-12-01 23:49:21 UTC
Fix verified in the latest rpm resource-agents-4.1.1-80.el8.x86_64.

I was able to create many gfs+crypt+lvm resource groups all using the same crypt_type now.


/tmp/luks_key_file -> host-073:/etc/luks_key_file
/tmp/luks_key_file -> host-092:/etc/luks_key_file
/tmp/luks_key_file -> host-093:/etc/luks_key_file
Creating VG STSRHTS130851 out of /dev/sdf2 /dev/sdf1 /dev/sdc2
Creating HA striped LV(s) and gfs2 filesystems on VG STSRHTS130851
        lvcreate --yes --activate sy --type striped -L 8G -i 2 -n lv STSRHTS130851
cryptsetup luksFormat /dev/STSRHTS130851/lv --type luks2 --key-file=/etc/luks_key_file
LUKS_UUID=d80704d1-b15f-4207-9df8-7eaf7ae5a2e8
cryptsetup luksOpen /dev/STSRHTS130851/lv luks_lv1 --key-file=/etc/luks_key_file
        Creating gfs2 filesystem
        mkfs.gfs2 -j 3 -J 32 -t STSRHTS13085:STSRHTS130851-lv /dev/mapper/luks_lv1 -O
cryptsetup luksClose luks_lv1


pcs resource create lv1 --group HA_STSRHTS130851 ocf:heartbeat:LVM-activate lvname="lv" vgname="STSRHTS130851" activation_mode=shared vg_access_mode=lvmlockd
pcs resource create crypt1 --force --group HA_STSRHTS130851 ocf:heartbeat:crypt crypt_dev="luks_lv1" crypt_type=luks2 key_file=/etc/luks_key_file encrypted_dev=d80704d1-b15f-4207-9df8-7eaf7ae5a2e8
pcs resource create fs1 --group HA_STSRHTS130851 Filesystem device="/dev/mapper/luks_lv1" directory="/mnt/fs1" fstype="gfs2" "options=noatime" op monitor interval=10s
pcs resource clone HA_STSRHTS130851
Creating VG STSRHTS130852 out of /dev/sdc1 /dev/sdd2 /dev/sdd1
Creating HA striped LV(s) and gfs2 filesystems on VG STSRHTS130852
        lvcreate --yes --activate sy --type striped -L 8G -i 2 -n lv STSRHTS130852
cryptsetup luksFormat /dev/STSRHTS130852/lv --type luks2 --key-file=/etc/luks_key_file
LUKS_UUID=ef277de5-8163-49c2-89dd-2d3e24e6c852
cryptsetup luksOpen /dev/STSRHTS130852/lv luks_lv2 --key-file=/etc/luks_key_file
        Creating gfs2 filesystem
        mkfs.gfs2 -j 3 -J 32 -t STSRHTS13085:STSRHTS130852-lv /dev/mapper/luks_lv2 -O
cryptsetup luksClose luks_lv2


pcs resource create lv2 --group HA_STSRHTS130852 ocf:heartbeat:LVM-activate lvname="lv" vgname="STSRHTS130852" activation_mode=shared vg_access_mode=lvmlockd
pcs resource create crypt2 --force --group HA_STSRHTS130852 ocf:heartbeat:crypt crypt_dev="luks_lv2" crypt_type=luks2 key_file=/etc/luks_key_file encrypted_dev=ef277de5-8163-49c2-89dd-2d3e24e6c852
pcs resource create fs2 --group HA_STSRHTS130852 Filesystem device="/dev/mapper/luks_lv2" directory="/mnt/fs2" fstype="gfs2" "options=noatime" op monitor interval=10s
pcs resource clone HA_STSRHTS130852
Creating VG STSRHTS130853 out of /dev/sdb2 /dev/sdb1 /dev/sde2
Creating HA striped LV(s) and gfs2 filesystems on VG STSRHTS130853
        lvcreate --yes --activate sy --type striped -L 8G -i 2 -n lv STSRHTS130853
cryptsetup luksFormat /dev/STSRHTS130853/lv --type luks2 --key-file=/etc/luks_key_file
LUKS_UUID=8cc87847-ec38-403a-81ab-4b0e79586a1b
cryptsetup luksOpen /dev/STSRHTS130853/lv luks_lv3 --key-file=/etc/luks_key_file
        Creating gfs2 filesystem
        mkfs.gfs2 -j 3 -J 32 -t STSRHTS13085:STSRHTS130853-lv /dev/mapper/luks_lv3 -O
cryptsetup luksClose luks_lv3


pcs resource create lv3 --group HA_STSRHTS130853 ocf:heartbeat:LVM-activate lvname="lv" vgname="STSRHTS130853" activation_mode=shared vg_access_mode=lvmlockd
pcs resource create crypt3 --force --group HA_STSRHTS130853 ocf:heartbeat:crypt crypt_dev="luks_lv3" crypt_type=luks2 key_file=/etc/luks_key_file encrypted_dev=8cc87847-ec38-403a-81ab-4b0e79586a1b
pcs resource create fs3 --group HA_STSRHTS130853 Filesystem device="/dev/mapper/luks_lv3" directory="/mnt/fs3" fstype="gfs2" "options=noatime" op monitor interval=10s
pcs resource clone HA_STSRHTS130853
pcs constraint order start locking-clone then HA_STSRHTS130853-clone



[root@host-073 ~]# pcs status
Cluster name: STSRHTS13085
Cluster Summary:
  * Stack: corosync
  * Current DC: host-093 (version 2.0.4-6.el8-2deceaa3ae) - partition with quorum
  * Last updated: Tue Dec  1 17:44:38 2020
  * Last change:  Tue Dec  1 15:40:53 2020 by root via cibadmin on host-073
  * 3 nodes configured
  * 36 resource instances configured

Node List:
  * Online: [ host-073 host-092 host-093 ]

Full List of Resources:
  * fence-host-073      (stonith:fence_xvm):     Started host-073
  * fence-host-092      (stonith:fence_xvm):     Started host-092
  * fence-host-093      (stonith:fence_xvm):     Started host-093
  * Clone Set: locking-clone [locking]:
    * Started: [ host-073 host-092 host-093 ]
  * Clone Set: HA_STSRHTS130851-clone [HA_STSRHTS130851]:
    * Started: [ host-073 host-092 host-093 ]
  * Clone Set: HA_STSRHTS130852-clone [HA_STSRHTS130852]:
    * Started: [ host-073 host-092 host-093 ]
  * Clone Set: HA_STSRHTS130853-clone [HA_STSRHTS130853]:
    * Started: [ host-073 host-092 host-093 ]

Comment 6 errata-xmlrpc 2021-05-18 15:11:15 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 (resource-agents 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/RHBA-2021:1736