Hide Forgot
Description of problem: The way the tripleo heat templates currently deploy deploy OpenStack, the identity_uri and similar settings (such as auth_url in netron.conf) get set to the same value as what the keystone admin endpoint is created from. By default on the VIP on the ctlplane This is problematic, since the ctlplane primarily is a provisioning network. So if the keystone admin-endpoint reside on this network (human) openstack admins need to have access to this network from their workstations. Not ideal if it's an isolated provisioning network. If on the other hand, the KeystoneAdminApiNetwork is changed in the ServiceNetMap to point to e.g. the network the public API:s reside on, to make access for human admins easier, then all compute nodes etc, need to have access to this network. This because the same value will be set in {netron,nova,etc}.conf. Which is not ideal either. I would therefore propose that we set the configurations in nova.conf, neutron.conf, etc. to point to the VIP on the _internal_ network. This is after all internal communication. And then of course, we also need to make ha-proxy listen for the keystone admin port on the internal network as well. This way, the keystone admin endpoint can be configured independently to whatever is most suitable for the operators.
so, the keystone admin endpoint's network is already configurable via the ServiceNetMap parameter in t-h-t. The default is the ctlplane network but this can easily be changed to the internal_api network if the deployer needs this. We could, however, change the service's configuration to attemt to use the internal keystone endpoint instead of the admin though. this should be easier with services moving to keystone v3.
*** Bug 1294775 has been marked as a duplicate of this bug. ***
Sorry for comment #6, I didn't see the bug was ON_QA. Verified in OSP11.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3462