[openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option
Rabi Mishra
ramishra at redhat.com
Fri Jun 16 05:11:06 UTC 2017
Hi All,
As we know, 'deferred_auth_method=trusts' being the default, we use
trust_auth_plugin whenever a resource requires deferred_auth (any resource
derived from SignalResponder and StackResource). We also support
'deferred_auth_method=password' where 'X-Auth-User'/username and
'X-Auth-Key'/password is passed in the request header and we then store
them in 'user_creds' (rather than 'trust_id') to create a 'password'
auth_plugin when loading the stack with stored context for signalling. I
assume for this very reason we've the '--include-pass' option in heat cli.
However, when using keystone session(which is the default), we don't have
the above implemented with SessionClient (i.e to pass the headers). There
is a bug[1] and patch[2] to add this to SessionClient in the review queue.
Aslo, we don't have anything like '--include-pass' for osc.
I've noticed that 'deferred_auth_method=password' is broken and does not
work with keystone v3 at all. As we don't store the 'user_domain_id/name'
in 'user_creds', we can not even intialize the 'password' auth_plugin when
creating the StoredContext, as it would not be able to authenticate the
user without the user_domain[3].
I'm not sure whether this works with keystone v2 and anyone is using it or
not. Keeping in mind that heat-cli is deprecated and keystone v3 is now the
default, we've 2 options
1. Continue to support 'deferred_auth_method=passsword' option and fix all
the above issues.
2. Remove/deprecate the option in pike itlsef.
I would prefer option 2, but probably I miss some history and use cases for
it.
Thoughts?
[1] https://bugs.launchpad.net/python-heatclient/+bug/1665321
[2] https://review.openstack.org/435213
[3]
https://github.com/openstack/heat/blob/master/heat/common/context.py#L292
--
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170616/d61baca2/attachment.html>
More information about the OpenStack-dev
mailing list