If one does not set in "local_settings.py":
OPENSTACK_API_VERSIONS = {
"identity": 2.0
}
django_openstack_auth falls back to version 2.0, and horizon to version 3.
This leads to weird behaviour.
When the keystone API is version 2.0 and that horizon falls back on to using 3 you get this:
- In the dashboard, as admin, add your user to a project.
- Log out and in
- You can select the project
- select the project you are admin on, and go to the admin tab
- remove yourself from the project you added yourself previously.
- Log out and in
- You can still see the project from which you removed yourself but can't select it (it falls back to the one you realy belong to).
- You can still see yourself in the project via the shell command "keystone user-list --tenant <project_id>"
- the "keystone user-role-remove --user <user_id> --tenant <project_id> --role <role_id>" fails with the following message: "Cannot remove role that has not been granted" even though you can list yourself in it with the previous command.
We should have a coherent fall-back version.
The best would be a real detection of the API version and a fall-back if detection fails, but the fall-back should be coherent (same mechanism -> same module).
In order to be DRY (Don't Repeat Yourself), since horizon requires the django_openstack_auth, horizon should e.g. use "openstack_auth.utils.get_keystone_version()" in order to set horizon.openstack_dashboard.keystone.VERSIONS.preferred_version
instead of forcing it to a hard-coded 3, so we should have:
from openstack_auth import utils
VERSIONS = IdentityAPIVersionManager("identity", preferred_version=utils.get_keystone_version())
instead of:
VERSIONS = IdentityAPIVersionManager("identity", preferred_version=3)
but the method to use to have coherent fall-back is open to debate.
Definitely right that this is a problem. If we can get a patch up ASAP I'd consider it for the Havana RC, but I'm not gonna hold it as a blocker.