Currently, we can get scoped token (domain scoped, project scoped)
as well as unscoped token.

When we use OSC to get a domain scoped token without explicitly set
domain information, the hint message show us we need to set a scoped
domain or project, but it miss that the parameters to be set in order
to get project or domain scoped token is not the same.

Thus, the hint message could be improved to make it more clear to
end user.

Change-Id: I94768c619b30be18737fec189ae6d81e81ba090d

Because of the way OSC registers all plugins together we end up
with os-tenant-X parameters being saved to the project-X attribute after
parsing. If you are using the v2 plugins directly then they and os-client-config
expect the tenant_X values and will assuming no scoping information if
they are not present.

Validating options for scope will also fail in this situation, not just
because the resultant auth dictionary is missing the tenant-X
attributes, but because OSC validates that either project or domain
scope information is present.

Fix this by just always setting the v2 parameters if the v3 parameters
are present. This will have no effect on the generic or v3 case but fix
the v2 case.

Expand validation to include the tenant options so it knows that v2
plugins are scoped.

Change-Id: I8cab3e423663f801cbf2d83106c671bddc58d7e6
Closes-Bug: #1460369

This adds a new option --os-cloud that allows the configuration values
for multiple clouds to be stored in a local file and selected with
a single option.

Internal option names have had 'os_' removed to be comptible with
the options returned from OpenStackConfig().get_one_cloud().

The config file is ~/.config/openstack/clouds.yaml:

Sample
------
clouds:
  devstack:
    auth:
      auth_url: http://192.168.122.10:35357/
      project_name: demo
      username: demo
      password: 0penstack
    region_name: RegionOne
  devstack:
     auth:
       auth_url: http://192.168.122.10:35357/
       project_name: demo
       username: demo
       password: 0penstack
     region_name: RegionOne

Co-Authored-By: Monty Taylor <mordred@inaugust.com>
Change-Id: I4939acf8067e44ffe06a2e26fc28f1adf8985b7d
Depends-On: I45e2550af58aee616ca168d20a557077beeab007

So we really weren't deferring the loading of client libs dadgummit,
do that for real where possible.  This shaves a couple of tenths off
the static import times.

Also defer as much import-time procesing as possible.  This is a little
ugly in api.auth but this also eliminates import of the auth plugins
until they are needed.

Change-Id: Ia11d4b9cf98231d37449103fc29101dc17afb009

Keystoneclient has always provided a TokenEndpoint plugin. Unfortunately
it uses a different option name for url, so subclass the original and
replace the options.

Change-Id: I7e16b31ceb9f75f1c1f6bfb224d8f8f353d06150

The plugin detection at the top of openstackclient.api.auth did not
detect the plugins at the bottom of that file because, surprise,
they had not been declared yet so the entry points were ignored.

Move both plugin subclasses into openstackclient.api.auth_plugin.

Fix a problem with the password callback that was otherwise made
worse with this change.

Closes-Bug: 1428912
Change-Id: Idc3b72534071e0013c8922884a8bc14137509a0f

It's actually breaking usage against HP Public Cloud.

Change-Id: Ic172786c6d1272798b768078a0bcf246f8d64ca8

When we got picky with the auth arguments we broke using help without
any auth config supplied.  This rearranges things a bit to do the argument
checking when the deferred auth request to Identity occurs so commands
that do not need auth have a chance to live short but useful lives.

Closes-Bug: #1399588
Change-Id: I8ceac491cf65e25eddb62ab2713f471fe686756d