[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