Improve domain related defaults when using v3 identity API

[Nathan Kinder]

In version 0.4.0 of python-openstackclient, the following command works fine:

openstack --os-identity-api-version 3 --os-auth-url http://rhos.rhosdom.test:35357/v3 --os-username admin --os-password Secret12 --os-project-name admin user list

This results in an authentication request of:

--------------------------------------------
{
    "auth": {
        "scope": {
            "project": {
                "domain": {
                    "id": "default"
                },
                "name": "admin"
            }
        },
        "identity": {
            "password": {
                "user": {
                    "domain": {
                        "id": "default"
                    },
                    "password": "XXXXXXXX",
                    "name": "admin"
                }
            },
            "methods": [
                "password"
            ]
        }
    }
}
--------------------------------------------

If I then install python-openstackclient from git and attempt the same command, it fails with a 400 error:

DEBUG: keystoneclient.session Request returned failure status: 400
ERROR: openstack Authentication failure: Expecting to find domain in project - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400)

The request looks like this:

--------------------------------------------
{
    "auth": {
        "scope": {
            "project": {
                "name": "admin"
            }
        },
        "identity": {
            "password": {
                "user": {
                    "password": "XXXXXXXX",
                    "name": "admin"
                }
            },
            "methods": [
                "password"
            ]
        }
    }
}
--------------------------------------------

The domain is no longer filled in when one is not explicitly specified as a command-line option. If I specify '--os-user-domain-id default --os-project-domain-id default', then the command works. Was this an intentional non-backwards compatible change?

[Dean Troyer (dtroyer)]

This may have happened when the auth option checking was shifted to the auth plugins from ksc, it is certainly not intentional.

[Steve Martinelli (stevemar)]

Are the functional tests passing? It should have v3 specific tests. Weird.

[Steve Martinelli (stevemar)]

I think this was caused when we removed the defaulting domain scope/user behaviour from OSC, in favor of getting all of our auth command line options from keystoneclient.

Defaulting the user and project domain id's back to 'default' should do the trick.

Refer to https://review.openstack.org/#/c/135152/

[Steve Martinelli (stevemar)]

Also, the functional tests are passing because they specify OS_USER_DOMAIN_ID and OS_PROJECT_DOMAIN_ID specifically.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Steve Martinelli (<email address hidden>) on branch: master
Review: https://review.openstack.org/135152

[Steve Martinelli (stevemar)]

Current support:

If a user is switching OS_IDENTITY_API_VERSION from 2.0 to 3, then the user will have to add:

  OS_USER_DOMAIN_NAME || OS_USER_DOMAIN_ID && OS_PROJECT_DOMAIN_NAME || OS_PROJECT_DOMAIN_ID

Or as optional arguments in the command line.

The intended solution (in m7) is to default OS_IDENTITY_API_VERSION to 3, and default OS_USER_DOMAIN_ID && OS_PROJECT_DOMAIN_ID to 'default'.

[Andrey Larionov (anlarionov)]

When you expecting release with this fix? It's serious usability problem in compare to old clients. Our users constantly forget to specify this defaults and bother support engineers.

[Terry Howe (thowe-g)]

It would be nice if osc would attempt to guess the release based on the url. If auth_url.endswith('v2.0) then identity_version = 2. It is always confusing with auth fails because you give a v3 authurl and you don't specify identity version of v3. This proposed change would have the same issue for users that specify a v2.0 auth url and don't specify identity version v2.

[Steve Martinelli (stevemar)]

Hey Andrey,

So we've been trying to approach a fix for this in a few different way, but I'd be very interested to see how your clients are using this. What environment variables are they setting (if any)? Which don't they want to set? Are they using non-default domains? Stuff like that... We could solve this in a few ways, but a real user concern would help guide us along.

[Steve Martinelli (stevemar)]

Andrey, can you take a look at https://review.openstack.org/#/c/135152/ and confirm if it would help the usability you've been seeing? It will essentially default OS_USER_DOMAIN_ID and OS_PROJECT_DOMAIN_ID to 'default'.

If OS_USER_DOMAIN_ID or OS_USER_DOMAIN_NAME or OS_PROJECT_DOMAIN_ID or OS_PROJECT_DOMAIN_NAME is provided, then it'll attempt to authenticate with that.

[Andrey Larionov (anlarionov)]

Thanks Steve. This patch definitely solve our problem

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/135152
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=1d75edb1678e42a36879245c6ebac69c14a5f965
Submitter: Jenkins
Branch: master

commit 1d75edb1678e42a36879245c6ebac69c14a5f965
Author: Steve Martinelli <email address hidden>
Date: Mon Nov 17 21:35:30 2014 -0500

    Default user domain id and project domain id

    If either of OS_USER_DOMAIN_ID or OS_USER_DOMAIN_NAME are present
    then we don't tinker with anything. Otherwise, we should set
    the USER_DOMAIN_ID to 'OS_DEFAULT_DOMAIN', as this provides a better UX,
    since the end user doesn't have to specify these arguments.

    Same logic applies for OS_PROJECT_DOMAIN_ID.

    Closes-Bug: #1385338

    Change-Id: I8a4034c16a1dd50d269f809abab8e960d5de20f7