Ambiguous option error shouldn't appear when arguments are not ambiguous

[Eric Harney]

$ cinder create --snapshot e23dc0a3-de01-4350-b6b6-b26f48a10c85 1
usage: cinder create [--snapshot-id <snapshot-id>]
                     [--source-volid <source-volid>] [--image-id <image-id>]
                     [--display-name <display-name>]
                     [--display-description <display-description>]
                     [--volume-type <volume-type>]
                     [--availability-zone <availability-zone>]
                     [--metadata [<key=value> [<key=value> ...]]]
                     <size>
error: ambiguous option: --snapshot could match --snapshot-id, --snapshot_id
Try 'cinder help create' for more information.

These two options are the same argument, just with different spellings. Can we set argparse to "hide" the second option, snapshot_id, so that it matches more sensibly?

[Alejandro Emanuel Paredes (alejandro-e-paredes)]

Hi Eric, I've tried to figuring out how to fix this behaviour, but unfortunately I couldn't.
Do we want to avoid that argparse match the second parameter (snapshot_id) when it receives "snapshot"? or hide that parameter in the error message?
Txs!

alejandro

[Alejandro Emanuel Paredes (alejandro-e-paredes)]

Another thought...
I think that hide arguments is not a proper solution due to the args parser should rise the ambiguity error when there is a true ambiguity between different arguments that starts with similar characters, and this is not this case. Here, we have the same argument written in two different ways.
Why we don't consider in removing the "snapshot_id" and all the duplicated arguments?
I've found similar behaviours in other clients like Nova and Keystone...is this a matter of backward compatibility?
Txs!

[Eric Harney (eharney)]

> I've found similar behaviours in other clients like Nova and Keystone...is this a matter of backward compatibility?

Yes, this is to support the older format of arguments that used underscores, before we standardized on using dashes.

[Juan Manuel Ollé (juan-m-olle)]

Eric,

What you want is not allow, we could ask argparse to include:
  - Allow a new parameter in "add_argument" called allow_abbrev to only allow the --snapshot-id for abbreviation
  - Allow exact mach with parameter and add --snapshot as argument (I think is the best)

The other solution is to override the
           def _get_option_tuples(self, option_string):
from argparse and in the case more than one argument matches with the abbreviation, we could remove from the list all items with help == SUPPRESS, in that case I think we will get the desired behaviour (but I think is a little ugly)

What do you think?

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/87285

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/87285
Committed: https://git.openstack.org/cgit/openstack/python-cinderclient/commit/?id=2b182c7e34b433589319b3d15d92ce53fa3dc814
Submitter: Jenkins
Branch: master

commit 2b182c7e34b433589319b3d15d92ce53fa3dc814
Author: Juan Manuel Olle <email address hidden>
Date: Mon Apr 14 11:53:10 2014 -0300

    Ambiguous option error should not appear if Arg is SUPPRESS

    Due to backward compatibility there are arguments hidden.
    For example:

    --tenant-id and --tenant_id

    On those case the abbreviation mechanism if a user enter
    --tenant throw that there is an ambiguity but the helps only
    show --tenant-id as an optional argument.
    This change remove this ambiguity if one of them is hidden.

    Change-Id: I413f1ebafc68b3e02b5abadce1608e6d48207b01
    Closes-Bug: #1252457