[openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option
Rabi Mishra
ramishra at redhat.com
Wed Jun 21 06:38:26 UTC 2017
On Fri, Jun 16, 2017 at 7:03 PM, Zane Bitter <zbitter at redhat.com> wrote:
[snip]
>
> 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.
>>
>
> Am I right in thinking that any user (i.e. not just the [heat] service
> user) can create a trust? I still see occasional requests about 'standalone
> mode' for clouds that don't have Heat available to users (which I suspect
> is broken, otherwise people wouldn't be asking), and I'm guessing that
> standalone mode has heretofore required deferred_auth_method=password.
>
I think standalone heat is broken in more than one way based on my testing.
It seems changes have not kept up with heat standalone as 'authpassword'
middleware is broken[1] and we don't seem to pass correct domain details in
the rpc context. I've tried to fix them in[2].
I'm also not sure why heat standalone historically restricts
deferred_auth_method to 'password'[3]. It seems to work well with 'trusts'
though.
[1] https://bugs.launchpad.net/heat/+bug/1699418
[2] https://review.openstack.org/#/c/476014/
[3] https://github.com/openstack/heat/blob/master/devstack/lib/heat#L74
> So if we're going to remove the option then we should probably either
> officially disown standalone mode or rewrite the instructions such that it
> can be used with the trusts method.
>
> I think disowning the standalone mode would be an easier option. Probably
we should rewrite the instructions for it to be used with 'trusts' method
as it seems to work, unless I miss something. However, without any testing
at the gate we would surely break it from time to time.
> cheers,
> Zane.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170621/5558ea12/attachment.html>
More information about the OpenStack-dev
mailing list