On Mon, Aug 14, 2017 at 2:48 AM, Chen CH Ji <jiche...@cn.ibm.com> wrote:
> In fixing bug 1704798, there's a proposed patch > https://review.openstack.org/#/c/485121/7 > but we stuck at http_connection_timeout and timeout value in keystoneauth1 > and keystonemiddle repo > > basically we want to reuse the keystone_auth section in nova.conf to avoid > create another section so we can > use following to create a session > > sess = ks_loading.load_session_from_conf_options(CONF, > 'keystone_authtoken', auth=context.get_auth_plugin()) > > any comments or we have to create another section and configure it anyway? > thanks > > > Best Regards! > > Kevin (Chen) Ji 纪 晨 > > Engineer, zVM Development, CSTL > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com > Phone: +86-10-82451493 <+86%2010%208245%201493> > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, > Beijing 100193, PRC > > __________________________________________________________________________ > 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 > > I think reusing the keystone_authtoken config is a bad idea. keystone_authtoken contains the configuration for the auth_token middleware so this is what we keystone developers expect it to be used for. A deployment may have different security needs for the auth_token middleware vs checking quotas in which case they'll need different users or project for the auth_token middleware and quota checking. And even if we don't need it now we might need it in the future, and it's going to create a lot of work going forward to rearchitect. If a deployer wants to use the same authentication for both auth_token middleware and the proxy, they can create a new section with the config and point both keystone_authtoken and quota checking to it (by setting the auth_section). -- - Brant
__________________________________________________________________________ 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