Hide Forgot
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
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 @.
see https://bugzilla.redhat.com/show_bug.cgi?id=1516035#c2
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.