Make version optional on auth_url

[Terry Howe]

It would be awesome if the version was optional on the auth_url and it was filled in based on the auth_type. For instance auth_url was set to http://127.0.01:5000/ and if v2 auth was selected, a v2.0 was appended automatically. This would make it easier to change authentication methods without changing auth_url.

[Terry Howe (thowe-g)]

This really may be a keystoneauth issue.

[Dolph Mathews (dolph)]

This is exactly how discovery already works, but it's certainly not implemented everywhere, and this is a great opportunity to identify the remaining pieces where discovery support still needs to be added (Jamie?).

[Dean Troyer (dtroyer)]

I don't think OSC has any requirement for a version in the auth URL.

[Colleen Murphy (krinkle)]

I think OSC and KSA have the same behavior here:

http://paste.openstack.org/show/494118/
http://paste.openstack.org/show/494119/

If the 'password' auth_type is used, it doesn't need a version in the URL and it uses service discovery to do the right thing. If a versioned auth_type is used, it does expect the version to already be in the URL.

Given that the ability to use a URL without a version already exists as long as you use the 'password' auth_type, is this still a desired feature?

[Brian Curtin (brian.curtin)]

Yes. It should work regardless.

[Brian Curtin (brian.curtin)]

...errrrr, I missed that this is reported to a bunch of other projects, thought this was just to SDK. Forcing people to use a specific type of auth to get that functionality doesn't cut it on my end.

[OpenStack Infra (hudson-openstack)]

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

[Jamie Lennox (jamielennox)]

'password' auth is the default that is recommended and works like this (actually it works more correctly because it queries keystone's version discovery page rather than assume you use the /v2.0 suffix). v2password and v3password are essentially the backends to password to do the work[1]. They are available via the CLI because people wanted to use them and they are useful in certain situations, but you would have to essentially opt in to use them. v2Token and v3Token will fall into the same category here.

The comment 'if v2 was selected' or 'forcing people to use a specific type of auth' is not really how this works. You always have to pick a plugin (and in CLI we can fall back to a default) and we recommend people use password and OSC and OCC both default to this. By picking v2password auth you are acknowledging you want to use a specific v2 endpoint and so I don't think specifying the versioned endpoint is a burden here.

[1]https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/generic/password.py#L43-L64

[OpenStack Infra (hudson-openstack)]

Change abandoned by Colleen Murphy (<email address hidden>) on branch: master
Review: https://review.openstack.org/306922
Reason: I agree with Jamie's comments on the bug report that this is not really needed, and that using a versioned auth type means opting into using a versioned URL.

[Steve Martinelli (stevemar)]

I'm agreeing with Colleen and Jamie here, this sounds invalid for keystoneauth.

[Steve Martinelli (stevemar)]

Marking as invalid for osc, we get our auth from o-c-c and keystoneauth

[Matthew Edmonds (edmondsw)]

I've confirmed that this is broken in openstacksdk 0.9.5. The same environment variables that work for openstackclient (version 3.2.0) without including version in the OS_AUTH_URL do not work with openstacksdk.

[Brian Curtin (brian.curtin)]

openstacksdk doesn't use environment variables