This also occurs with --os-auth-type password, forcing a bypass of OSC's broken endpoint hack. It is actually a two-part problem:
1) There appears to be a design choice in Keystone client. In keystoneclient/auth/identity/generic/base.py _do_create_plugin() line 151 (in my tree) we see:
if (_discover.version_match((2,), version) and self._has_domain_scope): # NOTE(jamielennox): if there are domain parameters there # is no point even trying against v2 APIs. continue
It appears that KSC assumes that you want v3 whenever domain args are present.
2) The user's selection of v2 is not enforced because OSC sets a default auth-type of osc_password. That really needs to be removed so discovery can work properly and --os-identity-api-version is honored.
In short, the obvious workaround is to not set domain args if you want to use v2 auth.
This also occurs with --os-auth-type password, forcing a bypass of OSC's broken endpoint hack. It is actually a two-part problem:
1) There appears to be a design choice in Keystone client. In keystoneclient/ auth/identity/ generic/ base.py _do_create_plugin() line 151 (in my tree) we see:
if (_discover. version_ match(( 2,), version) and
self. _has_domain_ scope):
# NOTE(jamielennox): if there are domain parameters there
# is no point even trying against v2 APIs.
continue
It appears that KSC assumes that you want v3 whenever domain args are present.
2) The user's selection of v2 is not enforced because OSC sets a default auth-type of osc_password. That really needs to be removed so discovery can work properly and --os-identity- api-version is honored.
In short, the obvious workaround is to not set domain args if you want to use v2 auth.