I do not believe the auth_uri entry is necessary at all - I've not used it for testing and I can't see it referenced anywhere in keystoneclient/auth/* (e.g the client plugins which consume this section)
I believe the project_name and project_domain_id in the docs is wrong - in fact I'm pretty sure including those will break completely with the default setting of deferred_auth_method=trusts, because we want the client to get a trust-scoped token, and it can't be scoped to both a trust and the project.
Testing proves that - keystone gives "Authentication cannot be scoped to multiple targets. Pick one of: project, domain, trust or unscoped" if you try the above.
So, we've got some docs errors to work out - thanks for highlighting them.
@Matt:
So, I did some more testing, and it appears that using an unversioned auth_url, and the generic "password" auth_plugin does the right thing:
[trustee] 192.168. 1.14:5000
auth_plugin = password
auth_url = http://
username = heat
password = foobar
user_domain_id = default
I do not believe the auth_uri entry is necessary at all - I've not used it for testing and I can't see it referenced anywhere in keystoneclient/ auth/* (e.g the client plugins which consume this section)
I believe the project_name and project_domain_id in the docs is wrong - in fact I'm pretty sure including those will break completely with the default setting of deferred_ auth_method= trusts, because we want the client to get a trust-scoped token, and it can't be scoped to both a trust and the project.
Testing proves that - keystone gives "Authentication cannot be scoped to multiple targets. Pick one of: project, domain, trust or unscoped" if you try the above.
So, we've got some docs errors to work out - thanks for highlighting them.