Cannot force v2password auth plugin

[Jamie Lennox]

To make OSC do v2 authentication with the keystone V3 APIs (which is necessary short term to update devstack to v3 everywhere) we need to force the use of the v2password plugin, otherwise OSC defaults to v3 auth.

The keystoneclient v2password plugin registers the project scoping parameters as --os-tenant-id and --os-tenant-name because this is what they were called in v2. I do not think that the v2 password plugin should look for the --os-project-id and --os-project-name params because the intended use case of plugins is that you would specify a plugin name and know what arguments that plugin took, and 'projects' didn't exist in v2.

In OSC we register all the options for all the plugins on the system at initialize time, this is something we should fix anyway. During this process we register the --os-tenant-X options with an os_project_X destination (attribute name on parsed namespace object) from the generic password plugin before the v2password plugin can register it to the os_tenant_X attribute. I suspect this would change based on the ordering of plugins but i haven't tried this.

When os-client-config is told that it should look up the auth parameters for v2password it tries to find the tenant_X parameters on the parsed namespace and fails because those values have been saved to the project_X parameters. It therefore returns auth options that don't include the tenant scope.

OSC then tries to validate the options it receives from OCC and because there is no project_X or domain_X scoping information it fails validation.

The best solution to this is to not register every plugin to argparse and use the keystoneclient.auth.register_argparse_arguments method - however we've had that debate in the past. Hopefully this is something we can fix in keystoneauth/some loading library in future. In the meantime i'm proposing that we should simply duplicate the project_X parameters on the parsed namespace to tenant_X parameters so that if a v2 plugin is requested then the values will be there and it should make no difference to the operation of v3 plugins.

[Terry Howe (thowe-g)]

--os-auth-type doesn't work for this?

[Jamie Lennox (jamielennox)]

I can force the auth plugin to use with --os-auth-type but all the plugins still register their own options into the argparser. This means when the v2password comes along and it expected to find the options.tenant_id parameter it's actually been saved as options.project_id. There are also scope assertions that only work for the v3 or generic plugins that prevent the v2password from being allowed to load.

Hopefully the review (which for some reason wasn't linked [1]) will make the problems clearer.

[1] https://review.openstack.org/#/c/187033/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/187033
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=3ae247fdceac0e2c7bb6160f9ffefc4ad5d8da29
Submitter: Jenkins
Branch: master

commit 3ae247fdceac0e2c7bb6160f9ffefc4ad5d8da29
Author: Jamie Lennox <email address hidden>
Date: Sun May 31 13:37:50 2015 +1000

    Set tenant options on parsed namespace

    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