On Fri, Jun 16, 2017 at 7:03 PM, Zane Bitter <zbit...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Rabi Mishra
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
