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 1378829 - vgrename does not support --select|-S option
Summary: vgrename does not support --select|-S option
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-23 10:45 UTC by Roman Bednář
Modified: 2021-09-03 12:40 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-15 07:46:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Roman Bednář 2016-09-23 10:45:30 UTC 
Description of problem:

This bug is based on bug #979121. 

vgrename does not support --select|-S option.
It can still be used by using uuid directly, but the select option is supposed to work. User even gets a hint to use it when vgrename is used in a wrong way.


How reproducible:
always

Steps to Reproduce:
(Wrong arguments here on purpose, we get a hint to use select option)
# vgrename vg_clone vg_new
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 on /dev/sdb was already found on /dev/sda.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 prefers device /dev/sda because device was seen first.
  Multiple VGs found with the same name: skipping vg_clone
  Use --select vg_uuid=<uuid> in place of the VG name.

# vgs -o +vg_uuid
  WARNING: Not using lvmetad because duplicate PVs were found.
  WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
  WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 on /dev/sdb was already found on /dev/sda.
  WARNING: PV 2qbsZ3-DWP7-3j7x-wFuV-tlat-Oe9z-iaKPh7 prefers device /dev/sda because device was seen first.
  VG            #PV #LV #SN Attr   VSize   VFree   VG UUID                               
  rhel_virt-283   1   2   0 wz--n-   7.79g  40.00m TrH3Io-2XLs-omfO-J1K9-ZRoq-T2QG-TzwmuZ
  vg_clone        1   0   0 wz--n- 972.00m 972.00m 6Hwtsh-tkgf-oV2G-CqZs-0Kgr-QBgj-tL3EoN
  vg_clone        1   0   0 wz--n-  40.00g  40.00g xjv8tG-XDO0-PGZZ-4wGK-whMq-KOa3-5PUtMv

# vgrename --select vg_uuid=6Hwtsh-tkgf-oV2G-CqZs-0Kgr-QBgj-tL3EoN vg_clone vg_renamed
vgrename: unrecognized option '--select'
  Error during parsing of command line.

Actual results:
vgrename: unrecognized option '--select'
  Error during parsing of command line.

Expected results:
command should pass with select option

Additional info:
The vgrename uses process_each_vg so it uses common code which also includes support for "-S|--select". The only issue here is that vgrename doesn't have that argument registered with the vgrenamen command (which is easy to add). However, in this case, we need to be sure that the select always selects one VG, not more (...and the command should fail if the result of selection gives us more items - I'm not sure now if we have this check or not within the process_each_* code if used together with -S|--select, but if yes, it should be easy to switch vgrenamen into using -S now.)
-prajnoha
Comment 2 David Teigland 2016-09-23 14:07:02 UTC 
Commands that can process "all VGs" are natural to use with --select, and commands that process one positional arg (VG, LV or PV) are fairly easy also.  But, commands with multiple positional args like 'vgrename X Y' are tricky to convert to --select.  With 'vgrename --select uuid=X Y', the new name in position 2 changes to position 1.

I'm using a new method to represent these situations in the command definitions I've been working on, and we may be able to use a similar scheme in the commands themselves.  I'm using a reserved word "Select" in the location of a required positional arg to mean that the positional arg is optional if the --select option is used.  i.e. "lvchange [options] VG|LV|Tag|Select ..." means that positional arg 1 is required unless options contains --select.  This is easier when defining commands because I'm dealing with reserved symbols anyway, and not real names.  In the case of real commands we'd need a way to represent Select, similar to the way we represent Tag in the positional arg with @.
Comment 3 David Teigland 2018-04-03 16:36:47 UTC 
see https://bugzilla.redhat.com/show_bug.cgi?id=1516035#c2
Comment 5 RHEL Program Management 2020-12-15 07:46:25 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.