Image building with --all is broken

[Ben Nemec]

Using the latest master branch, it is not possible to use --all to build all images. It fails like this:

$ openstack overcloud image build --all
[help output]
openstack overcloud image build: error: one of the arguments --all --type --builder is required

This is obviously bogus. It turns out that it is caused by a recent designateclient commit: https://review.openstack.org/#/c/324002/ The --all-projects option conflicts with our --all due to argparse abbreviation functionality.

According to the OSC team, those options should not have been added globally, but should be limited in scope to just the designate commands. As I understand it, this may very well break other OSC commands as well because --all and --all-projects are not uncommon option names.

[Ben Nemec (bnemec)]

Since we don't actually need designateclient on the undercloud, the simplest workaround for tripleo is probably to `rpm -e --nodeps python-designateclient` before building images.

[Alan Pevec (apevec)]

RFE for OSC: warning when options conflict

[Steve Martinelli (stevemar)]

I think this is related to bug 1503618

See https://review.openstack.org/#/q/status:merged+project:openstack/cliff+branch:master+topic:jd/bug1503618-abbrev for details

[Ben Nemec (bnemec)]

I've proposed a revert of the change in designateclient: https://review.openstack.org/#/c/333518/

[Dean Troyer (dtroyer)]

The problem of argparse partial matching is well known, and is almost always a conflict between OSC global and command-level options parsers. Plugins registering globals outside the plugin-specific (and namespaced) options were not anticipated and thus not documented as a risky move. We will do that now. FWIW, this is also one reason most global OSC options are prefixed with '--os-'.

To follow up Ben's comment above, rather than registering global options, designateclient needs to register those options on each command. Identity v3 has a similar issue and provides a good design pattern for this in how the domain options are handled in a common module.

Testing for option conflicts is going to have to be done in OSC functional tests when all known plugins are installed/loaded. Each plugin will need to implement a callable test to check its own commands and options. This will be an extension of the existing command resource checking already done in the OSC repo. We may ask plugins to also run that job so conflicts are detected before merges happen.

[Ben Nemec (bnemec)]

The revert has merged to designateclient, so this is resolved for TripleO. Thanks everybody!